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.
