Skype Stun Not Allowed due to incorrect UDP Port in APP-ID

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Skype Stun Not Allowed due to incorrect UDP Port in APP-ID

L1 Bithead

Hi,

 

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:

 

skype-allow-rule.png

 

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:

skype-traffic-deny.png

 

According to ARIN this entire range is assigned to Microsoft so making the assumption this is Skype traffic:

Net Range104.40.0.0 - 104.47.255.255
CIDR104.40.0.0/13
NameMSFT
HandleNET-104-40-0-0-1

 

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.

 

Thanks

 

Gu

8 REPLIES 8

Cyber Elite
Cyber Elite

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.

Capture.PNG

 

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."

Ref: https://live.paloaltonetworks.com/t5/Learning-Articles/Tips-amp-Tricks-How-to-Create-an-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.

 

Thanks again

Hi,

 

Did you try to create a custom add for stun without policy override:

 

https://www.youtube.com/watch?v=CwXdWJpw0UY

 

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."

Ref: https://www.paloaltonetworks.com/documentation/70/pan-os/pan-os/app-id/manage-custom-or-unknown-appl...

Hi,

 

Can you create a separate policy for stun app and identify in services as upd/tcp 3478 and 3480? Would that work ? This is without app override 

 

stun.PNG for stun.PNG

 

We did try that at the beginning but it didn't match the application as it was not on the expected port. That's why the service port is currently set to 'Any'. Based on the below paragraph, what you suggest should have worked but we found it didn't:

 

"Use application-default for the Service. The firewall compares the port used with the list of default ports for that application. If the port used is not a default port for the application, the firewall drops the session and logs the message appid policy lookup deny. If you have a application that is accessed on many ports and you would like to limit the ports on which the application is used, specify it in Service / Service Group objects in policies."

Ref: https://www.paloaltonetworks.com/documentation/60/pan-os/pan-os/app-id/best-practices-for-using-app-...

 

It's been a couple of weeks so going to need to review this again.

L0 Member

Hi,

 

is there an update on this topic ?

Hi,

SSL Decryption configuration must be done to prevent stun traffic.

 

 

 

  • 8707 Views
  • 8 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!