SRX

Expand all | Collapse all

Classifying Skype traffic

Jump to Best Answer
  • 1.  Classifying Skype traffic

    Posted 07-06-2019 06:07
    Hi,

    I’ve seen a lot of articles about using an SRX to prioritise traffic ... I can see if you know the UDP / TCP ports this works well.

    What if you have something like Skype with a vast range of ports in use? Anyway I can mark the traffic in Windows using a GPO etc to mark a DSCP value ... then tell the juniper to prioritise based on a certain dscp value?

    Thanks


  • 2.  RE: Classifying Skype traffic

     
    Posted 07-07-2019 04:13

    If you have the license enabled the SRX AppID can identify Skype traffic directly and engage AppCoS to apply policing and dscp values.

     

    https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-application-qos.html

     



  • 3.  RE: Classifying Skype traffic

    Posted 07-07-2019 04:38
    Thanks

    I might be misreading this, but this article seems to indicate the SRX345 wouldn’t need an extra license?

    https://kb.juniper.net/InfoCenter/index?page=content&id=KB33165&actp=RSS

    Would I be right in thinking the base license for a SRX345 provides this feature out of the box?

    Thanks


  • 4.  RE: Classifying Skype traffic
    Best Answer

     
    Posted 07-07-2019 05:26

    Hello,

     

    Yes, as the article mentions there is no license enforcement. However, customers should purchase the license that includes AppSecure for the right to use the feature.

     

    This means you can update the app-id signatures and configure the app-firewall without the firewall throwing an error.

     

    Regards,

     

    Vikas

     

     



  • 5.  RE: Classifying Skype traffic

    Posted 07-07-2019 06:56
    Thanks very much


  • 6.  RE: Classifying Skype traffic

     
    Posted 06-23-2020 05:13

    @spuluka wrote:

    If you have the license enabled the SRX AppID can identify Skype traffic directly and engage AppCoS to apply policing and dscp values.

     

    https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-application-qos.html

     

     

    Hi Steve. To enable this for Teams, is it simply a case of creating a permit Application Firewall rule for Teams? For example:-

     

    [edit security]
    +   application-firewall {
    +       rule-sets Teams {
    +           rule Teams {
    +               match {
    +                   dynamic-application [ junos:MS-TEAMS ];
    +               }
    +               then {
    +                   permit;
    +               }
    +           }
    +           default-rule {
    +               permit;
    +           }
    +       }
    +   }

     

     



  • 7.  RE: Classifying Skype traffic

     
    Posted 06-23-2020 15:01

    The use of appQoS also requires setting up the QoS that is involked by the rule too.   In addition to permit it has to apply the QoS setup.

     

    The full details are in this documentation.

     

    https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-application-qos.html

     



  • 8.  RE: Classifying Skype traffic

     
    Posted 06-24-2020 02:15

    @spuluka wrote:

    The use of appQoS also requires setting up the QoS that is involked by the rule too.   In addition to permit it has to apply the QoS setup.

     

    The full details are in this documentation.

     

    https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-application-qos.html

     


     

    Thank you Steve, as always.

     

    Briefly, can you suggest a more appropriate UDP flood threshold value (see my other recent message above)? I have the default of 500, and have just changed this to 50000, but I'm not sure if this effectively renders the protection pretty useless. I'd appreciate any thoughts you may have.



  • 9.  RE: Classifying Skype traffic

     
    Posted 06-24-2020 03:05

    Unfortunately with the flood thresholds they have to be tuned per network so you have two choices.  Start marching down in increments from your known too high then back off when you hit the legitimate traffic bump.  Or march up incrementally from the known bad until the legitimate traffic is clear.

     



  • 10.  RE: Classifying Skype traffic

     
    Posted 06-24-2020 06:32

    Thank you Steve, I understand.



  • 11.  RE: Classifying Skype traffic

     
    Posted 07-07-2019 21:07

    Just a couple of other questions ... are you actually trying to fix a quality issue?

     

    How are you connected to the internet? If you are connected with a PPP interface, all my testing has shown no matter what you do, the DSCP and COS marking will not be retained once the traffic leaves the SRX via PPP. Many ISP will actually honour some basic DSCP or COS tags. For the SRX you would need a DHCP connected internet interface for this to work end-to-end.

     

    There is NO point using COS unless your slowest interface is actually overloaded, if not it will have no effect, you could also look at policing.

     

    Another feature that would affect any voice/video application is screening, do you have a screen configured on your SRX and applied to the untrust zone? One of the typical issues I come across is when the UDP flood threshold is configured too low, let’s say 500pps which roughly would equate to 500ppsx1500bytes (typical packet size) = 750000 b/s or 0.0075 Mb/s (You can view screen statistics to see if you trigger any screen configured elements.

     

    I guess what I am saying is unless you understand the problem you cannot know the answer and by implication the solution.

     

    Just my throughts.



  • 12.  RE: Classifying Skype traffic

    Posted 07-07-2019 22:42
    Hi,

    These are really good points. Not actually trying to fix anything ... yet. More preemptive measures to be honest.

    This work is for a site to site vpn to a new branch site. Will go over a regular internet circuit (no QoS honouring as far as I’m aware).

    All I care about getting some decent bandwidth is some Skype traffic for the users and traffic that comes from one particular subnet.

    Looking for the easiest way to give that traffic a best chance across the wire. The circuit is 100mbps

    Thanks


  • 13.  RE: Classifying Skype traffic

     
    Posted 07-09-2019 18:17

    There are a number of ways to achieve this but I believe the simple approach is always the best approach, yes you can certainly achieve the results configuring forwarding-classes, firewall filters, traffic-control-profiles, shaping or a combination but a simpler approach might just be a policer? Perhaps allow 90Mpbs for all bandwidth and unlimited or 10Mbps for voice?

     

    You can apply the firewall filters to the st0 interface and manage the traffic across the vpn independently if needed.

     

    Have a look at this article:  Implement upload bandwidth-limiting using a firewall filter and a policer

     

    If however you are set on using class-of-server view this article: How to shape traffic from a subnet going out of a certain interface in SRX

     

    Both approaches can work, using the firewall filters will allow you to classify traffic and place them into the respective forwarding classes or apply the policers as needed.

     

    Hope that helps



  • 14.  RE: Classifying Skype traffic

    Posted 07-10-2019 04:05
    Thanks - totally agree simple is better

    I think I’ll use the bandwidth policer based on traffic coming from a particular subnet (some video conferencing units we have)

    My only concern was end users on Skype - there’s no slick method to identify this traffic ... I’m thinking as long as the video conferencing gets some dedicated bandwidth, we’ll be fine

    Thanks again


  • 15.  RE: Classifying Skype traffic

     
    Posted 07-10-2019 14:49

    It will actually be pretty simple... I dont think there is much the juniper boxes cannot handle 🙂

     

    I assume you are using the windows client? If so then create a group or local policy to classify traffic on the workstations as per this article,  notice the application option in step 5, you should actually specify the skype.exe in the policy and set all DSCP marking to EF (46) for that application following the article.

     

    DSCP Marking on windows applications

     

    Secondly you will configure your firewall policy to act on those markings as follows (remember to apply the filters to the interfaces required), you don't strictly speaking require a source address, but its just good practise to be as specific as you can be:

     

    firewall {
    	family inet {
    	   filter test {
    			term t1 {
    				from {
    					source-address {
    						10.0.0.0/24;
    			                }
    					dscp ef;
    				}
    				then {
    					policer policer-1mb;
    					accept;
    				}
    			}
    		}
    	}
    	policer policer-1mb {
    		if-exceeding {
    			bandwidth-limit 1m;
    			burst-size-limit 625k;
    		}
    		then discard;
    	}
    }

     

    This will then give you a process to identify the traffic as well as a way to process it on the SRX. Obviously you can use Wireshark to debug all of this and perhaps start with an FTP client to generate traffic and confirm the speed limits.

     

    Lastly you would need to consider all the "other" traffic, if other traffic is still able to overload the interface the above will be pointless, so its important to create another policer to capture the "all-else" and limit that traffic to allow bandwidth for voice.



  • 16.  RE: Classifying Skype traffic

     
    Posted 06-23-2020 05:01

    @Dawid wrote:

     

    Another feature that would affect any voice/video application is screening, do you have a screen configured on your SRX and applied to the untrust zone? One of the typical issues I come across is when the UDP flood threshold is configured too low, let’s say 500pps which roughly would equate to 500ppsx1500bytes (typical packet size) = 750000 b/s or 0.0075 Mb/s (You can view screen statistics to see if you trigger any screen configured elements.


     

    Re: the highlighted above, what would be a more sensible size in this scenario?