TLS-Inspection und Microsoft 365: Warum Microsoft den Bypass empfiehlt — und wie du ihn richtig baust

Wer nach Sophos Microsoft 365 Exceptions sucht, hat meistens gerade ein sehr konkretes Problem: Teams klingt nach Roboter, Outlook hängt in der Verbindungsherstellung, und die Firewall glüht. Die Kurzantwort vorab: Microsoft teilt seine Cloud-Endpunkte in drei Kategorien — Optimize, Allow und Default — und sagt für die Optimize-Klasse unmissverständlich: kein TLS-Aufbruch, keine Paketinspektion, kürzester Weg ins Internet. Auf der XGS baust du das mit drei Objekten und drei Regeln: FQDN-Gruppen für die Optimize- und Allow-Endpunkte, eine IP-Gruppe für die Teams-Medien-Netze, dazu Nicht-entschlüsseln-Regeln ganz oben im SSL/TLS-Regelwerk und eine UDP-Freigabe für die Ports 3478 bis 3481. Das ist keine Sicherheitslücke, sondern Microsofts offizielle Architektur-Empfehlung — und dieser Artikel erklärt die Begründung dahinter, zeigt die saubere Umsetzung, die Automatisierung der Listenpflege und woran du eine falsche Konfiguration erkennst, bevor das Callcenter anruft.

Warum M365-Traffic besonders ist: die Endpunkt-Kategorien

Microsoft 365 ist aus Netzwerksicht kein gewöhnlicher Web-Dienst, sondern eine Mischung aus drei sehr unterschiedlichen Verkehrsarten — und genau deshalb hat Microsoft seine Endpunkte kategorisiert, statt sie in einen Topf zu werfen. Die Kategorie Optimize ist die kleinste und wichtigste: eine bewusst knapp gehaltene, stabile Liste von Endpunkten, über die der Löwenanteil des Volumens läuft — Exchange Online mit seinen langlebigen Outlook-Verbindungen, SharePoint und OneDrive mit ihren Massentransfers und der Teams-Medienverkehr, der in Echtzeit über UDP fließen will. Diese Endpunkte sind latenzkritisch, volumenstark und arbeiten teils mit Certificate Pinning — jede Inspektionsstufe dazwischen kostet spürbar Qualität.

Die Kategorie Allow umfasst den breiteren Satz an Endpunkten, den der Dienst zum Funktionieren braucht: die Anmeldung über login.microsoftonline.com, die Teams-Signalisierung, Microsoft Graph, Verwaltungsportale. Weniger Volumen, aber funktionskritisch — bricht hier etwas, geht gar nichts mehr. Und die Kategorie Default sammelt den Rest: Telemetrie, Hilfeinhalte, verlinkte Drittressourcen — normaler Internetverkehr ohne Sonderbehandlungsanspruch. Die Ampel-Skizze übersetzt die drei Kategorien in die eine Frage, die dich als Firewall-Admin interessiert: Darf ich das inspizieren?

Skizze 1: Optimize ist rot (Bypass), Allow ist gelb (bevorzugt ausnehmen), Default ist grün (volle Prüfung) — die Kategorie vergibt Microsoft, nicht du.

Microsofts offizielle Empfehlung und ihre Begründung

Das ist keine Grauzonen-Auslegung, sondern dokumentierte Herstellerposition: Microsofts Netzwerkprinzipien für Microsoft 365 empfehlen für Optimize-Endpunkte den direkten, lokalen Internetausgang ohne TLS-Aufbruch, ohne Paketinspektion und ohne Proxy-Umwege. Die Begründung ist handfest und dreiteilig. Erstens die Physik: Teams-Medien sind Echtzeitverkehr — jedes Millisekunden-Budget, das ein TLS-Aufbruch mit Entschlüsseln, Prüfen und Neuverschlüsseln verbraucht, fehlt der Sprachqualität; und wird das bevorzugte UDP blockiert oder durch einen Proxy gezwungen, fällt der Client auf TCP zurück, was für Echtzeitmedien ungefähr so geeignet ist wie ein Reisebus für die Formel 1. Zweitens die Masse: SharePoint- und OneDrive-Transfers durch die DPI zu quälen verbrennt genau die Inspektionsleistung, die laut Datenblatt ohnehin knapp ist — für Inhalte, die Microsoft bereits mehrstufig scannt. Und drittens die Technik: Etliche M365-Clients prüfen per Certificate Pinning, ob sie wirklich mit Microsoft sprechen — ein aufgebrochenes Zertifikat der Firewall quittieren sie mit Verbindungsabbruch oder Anmeldeschleife.

Dazu kommt ein Sicherheitsargument, das gern übersehen wird: Der Bypass ist kein Blindflug. Die Verbindung geht nachweislich zu Microsoft-Endpunkten — das stellen ja gerade die FQDN- und IP-Objekte sicher —, sie bleibt Ende-zu-Ende verschlüsselt, und die Inhalte durchlaufen Microsofts eigene Schutzschichten von Exchange Online Protection bis Defender. Die Firewall behält derweil alles, was auf Verbindungsebene passiert: Regelwerk, Protokollierung, ATP. Wer die gesparte DPI-Leistung stattdessen auf den unbekannten Rest des Internets richtet, hat unterm Strich mehr Sicherheit, nicht weniger — Prüfung dort, wo sie Erkenntnis bringt, statt dort, wo sie nur Latenz erzeugt.

Umsetzung auf der Sophos XGS: Microsoft-365-Exceptions sauber konfigurieren

Auf der XGS ist der Bypass ein überschaubares Bauprojekt — vorausgesetzt, die Web-Filterung läuft in der DPI-Engine, denn dort steuern die SSL/TLS-Inspection-Regeln fein granular, was entschlüsselt wird; falls bei dir noch der alte Proxy-Modus aktiv ist, lies zuerst den Artikel zu den Proxy-Modi. Baustein eins sind die Objekte: eine FQDN-Hostgruppe »M365-Optimize« mit den Exchange-Online-Hosts (outlook.office365.com, outlook.office.com) und den SharePoint-/OneDrive-Wildcards (*.sharepoint.com, *-my.sharepoint.com), eine IP-Hostgruppe »Teams-Medien« mit den Microsoft-Medien-Netzen (13.107.64.0/18, 52.112.0.0/14, 52.122.0.0/15) und eine FQDN-Gruppe »M365-Allow« für Anmeldung, Signalisierung und Graph. Wildcard-FQDNs halten die Listen klein und robust gegen neue Unterdomänen.

Baustein zwei ist das SSL/TLS-Inspection-Regelwerk, und hier gilt dasselbe eherne Gesetz wie überall auf der XGS: Reihenfolge schlägt Absicht. Ganz oben steht die Nicht-entschlüsseln-Regel mit den drei M365-Gruppen als Ziel, darunter die üblichen weiteren Ausnahmen (Pinning-Apps, Banken, Gesundheitsthemen), und erst darunter die Entschlüsseln-Regel für den Rest des Verkehrs. Baustein drei wird am häufigsten vergessen und ist für Teams der wichtigste: eine Firewall-Regel, die UDP auf den Ports 3478 bis 3481 zu den Teams-Medien-Netzen ausdrücklich erlaubt — denn der schönste TLS-Bypass nützt nichts, wenn der Client mangels UDP-Weg in den TCP-Fallback rutscht. Die Konfigurations-Skizze zeigt alle Bausteine im Zusammenhang, die Tabelle danach die wichtigsten Endpunkte mit Behandlungsempfehlung.

Skizze 2: Drei Objekte, drei Regeln, eine UDP-Freigabe — mehr ist der berühmte M365-Bypass auf der XGS nicht.

Endpunktlisten aktuell halten: Automatisierung statt Zettelwirtschaft

Die schlechteste Version dieser Konfiguration ist die, die einmal gebaut und nie wieder angefasst wird — Microsofts Endpunktliste lebt, und eine veraltete Ausnahmenliste produziert schleichend genau die Symptome, die der Bypass verhindern sollte. Die gute Nachricht: Die Pflege lässt sich klein halten. Der Optimize-Kern ist ausdrücklich auf Stabilität ausgelegt und ändert sich selten; die Bewegung findet vor allem in den Allow- und Default-Kategorien statt. Der pragmatische Pflegeprozess sieht so aus: Der Endpunkt-Webservice liefert neben der Liste auch eine Versionsnummer — ein kleiner geplanter Task (PowerShell oder Python, ein Dutzend Zeilen) fragt die Version regelmäßig ab und schlägt bei Änderungen Alarm, per Mail oder Teams-Nachricht. Dann schaust du gezielt nach, was sich geändert hat, statt blind zu synchronisieren.

Wer es vollautomatisch mag, geht den Schritt weiter: Das Skript zieht die aktuelle Liste, filtert auf die relevanten Kategorien und pflegt die FQDN- und IP-Gruppen über die XGS-API nach — mit einem Sicherheitsnetz aus Versionierung und Änderungsprotokoll, damit nachvollziehbar bleibt, wann welche Ausnahme dazukam. Für die meisten Mittelständler ist allerdings die halbautomatische Variante der Sweet Spot: automatischer Versions-Alarm, manueller Abgleich im Quartalsrhythmus, jede Änderung mit einem Satz dokumentiert. Das kostet viermal im Jahr zwanzig Minuten und verhindert beide Extreme — die vergessene Liste von 2023 ebenso wie den ungeprüften Vollsync, der sich nachts selbst kaputtkonfiguriert. Und noch ein Betriebshinweis: Die Ausnahmengruppen sind dieselben Objekte, die auch beim Geo-Blocking als Erlauben-Anker dienen — einmal sauber gepflegt, bedienen sie mehrere Baustellen gleichzeitig.

Was inspiziert werden darf und soll

Der Bypass für Optimize heißt ausdrücklich nicht, dass rund um Microsoft 365 Inspektionsverbot herrscht — im Gegenteil, die Kunst liegt in der Präzision. Volle Prüfung verdient alles in der Default-Kategorie und der gesamte Nicht-Microsoft-Verkehr: Dort leisten TLS-Inspection, Web-Filter, IPS und Malware-Scan genau das, wofür sie da sind, und dort landet auch die DPI-Leistung, die der Bypass freischaufelt. Auf Verbindungsebene bleibt außerdem alles aktiv, was keine Entschlüsselung braucht: Firewall-Regeln und Zonen, Application Control auf Verbindungsmustern, ATP mit seiner Botnet- und C2-Erkennung, DNS-Schutz und die Protokollierung — die Firewall sieht also weiterhin, wer wann mit welchen Microsoft-Endpunkten spricht, sie liest nur nicht mit.

Zwei bewusste Sonderfälle verdienen einen ehrlichen Absatz. Erstens Tenant Restrictions: Wer erzwingen will, dass sich aus dem Firmennetz nur der eigene Microsoft-Tenant nutzen lässt, muss dafür Header in die Anmelde-Verbindungen injizieren — und das erfordert gezielte TLS-Inspection auf den Login-Endpunkten, also exakt dort, wo sonst die Ausnahme gilt. Das ist machbar, aber eine dokumentierte Einzelfallentscheidung mit Test auf Pinning-Nebenwirkungen, kein Nebenbei-Häkchen. Zweitens die Inhaltskontrolle: Wer wissen will, welche Dateien in welche Cloud wandern, löst das besser API-seitig — mit Microsofts eigenen Bordmitteln von Defender bis DLP — statt netzwerkseitig gegen die Architektur des Dienstes anzukämpfen. Die Firewall ist für diese Frage schlicht der falsche Messpunkt. Wie sich M365-Verkehr insgesamt netzwerkseitig optimieren lässt — lokale Breakouts, Routing, DNS —, vertieft übrigens der Bestandsartikel zur M365-Traffic-Optimierung [LINK: Bestandsartikel M365-Traffic-Optimierung].

Symptome falscher Konfiguration erkennen

Falsch oder unvollständig gebaute M365-Ausnahmen haben ein charakteristisches Krankheitsbild — und wer es kennt, diagnostiziert in Minuten statt Tagen. Das Leitsymptom ist Teams: Sobald Medienverkehr über TCP statt UDP läuft oder durch die Entschlüsselung muss, kippen Sprachqualität und Stabilität zuerst — Robotersound, Aussetzer, einfrierende Bildschirmfreigaben, bevorzugt in den Stoßzeiten, wenn die Firewall ohnehin zu tun hat. Der objektive Beleg findet sich im Teams Admin Center: Die Anrufqualitäts-Daten zeigen, ob Medien über UDP laufen und wie Latenz und Jitter aussehen — ein hoher TCP-Anteil ist die rauchende Pistole. Auf der XGS-Seite verrät der Log Viewer, welche Regel den Verkehr behandelt und ob er durch die Entschlüsselung läuft.

Das zweite Symptom-Bündel liefert Outlook: hängende »Verbindung wird hergestellt«-Zustände, zäher Ordnerwechsel, sporadische Kennwortabfragen — typisch, wenn die langlebigen Exchange-Verbindungen durch Inspektions- oder Proxy-Puffer laufen und an Timeouts sterben. Drittens die Anmeldung: Schleifen und Zertifikatsfehler in Office-Apps deuten fast immer auf entschlüsselte Login-Endpunkte und kollidierendes Certificate Pinning. Die Symptom-Tabelle ordnet die Klassiker ihren Ursachen zu — und die Traffic-Pfad-Skizze zeigt noch einmal im Vergleich, warum derselbe Teams-Call auf dem einen Weg leidet und auf dem anderen läuft.

Skizze 3: Derselbe Call, zwei Wege — oben die Leidensgeschichte mit Aufbruch und TCP-Fallback, unten die grüne Welle mit UDP und FastPath.

FAQ — häufige Fragen zu TLS-Inspection und Microsoft 365

Welche Microsoft-365-URLs muss ich von der TLS-Inspection ausnehmen?

Den Kern bilden die Optimize-Endpunkte: outlook.office365.com und outlook.office.com für Exchange Online, die Wildcards *.sharepoint.com und *-my.sharepoint.com für SharePoint und OneDrive sowie die Teams-Medien-Netze 13.107.64.0/18, 52.112.0.0/14 und 52.122.0.0/15 — Letztere zusammen mit einer UDP-Freigabe für die Ports 3478 bis 3481. Dringend empfohlen dazu die wichtigsten Allow-Endpunkte, allen voran login.microsoftonline.com (Certificate Pinning!), *.teams.microsoft.com und graph.microsoft.com. Verbindliche und vollständige Quelle ist Microsofts Endpunkt-Webservice unter endpoints.office.com — baue deine FQDN- und IP-Gruppen nach dieser Liste und halte sie über deren Versionsstand aktuell, nicht nach Blogartikeln oder Forenbeiträgen.

Warum bricht Teams hinter der Firewall ab?

In neun von zehn Fällen aus einem von zwei Gründen — oder beiden gleichzeitig. Grund eins: Der Medienverkehr findet keinen UDP-Weg, weil die Ports 3478 bis 3481 zu den Microsoft-Medien-Netzen nicht freigegeben sind; der Client fällt auf TCP über Port 443 zurück, und TCP ist für Echtzeitmedien konstruktionsbedingt ungeeignet — Robotersound und Abbrüche sind die Folge. Grund zwei: Der Medien- oder Signalisierungsverkehr läuft durch die TLS-Entschlüsselung und sammelt dort Latenz und Störungen ein. Die Diagnose liefert das Teams Admin Center: Ein niedriger UDP-Anteil in den Anrufqualitätsdaten ist der eindeutige Beleg. Die Therapie: Optimize-Bypass plus UDP-Regel setzen — danach normalisieren sich die Qualitätswerte erfahrungsgemäß binnen Tagen.

Ist der Bypass nicht ein Sicherheitsrisiko?

Die ehrliche Antwort: nein — sofern er präzise gebaut ist. Der Bypass gilt ausschließlich für verifizierte Microsoft-Endpunkte, festgemacht an FQDN- und IP-Objekten; er ist kein Freifahrtschein für beliebigen Verkehr. Die Verbindungen bleiben Ende-zu-Ende verschlüsselt, die Inhalte durchlaufen Microsofts eigene Schutzschichten, und deine Firewall behält alles auf Verbindungsebene: Regeln, Zonen, ATP, Protokollierung. Was du aufgibst, ist die Inhaltseinsicht in Verkehr, den du ohnehin kaum sinnvoll prüfen könntest — Certificate Pinning und Massenvolumen stehen dem entgegen. Was du gewinnst, ist DPI-Leistung für den Verkehr, bei dem Inspektion tatsächlich Erkenntnis bringt. Wer Inhaltskontrolle über M365-Daten braucht, setzt sie API-seitig um — mit Defender und DLP — statt netzwerkseitig gegen die Architektur des Dienstes.

Wie halte ich die M365-Endpunktliste automatisch aktuell?

Über Microsofts Endpunkt-Webservice, der die Liste maschinenlesbar samt Versionsnummer bereitstellt. Die pragmatische Ausbaustufe eins: Ein kleines Skript (PowerShell oder Python) fragt regelmäßig die Version ab und meldet Änderungen per Mail oder Teams-Nachricht — du gleichst dann gezielt ab, was sich geändert hat; im Quartalsrhythmus sind das typischerweise zwanzig Minuten Arbeit. Ausbaustufe zwei für Automatisierungsfreunde: Das Skript zieht die Liste, filtert auf Optimize und Allow und pflegt die FQDN- und IP-Gruppen über die XGS-API nach — zwingend mit Änderungsprotokoll und der Möglichkeit, einen Stand zurückzurollen. Beruhigend dabei: Der Optimize-Kern ist bewusst stabil gehalten und ändert sich selten; die eigentliche Fleißarbeit steckt in den Allow-Endpunkten, und genau dort hilft der Versions-Alarm am meisten.

Gilt der Bypass auch für QoS?

Nein — die beiden ergänzen sich, ersetzen sich aber nicht. Der Bypass sorgt dafür, dass der M365-Verkehr ungebremst durch die Firewall kommt: kein TLS-Aufbruch, keine Scan-Latenz, UDP bleibt UDP. QoS beantwortet die andere Frage — was passiert, wenn die Leitung voll ist: Dann entscheidet die Priorisierung, dass das Teams-Gespräch Vorrang vor dem parallelen Backup-Upload bekommt. Ein perfekter Bypass rettet dich also nicht vor einer gesättigten Leitung, und das beste QoS nützt wenig, wenn die Medien vorher durch die Entschlüsselung gequält werden — für saubere Telefonie brauchst du beides. Wie die Priorisierung für Teams konkret aussieht — DSCP-Markierungen, Bandbreitenklassen und die Umsetzung auf der XGS — ist Thema des eigenen QoS-Artikels [LINK: B7].

Was darf ich bei M365-Traffic trotzdem inspizieren?

Mehr, als der Begriff »Bypass« vermuten lässt. Volle Inspektion ist ausdrücklich in Ordnung für die Default-Kategorie — Telemetrie, Hilfeinhalte, verlinkte Drittressourcen — und selbstverständlich für allen Nicht-Microsoft-Verkehr. Auf Verbindungsebene bleiben außerdem sämtliche Kontrollen aktiv, die keine Entschlüsselung brauchen: Firewall-Regeln und Zonen, ATP mit Botnet- und C2-Erkennung, DNS-Schutz, Application Control und die vollständige Protokollierung, wer wann mit welchen Endpunkten spricht. Der eine bewusste Sonderfall: Tenant Restrictions, die den Zugriff auf fremde Microsoft-Tenants unterbinden, erfordern Header-Injection und damit gezielte Entschlüsselung der Login-Endpunkte — machbar, aber als dokumentierte Einzelentscheidung mit Pinning-Tests, nicht als Nebenwirkung. Kurzformel: Verbindungsebene immer, Inhalte bei Optimize nie, dazwischen mit Begründung.

Fazit: Prüfen, was prüfenswert ist

Der M365-Bypass ist eine der seltenen Konfigurationen, bei denen Sicherheit, Performance und Herstellervorgabe in dieselbe Richtung zeigen: Microsoft sagt für die Optimize-Endpunkte unmissverständlich »kürzester Weg, kein Aufbruch«, die XGS setzt das mit drei Objekten, drei Regeln und einer UDP-Freigabe um, und der Lohn ist messbar — Teams-Medien über UDP, stabile Outlook-Verbindungen, eine entlastete Firewall-CPU und eine DPI-Engine, die ihre Kraft dort einsetzt, wo Inspektion tatsächlich Erkenntnis bringt. Die einzige Dauerpflicht ist die Listenpflege, und die schrumpft mit einem Versions-Alarm auf Quartals-Minuten. Wer den Bypass verweigert, kämpft nicht gegen Angreifer, sondern gegen die Architektur eines Dienstes, den die eigene Belegschaft jeden Tag benutzt — ein Kampf, den noch keine Firewall gewonnen hat.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen zeichnet der Pillar-Artikel [LINK: Pillar]. Ob deine Web-Filterung überhaupt im richtigen Modus läuft, um die Ausnahmen sauber umzusetzen, klärt der Artikel zu den Proxy-Modi [LINK: A6]. Was nach dem Bypass die Gesprächsqualität weiter absichert — Priorisierung per QoS und DSCP — steht in [LINK: B7]. Und die netzwerkseitige Gesamtoptimierung des M365-Verkehrs vertieft der Bestandsartikel [LINK: Bestandsartikel M365-Traffic-Optimierung].