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

Sophos UTM Microsoft Teams Direct Routing/RTP Streams

Hallo Community,

wir nutzen seit kurzer Zeit für diverse User die Funktion MS Teams Direct Routing innerhalb einer PoC Phase.

Dies wird in Verbindung mit einem Audio Codes Gateway realisiert.

 

Immer wieder fällt auf das teilweise während Gespräche via Teams stattfinden, das diese zwischendurch Abbrüche von ca. 10-15 Sekunden haben.

Während dieser Abbrüche ist der jenige der das Gespräch führt dann nicht für die anderen Teilnehmen zu hören.

 

In Bezug auf die Firewall gibt es diverse Policies die wie unten aufgeführt aussehen:

Source

Destination

Service

Audio Codes GW (Int IP)

sip-all.pstnhub.microsoft.com

SIP/MTLS 5061 (TCP)

sip-all.pstnhub.microsoft.com

Audio Codes GW (Int IP)

SIP/TLS 5067 (TCP)

52.112.0.0/14 (MS Media Processor Network 01)

52.120.0.0/14 (MS Media Processor Network 02)     

Audio Codes GW (Int IP)

MS Media Processor Ports 01 (UDP/SRTP) (SRC Port = 49152-53247 / DST Port = 9500-9799)

MS Media Processor Ports 02 (UDP/SRTP) (SRC Port = 3478-3481 / DST Port = 9500-9799)

LAN Internal

52.112.0.0/14 (MS Media Processor Network 01)

52.120.0.0/14 (MS Media Processor Network 02)

3478-3481 (UDP)

 

Des Weiteren existieren für die oben zu sehenden Firewall Policies ebenfalls NAT Policies, welche wie folgt aussehen:

Traffic from

Using service

Going to

Change destination to

sip-all.pstnhub.microsoft.com

SIP/MTLS 5061 (TCP)

SIP/TLS 5067 (TCP)

Audio Codes GW (Public IP)

Audio Codes GW (Int IP)

52.112.0.0/14 (MS Media Processor Network 01)

MS Media Processor Ports 01 (UDP/SRTP) (SRC Port = 49152-53247 / DST Port = 9500-9799)

Audio Codes GW (Public IP)

Audio Codes GW (Int IP)

 

Wenn wir uns die Packet Caputer Logs anschauen, sehen wir das die Packete dort teilweise mit Ports aus der 30000er Range auftauchen.

Laut Firewall und NAT Policies sind diese allerdings nicht freigeben.

 

Wir haben schon diverse Logs/tcpdumps geprüft, können das Problem aber nicht immer nachstellen.

Teilweise kommen die Packete wie schon erwähnt aus der 30000er Range rein, aber erst auf dem internen DMZ Interface, auf dem externen Interface kommen die Ports korrekt an.

 

Anbei die TCP Dumps die entstehen sobald ein Call gestartet wird und die Ports in der 30000er Range starten:

<M> xxxxxx:/root # tcpdump -i ethx.xxx udp and dst xxx.xxx.xxx.xxx (<-- IP des internen Audio Codes GW)

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on ethx.xxx, link-type EN10MB (Ethernet), capture size 65535 bytes

16:39:22.444770 IP 52.113.60.151.36505 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.465469 IP 52.113.60.151.36505 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.485287 IP 52.113.60.151.36505 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.504848 IP 52.113.60.151.36505 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.526411 IP 52.113.60.151.36505 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.546755 IP 52.113.60.151.36505 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.564652 IP 52.113.60.151.36505 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.593007 IP 52.113.60.151.52332 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.610345 IP 52.113.60.151.52332 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.624301 IP 52.113.60.151.52332 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.645250 IP 52.113.60.151.52332 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.669270 IP 52.113.60.151.52332 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.685263 IP 52.113.60.151.52332 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.704987 IP 52.113.60.151.52332 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.724848 IP 52.113.60.151.52332 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.745857 IP 52.113.60.151.52332 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.765726 IP 52.113.60.151.52332 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.786166 IP 52.113.60.151.52332 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.805061 IP 52.113.60.151.52332 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.825538 IP 52.113.60.151.52332 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.846288 IP 52.113.60.151.52332 > xxx.xxx.xxx.xxx.9650: UDP, length 182

16:39:22.866598 IP 52.113.60.151.52332 > xxx.xxx.xxx.xxx.9650: UDP, length 182

 

Wie verhält sich die Sophos UTM hier genau, wird quasi die Portrange angesprochen die aktuell etwas "frei" hat

und die UTM entscheidet selbst das es mit der 30000er Range losgeht und er die Packete dann an die Destination weiterleitet?

Besten Dank im Voraus für die Unterstützung, & Gruß,

Judith



This thread was automatically locked due to age.
Parents
  • Hallo Judith,

    (Sorry, my German-speaking brain isn't creating thoughts at the moment. Frowning2)

    The links provided by Emmanuel will give you a more-complete solution than you requested.  In general, when you're having issues with UDP traffic (VoIP, Teams, etc.), you will likely see UDP anti-DoS Flooding activity in the Intrusion Prevention log.

    MfG - Bob (Bitte auf Deutsch weiterhin.)

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

    Vielen Dank für das Feedback.

    Wir werden ein paar Dinge ausprobieren, die in den Beiträgen empfohlen wurden.

    MfG,

    Judith

    ########

    Hi Balfson,

    thanks for the reply and the suggested posts.

    We will try a few things that were recommended within the posts.

    Regards,

    Judith

Reply
  • Hallo Balfson,

    Vielen Dank für das Feedback.

    Wir werden ein paar Dinge ausprobieren, die in den Beiträgen empfohlen wurden.

    MfG,

    Judith

    ########

    Hi Balfson,

    thanks for the reply and the suggested posts.

    We will try a few things that were recommended within the posts.

    Regards,

    Judith

Children
No Data