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; ä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

Wählen Sie den Gateway-Typ nach Datenpfad und Betriebsverantwortung, nicht nach der Anzahl der Klicks:

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. Halten Sie Zertifikat und privaten Schlüssel bereit. In den Gateway-Details unter Zertifikat 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.

Netzwerk, IPv4 und erlaubte Ziele

• Verwenden Sie für das Gateway weder 10.42.0.0/16 noch 10.43.0.0/16 oder 10.108.0.0/16. Diese Netze sind internen Diensten vorbehalten.
• IPv6 wird für Gateways nicht unterstützt. Weisen Sie Gateway und Endpoints in diesem Szenario keine IPv6-Adressen per DHCP zu. Bereits konfigurierte Endpoints müssen IPv6 manuell deaktivieren.
• Verwenden Sie eine statische IPv4-Adresse oder eine DHCP-Reservierung. 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, nehmen Sie wsserver-<Gateway-FQDN> von der Entschlüsselung aus.

ZTNA steuert webbasierte und lokale Anwendungen. Lokale Anwendungen benötigen den ZTNA-Agenten. 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

Verwenden Sie eigene Werte. Die folgenden Namen erklären nur die Zuordnung:

Aktuelle UI-Pfade

Die aktuellen deutschsprachigen Hilfetexte nennen diese Pfade und Aktionen:

• Meine Produkte > ZTNA > Gateways und danach Gateway hinzufügen
• Meine Produkte > ZTNA > Einstellungen > Domänen
• Geräte > Installer

1. VM-Image bereitstellen

Für ESXi:

1. Öffnen Sie Geräte > Installer, suchen Sie Zero Trust Network Access und laden Sie das Gateway-Image herunter.
2. Akzeptieren Sie Lizenzvereinbarung und gegebenenfalls Export-Compliance-Formulare.
3. Stellen Sie die OVA in vSphere über OVF-Vorlage bereitstellen bereit.
4. Deaktivieren Sie das automatische Einschalten. Die VM darf nicht ohne die später erzeugte ISO starten.

Für Hyper-V:

1. Öffnen Sie Geräte > Installer > Zero Trust Network Access und laden Sie das Gateway-VM-Image für Hyper-V herunter.
2. Extrahieren Sie die VHDX. Eine VHDX wird nur für eine VM verwendet; erstellen Sie für weitere VMs Kopien.
3. Erstellen Sie eine VM der Generation 1 mit mindestens 4096 MB Startspeicher und zwei virtuellen Prozessoren. Verbinden Sie die vorhandene VHDX.
4. Fügen Sie für eine zweiarmige Bereitstellung einen zweiten Netzwerkadapter hinzu. Ordnen Sie bei VLANs die passenden VLAN-IDs zu.

2A. Lokales Gateway anlegen

1. Öffnen Sie Meine Produkte > ZTNA > Gateways > Gateway hinzufügen.
2. Wählen Sie bei Gateway-Modus den Wert Lokal.
3. Tragen Sie Gateway-Name, Gateway-FQDN und die Domäne für Ressourcen ein.
4. Wählen Sie bei Plattformtyp VMware ESXi oder Hyper-V passend zum Host.
5. Wählen Sie den Bereitstellungsmodus Einarmig oder Zweiarmig.
6. Tragen Sie die Schnittstellen ein. Bei DHCP ist eine Reservierung Pflicht. Bei Statische IP geben Sie IP-Adresse, Subnetz und DNS-Server an. Wenn eine zweiarmige Bereitstellung Anwendungen in mehreren internen Netzen erreicht, tragen Sie Statische Routen ein.
7. Laden Sie das Wildcard-Zertifikat hoch.
8. Klicken Sie auf Speichern und Datei erstellen. Der Status lautet zunächst Warten auf Bereitstellung; die individuelle Start-ISO wird erzeugt.
9. Öffnen Sie auf der Firewall eingehend nur TCP 80 und 443, erstellen Sie für beide Ports DNAT zur externen Gateway-IP beziehungsweise Cluster-VIP und blockieren Sie alle anderen eingehenden Ports. Verwenden Sie keinen Reverse-Proxy.

2B. Sophos Cloud Gateway als VM anlegen

1. Validieren Sie zuerst die Domäne unter Meine Produkte > ZTNA > Einstellungen > Domänen > Domäne hinzufügen.
2. Sophos Fusion erzeugt einen CNAME, beispielsweise 5ccdee2b04764c75ac252a0f91f161b7.cert.prod.ztna.access.sophos.com. Veröffentlichen Sie den exakt für Ihren Tenant erzeugten Wert bei Ihrem DNS-Anbieter.
3. Warten Sie auf die DNS-Verteilung und klicken Sie unter Einstellungen > Domänen auf Validieren. Fahren Sie erst fort, wenn der Status validiert lautet.
4. Klicken Sie auf Gateway hinzufügen, wählen Sie bei Gateway-Modus Sophos Cloud und tragen Sie Gateway-Name sowie Gateway-FQDN ein. Der Gateway-FQDN muss dem bei der ZTNA-Anwendungsregistrierung angegebenen Wert entsprechen.
5. Wählen Sie die validierte Domäne, den passenden Plattformtyp, den Identitätsanbieter und unter Points of Presence die dem Rechenzentrum nächstgelegene Region.
6. Wählen Sie Einarmig oder Zweiarmig, konfigurieren Sie reservierte oder statische Schnittstellen und bei Bedarf statische Routen. Laden Sie das Wildcard-Zertifikat hoch.
7. Klicken Sie auf Speichern und Datei erstellen. Kopieren Sie die im Dialog Gateway hinzugefügt erzeugte Alias-Domäne und veröffentlichen Sie sie als CNAME des Gateway-FQDN im öffentlichen DNS.
8. Öffnen Sie an der externen Schnittstelle nur TCP 443 ausgehend. 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 Einstellungen deaktivieren. Wählen Sie den primären PoP trotzdem nahe am Rechenzentrum.

2C. Sophos Cloud Gateway auf Sophos Firewall anlegen

1. Prüfen Sie SFOS 19.5 MR3 oder höher und die zentrale Verwaltung in Sophos Fusion. Falls die Firewall noch nicht registriert ist, verwenden Sie in der Firewall Register mit Super-Admin-Anmeldedaten oder dem vom Super Admin erzeugten OTP.
2. Validieren Sie die Domäne wie in 2B.
3. Öffnen Sie Meine Produkte > ZTNA > Gateways > Gateway hinzufügen und wählen Sie Gateway-Modus: Sophos Cloud.
4. Tragen Sie Gateway-Name und Gateway-FQDN ein, wählen Sie die validierte Domäne und setzen Sie Plattformtyp auf Firewall.
5. Wählen Sie unter Firewall das SFOS-Gerät. 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. Wählen Sie Identitätsanbieter und Points of Presence, laden Sie das Zertifikat hoch und klicken Sie auf Speichern. Das Gateway sollte nach ungefähr fünf Minuten aktiv sein.
7. Ergänzen Sie beim Identitätsanbieter die abweichende Redirect-URL https://<externer-Gateway-FQDN>/ztna-oauth2/callback.

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 Webadmin-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

Erstellen Sie den Cluster, bevor Sie die Start-ISOs herunterladen:

1. Öffnen Sie das neue Gateway und klicken Sie auf Instanzen hinzufügen/bearbeiten > Eine weitere Instanz hinzufügen. Clustering wird automatisch aktiviert.
2. Tragen Sie eine noch nicht verwendete virtuelle Cluster-IP im selben IP-Bereich wie die Instanzen ein. Bei zweiarmiger Bereitstellung und externem Load Balancer bleibt die externe Cluster-VIP leer.
3. Tragen Sie VM-Name und Schnittstellen-IP ein; bei zweiarmiger Bereitstellung interne und externe IP.
4. Wiederholen Sie dies für mindestens drei Instanzen. Unterstützt sind drei bis neun Instanzen, immer eine ungerade Anzahl.
5. Richten Sie DNAT eines lokalen Gateways auf die externe Cluster-VIP. 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, Verbinden und Beim Einschalten verbinden auswählen. Ein vorhandenes serielles Gerät kann entfernt werden.
• Hyper-V: Unter VM-Einstellungen am DVD-Laufwerk IDE Controller 1 > Image-Datei wählen und die ISO einbinden.
• Starten Sie erst danach die VM. Die ISO muss auch nach erfolgreichem Start verbunden bleiben.
• Öffnen Sie die Gateway-Details. Der Status wechselt von Warten auf Bereitstellung zu Warte auf Genehmigung beziehungsweise Warten auf Gateway-Genehmigung.
• Klicken Sie auf Genehmigen. Bei einem Cluster genehmigen Sie nur die erste Instanz; weitere Instanzen werden anschliessend verwaltet.
• Die Genehmigung kann bis zu zehn Minuten dauern. Prüfen Sie den plattformspezifischen Endstatus: lokal auf ESXi Verbunden, lokal auf Hyper-V Aktiv, Sophos Cloud auf ESXi Aktiv und Verbunden, Sophos Cloud auf Hyper-V Aktiv.

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. Geben Sie den tatsächlich zuständigen DNS-Server explizit an:

nslookup <FQDN> <DNS-Server>

Validierung und erwartetes Ergebnis

Nehmen Sie nicht nur den grünen Gateway-Status ab. Verwenden Sie einen begrenzten Testbenutzer und genau eine Testressource.

1. Management: Unter Meine Produkte > ZTNA > Gateways ist das Gateway Aktiv oder Verbunden. 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: Prüfen Sie nicht nur die Anmeldung, sondern eine reale, begrenzte Transaktion. Der Rückweg funktioniert und die Anwendung sieht den erwarteten Verbindungsursprung.
8. Stabilität: Testen Sie extern und, falls vorgesehen, aus demselben Netz wie das Gateway. Der zweite Test bestätigt insbesondere MASQ und Rückweg.
9. Cluster: Stoppen Sie keinen Knoten ausserhalb eines genehmigten Wartungs- und Failover-Tests. Bei einem geplanten Test bleiben mindestens die Hälfte der Instanzen aktiv und Anfragen werden über die übrigen Knoten weitergeleitet.

Fehlt das erwartete Ergebnis, gehen Sie zur passenden Symptomebene unten. Ändern Sie nicht gleichzeitig DNS, Zertifikat, NAT und Policy.

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 „Warten auf Bereitstellung“ oder erreicht Sophos Fusion nicht

1. Prüfen Sie, ob die eindeutige ISO an genau der richtigen VM hängt und Beim Einschalten verbinden aktiviert ist.
2. Prüfen Sie Hostzeit und UTC-Zeitzone.
3. Prüfen Sie statische IP beziehungsweise DHCP-Reservierung, DNS und die erlaubten Ziele; ztna.apu.sophos.com benötigt TCP 22.
4. Prüfen Sie einen TLS-Decrypt-Ausnahme für wsserver-<Gateway-FQDN>.
5. Führen Sie die VM-Diagnose in vSphere beziehungsweise Hyper-V Manager aus.

Status wartet auf Genehmigung

Öffnen Sie die Gateway-Details und klicken Sie Genehmigen. Warten Sie bis zu zehn Minuten. Bei einem Cluster genehmigen Sie nur die erste Instanz. Bleibt der Status unverändert, prüfen Sie 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. Stellen Sie die ursprüngliche Adresszuordnung wieder her und setzen Sie eine DHCP-Reservierung oder statische Adresse. Prüfen Sie danach DNS, DNAT und bei Clustern die VIP-Ziele. Geplante IP-Änderungen sind keine einfache Laufzeitänderung und müssen als neue Bereitstellung behandelt werden.

Anmeldung funktioniert, die Ressource aber nicht

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

Externer Zugriff auf ein lokales Gateway schlägt fehl

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

Cloud Gateway oder agentenlose Ressource ist nicht erreichbar

Prüfen Sie in dieser Reihenfolge:

1. Domänenstatus validiert;
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. Wiederholen Sie die Abfrage mit explizitem DNS-Server. Ein Fehlschlag über den TAP-Adapter beweist nicht, dass der normale DNS-Server den Namen nicht kennt.

Zertifikatsfehler

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

Diagnosepaket für Sophos Support

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

1. Öffnen Sie Gateway-Details > Fehlerbehebungsprotokolle.
2. Klicken Sie auf Protokolle generieren. Die Erstellung kann einige Minuten dauern.
3. Laden Sie den neuen Eintrag in der Spalte Fehlerbehebungsprotokoll herunter. Er läuft nach einer Stunde ab.
4. Falls nötig, aktivieren Sie in den Gateway-Details zeitlich begrenzten Supportzugriff und übermitteln Sie das angezeigte Token ausschliesslich an Sophos Support.

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

Sicherer Rückweg oder Offboarding

Unterscheiden Sie 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

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

Ressourcen auf ein Firewall-Gateway verschieben

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

1. Richten Sie das Firewall-Gateway vollständig ein.
2. Ergänzen Sie dessen neue OAuth2-Redirect-URL beim Identitätsanbieter.
3. Öffnen Sie Ressourcen und Zugriff, wählen Sie die Ressource und setzen Sie Gateway auf das Firewall-Gateway.
4. Bei agentenlosem Zugriff veröffentlichen Sie die neue Alias-Domäne der Firewall als öffentlichen CNAME.
5. Validieren Sie mit einem begrenzten Benutzer. Entfernen Sie den alten DNS-Wert oder das alte Gateway erst nach erfolgreichem Anwendungstest.

Gateway löschen

In den Gateway-Details ist Gateway löschen 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. Löschen Sie nicht als ersten Rollback-Schritt.
2. Verschieben oder deaktivieren Sie zuerst die abhängigen Ressourcen im vereinbarten Änderungsfenster und prüfen Sie, dass kein produktiver Zugriff mehr über das Gateway läuft.
3. Entfernen Sie danach obsolete öffentliche DNS- und Firewall-Regeln anhand der vorab erfassten Liste.
4. Löschen Sie das Gateway erst nach Freigabe durch Anwendungs- und Netzwerkverantwortliche.
5. Wenn Abhängigkeiten oder Wiederherstellungsweg unklar sind, stoppen Sie vor Gateway löschen und eskalieren Sie an Sophos Support.

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. Prüfen Sie eine gültige Support-Subscription und sichern Sie die Firewall-Konfiguration.
2. Prüfen Sie vor dem Wechsel, ob die konfigurierte Gateway-Anzahl von der Zielversion unterstützt wird; überzählige Gateways müssen vor dem Firmwarewechsel gelöscht werden.
3. Planen Sie den Wechsel ausserhalb der Spitzenzeit. Die Firewall beendet Sitzungen und startet neu.
4. Unter Backup and firmware > Firmware können Sie 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. Melden Sie sich nach dem Neustart an und prüfen Sie oben links im Control Center die aktive Firmware sowie danach Gateway-Status, DNS und Pilotzugriff.

Betrieb, Review und Lifecycle

VM-Gateway aktualisieren

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

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. Prüfen Sie vor dem Wartungsfenster dennoch immer die in Sophos Fusion angebotene Zielversion und die aktuellen Release-Notes; leiten Sie aus dieser historischen Versionsangabe weder ein EOL-Datum noch eine heutige Zielversion ab.

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. Verwenden Sie diese Historie zur Änderungs- und Fehlerbewertung, nicht als Ersatz für die aktuelle Gateway-Detailansicht.

Regelmässiger Review

Prüfen Sie mindestens im eigenen Wartungsrhythmus:

• 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.

Veröffentlichen Sie keine Übergangs-, Migrationsfrist-, Retirement- oder EOL-Aussage ohne eine aktuelle, lesbare Produktmitteilung. Die vorliegenden Quellen stützen Betrieb und Release-Stand, aber keine solchen Lifecycle-Termine.

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.