Proxy-Modi der Sophos XGS erklärt: Transparent, Standard und die DPI-Engine

Der Sophos-Proxy ist ein Begriff, unter dem drei sehr verschiedene Betriebsarten laufen — und wer sie verwechselt, wundert sich über Zertifikatswarnungen, Anmelde-Popups oder verschenkten Durchsatz. Die Kurzantwort vorab: Die DPI-Engine ist seit SFOS 18 der Standard und für fast alle Umgebungen die richtige Wahl — sie prüft den Verkehr im Datenstrom der Firewall, ohne Verbindungen zu terminieren, und ist mit Abstand am schnellsten. Der transparente Proxy und der Standard-Proxy sind die Altmodi mit jeweils eigenem Verhalten bei Zertifikaten und Authentifizierung; ihre verbliebene Daseinsberechtigung sind explizite Proxy-Vorgaben und einzelne Legacy-Anforderungen. Der Haken: Viele Umgebungen fahren die Altmodi nicht aus Überzeugung, sondern aus Gewohnheit — mitgeschleppt aus UTM- und XG-Zeiten. Dieser Artikel sortiert die drei Modi, erklärt ihr Zertifikats- und Auth-Verhalten, zeigt die Performance-Wahrheit und liefert den Migrationspfad zur DPI-Engine — samt der Fallstricke, die der Wechsel bereithält.

Die drei Modi im Überblick: transparenter Proxy, Standard-Proxy, DPI-Engine

Sortieren wir zuerst die Begriffe, denn hier beginnt die halbe Verwirrung. Der transparente Proxy fängt Web-Verkehr auf den Ports 80 und 443 ab, ohne dass die Clients davon wissen — keine Proxy-Einstellung nötig, die Firewall leitet still um. Technisch terminiert ein Proxy-Prozess auf der XGS die Verbindung des Clients, prüft die Inhalte und baut eine neue Verbindung zum Ziel auf. Der Standard-Proxy (auch expliziter Proxy) macht dasselbe, aber mit Ansage: Die Clients kennen den Proxy — typischerweise auf Port 3128, verteilt per Gruppenrichtlinie oder WPAD — und sprechen ihn gezielt an. Der entscheidende Bonus dieser Ehrlichkeit: Ein explizit angesprochener Proxy darf sich beim Client ausweisen lassen, Stichwort HTTP-407-Authentifizierung, dazu gleich mehr.

Die DPI-Engine schließlich ist kein Proxy im klassischen Sinn, sondern die moderne Antwort der Xstream-Architektur: Web-Filterung, Application Control, Malware-Prüfung und IPS laufen als Stream-Scan direkt im Datenpfad der Firewall — die Verbindung zwischen Client und Ziel bleibt eine einzige, wird nicht terminiert und nicht neu aufgebaut, und bereits als sauber eingestufte Flows wandern auf den FastPath. Gesteuert wird das pro Firewall-Regel: Standardmäßig übernimmt die DPI-Engine, und nur wenn in der Regel ausdrücklich die Option gesetzt ist, den Web-Proxy zu verwenden, läuft der Verkehr durch den Altmodus. Genau dieses Häkchen ist übrigens der Ort, an dem in gewachsenen Umgebungen die Vergangenheit wohnt. Die erste Skizze stellt die drei Datenpfade nebeneinander.

Skizze 1: Beide Proxys terminieren und bauen neu — die DPI-Engine prüft im Vorbeiflug und lässt die Verbindung ganz.

Zertifikats- und Authentifizierungsverhalten je Modus

Jetzt zu den beiden Themen, die im Alltag die meisten Tickets produzieren. Zuerst die Zertifikate: Sobald HTTPS-Verkehr inhaltlich geprüft werden soll, muss die Firewall die Verschlüsselung aufbrechen — sie beendet die TLS-Verbindung des Clients und präsentiert ihm ein selbst ausgestelltes Zertifikat für die Zielseite, signiert von einer CA auf der XGS. Das gilt für alle drei Modi gleichermaßen; nur der Mechanismus unterscheidet sich: Beim Proxy ist die HTTPS-Entschlüsselung eine Einstellung im Web-Filter, bei der DPI-Engine steuern eigene SSL/TLS-Inspection-Regeln, was entschlüsselt wird — deutlich feiner steuerbar, etwa nach Zonen, Kategorien und Ausnahmen. Die eiserne Voraussetzung ist in jedem Fall dieselbe: Die signierende CA muss auf allen Geräten als vertrauenswürdig hinterlegt sein, sonst hagelt es Warnungen. Und wichtig für die Diagnose: Ein Standard-Proxy ohne aktivierte Entschlüsselung tunnelt HTTPS per CONNECT einfach durch — dann bleibt das Original-Zertifikat unangetastet und Warnungen haben eine andere Ursache.

Bei der Authentifizierung — also der Frage, welcher Benutzer hinter dem Verkehr steckt — trennen sich die Modi deutlich. Der Standard-Proxy hat hier sein Alleinstellungsmerkmal: Weil der Client ihn bewusst anspricht, darf er mit dem HTTP-Statuscode 407 eine Proxy-Anmeldung verlangen, und mit sauber eingerichtetem AD-SSO über Kerberos oder NTLM passiert das für den Benutzer unsichtbar. Transparenter Proxy und DPI-Engine können das prinzipbedingt nicht — der Client weiß ja nichts von ihnen, ein 407 käme für ihn aus dem Nichts. Beide beziehen die Benutzerinformation deshalb aus anderen Quellen: STAS, das Anmeldeereignisse der Domain Controller auswertet, die Sophos-Clients beziehungsweise der Heartbeat des Sophos-Endpoints, oder als letzte Instanz das Captive Portal. Für klassische AD-Umgebungen funktioniert das zuverlässig; spannend wird es bei reinen Entra-ID-Geräten ohne lokale AD-Anmeldung — wie die Identitätsanbindung dann aussieht, gehört in den Themenkreis der Entra-Integration [LINK: B1]. Die Vergleichsmatrix fasst das Verhalten zusammen.

Performance-Unterschiede in der Praxis

Die Architektur aus Kapitel eins übersetzt sich direkt in Leistung. Ein Proxy-Prozess terminiert jede Verbindung, puffert Inhalte, prüft sie und baut die Verbindung zum Ziel neu auf — das kostet CPU, Speicher und vor allem Latenz, und zwar pro Verbindung, von der eine moderne Webseite gern Dutzende gleichzeitig öffnet. Die DPI-Engine prüft dagegen im Datenstrom: keine Terminierung, keine doppelte Verbindungsverwaltung, ein einziger Scan-Durchlauf für Web, Apps, Malware und IPS — und Flows, deren Prüfung abgeschlossen ist, wandern auf den FastPath, auf den Rack-Modellen hardware-beschleunigt über den Xstream-Flow-Prozessor. Die Durchsatzwerte in den Sophos-Datenblättern beziehen sich auf genau diese Engine; wer den Proxy-Modus fährt, bewegt sich spürbar darunter.

In Zahlen lässt sich der Proxy-Malus nicht seriös auf eine Prozentangabe festnageln, weil er von Verbindungszahl, Dateigrößen und aktivierten Prüfungen abhängt — aber das Muster aus der Praxis ist eindeutig: Umgebungen, die vom flächigen Proxy-Betrieb auf die DPI-Engine wechseln, berichten von spürbar flotterem Seitenaufbau (die Latenz pro Verbindung sinkt), niedrigerer CPU-Grundlast auf der Firewall und deutlich entspannteren Lastspitzen am Morgen. Der Effekt ist umso größer, je kleiner die Box — auf einer Desktop-XGS ist der Proxy-Overhead ein relevanter Posten im Budget, das ohnehin knapp ist, sobald TLS-Inspection mitläuft. Was TLS-Aufbruch generell kostet und wie du die Last über kluge Ausnahmen steuerst, steht im Artikel zur TLS-Inspection [LINK: A7]; die Kurzfassung für hier: Der Modus entscheidet, wie effizient geprüft wird — die Inspection-Ausnahmen entscheiden, wie viel geprüft werden muss. Beides zusammen ergibt die Performance.

Migrationspfad zum DPI-Modus

Die gute Nachricht zuerst: Die Migration ist kein Big Bang, denn der Modus hängt an der einzelnen Firewall-Regel — du kannst also Regel für Regel, Zone für Zone umstellen und jederzeit zurück. Der Fahrplan hat fünf Phasen. Phase eins ist die Inventur: Welche Regeln tragen das Proxy-Häkchen, wie kommen die Clients an ihre Proxy-Einstellung (GPO, WPAD, Handarbeit — alles dokumentieren!), und welche Proxy-Funktionen werden wirklich genutzt? Der wichtigste Einzelpunkt dabei: Läuft die Benutzerauthentifizierung über den 407-Mechanismus des Standard-Proxys? Dann muss vor der Migration die Identitätsquelle geklärt sein — in AD-Umgebungen übernimmt STAS, ergänzt um die Sonderfälle wie Terminalserver.

Phase zwei legt das Fundament: die Signing-CA an sämtliche Geräte verteilen und die SSL/TLS-Inspection-Regeln bauen, die im DPI-Modus die Entschlüsselung steuern — inklusive der Pflicht-Ausnahmen für Microsoft 365 und die üblichen Pinning-Kandidaten. Phase drei ist der Pilot: eine unkritische Zone umstellen, eine Woche Logs und Tickets beobachten. Phase vier rollt in Wellen über die restlichen Regeln, wobei jede auffällige Anwendung eine dokumentierte Ausnahme bekommt statt eines Rollbacks. Und Phase fünf wird gern vergessen, ist aber die halbe Miete: die Proxy-Einstellungen von den Clients entfernen — GPO zurückbauen, WPAD-Einträge löschen — und die verwaisten Proxy-Regeln von der Firewall. Wer das auslässt, betreibt dauerhaft einen Zombie-Mischbetrieb. Die dritte Skizze zeigt den Fahrplan im Überblick.

Skizze 2: Fünf Phasen, klare Reihenfolge — die CA-Verteilung in Phase zwei ist der Schritt, den man nicht überspringen darf.

Troubleshooting typischer Proxy-Probleme

Zum Abschluss die Werkstatt. Die meisten Web-Filter-Tickets lassen sich einem von wenigen Mustern zuordnen — und das Muster verrät fast immer den Modus, in dem das Problem wohnt. Das wichtigste Diagnosewerkzeug ist der Log Viewer der XGS: Er zeigt, ob eine Verbindung durch Proxy oder DPI lief, welche Regel griff und woran es scheiterte. Zweites Werkzeug ist der Blick auf den Client: Steht dort noch eine Proxy-Einstellung (Systemsteuerung, Browser, WPAD), obwohl die Umgebung längst auf DPI laufen sollte? Solche Reste sind die häufigste Ursache für die beliebte Kategorie »geht nur bei manchen Kollegen nicht«. Die Tabelle sammelt die Klassiker samt Ursache und Abhilfe.

Ein Wort noch zu einem Troubleshooting-Thema der anderen Art: Was die Firewall im Web-Verkehr sehen kann, ist nicht nur eine Technik-, sondern auch eine Mitbestimmungsfrage — spätestens wenn HTTPS-Entschlüsselung und personenbezogene Auswertungen ins Spiel kommen, gehört der Betriebsrat an den Tisch, bevor die Konfiguration scharf geschaltet wird. Wie der Fahrplan durch Mitbestimmung und Datenschutz aussieht und welche Konfiguration datensparsam bleibt, behandelt ausführlich der Artikel zu TLS-Inspection und Betriebsrat [LINK: C3].

FAQ — häufige Fragen zu den Proxy-Modi der Sophos XGS

Was ist der Unterschied zwischen transparentem und Standard-Proxy?

Beide sind klassische Proxys — sie terminieren die Verbindung des Clients, prüfen die Inhalte und bauen eine neue Verbindung zum Ziel auf. Der Unterschied liegt darin, ob der Client davon weiß: Beim transparenten Proxy nicht — die Firewall leitet Port-80/443-Verkehr still um, keine Client-Konfiguration nötig, dafür keine Proxy-Authentifizierung möglich. Beim Standard-Proxy (explizit) kennt der Client den Proxy per GPO, WPAD oder manueller Einstellung und spricht ihn gezielt an — und genau deshalb darf der Proxy hier per HTTP 407 eine Anmeldung verlangen, mit AD-SSO auch unsichtbar für den Benutzer. Kurz: transparent ist bequem in der Verteilung, explizit ist stark in der Authentifizierung — und beide sind heute die Ausnahme neben der DPI-Engine.

Wann sollte ich die DPI-Engine statt des Proxys nutzen?

Im Zweifel: immer — sie ist seit SFOS 18 der Standard, und die Beweislast liegt beim Proxy, nicht bei ihr. Die DPI-Engine prüft im Datenstrom statt per Verbindungsterminierung, ist damit die mit Abstand schnellste Variante, nutzt den FastPath samt Hardware-Beschleunigung der Rack-Modelle und steuert die HTTPS-Entschlüsselung über fein granulare SSL/TLS-Inspection-Regeln. Für den Proxy sprechen heute nur noch zwei Dinge: eine harte Vorgabe für einen expliziten Proxy — etwa Clients ohne Default-Route ins Internet oder eine Konzernrichtlinie — sowie einzelne, dokumentierte Legacy-Anforderungen, die nachweislich nur der Proxy erfüllt. Beides sind begründete Ausnahmen für einzelne Regeln, kein Betriebsmodell für die ganze Firma.

Warum kommen Zertifikatswarnungen bei Benutzern an?

Weil die Firewall bei aktivierter HTTPS-Prüfung die Verschlüsselung aufbricht und den Clients ein selbst signiertes Zertifikat für die Zielseite präsentiert — und die Geräte, die warnen, kennen die signierende CA der XGS nicht als vertrauenswürdig. Der Klassiker: Domänen-PCs haben die CA per GPO bekommen, aber BYOD-Geräte, Nicht-Domänen-Notebooks, Smartphones im Firmen-WLAN oder das übernommene Tochterunternehmen nicht. Zweiter Verdächtiger: Anwendungen mit Certificate Pinning, die grundsätzlich nur ihr Original-Zertifikat akzeptieren — die brauchen eine Inspection-Ausnahme statt einer CA. Und der Vollständigkeit halber: Ein Standard-Proxy ohne Entschlüsselung tunnelt HTTPS unangetastet durch — kommen dort Warnungen an, liegt die Ursache woanders, etwa an einem echten Zertifikatsproblem der Zielseite.

Funktioniert AD-SSO im transparenten Modus?

Nicht über den Proxy-Mechanismus — das ist prinzipbedingt: Die 407-Proxy-Authentifizierung setzt voraus, dass der Client wissentlich mit einem Proxy spricht, und genau das tut er im transparenten Modus nicht. Ein unsichtbares SSO gibt es trotzdem, nur auf anderem Weg: Die XGS ordnet Verkehr Benutzern über STAS zu, das die Anmeldeereignisse der Domain Controller auswertet — meldet sich ein Benutzer an seinem PC an, kennt die Firewall ab diesem Moment die Zuordnung von IP zu Benutzer, ganz ohne Browser-Dialog. Alternativ liefern die Sophos-Clients beziehungsweise der Endpoint-Heartbeat die Identität, und als Rückfallebene bleibt das Captive Portal. Wackelig wird die Zuordnung bei Terminalservern (viele Benutzer, eine IP) und bei reinen Entra-ID-Geräten ohne klassische AD-Anmeldung — beides sind lösbare Sonderfälle, aber eben Sonderfälle mit eigener Konfiguration.

Wie migriere ich vom Standard-Proxy zur DPI-Engine?

Regelweise und in fünf Phasen — ein Big Bang ist weder nötig noch klug. Erstens Inventur: Regeln mit Proxy-Häkchen, GPO-/WPAD-Verteilung und genutzte Proxy-Funktionen erfassen; kritischster Punkt ist die 407-Authentifizierung, für die eine alternative Identitätsquelle (STAS) stehen muss. Zweitens Fundament: Signing-CA an wirklich alle Geräte verteilen und die SSL/TLS-Inspection-Regeln samt Microsoft-365- und Pinning-Ausnahmen bauen. Drittens Pilot: eine unkritische Zone umstellen, eine Woche beobachten. Viertens Wellen: die übrigen Regeln nacheinander, Auffälligkeiten per dokumentierter Ausnahme statt Rollback lösen. Fünftens Aufräumen: Proxy-Einstellungen von den Clients (GPO zurückbauen, WPAD löschen) und verwaiste Proxy-Regeln von der Firewall entfernen — sonst bleibt ein Mischbetrieb zurück, in dem niemand mehr weiß, wer wo geprüft wird.

Welcher Modus ist am schnellsten?

Eindeutig die DPI-Engine, und zwar aus Architekturgründen: Sie prüft den Verkehr im Datenstrom, ohne Verbindungen zu terminieren und neu aufzubauen, erledigt Web-, App-, Malware- und IPS-Prüfung in einem Durchlauf und schickt fertig geprüfte Flows auf den FastPath — auf den Rack-Modellen zusätzlich hardware-beschleunigt durch den Xstream-Flow-Prozessor. Die Durchsatzangaben der Sophos-Datenblätter beziehen sich auf diese Engine. Beide Proxy-Modi liegen darunter, weil jede Verbindung terminiert, gepuffert und doppelt verwaltet wird — spürbar vor allem als Latenz beim Seitenaufbau und als CPU-Grundlast, und am deutlichsten auf den kleineren Desktop-Modellen. Zwischen transparentem und Standard-Proxy ist der Unterschied dagegen marginal; sie teilen sich dieselbe Mechanik und damit denselben Malus.

Fazit: Der Proxy ist Geschichte mit Restlaufzeit

Die Landkarte ist übersichtlicher, als der Begriffsnebel vermuten lässt: Die DPI-Engine ist seit Jahren der Standard und in Performance, Granularität und Betriebssicherheit die beste Wahl — sie prüft, wo der Verkehr ohnehin vorbeikommt, und lässt sich von keiner vergessenen Client-Einstellung austricksen. Der Standard-Proxy behält seine Nische, wo explizite Proxys gefordert sind und das 407-SSO gebraucht wird; der transparente Proxy ist eine Übergangslösung mit Ablaufdatum. Wer heute noch flächig im Proxy-Modus fährt, sollte die Migration nicht als Pflichtübung sehen, sondern als das, was sie ist: bezahlte Leistung endlich abrufen, Zertifikats- und Auth-Verhalten vereinheitlichen und nebenbei die Lücken schließen, durch die bisher die halbe Flotte lief. Fünf Phasen, kein Big Bang — und am Ende ein Web-Filter, der zur Firewall passt, die man gekauft hat.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen liefert der Pillar-Artikel [LINK: Pillar]. Was nach dem Moduswechsel die eigentliche Feinarbeit ist — die TLS-Inspection mit sauberen Microsoft-365-Ausnahmen — steht in [LINK: A7]. Wie die Benutzerzuordnung in modernen Identitätslandschaften bis hin zu Entra ID funktioniert, behandelt [LINK: B1]. Und warum die Sichtbarkeits-Frage des Web-Filters auch eine Mitbestimmungs-Frage ist, klärt der Betriebsrats-Artikel [LINK: C3].