Sophos ZTNA Gateway planen und erstellen

Ein Sophos ZTNA Gateway verbindet Benutzer mit internen Anwendungen, ohne dass dafür ein klassischer Volltunnel-VPN-Zugang nötig ist. Der eigentliche Nutzen entsteht aber erst, wenn Gateway-Modus, DNS, Zertifikat, Firewall-Regeln und interne Erreichbarkeit sauber geplant sind.

Diese Anleitung beschreibt die Planung und Erstellung eines ZTNA Gateways in Sophos Central. Der Fokus liegt auf dem Gateway-Teil. Für die grundsätzliche Entscheidung zwischen VPN, ZTNA und anderen Remote-Access-Varianten passt zusätzlich Sophos Connect oder SSL VPN: Welche Remote-Access-Lösung passt?.

Für die herstellerneutrale Grundlage zu Zero Trust, ZTNA und der Abgrenzung zu VPN passt zuerst Zero Trust einfach erklärt: ZTNA statt klassischem VPN.

Die Gateway-Modi verstehen

Sophos ZTNA kann mit einem On-premise Gateway oder einem Sophos Cloud Gateway betrieben werden. Beide Varianten stellen Zugriff auf interne Ressourcen bereit, unterscheiden sich aber deutlich bei Internet-Exposition, DNS, Betrieb und Fehlersuche.

Typische Modelle:

• On-premise Gateway: Die Gateway-VM steht im eigenen Rechenzentrum oder Standortnetz. Man betreibt eine eigene VM, eigenes Public DNS, DNAT auf Port 443 und hat direktere Kontrolle über den Datenpfad.
• Sophos Cloud Gateway: Benutzer verbinden sich über Sophos Cloud Points of Presence. Dadurch gibt es weniger direkte Internet-Exposition, aber andere DNS-CNAMEs und eine bewusste Point-of-Presence-Auswahl.
• Sophos Firewall als Cloud Gateway: Die Sophos Firewall übernimmt die Gateway-Rolle für ZTNA Cloud Gateway. Es braucht keine separate Gateway-VM, aber SFOS, Sophos Central und Firewall-Betrieb werden stärker voneinander abhängig.

Der Modus ist nicht nur eine technische Checkbox. Er bestimmt, wo Traffic eintritt, wer den Datenpfad betreibt, welche DNS-Einträge nötig sind und ob eine DNAT-Regel auf der Firewall gebraucht wird.

On-premise Gateway

Bei einem On-premise Gateway wird eine Gateway-VM auf VMware ESXi oder Microsoft Hyper-V bereitgestellt. Das Gateway ist aus dem Internet erreichbar und nimmt den ZTNA-Zugriff entgegen. In der Praxis zeigt ein öffentlicher DNS-Name auf die Firewall, und eine DNAT-Regel leitet HTTPS auf das Gateway weiter.

Vorteile:

• direkter Datenpfad zum eigenen Standort,
• volle Kontrolle über Gateway, Segment, DNS und Firewall-Regeln,
• keine Abhängigkeit vom Sophos Cloud Data Plane für den eigentlichen Einstiegspunkt.

Nachteile:

• Gateway-VM muss betrieben und aktualisiert werden,
• Port 443 muss von aussen erreichbar sein,
• Zertifikat, DNS, DNAT und internes Routing müssen sauber stimmen,
• Verfügbarkeit hängt am eigenen Standort, Internetanschluss und Hypervisor.

Wenn ein On-premise Gateway per DNAT veröffentlicht wird, sollte die Regel genauso bewusst geplant werden wie andere Veröffentlichungen. Die Grundlagen dazu stehen in Server mit DNAT auf Sophos Firewall veröffentlichen.

Sophos Cloud Gateway

Beim Sophos Cloud Gateway wird der Zugriff über Sophos Cloud Points of Presence geführt. Die interne Gateway-Komponente verbindet Sophos Cloud mit den internen Ressourcen. Dadurch müssen Benutzer nicht direkt auf eine eigene öffentliche Gateway-IP zugreifen.

Das reduziert die direkte Internet-Exposition, verschiebt aber Teile des Datenpfads in die Sophos Cloud. Wichtig sind deshalb:

• passender Point of Presence nahe am Rechenzentrum,
• korrekte öffentliche CNAME-Einträge,
• funktionierende interne DNS-Auflösung,
• klare Erwartung an Latenz, Verfügbarkeit und Traffic-Profile,
• Prüfung von Lizenz-, Produkt- und Traffic-Grenzen für die konkrete Umgebung.

Für sehr datenintensive Anwendungen wie grosse Dateiablagen, CAD-Dateien oder Massendownloads sollte man ZTNA Cloud Gateway nicht nur anhand der Anmeldung testen. Entscheidend ist, wie sich echte Nutzung, Latenz und Datenvolumen im Alltag verhalten.

Sophos Firewall als ZTNA Cloud Gateway

Ein Sophos Cloud Gateway kann auch auf zentral verwalteten Sophos-Firewall-Geräten eingerichtet werden. Das ist interessant, wenn bereits eine Sophos Firewall am Standort steht und keine separate Gateway-VM betrieben werden soll.

Diese Variante sollte trotzdem nicht als Nebenfunktion nebenbei aktiviert werden. Zu prüfen sind:

• Unterstützte SFOS-Version und Central-Management-Status.
• ZTNA-Lizenzierung und Benutzerzuordnung.
• Erreichbarkeit der internen Ressourcen aus Sicht der Firewall.
• Einfluss auf Wartungsfenster, Firmware-Updates und Firewall-Betrieb.
• Logging und Zuständigkeit bei Störungen.

Wenn die Firewall ohnehin der zentrale Remote-Access-Knoten ist, kann diese Variante elegant sein. Wenn ZTNA dagegen unabhängig von Firewall-Wartungen laufen soll, ist eine eigene Gateway-VM oder ein anderes Design manchmal sauberer.

Voraussetzungen

Vor dem Deployment sollten diese Punkte geklärt sein:

• Sophos Central Tenant mit ZTNA-Lizenz.
• Synchronisierte Benutzer und Gruppen.
• Identity Provider, zum Beispiel Microsoft Entra ID.
• Entscheidung für On-premise Gateway oder Sophos Cloud Gateway.
• Hypervisor oder unterstützte Sophos Firewall, je nach Modus.
• Public DNS für Gateway und Ressourcen.
• Wildcard-Zertifikat oder passendes Zertifikatskonzept.
• Interne DNS-Auflösung der Zielanwendungen.
• Netzwerksegment für das Gateway.
• Firewall-Regeln vom Gateway zu den Anwendungen.
• Owner für Betrieb, Logs, Zertifikate und spätere Änderungen.

Für Zertifikate ist ein Wildcard-Zertifikat oft die praktischste Variante. Die Beschaffung eines Wildcard-Zertifikats ist in Let’s Encrypt Wildcard-Zertifikat erstellen beschrieben. Wenn Zertifikate direkt auf der Sophos Firewall verwaltet werden, passt zusätzlich Let’s Encrypt Zertifikate auf Sophos Firewall verwalten.

Plattform und Dimensionierung

Für Gateway-VMs sind VMware ESXi und Microsoft Hyper-V die typischen Plattformen. Je nach Modus und Sophos-Stand können weitere Optionen relevant sein. Entscheidend ist, dass die Plattform offiziell unterstützt, aktuell und sauber überwacht ist.

Für kleine bis mittlere Setups ist eine Gateway-VM mit 2 vCPU und 4 GB RAM ein realistischer Startpunkt. Das ersetzt aber keine Betriebsplanung. Massgebend sind Anzahl Benutzer, Ressourcen, Traffic-Profil, TLS, Latenz und Verfügbarkeit.

Für produktive Umgebungen sollte man zusätzlich planen:

• Gibt es ein Gateway-Cluster?
• Läuft das Gateway in einem eigenen VLAN?
• Wie wird die VM gesichert oder wiederhergestellt?
• Gibt es Hypervisor-Monitoring?
• Wer aktualisiert das Gateway?
• Gibt es ein Wartungsfenster für Neustarts?

Netzwerk und Subnetz

Das ZTNA Gateway sollte in einem eigenen Subnetz oder VLAN betrieben werden. Es sollte nicht einfach in ein Client- oder Servernetz gestellt werden. Ein eigenes Segment erleichtert Firewall-Regeln, Logging, Packet Capture und spätere Fehlersuche.

Diese Netzwerke sollten nicht für das Gateway verwendet werden:

• 10.42.0.0/16
• 10.43.0.0/16
• 10.108.0.0/16

Für ein On-premise Gateway zeigt ein öffentlicher DNS-Name, zum Beispiel ztna.example.com, auf die Public-IP der Firewall. Die Firewall leitet Port 443 per DNAT auf das Gateway weiter. Das Gateway benötigt danach Zugriff ins Internet und Zugriff auf die VLANs oder Servernetze, in denen die veröffentlichten Anwendungen liegen.

Für ein Sophos Cloud Gateway unterscheiden sich die DNS-Einträge. Dort werden CNAMEs für Domainvalidierung, Gateway-Alias und je nach Zugriffsart auch Ressourcen-Aliase relevant. Die öffentlichen DNS-Einträge sollten deshalb vor dem Rollout als eigener Arbeitsschritt geprüft werden.

Vor dem Deployment entscheiden

Vor dem Klick auf Add gateway sollten diese Fragen beantwortet sein:

Wichtige Fragen:

• Welche Anwendungen werden veröffentlicht? Web-App, TCP-App und Dateiablage haben unterschiedliche Anforderungen.
• Agentless oder agent-based Zugriff? DNS, CNAMEs und Benutzererlebnis unterscheiden sich.
• On-premise oder Cloud Gateway? Diese Entscheidung bestimmt DNAT, Datenpfad und Betriebsverantwortung.
• Welche Benutzergruppen dürfen zugreifen? ZTNA lebt von enger Zuordnung, nicht von breiten Gruppen.
• Wie wird DNS intern und extern aufgelöst? Falsche DNS-Ziele sind eine der häufigsten Fehlerquellen.
• Welches Zertifikat wird verwendet? Zertifikatsfehler wirken für Benutzer wie ein ZTNA-Ausfall.
• Wer prüft Logs und Änderungen? Ohne Owner wird ZTNA schnell schwer supportbar.

ZTNA Gateway herunterladen

In Sophos Central lassen sich im Hauptmenü unter Protect Devices die Dateien für die virtuelle Maschine herunterladen.

VM auf Hyper-V oder ESXi bereitstellen

Für ein On-premise Gateway oder eine Gateway-VM wird zuerst die virtuelle Maschine erstellt.

Typische Einstellungen:

• Generation 1 für Hyper-V.
• 2 virtuelle Prozessoren als Startwert.
• 4 GB RAM als Startwert.
• Netzwerk in einem eigenen VLAN oder Gateway-Segment.
• Hyper-V: heruntergeladene .vhdx-Dateien verwenden.
• ESXi: OVA-Datei verwenden.

Die VM sollte nicht gestartet werden, bevor das ISO-Image mit den Gateway-Einstellungen erstellt wurde. Dieses ISO verbindet die VM später mit dem Sophos Central Tenant und den Gateway-Einstellungen.

Gateway-Einstellungen in Sophos Central

In Sophos Central wird danach das Gateway hinzugefügt und konfiguriert.

Wichtige Felder:

Besonders wichtige Felder:

• Mode: On-premise Gateway oder Sophos Cloud Gateway bewusst wählen.
• Name: Standort, Zweck oder Hostname verwenden.
• Location: Optional, aber bei mehreren Gateways hilfreich.
• FQDN: Beim On-premise Gateway ist das der öffentliche DNS-Name, der auf die Firewall oder Gateway-IP zeigt.
• Domain: Domain passend zum Zertifikat und zu den Ressourcen wählen.
• Platform type: Je nach Modus VMware ESXi, Hyper-V, AWS oder eine unterstützte Sophos-Firewall-Variante auswählen.
• Identity provider: Zuvor eingerichteten Identity Provider auswählen.
• Gateway Instance Deployment mode: One-arm für einfache DNAT-Szenarien, Two-arm bei getrenntem WAN/LAN-Design.
• IP-Adresse: Für produktive Gateways eine statische oder reservierte IP-Adresse bevorzugen.
• Zertifikat: Wildcard- oder passendes Gateway-Zertifikat verwenden.

One-arm ist oft einfacher, weil ein Interface für ein- und ausgehenden Traffic verwendet wird. Two-arm trennt WAN- und LAN-Seite, braucht aber zwei Interfaces und ein klareres Netzdesign.

Nach dem Speichern erzeugt Sophos Central ein ISO-Image mit den Gateway-Informationen. Dieses ISO wird der VM als Boot-ISO zugewiesen.

Je nach Hostleistung und Umgebung kann der erste Start und die Registrierung bei Sophos Central einige Zeit benötigen. Sobald sich das Gateway meldet, kann es in Central akzeptiert werden.

Nach dem Start prüfen

Nach der Registrierung ist das Gateway noch nicht automatisch produktionsbereit. Erst diese Prüfungen zeigen, ob das Design funktioniert:

Wichtige Prüfungen:

• Gateway status: Gateway ist in Sophos Central online und zeigt eine plausible Version.
• Public DNS: Gateway-FQDN oder CNAMEs zeigen auf das erwartete Ziel.
• Zertifikat: Browser und ZTNA-Client vertrauen dem Zertifikat.
• Interne DNS-Auflösung: Gateway kann interne Ressourcen korrekt auflösen.
• Firewall-Regeln: Gateway erreicht nur die benötigten Anwendungen und Ports.
• DNAT bei On-premise: Port 443 trifft die erwartete NAT- und Firewall-Regel.
• Testbenutzer: Eine Pilotgruppe kann genau die geplanten Ressourcen erreichen.
• Logs: Gateway-, Central- und Firewall-Logs zeigen nachvollziehbare Ereignisse.

Wenn ZTNA als Alternative zu VPN eingeführt wird, sollte ein Pilot nicht nur mit einer Beispiel-Webseite getestet werden. Besser sind reale Zielanwendungen: internes Webportal, RDP/SSH-Jump, Fachapplikation oder Dateizugriff, je nach geplanter Nutzung.

Typische Fehler

Typische Fehlerbilder:

• Public DNS zeigt falsch: Benutzer erreichen das Gateway nicht. A/CNAME, TTL und externe Auflösung prüfen.
• Interne DNS-Auflösung fehlt: Anmeldung funktioniert, die Ressource öffnet aber nicht. Private DNS, Resource FQDN oder Ziel-IP prüfen.
• Zertifikat passt nicht: Browser oder Client zeigen Warnungen. Wildcard, SAN, Chain und Domain prüfen.
• DNAT fehlt beim On-premise Gateway: Gateway bleibt von aussen unerreichbar. NAT-Regel, Port 443, WAN-IP und Log Viewer prüfen.
• Gateway darf Anwendung nicht erreichen: Ressource bleibt offline oder läuft in einen Timeout. Firewall-Regeln vom Gateway-Segment zum Ziel prüfen.
• DHCP-Adresse ändert sich: ZTNA fällt nach Neustart aus. Reservierte oder statische IP-Adresse verwenden.
• Zu breite Benutzergruppe: Zu viele Ressourcen sind sichtbar. Gruppen, Policies und Ressourcen enger zuordnen.
• Cloud Gateway mit falschem PoP: Latenz wird spürbar. Point of Presence nahe am Rechenzentrum wählen.

Für Regel- und NAT-Analyse auf Sophos Firewall helfen Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture und NAT auf Sophos Firewall verstehen.

Betriebscheckliste

• Gateway-Modus dokumentiert.
• Public DNS und private DNS getestet.
• Zertifikat gültig und erneuerbar.
• Gateway in eigenem Segment betrieben.
• DNAT nur beim On-premise Gateway eingerichtet.
• Gateway-Regeln zu internen Ressourcen eng begrenzt.
• Pilotbenutzer und Pilotressourcen definiert.
• Logs, Owner und Supportablauf geklärt.
• Gateway-Update- und Wartungsfenster geplant.
• Rückbauplan vorhanden, falls Pilot nicht funktioniert.

FAQ