Teams-Telefonie durch die Sophos XGS: QoS, Ports und Direct Routing sauber konfiguriert

Wenn Teams-Calls ruckeln, Stimmen blechern klingen oder Sätze verschluckt werden, lautet die reflexhafte Diagnose »das Internet ist halt schlecht« — und sie ist fast immer falsch. Die Kurzantwort vorab: Ruckelnde Teams-Telefonie durch die Firewall hat in der Praxis drei Standardursachen, alle hausgemacht: fehlende QoS-Behandlung (die Sprache steht im selben Stau wie das Windows-Update), Reste alter VoIP-Hilfskonstruktionen wie SIP-ALG, die an Paketen herumbasteln, oder Medienverkehr, der durch Inspektionsmaschinen gezwungen wird, die für ihn nie gedacht waren. Dieser Artikel räumt die Firewall-Seite systematisch auf: wie der Teams-Medienverkehr technisch wirklich funktioniert, welche Ports Clients und SBC brauchen (mit Portmatrix), wie QoS mit DSCP-Markierung und Bandbreitenreservierung auf der XGS entsteht, was niemals inspiziert werden darf, wie sich Sprachqualitätsprobleme messbar diagnostizieren lassen — und welche Sonderregeln für Direct Routing mit eigenem SBC gelten.

Wie Teams-Medienverkehr technisch funktioniert

Wer die Firewall für Teams richtig konfigurieren will, muss eine Eigenheit verstehen: Teams trennt strikt zwischen Signalisierung und Medien. Die Signalisierung — wer ruft wen an, Anwesenheit, Chat — läuft als gewöhnliches HTTPS auf 443 und ist firewallseitig unspektakulär. Die Medien dagegen — die eigentliche Sprache, das Video, die Bildschirmfreigabe — reisen als Echtzeitströme (verschlüsseltes RTP) über UDP, und zwar auf zwei möglichen Wegen: Bei externen Gesprächen verbindet sich der Client mit Microsofts Transport-Relays über die UDP-Ports 3478 bis 3481, wobei die Zielnetze dokumentiert sind (13.107.64.0/18, 52.112.0.0/14, 52.122.0.0/15). Bei internen Gesprächen im selben Netz handeln die Clients per ICE einen Direktpfad aus — die Medien fließen dann von PC zu PC, ohne die Firewall überhaupt zu sehen. Und wenn UDP blockiert ist, greift der Notnagel: Rückfall auf TCP 443 — der Anruf kommt zustande, aber Echtzeitverkehr über TCP ist wie Espresso durch einen Strohhalm: technisch möglich, Genuss ist anders.

Aus dieser Architektur folgt fast alles Weitere im Artikel: UDP zu den Relays muss offen sein (sonst Strohhalm-Modus), die Medienströme sind empfindlich gegen alles, was Pakete verzögert oder anfasst — und Sprachqualität bemisst sich nicht in Bandbreite, sondern in drei Größen: Latenz (wie lange ist das Paket unterwegs), Jitter (wie gleichmäßig kommen die Pakete an) und Paketverlust. Ein Audiostrom braucht lächerliche 100 Kilobit pro Sekunde — aber er braucht sie pünktlich. Der Faktenkasten liefert die Grenzwerte zum Zitieren; die Medienpfad-Skizze zeigt die Wege im Überblick, inklusive des SBC-Astes, der später sein eigenes Kapitel bekommt.

Skizze 1: Signalisierung über 443, Medien als UDP zu den Relays — interne Calls laufen P2P an der Firewall vorbei, und der SBC ist ein eigener Verkehrsteilnehmer.

Portfreigaben für Teams und Direct Routing/SBC

Die gute Nachricht zuerst: Für den reinen Client-Betrieb ist die Portliste kurz. Ausgehend braucht es UDP 3478 bis 3481 zu den drei Microsoft-Medien-Netzen — als eigene Firewall-Regel mit einer gepflegten IP-Hostgruppe als Ziel, denn diese Regel wird gleich noch der Anker für QoS und Inspektionsausnahmen. Die vier Ports haben übrigens System: 3478 ist der allgemeine Vermittlungsport, 3479 bis 3481 sind Audio, Video und Bildschirmfreigabe zugeordnet — was später in der Diagnose hilft, weil sich die Verkehrsarten unterscheiden lassen. Dazu kommt HTTPS 443 für Signalisierung und den TCP-Notnagel, das ohnehin offen ist. Eingehende Freigaben braucht der Client-Betrieb: keine. Die Quellports der Clients (50000 bis 50059, sauber nach Verkehrsart gestaffelt) sind dagegen kein Firewall-, sondern ein QoS-Thema — sie werden per Gruppenrichtlinie festgelegt und dienen als Erkennungsmerkmal für die Markierung, dazu gleich mehr.

Mit Direct Routing und eigenem SBC kommt ein zweiter, anspruchsvollerer Verkehrsteilnehmer dazu: Der SBC spricht mit Microsofts SIP-Endpunkten (sip.pstnhub.microsoft.com und Geschwister) über SIP-TLS auf Port 5061 — und zwar in beide Richtungen, denn Microsoft baut auch aktiv Verbindungen zum SBC auf; die eingehende 5061-Freigabe gehört dabei strikt auf Microsofts dokumentierte SIP-Quellnetze beschränkt. Die Medien zwischen SBC und Microsoft laufen über den UDP-Bereich 49152 bis 53247 zu den bekannten Medien-Netzen. Die Blockgrafik zeigt beide Welten getrennt, die Portmatrix macht daraus die Regelliste — und die Pflege der IP-Gruppen läuft über Microsofts Endpunkt-Webservice, dessen Feinheiten samt Automatisierung der TLS-Inspection-Artikel behandelt.

Skizze 2: Oben der Client-Alltag (vier UDP-Ports ausgehend genügen), unten die SBC-Welt mit SIP-TLS 5061 und eigener Medien-Range — der einzige Teilnehmer mit eingehenden Freigaben.

QoS für Teams-Telefonie: Markierung, Queues und Bandbreitenreservierung auf der XGS

QoS wird gern als Bandbreiten-Zauberei missverstanden — dabei ist es schlicht Vorfahrtsrecht: Die Leitung wird nicht schneller, aber im Stau fährt die Sprache zuerst. Das Gesamtsystem hat zwei Zutaten. Zutat eins ist die Markierung: Die Windows-Clients stempeln ihre Medienpakete per richtlinienbasiertem QoS (Gruppenrichtlinie) mit DSCP-Werten — erkannt an den Quellportbereichen, die Teams dafür sauber staffelt: Audio bekommt EF (46), Video AF41 (34), Bildschirmfreigabe AF21 (18). Diese Markierung wirkt vor allem im eigenen Haus: auf Switchen mit aktivierter Priorisierung, im WLAN — und als Klassifizierungsmerkmal an der Firewall. Die Ehrlichkeit gehört dazu: Jenseits des eigenen Anschlusses entfernt der Internet-Provider die Markierung in aller Regel; DSCP ist kein Fernversprechen, sondern Hausrecht. Genau deshalb ist Zutat zwei entscheidend.

Zutat zwei ist die Warteschlangen-Arbeit der XGS am Engpass, und der Engpass ist praktisch immer der WAN-Uplink. Das Rezept: Zuerst in den Traffic-Shaping-Einstellungen die tatsächliche Gesamtbandbreite der Leitung hinterlegen — ohne diesen Wert rechnet kein Shaping der Welt korrekt, und das Vergessen dieses einen Feldes ist der häufigste Grund für wirkungsloses QoS. Dann eine Traffic-Shaping-Richtlinie für die Sprache: garantierte Bandbreite (großzügig gerechnet: 100 kBit/s je gleichzeitigem Gespräch plus Reserve) mit höchster Priorität, angewendet auf die Medien-Firewall-Regel aus dem Portkapitel — und zwar in beide Richtungen, denn ein Telefonat ist symmetrisch, und die vergessene Gegenrichtung ist der zweithäufigste QoS-Fehler. Video und Sharing bekommen eigene Klassen mit hoher beziehungsweise mittlerer Priorität und einem Deckel, damit die Videokonferenz nicht ihrerseits alles frisst. Der Rest der Welt fährt Best Effort — und genau das ist der Sinn der Übung. Das Klassenmodell zeigt die Aufteilung, die DSCP-Tabelle liefert die Werte zum Nachbauen.

Skizze 3: Vier Klassen am Uplink — Audio klein aber heilig, Video mit Deckel, Sharing geduldig, der Rest bekommt, was übrig bleibt.

Was niemals inspiziert werden darf

Jetzt zur Verbotsliste, und sie hat einen gemeinsamen Nenner: Echtzeit-Medienströme vertragen keine Zwischenhändler. Erstens die TLS-Inspection — Teams-Medien sind Ende-zu-Ende auf Transportebene gesichert, eine Entschlüsselung liefert null Erkenntnisgewinn und kostet im besten Fall Latenz, im schlechteren bricht sie die Verbindung auf den TCP-Notnagel herunter; die Medien-IP-Gruppe samt UDP 3478–3481 gehört deshalb in die Ausnahmeliste, deren komplette Konstruktion (inklusive der übrigen Microsoft-365-Kategorien) im TLS-Inspection-Artikel [LINK: A7] steht. Zweitens das IPS: Musterprüfung auf zehntausenden verschlüsselten RTP-Paketen pro Minute erzeugt exakt die Mikroverzögerungen, die als Jitter im Ohr landen — die Medien-Regel bekommt kein IPS-Profil, und das gilt ausdrücklich auch für interne Verkehrsbeziehungen, wenn Telefonie-VLANs über die Firewall geroutet werden. Drittens der Web-Proxy: UDP-Echtzeitverkehr hat in keiner Proxy-Warteschlange etwas verloren. Und viertens die Anwendungserkennung mit Drosselungsambitionen — wer Teams-Medien versehentlich in einer App-Kategorie »Streaming« gedeckelt hat, wundert sich über präzise reproduzierbare Aussetzer.

Diagnose von Sprachqualitätsproblemen

Sprachqualität diskutiert man nicht, man misst sie — und Microsoft liefert das Werkzeug frei Haus. Erste Anlaufstelle ist die Anrufanalyse im Teams Admin Center: Für jedes einzelne Gespräch zeigt sie pro Teilstrecke Latenz, Jitter, Paketverlust — und, oft der entscheidende Blick: den verwendeten Transport. Steht dort TCP statt UDP, ist die Diagnose praktisch fertig — die UDP-Freigabe zu den Relays fehlt oder greift nicht, und der Anruf lief im Strohhalm-Modus. Für Muster über viele Gespräche (immer dieselbe Etage? immer nachmittags?) ist das Call Quality Dashboard die Flughöhe darüber. Auf der XGS-Seite gehören drei Blicke dazu: die Auslastung des WAN-Interfaces zum fraglichen Zeitpunkt (war der Uplink gesättigt — und hat die Shaping-Richtlinie gegriffen?), das Firewall-Log auf verworfene UDP-Pakete Richtung Relay-Netze, und die Traffic-Shaping-Statistik, ob die Sprachklasse ihre Garantie tatsächlich bekommen hat.

Das dritthäufigste Fehlerbild verdient einen eigenen Absatz, weil es so schön kontraintuitiv ist: »Extern ist alles gut, nur intern klingt es furchtbar.« Der Reflex sucht im Internet — dabei laufen interne Calls ja gerade nicht durchs Internet, sondern P2P im Haus. Die Verdächtigen sitzen also lokal: ein WLAN ohne saubere Priorisierung (Sprachpakete im selben Topf wie der Streaming-Traffic der Kaffeeküche), Switche, die DSCP-Markierungen ignorieren oder wegwerfen — oder der Klassiker in segmentierten Netzen: Die Telefonie-VLANs sind über die Firewall geroutet, und auf der Inter-VLAN-Regel sitzt ein IPS-Profil, das jedem Sprachpaket eine Musterprüfung spendiert. Die Anrufanalyse entlarvt das übrigens sauber, weil sie die betroffene Teilstrecke benennt. Der Praxis-Kasten erzählt den Fall, wie er im Lehrbuch stehen könnte.

Besonderheiten mit eigenem SBC (Direct Routing)

Direct Routing macht aus Teams eine vollwertige Telefonanlage — und aus dem Session Border Controller den wichtigsten Verkehrsteilnehmer im Firewall-Regelwerk. Die Grundsätze: Der SBC gehört in eine eigene Zone (klassisch die DMZ), erreichbar nach dem Minimalprinzip — SIP-TLS 5061 zu und von Microsofts SIP-Endpunkten (eingehend strikt auf deren dokumentierte Quellnetze beschränkt), die Medien-Range UDP 49152–53247 zu den Microsoft-Medien-Netzen, und auf der anderen Seite der Trunk zum Provider, ebenfalls eng auf dessen IPs geschnitten. Dazu die Identitätsfragen, an denen Direct-Routing-Projekte real scheitern: Der SBC braucht einen öffentlichen FQDN mit Zertifikat einer öffentlichen CA (Microsoft prüft das kompromisslos), und beim NAT gilt: sauberes statisches 1:1 statt dynamischem Port-Wirrwarr — SIP transportiert Adressinformationen in der Nutzlast, und der SBC muss wissen, unter welcher Adresse die Welt ihn sieht.

Womit wir beim Erzfeind wären, der einen eigenen Faktenkasten verdient: dem SIP-ALG. Für die QoS-Seite gilt dieselbe Logik wie bei den Clients, nur mit höherem Einsatz — über den SBC laufen alle PSTN-Gespräche des Hauses gleichzeitig; seine Medienströme gehören in die Audio-Klasse mit garantierter Bandbreite (gleichzeitige Amtsgespräche mal 100 kBit/s plus Reserve), selbstverständlich ohne IPS oder Proxy im Pfad. Die Sicherheitsseite des SBC-Betriebs — Toll-Fraud, Trunk-Härtung — vertieft der VoIP-Sicherheits-Bestandsartikel; die Teams-Gesamtsicht auf Rufnummernkonzepte und Migrationswege liefert der Telefonie-Cluster.

FAQ — häufige Fragen zu Teams-Telefonie und Sophos-Firewall

Welche Ports braucht Microsoft Teams durch die Firewall?

Für den Client-Betrieb genügen zwei Freigaben: ausgehend UDP 3478 bis 3481 zu Microsofts Teams-Medien-Netzen (als IP-Hostgruppe gepflegt: 13.107.64.0/18, 52.112.0.0/14, 52.122.0.0/15 — verbindlich ist die offizielle Endpunktliste) für die Echtzeit-Medien, plus das ohnehin offene TCP 443 für Signalisierung und den Qualitäts-Notnagel. Eingehende Freigaben braucht der Client-Betrieb keine. Die Client-Quellports 50000 bis 50059 sind kein Freigabe-, sondern ein QoS-Thema — sie dienen der DSCP-Markierung per Gruppenrichtlinie. Erst mit Direct Routing kommt Eingehendes dazu: Der SBC spricht SIP-TLS auf 5061 mit Microsofts SIP-Endpunkten in beiden Richtungen (eingehend strikt auf deren Quellnetze beschränkt) und nutzt für Medien den UDP-Bereich 49152 bis 53247. Der wichtigste Einzelpunkt: Ist das Medien-UDP zu, funktioniert Teams trotzdem — über TCP 443, in trauriger Qualität. Ein »geht doch« ist hier kein Beweis für eine korrekte Konfiguration.

Wie richte ich QoS für Teams auf der Sophos XGS ein?

In vier Schritten. Erstens die Voraussetzung, die am häufigsten fehlt: In den Traffic-Shaping-Einstellungen die reale Gesamtbandbreite des WAN-Anschlusses hinterlegen — ohne diesen Referenzwert kann kein Shaping korrekt rechnen. Zweitens eine dedizierte Firewall-Regel für die Teams-Medien (UDP 3478–3481 zur Medien-IP-Gruppe), denn Shaping wird auf der XGS über Regeln zugeordnet. Drittens die Traffic-Shaping-Richtlinie: für Audio garantierte Bandbreite mit höchster Priorität (gerechnet: gleichzeitige Gespräche mal 100 kBit/s plus Reserve), für Video hohe Priorität mit Obergrenze, Sharing mittig — und die Richtlinie in beide Richtungen anwenden, weil Telefonate symmetrisch sind. Viertens die Markierung auf den Clients: per Gruppenrichtlinie richtlinienbasiertes QoS mit den Teams-Quellportbereichen (Audio EF 46, Video AF41, Sharing AF21), damit auch Switche und WLAN priorisieren. Danach beweist die Anrufanalyse, ob es wirkt — Jitter und Latenz unter Last sind die Messgröße, nicht das Bauchgefühl.

Warum ist die Sprachqualität nur intern schlecht?

Weil interne Calls einen völlig anderen Weg nehmen als externe — die Medien fließen per ICE direkt von Client zu Client durchs eigene Netz, das Internet ist unbeteiligt. Schlechte Qualität nur bei internen Gesprächen zeigt also mit dem Finger auf die eigene Infrastruktur, und dort gibt es drei übliche Verdächtige: Erstens das WLAN — ohne funktionierende Priorisierung stehen Sprachpakete im selben Funk-Stau wie alles andere, und gerade volle Access Points produzieren prächtigen Jitter. Zweitens Switche, die DSCP-Markierungen nicht auswerten oder beim Übergang zwischen VLANs entfernen — die schöne Client-Markierung verpufft dann wirkungslos. Drittens, in segmentierten Netzen der Klassiker: Clients in verschiedenen VLANs, Verkehr über die XGS geroutet, und auf der Inter-VLAN-Regel verpasst ein IPS-Profil jedem Sprachpaket eine Musterprüfung — Mikroverzögerungen, die sich als Jitter summieren. Die Anrufanalyse benennt die Teilstrecke; die Abhilfe reicht von WMM im WLAN über DSCP-Trust auf den Switchen bis zur IPS-Ausnahme für interne Medienströme.

Muss Teams-Traffic von der TLS-Inspection ausgenommen werden?

Ja, und zwar aus zwei unterschiedlichen Gründen je Verkehrstyp. Die Echtzeit-Medien (UDP 3478–3481 zu den Medien-Netzen) gehören kompromisslos an der Entschlüsselung vorbei: Es gibt dort nichts Sinnvolles zu sehen, aber viel Laufzeit zu verlieren — und im schlechtesten Fall drückt eine Störung die Verbindung in den TCP-Fallback mit hörbaren Folgen. Die Signalisierungs- und Dienst-Endpunkte von Teams wiederum reagieren empfindlich auf aufgebrochenes TLS (Zertifikat-Pinning und moderne Authentifizierungsverfahren vertragen keinen Mittelsmann) und stehen deshalb ebenfalls auf Microsofts Nicht-anfassen-Liste. Die vollständige Ausnahmen-Architektur — welche Microsoft-365-Kategorien umgangen werden, wie die IP- und FQDN-Gruppen heißen und wie ihre Pflege über die Endpunktliste automatisiert wird — ist das Kernthema des TLS-Inspection-Artikels [LINK: A7]. Kurzfassung für hier: Medien-Regel und Teams-Endpunkte ausnehmen, Rest der Welt gern weiter inspizieren — das ist kein Sicherheitsverzicht, sondern dokumentierte Microsoft-Vorgabe.

Welche Freigaben braucht ein SBC für Direct Routing?

Vier Beziehungen, alle eng geschnitten. Erstens Signalisierung Richtung Microsoft: SIP-TLS auf Port 5061 zu sip.pstnhub.microsoft.com und den Geschwister-Endpunkten. Zweitens Signalisierung von Microsoft: Die Cloud baut auch aktiv Verbindungen zum SBC auf — eingehend 5061, strikt beschränkt auf Microsofts SIP-Quellnetze, an die öffentliche Adresse des SBC (sauberes statisches 1:1-NAT oder eigene Public IP). Drittens die Medien: UDP 49152 bis 53247 beidseitig zu den Microsoft-Medien-Netzen. Viertens der Provider-Trunk: SIP und RTP-Bereich gemäß Provider-Vorgabe, eingegrenzt auf dessen IPs. Dazu die nicht verhandelbaren Rahmenbedingungen: eigene Firewall-Zone, öffentlicher FQDN mit Zertifikat einer öffentlichen CA (Microsoft lehnt anderes ab), deaktivierter SIP-Helper — und bei Media Bypass zusätzlich die direkten Medienpfade zwischen internen Clients und SBC. Die IP-Listen beider Gegenstellen gehören in gepflegte Hostgruppen, denn sie ändern sich — selten, aber zuverlässig dann, wenn niemand hinschaut.

Bringt Bandbreitenreservierung bei ausreichender Leitung etwas?

Ja — genau in den Momenten, in denen die »ausreichende« Leitung es kurzzeitig nicht ist. Der Denkfehler steckt im Durchschnitt: Eine im Mittel zu 30 Prozent ausgelastete Leitung ist trotzdem mehrmals täglich für Sekunden randvoll — ein Update-Schwung, die Cloud-Sicherung, ein ISO-Download. Für Web und Mail sind solche Spitzen unsichtbar; ein Sprachpaket in der Warteschlange ist sofort hörbar, denn Latenz- und Jitterspitzen entstehen exakt am gesättigten Puffer. QoS ist deshalb keine Bandbreiten-, sondern eine Versicherungsfrage: Die Garantie für die Sprachklasse kostet im Normalbetrieb nichts (ungenutzte Reserve steht allen zur Verfügung) und zahlt genau dann aus, wenn die Lastspitze kommt. Die ehrliche Grenze gehört dazu: QoS wirkt am eigenen Engpass — gegen einen überbuchten Provider-Backbone oder ein schwaches Heim-WLAN hilft die schönste Uplink-Queue nichts. Aber den eigenen Anteil macht sie deterministisch, und das ist mehr, als der Durchschnittswert je verspricht.

Fazit: Durchlassen, priorisieren, in Ruhe lassen

Teams-Telefonie durch die XGS ist kein Hexenwerk, sondern Disziplin in drei Sätzen: Die Medien brauchen ihren UDP-Weg zu den Relays (sonst Strohhalm-Modus über TCP — und die Transport-Spalte der Anrufanalyse verrät es), sie brauchen Vorfahrt am Uplink (Gesamtbandbreite hinterlegen, Audio-Garantie in beide Richtungen, Client-Markierung per GPO), und sie brauchen Ruhe vor jeder Inspektionsambition — kein TLS-Aufbruch, kein IPS, kein Proxy, kein SIP-ALG, auch nicht auf den internen VLAN-Übergängen. Mit Direct Routing kommt der SBC als vierter Satz dazu: eigene Zone, enge beidseitige Freigaben, öffentliches Zertifikat, sauberes NAT. Wer diese Liste abarbeitet, hat die Firewall-Seite der Sprachqualität deterministisch im Griff — und wenn es dann noch ruckelt, zeigt die Anrufanalyse messbar auf WLAN, Switch oder Homeoffice-Router statt auf das ewige Phantom »das Internet«.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen zeichnet der Pillar-Artikel [LINK: Pillar]. Die komplette Ausnahmen-Architektur der TLS-Inspection für Microsoft 365 — inklusive der hier verwendeten Medien-IP-Gruppen und ihrer automatisierten Pflege — steht in [LINK: A7]. Die Sicherheitsseite des SBC-Betriebs von Toll-Fraud bis Trunk-Härtung behandelt der Bestandsartikel [LINK: VoIP-Bestandsartikel]. Und die Teams-Telefonie-Gesamtsicht jenseits der Firewall — Rufnummernkonzepte, Lizenzen, Migrationswege — liefert der [LINK: Teams-Telefonie-Cluster].