Sophos ZTNA Gateway planen, bereitstellen und betreiben

Ein Sophos ZTNA Gateway verbindet berechtigte Benutzer mit internen Anwendungen. Für die Bereitstellung gibt es drei unterstützte Wege: eine lokale Gateway-VM auf VMware ESXi oder Microsoft Hyper-V, eine Sophos-Cloud-Gateway-VM auf einem dieser Hypervisoren oder ein Sophos Cloud Gateway auf einer zentral verwalteten Sophos Firewall. Dieses Runbook führt von der Auswahl bis zur Abnahme und zum sicheren Rückweg. Für die vorgelagerte Entscheidung zwischen ZTNA und klassischem Remote Access helfen Sophos Connect oder SSL VPN: Welche Remote-Access-Lösung passt? und Zero Trust einfach erklärt: ZTNA statt klassischem VPN.

Die aktuelle Oberfläche heisst Sophos Fusion (ehemals Sophos Central); ältere Hilfetexte und einige Abbildungen verwenden noch Sophos Central. Die hier ausgeschriebenen aktuellen Pfade und Feldnamen sind massgebend, wenn eine Abbildung abweicht.

Zweck und direkte Antwort

Den Gateway-Typ wählt man nach Datenpfad und Betriebsverantwortung, nicht nach der Anzahl der Klicks:

Lokales Gateway

• Unterstützte Plattform: ESXi oder Hyper-V
• Datenpfad und Exposition: Gateway und Datenebene laufen im Kunden-Rechenzentrum; das Gateway ist aus dem Internet erreichbar.
• Wesentliche Netzanforderung: An den externen Schnittstellen nur TCP 80 und 443 eingehend öffnen, beide Ports per DNAT weiterleiten, alle anderen eingehenden Ports blockieren. Keinen Reverse-Proxy vorschalten.

Sophos Cloud Gateway als VM

• Unterstützte Plattform: ESXi oder Hyper-V
• Datenpfad und Exposition: Sophos verwaltet den Cloud-Einstieg; die VM verbindet die Sophos Cloud mit internen Ressourcen und ist nicht als eigener Internet-Einstieg veröffentlicht.
• Wesentliche Netzanforderung: An der externen Gateway-Schnittstelle nur TCP 443 ausgehend öffnen; öffentliche CNAMEs und private DNS-Auflösung bereitstellen.

Sophos Cloud Gateway auf Sophos Firewall

• Unterstützte Plattform: zentral verwaltete Hardware-, Cloud-, virtuelle oder Software-Firewall ab SFOS 19.5 MR3
• Datenpfad und Exposition: Keine separate Gateway-VM; Authentifizierung und Autorisierung erfolgen in der Sophos Cloud.
• Wesentliche Netzanforderung: Firewall muss von Sophos Fusion verwaltet werden; Region, Identitätsanbieter, Zertifikat und besondere Redirect-URL einplanen.

Eine VM kann einarmig oder zweiarmig bereitgestellt werden. Einarmig verwendet die externe Schnittstelle für ein- und ausgehenden Verkehr und minimiert Infrastrukturänderungen. Zweiarmig trennt externe und interne Schnittstelle, benötigt zwei Netzwerkkarten und gegebenenfalls statische Routen; diese Variante bietet laut Hersteller die beste Sicherheit und den besten Durchsatz. Die getrennte Anleitung Server mit DNAT auf Sophos Firewall veröffentlichen erklärt die zugrunde liegende Firewall-Funktion; die ZTNA-spezifische Portvorgabe folgt unten.

Voraussetzungen, Lizenz und Rollen

Lizenz und administrative Rollen

• Für ZTNA-Funktionen muss die passende Lizenz vorhanden sein. Die Gateway-Release-Notes kennzeichnen Funktionen ausdrücklich als lizenzabhängig.
• Sophos Fusion Firewall Management benötigt eine kostenpflichtige Subscription zusätzlich zur Base-Firewall-Lizenz.
• Zum Registrieren einer Firewall bei Sophos Fusion ist ein Central Super Admin erforderlich. Alternativ kann dieser Administrator anhand der Firewall-Seriennummer ein OTP erzeugen und an den Firewall-Administrator übergeben; das OTP ist 14 Tage gültig.
• Die zugewiesenen Benutzergruppen müssen in Sophos Fusion synchronisiert sein. Unterstützt werden Microsoft Entra ID oder Active Directory als Verzeichnisdienst. Als Identitätsanbieter sind Microsoft Entra ID, Okta und lokales Active Directory dokumentiert.
• Entra-ID-Gruppen müssen sicherheitsaktiviert sein. Bei direkt in Entra ID erstellten Gruppen ist das automatisch der Fall; aus AD importierte oder über das Microsoft-365-Portal erstellte Gruppen können davon abweichen.

Die ausgewertete Gateway-Dokumentation nennt keine feinere ZTNA-Administratorrolle. Wenn das Konto die beschriebenen Menüs oder Aktionen nicht sieht, Rechte nicht durch Versuch und Irrtum erweitern, sondern die tenant-spezifische Rollenvergabe durch einen autorisierten Sophos-Fusion-Administrator prüfen lassen.

Zertifikat

Für das Gateway ist ein Wildcard-Zertifikat erforderlich. Unterstützt sind Zertifikate von Let’s Encrypt oder einer vertrauenswürdigen Zertifizierungsstelle:

• RSA mit mindestens 2048 Bit;
• ECDSA, jedoch nicht mit P-384 oder P-521.

Bei der VM-Bereitstellung wird ein einzelnes Wildcard-Zertifikat unterstützt. Zertifikat und privaten Schlüssel bereithalten. In den Gateway-Details unter Certificate lassen sie sich hochladen; alternativ kann Sophos Fusion dort ein Let’s-Encrypt-Zertifikat erzeugen.

Die praktische Beschaffung behandelt Let’s Encrypt Wildcard-Zertifikat erstellen. Für direkt auf Sophos Firewall verwaltete Zertifikate ist Let’s Encrypt Zertifikate auf Sophos Firewall verwalten der getrennte Betriebsablauf.

Host, Zeit und Kapazität

SSDs werden für gleichmässigere Disk-I/O-Leistung empfohlen. Datum und Uhrzeit des Hosts müssen stimmen; die Zeitzone muss UTC sein. Das Gateway übernimmt die Hostzeit und kann bei falscher Zeit nicht korrekt arbeiten.

Für die Skalierung von Gateway-VMs nennt Sophos 10’000 Agentverbindungen pro Knoten und bis zu 90’000 Agentverbindungen in einem Cluster mit höchstens neun Knoten. Diese Herstellerangaben sind keine garantierte Durchsatzleistung und keine Benutzer- oder Lizenzzählung. Sie werden nicht pauschal auf ein Gateway auf Sophos Firewall oder auf agentenlose Browser-Sitzungen übertragen. Für die Planung bleiben Hostressourcen, Anwendungslast und die gewünschte Reserve bei einem Knotenausfall separat zu bewerten; die unten beschriebenen Clusterregeln und Pilotprüfungen gelten weiterhin.

Netzwerk, IPv4 und erlaubte Ziele

• Für das Gateway weder 10.42.0.0/16 noch 10.43.0.0/16 oder 10.108.0.0/16 verwenden. Diese Netze sind internen Diensten vorbehalten.
• IPv6 wird für Gateways nicht unterstützt. Gateway und Endpoints in diesem Szenario keine IPv6-Adressen per DHCP zuweisen. Bereits konfigurierte Endpoints müssen IPv6 manuell deaktivieren.
• Eine statische IPv4-Adresse oder eine DHCP-Reservierung verwenden. Ein Gateway kann eine spätere Änderung seiner IP-Adresse nicht verarbeiten.
• Wenn Benutzer aus demselben Netz wie das Gateway auf ZTNA-Ressourcen zugreifen, verhindert eine SNAT-Regel vom Typ MASQ asymmetrisches Routing.
• Bei mehreren Gateway-Knoten müssen alle Knoten im selben Subnetz liegen und untereinander eine sehr geringe Latenz haben.

Für ein lokales Gateway hinter einer Firewall müssen die folgenden Ziele erreichbar sein, normalerweise über TCP 443:

• sophos.jfrog.io
• jfrog-prod-use1-shared-virginia-main.s3.amazonaws.com
• *.amazonaws.com
• production.cloudflare.docker.com
• *.docker.io
• *.sophos.com
• login.microsoftonline.com
• graph.microsoft.com
• sentry.io
• *.okta.com, wenn Okta als Identitätsanbieter dient
• wsserver-<Gateway-FQDN>
• der in den Gateway-Einstellungen konfigurierte Gateway-FQDN

Zusätzlich benötigt ztna.apu.sophos.com TCP 22. Wenn eine vorgeschaltete Firewall TLS entschlüsselt, nimmt man wsserver-<Gateway-FQDN> von der Entschlüsselung aus.

ZTNA steuert webbasierte und lokale Anwendungen. Der hier beschriebene native Anwendungszugriff nutzt den ZTNA-Agenten. Der agentenlose RDP-/SSH-Zugriff über den vollständigen Protected Browser ist ein separater Pfad mit eigenen Ressourcen und Policies; die Browser-Erweiterung reicht dafür nicht und beliebige lokale Protokolle sind damit nicht allgemein freigegeben. Anwendungen mit dynamischer Portzuweisung oder sehr vielen Ports, beispielsweise ältere VoIP-Produkte, werden nicht unterstützt. Der Agent ist für Windows 10 1803 oder neuer und macOS Big Sur 11 oder neuer dokumentiert.

Konfiguration mit anpassbaren Beispielwerten

Eigene Werte verwenden. Die folgenden Namen erklären nur die Zuordnung:

Aktuelle UI-Pfade

Die folgenden Pfade und Aktionen entsprechen den englischen UI-Bezeichnungen der aktuellen Herstellerhilfe. Name, Gateway-FQDN und Ressourcendomäne werden als technische Eingabewerte beschrieben, nicht als unbestätigte Feldbezeichnungen:

• My Products > ZTNA > Gateways und danach Add gateway
• My Products > ZTNA > Settings > Domains
• Devices > Installers

1. VM-Image bereitstellen

Für ESXi:

1. Devices > Installers öffnen, Zero Trust Network Access suchen und das Gateway-Image herunterladen.
2. Lizenzvereinbarung und gegebenenfalls Export-Compliance-Formulare akzeptieren.
3. Die OVA in vSphere über den Bereitstellungsassistenten bereitstellen.
4. Das automatische Einschalten deaktivieren. Die VM darf nicht ohne die später erzeugte ISO starten.

Für Hyper-V:

1. Devices > Installers öffnen und unter Zero Trust Network Access auf Download Gateway VM image for Hyper-V klicken.
2. Die VHDX extrahieren. Eine VHDX wird nur für eine VM verwendet; für weitere VMs Kopien erstellen.
3. Eine VM der Generation 1 mit mindestens 4096 MB Startspeicher und zwei virtuellen Prozessoren erstellen. Die vorhandene VHDX verbinden.
4. Für eine zweiarmige Bereitstellung einen zweiten Netzwerkadapter hinzufügen. Bei VLANs die passenden VLAN-IDs zuordnen.

2A. Lokales Gateway anlegen

1. My Products > ZTNA > Gateways > Add gateway öffnen.
2. Bei Gateway Mode den Wert On-premises wählen.
3. Gateway-Name, Gateway-FQDN und die Ressourcendomäne eintragen.
4. Bei Platform type VMware ESXi oder Hyper-V passend zum Host wählen.
5. Den Deployment mode One-arm oder Two-arm wählen.
6. Die Schnittstellen eintragen. Bei DHCP ist eine Reservierung Pflicht. Bei Static IP gibt man IP-Adresse, Subnetz und DNS-Server an. Wenn eine zweiarmige Bereitstellung Anwendungen in mehreren internen Netzen erreicht, trägt man Static routes ein.
7. Das Wildcard-Zertifikat hochladen.
8. Auf Save and generate file klicken. Der Status lautet zunächst Waiting for Deployment; die individuelle Start-ISO wird erzeugt.
9. Auf der Firewall eingehend nur TCP 80 und 443 öffnen, für beide Ports DNAT zur externen Gateway-IP beziehungsweise Cluster-VIP erstellen und alle anderen eingehenden Ports blockieren. Keinen Reverse-Proxy verwenden.

2B. Sophos Cloud Gateway als VM anlegen

1. Zuerst die Domäne unter My Products > ZTNA > Settings > Domains > Add domain validieren.
2. Sophos Fusion erzeugt einen CNAME, beispielsweise 5ccdee2b04764c75ac252a0f91f161b7.cert.prod.ztna.access.sophos.com. Beim eigenen DNS-Anbieter den exakt für den eigenen Tenant erzeugten Wert veröffentlichen.
3. Auf die DNS-Verteilung warten und unter Settings > Domains auf Validate klicken. Erst fortfahren, wenn der Status Validated lautet.
4. Auf Add gateway klicken, bei Gateway Mode Sophos Cloud wählen und Gateway-Name sowie Gateway-FQDN eintragen. Der Gateway-FQDN muss dem bei der ZTNA-Anwendungsregistrierung angegebenen Wert entsprechen.
5. Die validierte Domain, den passenden Platform type, den Identity provider und unter Points of Presence die dem Rechenzentrum nächstgelegene Region wählen.
6. One-arm oder Two-arm wählen, reservierte oder statische Schnittstellen und bei Bedarf statische Routen konfigurieren. Das Wildcard-Zertifikat hochladen.
7. Auf Save and generate file klicken. Die im Dialog Gateway added erzeugte Alias-Domäne kopieren und als CNAME des Gateway-FQDN im öffentlichen DNS veröffentlichen.
8. An der externen Schnittstelle nur TCP 443 ausgehend öffnen. Für dieses Modell wird keine eingehende DNAT-Veröffentlichung der VM eingerichtet.

Seit ZTNA 2.1 ist standardmässig ein sekundärer, zum primären PoP benachbarter Zugangspunkt konfiguriert. Er lässt sich unter Settings deaktivieren. Den primären PoP wählt man trotzdem nahe am Rechenzentrum.

2C. Sophos Cloud Gateway auf Sophos Firewall anlegen

Auch für Ressourcen in Azure kann man diesen Weg nutzen: zuerst Sophos Firewall als virtuelle SFOS-Appliance auf einer unterstützten Plattform bereitstellen, zentral verwalten und danach das ZTNA-Gateway auf dieser Firewall einrichten. Das ist nicht die separate Gateway-VM aus 2A oder 2B; deren ESXi-/Hyper-V-Vorgaben sind keine Azure-Bereitstellungsanleitung.

1. SFOS 19.5 MR3 oder höher und die zentrale Verwaltung in Sophos Fusion prüfen. Falls die Firewall noch nicht registriert ist, verwendet man in der Firewall Register mit Super-Admin-Anmeldedaten oder dem vom Super Admin erzeugten OTP.
2. Die Domäne wie in 2B validieren.
3. My Products > ZTNA > Gateways > Add gateway öffnen und Gateway Mode: Sophos Cloud wählen.
4. Gateway-Name und Gateway-FQDN eintragen, die validierte Domain wählen und Platform type auf Firewall setzen.
5. Unter Firewall das SFOS-Gerät wählen. Die Liste zeigt nur zentral verwaltete Firewalls ab 19.5 MR3. Aus einem HA-Paar kann die aktive Firewall gewählt werden; damit können Datenverkehr und Dienste beim Failover übernommen werden.
6. Identity provider und Points of Presence wählen, das Zertifikat hochladen und auf Save klicken. Das Gateway sollte nach ungefähr fünf Minuten aktiv sein.
7. Beim Identitätsanbieter die abweichende Redirect-URL https://<externer-Gateway-FQDN>/ztna-oauth2/callback ergänzen.

Für den administrativen Zugriff empfiehlt Sophos das Webadmin-Portal als ZTNA-Ressource statt direktem Zugriff über WAN. Bevor man einen bestehenden WAN-Zugang einschränkt, prüft man den ZTNA-Zugriff mit einem berechtigten Admin und hält einen freigegebenen alternativen Verwaltungszugang bereit. Die folgenden HA- und Portalgrenzen bleiben dabei verbindlich.

Bei zentral verwalteten Firewalls zeigt das Control Center den ZTNA-Status: Active nach der Einrichtung, Not configured ohne Einrichtung. Das ist eine Integrationsanzeige, kein Beweis für funktionierenden Ressourcenzugriff; DNS-, Zertifikats- und Pilotprüfungen im Abschnitt zur Validierung bleiben erforderlich.

Grenzen dieser Variante:

• Bei einer Aktiv-Aktiv-HA-Bereitstellung ist das Webadmin-Portal der Firewall nicht über ZTNA erreichbar.
• Benutzerportal und VPN-Portal der Firewall werden über das ZTNA-Gateway nicht unterstützt.
• Das Webadmin-Portal kann ansonsten als Ressourcentyp Web Admin Portal angelegt werden. Beim agentenlosen Zugriff wird die erzeugte Alias-Domäne als öffentlicher CNAME veröffentlicht; beim agentenbasierten Zugriff fängt der Agent den externen FQDN ab.

3. Optional einen VM-Cluster erstellen

Den Cluster erstellt man, bevor man die Start-ISOs herunterlädt:

1. Das neue Gateway öffnen und auf Add/Edit instances > Add another instance klicken. Clustering wird automatisch aktiviert.
2. Eine noch nicht verwendete virtuelle Cluster-IP im selben IP-Bereich wie die Instanzen eintragen. Bei zweiarmiger Bereitstellung und externem Load Balancer bleibt die externe Cluster-VIP leer.
3. VM-Name und Schnittstellen-IP eintragen; bei zweiarmiger Bereitstellung interne und externe IP.
4. Dies für mindestens drei Instanzen wiederholen. Unterstützt sind drei bis neun Instanzen, immer eine ungerade Anzahl.
5. DNAT eines lokalen Gateways auf die externe Cluster-VIP richten. Mindestens die Hälfte der Knoten muss aktiv bleiben.

4. Start-ISO verbinden und Registrierung genehmigen

Jede ISO ist einem Gateway beziehungsweise einer Instanz eindeutig zugeordnet und darf nicht wiederverwendet werden.

• ESXi: ISO am CD/DVD-Laufwerk einbinden, Connect und Connect at Power on auswählen. Ein vorhandenes serielles Gerät kann entfernt werden.
• Hyper-V: Unter VM-Einstellungen am DVD-Laufwerk IDE Controller 1 > Image file wählen und die ISO einbinden.
• Erst danach die VM starten. Die ISO muss auch nach erfolgreichem Start verbunden bleiben.
• Die Gateway-Details öffnen. Der Status wechselt von Waiting for Deployment zu Awaiting Approval beziehungsweise Waiting for gateway approval.
• Auf Approve klicken. Bei einem Cluster genehmigt man nur die erste Instanz; weitere Instanzen werden anschliessend verwaltet.
• Die Genehmigung kann bis zu zehn Minuten dauern. Den plattformspezifischen Endstatus prüfen: lokal auf ESXi Connected, lokal auf Hyper-V Active, Sophos Cloud auf ESXi Active und Connected, Sophos Cloud auf Hyper-V Active.

DNS und Datenpfad richtig prüfen

Öffentliche und private DNS-Server erfüllen unterschiedliche Aufgaben:

Lokales Gateway

• Mit Agent: Der Agent fängt die Anfrage für die private Anwendung ab und vergibt dafür eine Adresse aus 100.64.x.x. Um den Tunnel aufzubauen, löst er den Gateway-FQDN über einen öffentlichen A-Record zur Gateway-IP auf. Das Gateway löst den Anwendungs-FQDN anschliessend über den privaten DNS-Server auf.
• Agentenlos: Ein öffentlicher CNAME der Anwendung zeigt auf den Gateway-FQDN; dessen öffentlicher A-Record zeigt auf die Gateway-IP. Das Gateway fragt den privaten DNS-Server nach dem internen Anwendungsziel.

Sophos Cloud Gateway

• Mit Agent: Der öffentliche DNS löst die private Anwendung zur zugeordneten Alias-Domäne auf. Diese führt über den Sophos Cloud PoP zum Gateway. Danach löst das Gateway das interne Ziel über privaten DNS auf.
• Agentenlos: Der öffentliche CNAME der Ressource zeigt auf die von Sophos erzeugte Alias-Domäne. Für jede neue agentenlose Ressource initiiert das Gateway auf TCP 443 einen neuen Tunnel zum PoP. Der PoP ordnet die Anfrage anhand des Alias dem Gateway zu.

Die Verbindung vom Agenten zum Gateway beziehungsweise PoP verwendet gegenseitiges TLS. Dokumentiert sind TLS 1.2 und neuer sowie Verschlüsselungsprotokolle mit Schlüssellängen bis 256 Bit.

Der ZTNA-Agent ändert den Standard-TAP-Adapter. Deshalb kann nslookup für Namen ausserhalb von ZTNA scheinbar fehlschlagen. Den tatsächlich zuständigen DNS-Server explizit angeben:

nslookup <FQDN> <DNS-Server>

Validierung und erwartetes Ergebnis

Man nimmt nicht nur den grünen Gateway-Status ab. Einen begrenzten Testbenutzer und genau eine Testressource verwenden.

1. Management: Unter My Products > ZTNA > Gateways ist das Gateway Active oder Connected. Unter Gateway Details stimmen Softwareversion und bei Clustern alle Knoten.
2. Öffentlicher DNS: Beim lokalen Gateway liefern Gateway-A-Record und gegebenenfalls Ressourcen-CNAME die geplante öffentliche IP. Beim Cloud Gateway sind Domainvalidierungs-, Gateway- und Ressourcen-CNAME exakt die von Sophos erzeugten Werte.
3. Privater DNS: Das Gateway kann den internen Ressourcen-FQDN zur internen Server-IP auflösen.
4. Zertifikat: FQDN, Wildcard-Geltungsbereich, Kette, Laufzeit und privater Schlüssel passen. Browser oder Agent zeigen keine Vertrauenswarnung.
5. Netzwerk: Beim lokalen Gateway treffen TCP 80 und 443 die vorgesehenen DNAT-Regeln; andere eingehende Ports sind blockiert. Beim Cloud Gateway funktioniert der ausgehende TCP-443-Tunnel ohne eingehende Veröffentlichung.
6. Zugriff: Der berechtigte Pilotbenutzer erreicht nur die zugewiesene Anwendung. Ein nicht berechtigter Testbenutzer erhält keinen Zugriff.
7. Anwendung: Nicht nur die Anmeldung, sondern eine reale, begrenzte Transaktion prüfen. Der Rückweg funktioniert und die Anwendung sieht den erwarteten Verbindungsursprung.
8. Stabilität: Extern und, falls vorgesehen, aus demselben Netz wie das Gateway testen. Der zweite Test bestätigt insbesondere MASQ und Rückweg.
9. Cluster: Keinen Knoten ausserhalb eines genehmigten Wartungs- und Failover-Tests stoppen. Bei einem geplanten Test bleiben mindestens die Hälfte der Instanzen aktiv und Anfragen werden über die übrigen Knoten weitergeleitet.

Fehlt das erwartete Ergebnis, geht man zur passenden Symptomebene unten. DNS, Zertifikat, NAT und Policy nicht gleichzeitig ändern.

Für die getrennte Analyse der Firewall-Schicht stehen Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture und NAT auf Sophos Firewall verstehen bereit.

Troubleshooting nach Symptom

Gateway bleibt bei „Waiting for Deployment“ oder erreicht Sophos Fusion nicht

1. Prüfen, ob die eindeutige ISO an genau der richtigen VM hängt und Connect at Power on aktiviert ist.
2. Hostzeit und UTC-Zeitzone prüfen.
3. Statische IP beziehungsweise DHCP-Reservierung, DNS und die erlaubten Ziele prüfen; ztna.apu.sophos.com benötigt TCP 22.
4. Eine TLS-Decrypt-Ausnahme für wsserver-<Gateway-FQDN> prüfen.
5. Die VM-Diagnose in vSphere beziehungsweise Hyper-V Manager ausführen.

Status wartet auf Genehmigung

Die Gateway-Details öffnen und auf Approve klicken. Bis zu zehn Minuten warten. Bei einem Cluster genehmigt man nur die erste Instanz. Bleibt der Status unverändert, prüft man zuerst Erreichbarkeit und Zeit, statt weitere Instanzen neu anzulegen.

Gateway fällt nach DHCP- oder Netzänderung aus

Das Gateway verarbeitet keine Änderung seiner IP-Adresse. Die ursprüngliche Adresszuordnung wiederherstellen und eine DHCP-Reservierung oder statische Adresse setzen. Danach DNS, DNAT und bei Clustern die VIP-Ziele prüfen. Geplante IP-Änderungen sind keine einfache Laufzeitänderung und müssen als neue Bereitstellung behandelt werden.

Anmeldung funktioniert, die Ressource aber nicht

1. Den Ressourcen-FQDN gezielt am privaten DNS-Server auflösen.
2. Route und Firewall-Freigabe vom Gateway zum dokumentierten Zielport prüfen.
3. Bei zweiarmiger Bereitstellung statische Routen zu weiteren internen Netzen prüfen.
4. Bei Zugriff aus demselben Gateway-Netz die MASQ-Regel und asymmetrisches Routing prüfen.
5. Prüfen, ob die Anwendung dynamische oder sehr viele Ports nutzt; solche Anwendungen sind nicht unterstützt.

Externer Zugriff auf ein lokales Gateway schlägt fehl

Öffentlichen A-Record, TCP 80 und 443, beide DNAT-Regeln und deren Ziel-IP beziehungsweise Cluster-VIP prüfen. Sicherstellen, dass kein Reverse-Proxy vorgeschaltet ist. Andere eingehende Ports bleiben blockiert.

Cloud Gateway oder agentenlose Ressource ist nicht erreichbar

In dieser Reihenfolge prüfen:

1. Domänenstatus Validated;
2. Gateway-CNAME und Ressourcen-CNAME gegen die in Sophos Fusion erzeugten Alias-Domänen;
3. ausgehendes TCP 443 vom Gateway zum PoP;
4. private DNS-Auflösung vom Gateway zur Anwendung;
5. korrekte PoP-Region und bei Firewall-Gateways die besondere OAuth2-Redirect-URL.

nslookup liefert nach Agentinstallation falsche Ergebnisse

Der Agent setzt den ZTNA-TAP-Adapter als Standard. Die Abfrage mit explizitem DNS-Server wiederholen. Ein Fehlschlag über den TAP-Adapter beweist nicht, dass der normale DNS-Server den Namen nicht kennt.

Zertifikatsfehler

Wildcard-Geltungsbereich, vollständige Kette, privaten Schlüssel und Algorithmus prüfen. P-384/P-521 bei ECDSA sowie RSA unter 2048 Bit sind nicht unterstützt. Gateway-FQDN, Ressourcendomäne und Zertifikatsnamen vergleichen, bevor man ein neues Zertifikat hochlädt.

Diagnosepaket für Sophos Support

Für VM-Gateways auf ESXi oder Hyper-V:

1. Gateway Details > Troubleshooting logs öffnen.
2. Auf Generate logs klicken. Die Erstellung kann einige Minuten dauern.
3. Den neuen Eintrag in der Spalte Troubleshooting log herunterladen. Er läuft nach einer Stunde ab.
4. Falls nötig, in den Gateway-Details zeitlich begrenzten Supportzugriff aktivieren und das angezeigte Token ausschliesslich an Sophos Support übermitteln.

Diese Protokollfunktion gilt nicht für das auf Sophos Firewall integrierte Gateway.

Sicherer Rückweg oder Offboarding

Man unterscheidet zwischen einer Konfigurationsänderung, einem VM-Gateway-Update, einem Firewall-Firmwarewechsel und dem endgültigen Löschen. Dafür gelten nicht dieselben Rückwege.

Vor jeder Änderung

• Gateway-Modus, FQDN, IPs, Cluster-VIP, Plattform, Version, Zertifikat, öffentliche CNAME/A-Records, DNAT/SNAT, statische Routen, zugewiesene Ressourcen und Pilotgruppe erfassen.
• Prüfen, welche Ressourcen und Benutzer vom Gateway abhängen, und ein Wartungsfenster vereinbaren.
• Im Pilot nur eine Ebene pro Schritt ändern. Die zuletzt funktionierenden DNS- und Firewall-Werte festhalten.

Ressourcen auf ein Firewall-Gateway verschieben

Für die dokumentierte Migration von einem bestehenden Gateway auf ein Firewall-Gateway:

1. Das Firewall-Gateway vollständig einrichten.
2. Dessen neue OAuth2-Redirect-URL beim Identitätsanbieter ergänzen.
3. Resources & access öffnen, die Ressource wählen und Gateway auf das Firewall-Gateway setzen.
4. Bei agentenlosem Zugriff die neue Alias-Domäne der Firewall als öffentlichen CNAME veröffentlichen.
5. Mit einem begrenzten Benutzer validieren. Den alten DNS-Wert oder das alte Gateway erst nach erfolgreichem Anwendungstest entfernen.

Gateway löschen

In den Gateway-Details ist Delete verfügbar. Die zugeordneten Quellen beschreiben jedoch weder eine Wiederherstellung eines gelöschten Gateways noch einen transaktionssicheren automatischen Rückbau von DNS, NAT, Ressourcen und Zertifikaten. Deshalb:

1. Nicht als ersten Rollback-Schritt löschen.
2. Zuerst die abhängigen Ressourcen im vereinbarten Änderungsfenster verschieben oder deaktivieren und prüfen, dass kein produktiver Zugriff mehr über das Gateway läuft.
3. Danach obsolete öffentliche DNS- und Firewall-Regeln anhand der vorab erfassten Liste entfernen.
4. Das Gateway erst nach Freigabe durch Anwendungs- und Netzwerkverantwortliche löschen.
5. Wenn Abhängigkeiten oder Wiederherstellungsweg unklar sind, vor Delete stoppen und an Sophos Support eskalieren.

Rückweg bei Updates

Für VM-Gateway-Updates ist in den ausgewerteten Anweisungen kein Downgrade beschrieben. Bei einem fehlgeschlagenen Update keine nicht dokumentierte Image-Rücksetzung versuchen; Protokolle erzeugen, Zugriff über die unveränderte Instanz beziehungsweise den Cluster erhalten und an Sophos Support eskalieren.

Für ein auf Sophos Firewall integriertes Gateway gilt der dokumentierte Firmware-Rückweg:

1. Eine gültige Support-Subscription prüfen und die Firewall-Konfiguration sichern.
2. Vor dem Wechsel prüfen, ob die konfigurierte Gateway-Anzahl von der Zielversion unterstützt wird; überzählige Gateways müssen vor dem Firmwarewechsel gelöscht werden.
3. Den Wechsel ausserhalb der Spitzenzeit planen. Die Firewall beendet Sitzungen und startet neu.
4. Unter Backup and firmware > Firmware kann man eine kompatible Version hochladen und mit Upload and boot starten oder ein bereits inaktives Image über Boot firmware image booten.
5. Die aktive und vorherige Firmware liegen mit ihren jeweiligen Konfigurationen auf getrennten Partitionen. Ein Rollback auf die vorherige Firmware setzt deshalb auch die Konfiguration auf deren vorherigen Stand zurück.
6. Nach dem Neustart anmelden und oben links im Control Center die aktive Firmware sowie danach Gateway-Status, DNS und Pilotzugriff prüfen.

Betrieb, Review und Lifecycle

VM-Gateway aktualisieren

Unter Gateways zeigt ein grünes Häkchen neben der Versionsnummer eine verfügbare VM-Version an. Auf die Versionsnummer klicken, die Zielversion wählen und das Update planen oder Now wählen. Wenn ein Neustart nötig ist, zeigt die Oberfläche eine Warnung; ihn in einem Wartungsfenster planen. Diese Funktion gilt nur für ESXi- und Hyper-V-Gateways. Ein Firewall-Gateway wird über die SFOS-Firmware aktualisiert.

Prüfstand 21. Oktober 2026: Sophos hat am 6. Oktober 2026 die Updates 2.2.1 für die Anwendung und 2.3.0 für das Basis-Image angekündigt. Sie gelten für kundenverwaltete ZTNA-Gateway-VMs auf ESXi und Hyper-V. Wegen der Sicherheitskorrekturen in 2.3.0 empfiehlt Sophos, den Upgradeprozess zeitnah zu beginnen. Die beiden Stufen werden getrennt abgenommen:

1. Ausgangsversion und angebotenen Upgradepfad prüfen. Ein altes Gateway mit 2.1.2 darf nicht direkt auf 2.2.1 überspringen; zuerst die erforderlichen Zwischenversionen anhand der Release-Reihenfolge und der in Fusion angebotenen Schritte klären.
2. Das angebotene Anwendungsupdate auf 2.2.1 ausführen oder planen.
3. Warten, bis das Gateway wieder Active meldet. In der Gateway-Diagnosekonsole müssen alle Tests bestehen, bevor die nächste Stufe startet.
4. Anschliessend das Basis-Image auf 2.3.0 aktualisieren. Erneut Active, erfolgreiche Gateway-Diagnose und den oben beschriebenen Pilotzugriff bestätigen.

Sophos nennt ungefähr 30 Minuten je Update für einen einzelnen Knoten; bei mehreren Knoten steigt der Zeitbedarf entsprechend. Für diese Gateway-Updates ist kein ZTNA-Agent-Update erforderlich. Ein Sophos-Firewall-Gateway benötigt diese VM-Updates nicht und bleibt im SFOS-Firmwareprozess. Bei fehlgeschlagener Diagnose die nächste Stufe stoppen; der Abschnitt zum Update-Rückweg gilt weiterhin.

Die erfassten Release-Notes führen ZTNA 2.2 vom 13. Januar 2026 für ESXi und Hyper-V in lokaler wie Sophos-Cloud-Bereitstellung und bezeichnen das Upgrade wegen neuer erforderlicher Fähigkeiten als verpflichtend. Vor dem Wartungsfenster prüft man dennoch immer die in Sophos Fusion angebotene Zielversion und die aktuellen Release-Notes; aus dieser historischen Versionsangabe weder ein EOL-Datum noch eine heutige Zielversion ableiten.

Die Release-Historie nennt ausserdem einen konfigurierbaren Inaktivitäts-Timeout für Agent-Gateway-Tunnel und das Abschalten des Resource Connection Pooling ab 2.1.2. Für 2.2 dokumentiert sie Korrekturen für intermittierende Verbindungen agentenbasierter Ressourcen über ein lokales Gateway, einen nach Image-Updates hängenbleibenden Status Updating, irreführende Diagnosemeldungen zu Cluster-Pods und eine Race Condition bei Kubernetes-Pods. Diese Historie verwendet man zur Änderungs- und Fehlerbewertung, nicht als Ersatz für die aktuelle Gateway-Detailansicht.

AD-/Kerberos-Probleme nach dem Gateway-Update gesondert prüfen

Die Aussage, dass für das Gateway-Update kein Agentupdate erforderlich ist, beschreibt die Upgrade-Voraussetzung. Sie bestätigt nicht, dass jeder agentenseitige Fehler damit behoben wird. Unter NZT-10022 nennt Sophos für Gateway 2.2 und 2.3 intermittierende Verluste grösserer AD-Pakete, die unter anderem RDP, Dateifreigaben und Kerberos beeinträchtigen können.

Nach einem Update deshalb mit einem begrenzten Windows-Pilot auch die betroffenen AD-abhängigen Anwendungen prüfen und Agent-/Gateway-Version, Zeitpunkt und reproduzierbares Fehlerbild dokumentieren. Die Known-Issues-Liste verweist am 24. Oktober 2026 auf einen noch kommenden Windows Endpoint Agent 2026.3 als Korrektur. Diese Ankündigung ist kein Nachweis, dass der passende ZTNA-Fix bereits im eigenen Updatekanal ausgerollt ist. Vor einem Agent-Rollout die konkrete Freigabe und Fix-Zuordnung prüfen; ein Gateway-Upgrade auf 2.3.0 allein nicht als Lösung zusagen. Bleibt das Fehlerbild bestehen, die Belege an Sophos Support übergeben und einen vorübergehenden Workaround fallbezogen abstimmen.

Regelmässiger Review

Mindestens im eigenen Wartungsrhythmus prüfen:

• Gateway- und Knotenstatus sowie installierte und angebotene Version;
• Zertifikatslaufzeit und vollständige Kette;
• öffentliche Domainvalidierungs-, Gateway- und Ressourcen-CNAMEs;
• private DNS-Auflösung und nur noch benötigte Routen, DNAT-, SNAT- und Firewall-Regeln;
• PoP-Region, sekundären PoP und reale Latenz beim Cloud Gateway;
• synchronisierte, sicherheitsaktivierte Benutzergruppen und den Identitätsanbieter;
• Gateway-Ressourcenzuordnungen und nicht mehr benötigte Gateways;
• Diagnose- und Supportverfahren, Wartungsfenster und verantwortliche Personen.

Für die Gateway-Planung ist hier kein belastbarer Übergangs-, Migrations- oder EOL-Termin genannt. Solche Fristen vor einer Ablösung anhand einer aktuellen Produktmitteilung prüfen.

Verwandte bestehende Anleitungen

Dieses Runbook endet bewusst an den Gateway-Grenzen. Die vollständige Einrichtung von Verzeichnisdienst und Identitätsanbieter, die Installation oder Entfernung des ZTNA-Agenten, agentenspezifische Fehlerdiagnose, Ressourcenzugriffsregeln und besondere Designs mit mehreren Domänencontrollern gehören in die jeweiligen bestehenden Anleitungen. Die oben verknüpften Grundlagen zu Zero Trust, Remote Access, Zertifikaten, DNAT und Firewall-Diagnose ergänzen den Gateway-Ablauf, ohne diese getrennten Verfahren zu duplizieren.