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
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 23 replies
  • Subscribers 13 subscribers
  • Views 9079 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

Verbindungsprobleme in Microsoft Teams SophosXG 310

Julian Hilgenberg

Hallo Zusammen,

wir haben immer wieder relativ starke Probleme in MS Teams Konferenzen.
Diese Probleme treten nur auf, wenn die Kollegen hier im Büro sind uns somit über unsere Sophos Firewall an der Teams Konferenz teilnehmen.
Die Probleme äußern sich insofern, als dass mitten in der Konferenz für ca. 10-20 Sekunden die Verbindung sehr schlecht wird (Bild und Ton Aussetzer).
Teilweise bricht die Verbindung auch komplett ab. Teams meldet dann immer eine schlechte Netzwerkverbindung.
Auf dem Client ist dann auch zu erkennen, das Der Netzwerk-Traffic nahezu komplett einbricht:


Für die Kollegen gilt eine Firewall-Regel, in der folgende Module aktiv sind:

Ich habe in der Firewall schon folgende Konfigurationen vorgenommen, jedoch bisher ohne Erfolg:

utmshop Support-Portal - Sophos Firewall v18 und UTM9: UDP-Flood-Protection-Ausnahme für Microsoft Teams (utm-shop.de)

Außerdem habe ich in der WebProtection sicherheitshalber auch folgende Ausnahmen definiert:

Leider hat dies bisher auch noch nicht geholfen.
Da wir zwei separate Internetleitungen über zwei verschiedene Anbieter (Glasfaser und Kupfer-DSL) haben, und bei beiden
die selben Probleme auftreten, würde ich Probleme auf Anbieterseite ausschließen.

Leider bin ich aber mit meinem Latein am Ende.

Bin um jeden Rat dankbar.

Besten Dank,

grüße



Added TAGs
[edited by: Erick Jan at 11:33 PM (GMT -7) on 29 May 2023]
  • 0 in reply to LHerzog

    ich schreib hier mal unten dran, man verliert sonst den Überblick.

    mit set vpn conn-remove-tunnel-up disable deaktivierst du das Flushen von Connections wenn sich IPSec VPNs neuverbinden.

    Hast du Tunnels eingerichtet und haben die sich zu den festgestellten Zeiten neuverbunden?

  • 0 in reply to LuCar Toni

    Hallo Zusammen,

    LuCar Toni said:
    Wenn du set vpn conn-remove-tunnel-up disable in der Console eingibst, hilft das? 

    Das war bei uns die Lösung.

    Seit dem haben wir überhaupt keine Probleme mehr mit unseren Teams Konferenzen.

    Besten dank für deine Hilfe.

    Wir haben durchschnittlich Paketverluste von unter 1% Bei uns war direkt nachdem ich den Befehl in der Console eingegeben habe. Die Problematik erledigt.

  • 0 in reply to syinf

    In der Online Hilfe sind noch ein paar Punkte, die man ausprobieren könnte: 

    https://docs.sophos.com/nsg/sophos-firewall/18.5/Help/en-us/webhelp/onlinehelp/nsg/sfos/concepts/FirewallVoIP.html?hl=voip

    __________________________________________________________________________________________________________________

  • 0 in reply to LHerzog

    Probleme treten erst dann auf, wenn interne mit externen kommunizieren und mindestens 3 Teilnehmer in der Konferenz sind. Bei 1:1 calls (intern / intern und intern / extern) scheint es keine Probleme zu geben.

    Hier ist der Kommunikationsaufbau von Teams ganz gut erklärt: https://blog.valeconsulting.co.uk/2018/09/11/microsoft-teams-stun-turn-and-nat-get-your-media-right/

    Dort findet sich auch der Hinweis zum NAT:

    So STUN is just the process of allowing the client to discovery its public IP and Port. However, in order for STUN to work properly, the firewall needs to support certain NAT types. In a nutshell STUN does not work with firewalls configured to enforce symmetric NAT. Other forms of NAT are OK e.g. full cone, restricted cone and port restricted cone NAT.

    Die Wireshark- und TCPdumps sehen für mich hier nach meinem Verständnis allerdings ok aus.

  • 0 in reply to syinf

    ich kenne Teams jetzt nicht in und auswendig, aber ist es möglich, dass Teams wie inzwischen einige andere Meeting Programme auch peer to peer kommuniziert? Ich kenne da so ein paar Anbieter die sowas gerne machen. Sehr schön in segmentierten LANs....

    Ist das Problem als bspw. wenn einige Teilnehmer intern sind und einige extern? Könnte sein, dass nur die internen Probleme haben.

  • 0 in reply to LHerzog

    Hi, das denke ich nämlich auch, daher meine kritische Nachfrage. ;) 

    Nein, die XG ist alleinige Firewall bei uns, wir haben die besagte, dedizierte WAN-Regel für Teams mit Priorisierung und generell IPS und WebProxy aus. Zudem die Anpassung "set vpn conn-remove-tunnel-up disable" und damit die größten Paketverluste eliminiert.

    Aktuell aber weiterhin konstant hohe Paketverluste bei Calls ab 3 Personen und laut Messungen nur bei eingehenden Paketen...

    Ich lese immer wieder, dass man hinsichtlich NATting wegen STUN / TURN einiges beachten muss, wir fahren hier seit eh und je ein Masquerading auf unsere öffentliche IP. Kann es eventuell damit etwas zu tun haben?

  • 0 in reply to syinf

    Hi, so wie du das beschreibst, würde ich auch sagen, dass Teams nun ungefiltert raus darf. Wichti gist hier, zu überprüfen, dass die genannten VoIP Ports raus dürfen.

    Du brauchst natürlich keine Web Exceptions, wenn keine Webfilter aktiv sind und auch DPI nicht verwendet wird.

    Gibt es eine andere Firewall vor der XG?

  • 0 in reply to LHerzog

    Hi und danke für deinen Input. Die WebExceptions habe ich zum Großteil schon implementiert, aber ich muss hier noch mal doof nachfragen. Aktuell haben wir den WebProxy bei allen WAN-Regeln komplett deaktiviert, dann kann es doch nach meinem Verständnis nicht an eventuell fehlenden Exceptions im WebProxy liegen, oder übersehe ich hier etwas? 

    Sorry für meine kritische Nachfrage, aber ich versuche dieses merkwürdige Verhalten der XG zu verstehen. Für mich kann es nicht am Proxy liegen, da wir derzeit keine Policy in den entsprechenden WAN-Regeln aktiv haben... Um die Exceptions aktiv zu bekommen, müsste ich ja in den FW-Regeln wieder Proxy-Policies zuweisen und den WebProxy damit aktivieren. Wir verzichten ja derzeit aktiv auf diese Funktion, um den Schuldigen für die Paketverluste zu finden...

    Die Destination habe ich übrigens erweitert in der FW-Regel für Teams, ohne Erfolg.

    Grüße
    Sascha

  • 0 in reply to syinf

    ich würde mal sagen, diese Regel ist zu "klein" was die Source Networks angeht.

    Siehe https://docs.microsoft.com/en-us/microsoftteams/3-envision-evaluate-my-environment

    Abschnitt "Firewall and proxy requirements"

    Setz die Destinations fürs Debugging auf any. Diese Ports werden eh von vielen Meetings Tools inzwischen benutzt.

    Darüber hinaus brauchst du die ganzen Proxy Exceptions. O365 durch die XG ist eine Menge Arbeit, aber es geht. Wurde alles schon kürzlich hier diskutiert.

    Wenn du da welche vergisst, tritt das hier ein: "In the event of a proxy server being deployed, we recommend that you bypass the proxy server for all Teams services. Although using a proxy might work, it's very likely that quality will be reduced due to media being forced to use TCP instead of UDP."

  • 0 in reply to Michael Wulfert

    Hi Michael,

    ich muss hier leider doch noch mal einhaken, da wir die konstant hohen Verluste bei eingehenden Paketen nicht in den Griff bekommen. Durch die Änderung an VPN sind wir aber die heftigen Peaks losgeworden, das ist also schon Mal ein großer Fortschritt.

    Aktuell messen wir über Teams bei eingehenden Paketen einen Verlust bis ca. 20% hinter der XG, Kollegen im Home Office sind hier eher bei 0%. Bei ausgehenden Paketen scheint alles fein zu sein...:

    Wir nutzen hier schon für WAN-traffic für UDP zu Teams eine dedizierte Regel, die WebProxy, IPS, etc. umgeht und "Shape traffic" aktiviert hat:

     

    Habt ihr dieses Problem mit den konstant hohen Paketverlusten nicht und habt ihr hier noch mehr gemacht, damit Teams stabil läuft?

    Danke euch im Voraus und viele Grüße
    Sascha

Unfiltered HTML