Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 4 subscribers
  • Views 2184 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

Getting default drop STUN in the Firewall Live log while using Microsoft Teams

MrRM

This is what we see when we deny or stop a Microsoft Teams voice call from a Samsung through wireless.

Wireless is a seperate zone (wlan15), masqueraded to the "Uplink Interfaces" object.

From the WebAdmin Live Log: Firewall:

11:15:10 Default DROP STUN 172.16.20.32:50016 <EXTERNAL_WAN_ADDRESS>:50011 len=140 ttl=64 tos=0x00 srcmac=<SAMSUNG_XCOVER_4S_MAC> dstmac=<SOPHOS_AP_MAC>

From the /var/log/packetfilter.log:

2020:11:18-11:15:10 <UTM_HOSTNAME> ulogd[20440]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="wlan15" mark="0x21dd" app="477" srcmac="<SAMSUNG_XCOVER_4S_MAC>" dstmac="<SOPHOS_AP_MAC>" srcip="172.16.20.32" dstip="<EXTERNAL_WAN_ADDRESS>" proto="17" length="140" tos="0x00" prec="0x00" ttl="64" srcport="50016" dstport="50011"

We get a whole bunch of them, in pairs, because we are testing from one device to the other, both on the same wireless network.

The calling works, except when we start moving through the building, in some areas the call will start to sound robotic or the call will drop.
I think it is a matter of "AP hopping".

However I want to eliminate the STUN drops as a possible cause.

My questions:

- Are these messages purely informational? Or should I resolve them?

- Why am I seeing 60001 errors? I have read Rulez and KB-000034242, but not sure what to do.

Thanks for your time!



This thread was automatically locked due to age.
Parents
  • 0

    Hoi and welcome to the UTM Community!

    60001 means a default block of a packet in the INPUT chain (see diagrams at the bottom of Rulz (last updated 2020-11-12)).  It appears that your internal devices are trying to communicate with each other via the "External (Address)" and that you don't have a Full NAT in place to allow that.  Probably, you want to make a change in your internal DNS ("split DNS") or maybe use a Full NAT as in Accessing Internal or DMZ Webserver from Internal Network.  Let us know which you choose.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • 0

    Hoi and welcome to the UTM Community!

    60001 means a default block of a packet in the INPUT chain (see diagrams at the bottom of Rulz (last updated 2020-11-12)).  It appears that your internal devices are trying to communicate with each other via the "External (Address)" and that you don't have a Full NAT in place to allow that.  Probably, you want to make a change in your internal DNS ("split DNS") or maybe use a Full NAT as in Accessing Internal or DMZ Webserver from Internal Network.  Let us know which you choose.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • 0 in reply to BAlfson

    Hi Bob,

    Thanks for the welcome and thanks for taking time to reply to my question.

    Have a second look at the diagram helped me in understanding why the UTM is generating the 60001, so thanks for that!

    Not sure if either of those solutions can help us: we have 80 Samsungs with the Teams app on it, so split DNS won't work.

    And Full NAT gets me confused: there is not one web server which we want to connect to, but more like 79 possibilities.

    No idea how to capture that in only one Full NAT rule?

    I also don't know why the STUN traffic is directed to the external interface of the UTM.

    Probably because the mobile network is using masquerading bound to the external interface.

    And since both devices in my test are on the same (separate zone) wireless network, I get to see the STUN messages in pairs.

    As said before: making calls works, I can see the STUN messages right before and right after a call.

    Or when we roam from one AP to another, but not always in that case. Guess that is how the Teams app works, nothing to do with Sophos.

    Big question for me is : can I ignore this or should I fix this?

  • 0 in reply to MrRM

    Interesting!  That's not even the "usual" port for STUN, so my guess is that only Microsoft could address this.  In any case, if functionality is not affected, I wouldn't worry about the log lines.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Yeah those two ports from the log 50011 and 50016 are the ports used by Microsoft Teams (3478-3481 , 80, 443, 50000-50019 for audio, 50020-50039 for video and 50040-50059 for screen sharing) for audio.

    Anyway, Teams calling functions, we only have issues when the callers start to walk around and roam from AP to AP. Of course, not always, that would be to easy, only in specific areas. So I will focus on that now.

    Thanks for your time and help!

Unfiltered HTML