Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 40 subscribers
  • Views 20924 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Can we talk about STUN traffic?

Wayne Folta

I'm noticing that when I do reports or look at live connections, I see a lot of STUN traffic. And it's a LOT of traffic, which is puzzling in that I thought STUN was merely a tool to figure out how to get a direct connection when that would otherwise be frustrated by being behind NAT. So I would expect little actual STUN traffic.

But it appears that -- at least for certain considerations -- SFOS is smart enough to follow a STUN series of exchanges and the resulting successful connection and consider all of that and the follow-on traffic to be "STUN traffic". Does anyone have insight on this?

I'm running a dual-stack (IPv4/IPv6) network via an IPv6 6in4 tunnel, and I see IPv6 STUN traffic, too, which makes no sense. (Unless somehow not being "native" IPv6 causes problems that appear to STUN algorithms to be NAT-like.)

I've blocked STUN ports (TCP/UDP 3478 and TCP 5349) under IPv6, and it is in fact blocking traffic. I'm wondering if this is an oddity whereby STUN is focusing on IPv4 but Apple prioritizes IPv6. I also have a separate IPv4 firewall rule for STUN ports, to monitor things and traffic under this rule is low. Which is why I'm assuming that SFOS follows the connection resulting from STUN mechanisms and considers it STUN for some Application purposes. (Though I think there are other Application displays where the traffic is thrown under SSL or some other Application type.)

I have traffic shaping that should apply to various conferencing software (Teams, Zoom, etc), and I see some amount of traffic associated with them, but it also appears that some large amount of traffic is considered to be STUN and I assume it is not traffic-shaped or prioritized as conferencing.

Again, any insights or tips on STUN traffic?



This thread was automatically locked due to age.
Parents
  • +1

    Hello ,

    Thank you for reaching to the community, STUN is standard protocol for traversal of network address translator gateways in applications of real-time voice, video, messaging, and other interactive. The same protocol is also used in What's app application too. 

    However if you wish to block the protocol, you can block with the help of application filter, as shown in the example below:
    Application filter has a higher precedence in respect to web filter. 


    > Just ensure the IPS engine is running and patterns for the IPS and Application signatures should be up to date.

    Thanks & Regards,
    _______________________________________________________________

    Vivek Jagad | Team Lead, Technical Support, Global Customer Experience

    Log a Support Case | Sophos Service Guide
    Best Practices – Support Case  | Security Advisories 
    Compare Sophos next-gen Firewall | Fortune Favors the prepared
    Sophos Community | Product Documentation | Sophos Techvids | SMS
    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to Vivek Jagad

    I've accepted the answer because it has a way to address STUN via IPS, which I hadn't thought of.

    At the same time, I'd like to know more about what SFOS considers to be STUN traffic. As I said, STUN appears to be a set of tools for figuring out how to directly communicate, not a transportation mechanism. In which case, I shouldn't see GB of "STUN" data in reports. As I understand it, once an application has used STUN to figure out how to directly connect it will then use that connection and not "STUN".

    So is SFOS watching STUN happen and then continuing to regard the ongoing connection as STUN traffic? And why would it classify IPv6 traffic as STUN when one of the key characteristics of IPv6 is that it does not require STUN?

    The vast majority of SFOS installations probably can't completely prohibit STUN. Maybe limit the initial STUN servers to known servers, or maybe prohibit for some users, etc, but ultimately if you're running IPv4 and you have people who want to conference you need to allow some level of STUN.

Reply
  • 0 in reply to Vivek Jagad

    I've accepted the answer because it has a way to address STUN via IPS, which I hadn't thought of.

    At the same time, I'd like to know more about what SFOS considers to be STUN traffic. As I said, STUN appears to be a set of tools for figuring out how to directly communicate, not a transportation mechanism. In which case, I shouldn't see GB of "STUN" data in reports. As I understand it, once an application has used STUN to figure out how to directly connect it will then use that connection and not "STUN".

    So is SFOS watching STUN happen and then continuing to regard the ongoing connection as STUN traffic? And why would it classify IPv6 traffic as STUN when one of the key characteristics of IPv6 is that it does not require STUN?

    The vast majority of SFOS installations probably can't completely prohibit STUN. Maybe limit the initial STUN servers to known servers, or maybe prohibit for some users, etc, but ultimately if you're running IPv4 and you have people who want to conference you need to allow some level of STUN.

Children
Unfiltered HTML