One of my customers is having an issue where by Skype is not being allowed through despite the Stun and RTP applications being allowed through:
Previously we'd used the 'skype' and 'skype-probe' but this was not matching with the traffic.
Looking through the traffic logs the traffic is being denied because Stun is running on a high level port and not the default TCP/UDP 3478:
According to ARIN this entire range is assigned to Microsoft so making the assumption this is Skype traffic:
|Net Range||126.96.36.199 - 188.8.131.52|
This customer does not have URL filtering filtering installed so we are unable to permit/deny based on any details included in that. The infrastructure also does not permit FQDN for using dynamic IP address lookups, hence the any in the destination IP rule.
At the present we have allowed this traffic by setting the service to 'any' not 'application-default'
The device is a PA-5050 running 7.0.11
Anyone else hit this issue and know of a fix?
One other thing I'd thought about doing is to clone the built-in 'stun' application (e.g. 'skype-stun') so that I can specify alternative port or set it to dynamic but it doesn't seem possible to do that.
You could simply apply an applicaiton override policy to that traffic that looks like the screenshot I took. Simply put it will label anything that goes to that specific port and to the specified destination addresses as 'stun' traffic.
One thing to point out is that looking at the rule that you shared it doesn't look like you are using an 'application-default' service entry; therefore you should be seeing the traffic being allowed as long as it is hitting that rule.
Thanks for the reply BPry,
Because the port defined for Stun in the PA's application defintion is different to the port being used by actual traffic, I believe this is why it's not matching.
I've had a read of application override and I don't believe this is what my customer will want as it disables any further APP-ID inspection:
"As soon as the Application Override policy takes effect, all further App-ID inspection of the traffic is stopped and the session is identified with the custom application."
Because it's not possible to lock the rule down by destination IP we'd effectively be allowing any traffic out of the network just as long as goes on the correct port number, this is definately not ideal.
What I'd really like to be able to do is tell the Palo Alto that this port should be used by Stun and have it pass through the same level of filtering as if it was using the default port defined in the Stun application.
Not tried a custom app as yet as I don't know what signatures to apply in order to match the traffic.
All I need is for Stun to be matched on the different port but using the same signatures. Would creating a custom app and setting 'Stun' as the parent but with a different port number achieve the same thing and inherit the original signatures?
I'm thinking from the below paragraph that it won't as it would need to trigger the parent app first which is not on the correct port:
"For example, if you build a custom application that triggers on a host header www.mywebsite.com, the packets are first identified as web-browsing and then are matched as your custom application (whose parent application is web-browsing). Because the parent application is web-browsing, the custom application is inspected at Layer-7 and scanned for content and vulnerabilities."
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!