Call quality issues with Teams

Hi Bob,

a question of understanding on my part. What is the purpose of your service definition "Response"? And is it not enough to set the type of definition to UDP?

Hallo Ludo - great question!

A request on port 3478 has dstport="3478" and the response to it has srcport="3478".  Sometimes Teams is responding to us and maybe sometimes we're responding to Teams, so I wanted to be sure that Intrusion Prevention didn't block responses or requests from Teams.  Realistically, we probably only needed the "Response" definitions, but I already had the request Services defined for a firewall Allow rule and I didn't want to risk leaving the client with any exposure.

The docs from Microsoft specified TCP/UDP, so that's why the request and response Service definitions use that.  UDP is the only thing that might trigger an anti-flooding drop, so that probably could have been used in definitions here.

Cheers - Bob

Hi Bob,

the docs from Microsoft specified only UDP (see Screenshot)?! Or do I not understand something?

Ok, understand, with the responseservice you want to play it safe. But actually this is not necessary, is it?

I've slept since then, so I don't remember the details of which client I first did this for, whether the client I was using as an example had already started configuring and what other documentation might have led to using TCP/UDP.  If you try this with only UDP, please let us know if that's indeed all that's needed for firewall rules and Intrusion Prevention Exceptions.

Cheers - Bob

Unfortunately, I cannot find any clear statements on the Internet. On the Microsoft side, the network request is UDP ports 3478 to 3481. In my Teams Admin Center, however, under the meeting settings 50000-50019 for audio, 50020-50039 for video and 50040-50059 for screen sharing. Nevertheless, I set up everything on my Sophos as you described. I just had a meeting with four participants and repeatedly had connection problems with sound and image. On my Internet interface, in the Flowmonitor, I can see how the http application suddenly swallows the entire bandwidth (30MBit). But I don't know what the problem is :-(

We had a lot of customers with VoIP and Webconf issues (Teams, Skype for Business and Zoom). The magic trick for us was to disable SYN flood protection. The difference was huge. 

I have already deactivated TCP SYN flood protection via the exception in Intrusion Prevention.

L'UNICA SOLUZIONE PER ME  è STATA QUELLA DELLA DISABILITAZIONE Protezione contro il flooding UDP

UDP flooding disabled was the only solution for me. no exceptions worked.

Without disabling UDP flooding from ips, Teams, Zoom, Cisco WebEX do not work correctly ..

Ciao Luca and welcome to the UTM Community!

It would be interesting to see an extract of the Intrusion Prevention log when Teams, Zoom or WebEx is active.  That might tell us what Exception was missing.

Cheers - Bob
PS Thanks for posting in Italiano - reminded me of the time when I lived in Paris and traveled all over France, Germany and northern Italia to participate in scherma competitions.