Server per DNAT auf Sophos Firewall veröffentlichen

Mit DNAT veröffentlicht man einen internen Server über eine öffentliche IP-Adresse oder einen öffentlichen Port. Die Sophos Firewall leitet eingehenden Traffic dann an den internen Zielserver weiter. Typische Beispiele sind Webserver, Reverse Proxies, VPN Gateways oder andere Dienste in einer DMZ.

Der Artikel erklärt, welche Punkte man vor und nach einer DNAT-Regel prüfen sollte und wie man die Freigabe möglichst eng absichert.

Planung vor der Veröffentlichung

Vor einer DNAT-Freigabe sollte klar sein, ob der Dienst wirklich öffentlich erreichbar sein muss und welche technische Variante am besten passt. Eine gute Planung verhindert offene Ports, doppelte NAT-Regeln und schwer nachvollziehbare Rückwege.

Voraussetzungen

• Öffentliche IP-Adresse oder WAN-Schnittstelle
• Interner Server mit fester IP-Adresse
• Bekannter Dienst und Port, zum Beispiel TCP 443
• Passende Firewall-Regel
• Optional: IPS, Webserver Protection oder Reverse Proxy je nach Dienst

⚠️ DNAT veröffentlicht einen internen Dienst nach aussen. Jeder veröffentlichte Dienst erhöht die Angriffsfläche. Es sollte nur veröffentlicht werden, was wirklich nötig ist. Quelle, Port und Ziel sollten möglichst eng begrenzt sein.

Vorab klären

Vor der Regelanlage sollte man diese Fragen beantworten:

• Welche öffentliche IP oder WAN-Schnittstelle wird verwendet?
• Welcher externe Port soll erreichbar sein?
• Auf welche interne IP wird weitergeleitet?
• Bleibt der Port gleich oder wird er übersetzt?
• Soll der Zugriff von überall oder nur von bestimmten Quellnetzen erlaubt sein?
• Muss Source NAT oder Reflexive NAT beachtet werden?
• Braucht es eine Loopback-Regel für interne Clients, die den öffentlichen FQDN verwenden?
• Wird nur ein interner Server veröffentlicht oder mehrere Server mit Load Balancing?
• Gibt es bereits eine Regel, die denselben Port verwendet?
• Befindet sich die Sophos Firewall direkt am Internet oder hinter einem Provider-Router?
• Müssen zusätzlich Regeln in einer Cloud Security Group geöffnet werden?

Diese Informationen verhindern spätere Konflikte mit bestehenden NAT- oder Firewall-Regeln.

Wenn die Begriffe Original source, Original destination, Translated destination, Translated service, Loopback oder Reflexive Rule noch unklar sind, sollte zuerst NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT gelesen werden. Diese Seite hier konzentriert sich auf die konkrete Veröffentlichung eines internen Dienstes.

DNAT, WAF, VPN oder ZTNA?

Nicht jeder öffentlich erreichbare Dienst sollte automatisch per DNAT veröffentlicht werden. DNAT ist technisch einfach, aber auch sehr direkt: Die Firewall leitet einen Port an ein internes Ziel weiter. Ob das sinnvoll ist, hängt vom Dienst, von den Quellen und vom Schutzbedarf ab.

• Nicht-HTTP-Dienst mit klar definierten Quellen: DNAT mit enger Source-Einschränkung, Logging und IPS kann passen.
• Öffentliche HTTP- oder HTTPS-Anwendung: Zuerst Sophos Firewall WAF prüfen.
• Adminzugriff wie SSH, RDP oder internes Admin-Portal: Möglichst VPN, ZTNA oder feste Quell-IP statt offenes DNAT verwenden.
• Zugriff nur für wenige Partner oder Standorte: Quell-IP, VPN oder Site-to-Site-Verbindung bevorzugen.
• Anwendung soll intern und extern unter demselben Namen erreichbar sein: Split DNS oder bewusst geplante Loopback-Regel prüfen.

Für klassische Webanwendungen ist WAF häufig der bessere Startpunkt, weil Hostnamen, Zertifikate, Pfade, Web-Schutzprofile und optional Authentifizierung berücksichtigt werden können. Für administrative Zugriffe sollte DNAT nur in Ausnahmefällen verwendet werden. Wenn ein interner Dienst nicht wirklich öffentlich sein muss, sind VPN oder eine ZTNA-Architektur meistens die sauberere Lösung. Die bestehenden ZTNA-Grundlagen stehen in Wie man Sophos ZTNA einrichtet und Sophos ZTNA Gateway erstellen.

Wenn die Firewall hinter einem Router steht

DNAT funktioniert auch, wenn die Sophos Firewall nicht direkt die öffentliche IP-Adresse besitzt, sondern hinter einem NAT-Router des Providers steht.

In diesem Fall braucht es zwei Weiterleitungen:

1. Auf dem Provider-Router wird der öffentliche Port an die WAN-IP der Sophos Firewall weitergeleitet.
2. Auf der Sophos Firewall wird der Port per DNAT an den internen Server weitergeleitet.

Viele Provider-Router bieten dafür klassische Portweiterleitungen oder eine Funktion wie Exposed Host beziehungsweise DMZ Host. Bei einer Exposed-Host-Funktion werden häufig sehr viele oder alle eingehenden Ports an die Firewall weitergeleitet. Das kann praktisch sein, sollte aber bewusst abgesichert werden, weil die eigentliche Kontrolle dann vollständig auf der Sophos Firewall liegt.

Wenn keine fixe öffentliche IP vorhanden ist, kann man DynDNS verwenden. Die Sophos Firewall kann Dynamic DNS einrichten, damit ein DNS-Name immer auf die aktuelle öffentliche IP zeigt. Wichtig ist trotzdem: Die Portweiterleitung auf dem Provider-Router muss auf die Sophos Firewall zeigen.

In Cloud Umgebungen gilt dasselbe Prinzip. Bei Azure reicht die DNAT-Regel auf der Sophos Firewall allein nicht aus. Zusätzlich müssen die passenden Inbound rules in der Network Security Group geöffnet werden, sonst erreicht der Traffic die Firewall gar nicht.

DNAT und Firewall-Regel konfigurieren

Eine Server-Veröffentlichung besteht immer aus zwei Teilen: Die NAT-Regel übersetzt Ziel oder Port, die Firewall-Regel erlaubt und kontrolliert den Traffic.

Server Access Assistant oder manuelle DNAT-Regel?

Sophos Firewall bietet für Serververöffentlichungen zwei Wege:

• Server access assistant (DNAT): Passt als schneller Standardfall für eine einzelne Veröffentlichung. Der Assistent erstellt mehrere Regeln automatisch und setzt sie oben in die Regelbasis.
• Manuelle DNAT-Regel: Passt für komplexere Umgebungen mit Alias-IP, PAT, Load Balancing, speziellen Quellen oder bewusstem Regel-Design. Jedes Feld muss selbst gesetzt und getestet werden.

Der Assistent kann hilfreich sein, weil er nicht nur eine eingehende DNAT-Regel erzeugt, sondern je nach Auswahl auch eine Loopback-Regel, eine reflexive SNAT-Regel und die passende Firewall-Regel anlegt. Das spart Zeit, ist aber kein Ersatz für eine Prüfung der erzeugten Regeln.

Nach der Verwendung des Assistenten sollte man immer kontrollieren:

• Sind NAT- und Firewall-Regel an der richtigen Position?
• Ist die Source wirklich so eng wie geplant oder steht sie noch auf Any?
• Wurde eine Loopback-Regel erzeugt, obwohl Split DNS die sauberere Lösung wäre?
• Wurde eine reflexive Regel erzeugt, die für ausgehenden Server-Traffic gar nicht benötigt wird?
• Passt die Firewall-Regel zur Zielzone nach NAT und zum öffentlichen Zielobjekt vor NAT?

Für produktive Umgebungen ist oft eine manuell benannte und bewusst platzierte DNAT-Regel besser nachvollziehbar. Der Assistent ist gut für einen schnellen Start, aber die erzeugten Regeln gehören danach in denselben Review wie manuell erstellte Regeln.

DNAT-Regel erstellen

Ein typisches DNAT-Beispiel:

• Original source: Any oder definierte Quellnetze
• Original destination: WAN-IP oder WAN-Schnittstelle
• Original service: HTTPS
• Translated destination: interner Server
• Translated service: unverändert oder interner Zielport

Vorgehen:

1. Rules and policies öffnen.
2. Zum Bereich NAT rules wechseln.
3. Add NAT rule > New NAT rule auswählen.
4. Original Source, Destination und Service definieren.
5. Translated Destination auf den internen Server setzen.
6. Optional Translated Service setzen.
7. Inbound und Outbound Interface bewusst prüfen.
8. Regel speichern und aktivieren.

Wenn nur wenige externe Quell-IP-Adressen zugreifen müssen, sollte die Original Source nicht Any sein, sondern auf diese Quellen beschränkt werden.

Bei produktiven Freigaben ist ein Host-Objekt für die öffentliche IP meist sauberer als die direkte Auswahl eines WAN-Interfaces. Das Objekt bleibt nachvollziehbar, wenn sich Interfaces, Alias-Adressen oder Provider-Details später ändern.

Original und Translated richtig verstehen

Bei NAT-Regeln ist die Unterscheidung zwischen Original und Translated wichtig.

• Original source / destination / service beschreibt den Traffic, wie er bei der Sophos Firewall ankommt.
• Translated source / destination / service beschreibt den Traffic, wie er die Sophos Firewall nach der Übersetzung wieder verlässt.

Für eine eingehende DNAT-Regel bedeutet das:

• Original destination ist die öffentliche IP oder WAN-Adresse der Firewall.
• Original service ist der externe Port, den der Client anspricht.
• Translated destination (DNAT) ist der interne Server.
• Translated service (PAT) ist der interne Port auf dem Zielserver, falls der Port übersetzt werden soll.
• Translated source (SNAT) bleibt bei normalen DNAT-Regeln meistens auf Original.

Port Forwarding und PAT

Port Forwarding ist technisch eine Service-Translation. Auf der Sophos Firewall wird dafür Translated service (PAT) verwendet.

Beispiel:

• Extern: TCP 20120
• Intern: TCP 22

Der externe Client verbindet sich auf Port 20120, die Sophos Firewall leitet intern aber auf SSH-Port 22 weiter. Das kann sinnvoll sein, ersetzt aber keine Zugriffsbeschränkung. Ein geänderter externer Port reduziert vielleicht etwas Hintergrundrauschen, macht einen Dienst aber nicht sicher.

Wichtig: Das Protokoll muss gleich bleiben. TCP kann auf einen anderen TCP-Port übersetzt werden, UDP auf einen anderen UDP-Port. TCP zu UDP ist keine gültige Portübersetzung.

Wenn HTTPS veröffentlicht wird, muss man ausserdem prüfen, ob es Konflikte mit WebAdmin oder User Portal der Sophos Firewall gibt. Standardmässig nutzt die Admin-Konsole HTTPS-Port 4444, das User Portal HTTPS-Port 443. Bei Überschneidungen müssen die Firewall-eigenen Ports oder die veröffentlichten Dienste sauber getrennt werden.

Quell-IP und Rückweg bewusst planen

Bei einer normalen DNAT-Veröffentlichung sollte Translated source (SNAT) meistens auf Original bleiben. Dann sieht der interne Server die echte externe Quell-IP. Das ist wichtig für Server-Logs, Rate Limits, Fail2Ban-ähnliche Schutzmechanismen, Applikationslogs, WAF- oder Reverse-Proxy-Auswertung und spätere Incident-Analyse.

SNAT auf die Firewall oder eine interne Adresse kann trotzdem nötig sein, wenn der Rückweg sonst nicht über die Sophos Firewall läuft. Das ist zum Beispiel möglich, wenn der veröffentlichte Server ein anderes Default Gateway verwendet, in einem fremden Routingsegment steht oder eine asymmetrische Routing-Situation besteht.

Die Entscheidung sollte bewusst getroffen werden:

• Source bleibt Original: Der Server sieht die echte externe IP. Dafür muss der Rückweg sauber über die Firewall laufen.
• Source wird per SNAT übersetzt: Der Rückweg ist einfacher kontrollierbar. Dafür sieht der Server nur die Firewall- oder SNAT-IP, und die echte Client-IP geht im Serverlog verloren.

Wenn ein Dienst nur mit SNAT funktioniert, sollte man nicht sofort dabei bleiben und das Thema abhaken. Besser ist zuerst zu prüfen, ob Gateway, Route, VLAN, Server-Firewall oder Routingdesign korrigiert werden können. SNAT kann ein legitimer Workaround sein, macht spätere Analysen aber schwerer.

Beim Test sollte deshalb immer kontrolliert werden, welche Source-IP der Server tatsächlich sieht. Wenn statt der externen Client-IP nur die Firewall-IP auftaucht, muss klar dokumentiert sein, ob das Absicht ist.

Firewall-Regel prüfen

Eine NAT-Regel allein erlaubt den Traffic nicht automatisch. Zusätzlich braucht es eine passende Firewall-Regel.

Bei DNAT ist die Sicht in der Firewall-Regel ungewohnt, weil die Firewall gleichzeitig den ursprünglichen Zugriff von aussen und das übersetzte interne Ziel kennen muss.

Die wichtigste Faustregel:

⚠️ Bei DNAT verwendet die Firewall-Regel die Zielzone nach NAT, aber das Zielnetzwerk vor NAT.

Typische Zuordnung:

• Source zone: Meist WAN, wenn der Zugriff aus dem Internet kommt.
• Source networks and devices: Möglichst eingeschränkt, zum Beispiel einzelne IPs, Netze, Länder oder Gruppen.
• Destination zones: Zone des internen Servers nach DNAT, zum Beispiel DMZ oder SERVER.
• Destination networks: Öffentliche Zieladresse beziehungsweise WAN-Host-Objekt aus Original destination.
• Services: Externer Service aus Original service, also der Port, den Clients von aussen ansprechen.
• Security Profile: Je nach Dienst IPS, Malware Scan, Web Policy oder andere passende Prüfung.
• Logging: Für veröffentlichte Dienste aktivieren.

Ohne passende Firewall-Regel wird der Traffic trotz DNAT verworfen.

Dieser Punkt ist eine häufige Fehlerquelle: Wenn man als Destination network den internen Server einträgt, obwohl die Regel das öffentliche WAN-Objekt erwartet, matcht die Regel nicht. Die genaue Logik wird im Artikel NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT ausführlicher eingeordnet.

Auch bei NAT-Regeln gilt die Reihenfolge. Sophos prüft NAT-Regeln von oben nach unten und verwendet die erste passende Regel. Eine zu allgemeine NAT-Regel oberhalb kann deshalb verhindern, dass die spezifische DNAT-Regel greift.

Erweiterte NAT-Optionen

Diese Optionen werden erst relevant, wenn interne Clients öffentliche Namen verwenden, Rückwege speziell übersetzt werden müssen oder mehrere Zielserver beteiligt sind.

Loopback, Reflexive und Linked NAT Rules

Die Sophos Firewall bietet mehrere NAT-Optionen, die leicht verwechselt werden:

• Loopback rule: Hilft, wenn interne Clients einen internen Server über die öffentliche IP oder den öffentlichen DNS-Namen erreichen sollen.
• Reflexive rule: Erstellt eine spiegelnde SNAT-Regel zu einer DNAT-Regel, damit Rückverkehr oder bestimmte Gegenrichtungen passend übersetzt werden.
• Linked NAT rule: Wird aus einer Firewall-Regel heraus erstellt und ist eine verknüpfte SNAT-Regel. Eine Linked NAT Rule ist nicht dasselbe wie eine eingehende DNAT-Regel für einen veröffentlichten Server.

Für klassische Server-Veröffentlichungen ist meist eine eigenständige DNAT-Regel plus passende Firewall-Regel am übersichtlichsten. Linked NAT Rules können sinnvoll sein, wenn eine Firewall-Regel direkt eine spezielle SNAT-Übersetzung benötigt. In allgemeinen Umgebungen bleiben eigenständige, klar benannte NAT-Regeln jedoch meistens einfacher zu verstehen und zu warten.

Wichtig: Loopback- und reflexive Regeln werden aus der ursprünglichen DNAT-Regel abgeleitet. Wenn die ursprüngliche DNAT-Regel später geändert wird, sollte man die abgeleiteten Regeln separat prüfen. Sonst kann es passieren, dass der externe Zugriff korrekt angepasst wurde, interne Loopback-Zugriffe oder ausgehender Server-Traffic aber weiterhin nach der alten Logik laufen.

Load Balancing und Health Check

Wenn mehrere interne Server hinter einer öffentlichen IP veröffentlicht werden, kann DNAT auch für Load Balancing oder Failover verwendet werden.

Mögliche Methoden sind zum Beispiel:

• Round robin
• First alive
• Random
• Sticky IP
• One-to-one

Wenn die Firewall erkennen soll, ob ein Zielserver verfügbar ist, muss ein Health check konfiguriert werden. Ohne Health Check kann die Firewall Traffic auch an einen Server weiterleiten, der nicht erreichbar ist.

Absicherung und Go-live

Ein veröffentlichter Dienst ist sofort Teil der öffentlichen Angriffsfläche. Deshalb gehören enger Zugriff, Logging, Security Profile und ein klarer Rollback zum Go-live.

Go-live und Rollback planen

Eine DNAT-Veröffentlichung sollte wie eine kleine Produktionsänderung behandelt werden. Sobald die Regel aktiv ist, kann der Dienst aus dem Internet erreichbar sein. Deshalb sollte vor dem Go-live klar sein, welche Regel aktiv wird, wie der Zugriff getestet wird und wie man bei Problemen zurückgeht.

Vor dem Go-live prüfen:

• Aktuelle Firewall-Konfiguration sichern oder mindestens die betroffenen NAT- und Firewall-Regeln dokumentieren.
• Bestehende NAT-Regeln auf dieselbe öffentliche IP, denselben externen Port und dieselbe WAN-Schnittstelle prüfen.
• Provider-Router, Cloud Security Group oder vorgelagerte Firewall-Regeln mit der Sophos-Konfiguration abgleichen.
• DNS-TTL berücksichtigen, wenn ein Hostname neu auf die veröffentlichte Adresse zeigt.
• Testquelle ausserhalb des eigenen LAN vorbereiten, zum Beispiel Mobilfunk, externer Standort oder kontrollierter Online-Porttest.
• Erwartete Logstellen festlegen: Log Viewer, NAT Rule ID, Firewall Rule ID, Packet Capture und Server-Log.
• Rollback-Kriterium definieren, zum Beispiel falscher Dienst erreichbar, Server antwortet nicht, Zertifikatsfehler, Security Profile blockiert legitimen Traffic oder unerwartete Quell-IP auf dem Server.

Ein einfacher Rollback besteht meistens darin, die neue DNAT-Regel und die passende Firewall-Regel zu deaktivieren. Wenn eine alte Veröffentlichung ersetzt wurde, sollte klar sein, ob die alte Regel wieder aktiviert werden darf oder ob zuerst Provider-Portweiterleitung, DNS oder Monitoring zurückgestellt werden müssen.

Bei kritischen Diensten sollte man nicht mehrere Dinge gleichzeitig ändern. Wenn DNS, Provider-Router, NAT-Regel, Firewall-Regel und Serverkonfiguration gleichzeitig angepasst werden, ist ein Fehler später schwer zuzuordnen. Besser ist ein kurzer Ablauf mit klaren Schritten: vorbereiten, aktivieren, extern testen, Logs prüfen, Server prüfen, Ergebnis dokumentieren.

Zugriff möglichst eng einschränken

Nicht jeder veröffentlichte Dienst muss aus dem gesamten Internet erreichbar sein. Wenn möglich, sollte man den Zugriff begrenzen.

Sinnvolle Einschränkungen:

• Nur einzelne Quell-IP-Adressen erlauben.
• Nur bekannte FQDN-Hosts erlauben, wenn die Gegenseite dynamische IPs verwendet.
• Nur bestimmte Länder erlauben.
• Bestimmte Länder explizit blockieren.
• Zugriff nur über VPN ermöglichen.
• Statt direkter Veröffentlichung eine ZTNA Lösung verwenden.

Für administrative Dienste wie SSH, RDP oder interne Admin-Portale ist DNAT meistens nicht die beste Lösung. Wenn der Zugriff nicht öffentlich sein muss, ist VPN oder ZTNA fast immer die bessere Wahl.

Sicherheit verbessern

Für veröffentlichte Dienste sollte man prüfen:

• Ist der Server aktuell gepatcht?
• Gibt es eine WAF oder Reverse-Proxy-Option?
• Ist IPS auf der Firewall-Regel aktiv?
• Sind nur notwendige Ports geöffnet?
• Wird der Dienst geloggt?
• Gibt es Geo-IP-, Threat-Feed- oder Quell-IP-Einschränkungen?
• Ist MFA möglich, falls es sich um ein Portal handelt?

Für Webanwendungen kann statt reinem DNAT auch Web Server Protection / WAF sinnvoll sein.

Bots und Threat Feeds

Öffentliche Ports wie HTTP, HTTPS, SSH oder RDP stehen permanent im Fokus von Bots. Sobald ein Port im Internet erreichbar ist, sieht man oft sehr schnell Verbindungsversuche, Scans, Loginversuche oder Exploit-Traffic im Log Viewer.

Das bedeutet nicht automatisch, dass der Server kompromittiert ist. Es zeigt aber, dass der Dienst Teil der öffentlichen Angriffsfläche ist. Deshalb empfehlen wir, veröffentlichte Dienste zusätzlich mit IPS, Logging, engen Quellen und Third-Party Threat Feeds abzusichern.

Threat Feeds liefern der Firewall laufend aktuelle Indicators of Compromise, zum Beispiel bösartige IP-Adressen oder Domains. Dadurch kann die Firewall bekannte Angreifer, Botnetze oder Scanner blockieren, bevor sie den veröffentlichten Dienst erreichen.

Mehr dazu: Sophos Firewall Threat Feeds

Test

Nach dem Speichern der DNAT-Regel:

• Aus einem externen Netz testen, nicht aus demselben LAN
• Nur den erwarteten öffentlichen Port prüfen, nicht breit gegen fremde Adressen scannen
• Log Viewer auf Firewall Rule ID und NAT Rule ID prüfen
• Packet Capture mit externer Source, öffentlicher Destination und internem Ziel vergleichen
• Server-Logs kontrollieren
• Sichtbare Quell-IP auf dem Zielsystem kontrollieren

Wenn der Test aus dem internen LAN auf die öffentliche IP erfolgen soll, kann zusätzlich Hairpin NAT oder eine interne DNS-Lösung nötig sein.

Testmatrix für DNAT-Freigaben

Ein einzelner Porttest reicht für eine produktive DNAT-Freigabe selten aus. Besser ist eine kleine Testmatrix, die erlaubte und unerwünschte Pfade trennt. So sieht man nicht nur, ob der Dienst erreichbar ist, sondern auch, ob Einschränkungen, Logging und Rückweg korrekt funktionieren.

Sinnvolle Testquellen:

• Externe erlaubte Quelle: Verbindung von Mobilfunk, externem Standort oder Partnernetz auf öffentliche IP und externen Port testen. Im Log Viewer müssen erwartete Firewall Rule ID und NAT Rule ID erscheinen.
• Externe nicht erlaubte Quelle: Wenn die Freigabe auf bestimmte Quellen begrenzt ist, sollte ein Test von einer nicht erlaubten Quelle bewusst scheitern. Sonst ist die Source-Einschränkung zu breit.
• Interner Client mit internem DNS-Namen: Prüfen, ob interne Benutzer direkt zur internen Server-IP auflösen. Das ist oft sauberer als Loopback NAT.
• Interner Client mit öffentlichem FQDN: Nur testen, wenn dieser Zugriff wirklich benötigt wird. Falls er scheitert, zuerst Split DNS prüfen und Loopback NAT nicht automatisch ergänzen.
• Zielserver selbst: Server-Log, lokale Firewall, gebundener Dienst, Zertifikat und sichtbare Source-IP prüfen. So erkennt man, ob der Server die echte externe IP oder eine SNAT-Adresse sieht.
• Monitoring oder externer Health Check: Prüfen, ob der Test dieselbe URL, denselben Port und dieselbe Quelllogik verwendet wie die echte Überwachung.

Nach jedem Test sollte man nur einen Befund bewerten: Kommt der Traffic bei der Sophos Firewall an, greift die erwartete NAT-Regel, greift die erwartete Firewall-Regel, erreicht das Paket den Server und kommt eine Antwort zurück. Wenn mehrere Dinge gleichzeitig geändert werden, ist der nächste Fehler sonst kaum noch zuzuordnen.

Ein sauberer DNAT-Test vergleicht drei Sichtweisen:

• Externer Client: Verbindung zur öffentlichen IP und zum externen Port funktioniert oder wird bewusst blockiert.
• Sophos Firewall: Log Viewer zeigt die erwartete Firewall Rule ID und NAT Rule ID.
• Interner Server: Dienst sieht die erwartete Source-IP, antwortet über den richtigen Gateway und protokolliert den Zugriff.

Wenn nur eine dieser Sichtweisen geprüft wird, bleiben typische Fehler unentdeckt. Ein erfolgreicher externer Porttest sagt zum Beispiel noch nicht, ob Logging, IPS, Source-Einschränkung oder Server-Owner sauber dokumentiert sind.

Troubleshooting und Betrieb

Nach dem Go-live sollte man nicht nur prüfen, ob der Dienst erreichbar ist. Wichtig sind Log Viewer, NAT Rule ID, Firewall Rule ID, Server-Logs und regelmässige Reviews alter Freigaben.

Troubleshooting

Häufige Fehler:

• Firewall-Regel fehlt
• falsche WAN-IP gewählt
• Portweiterleitung auf dem Provider-Router fehlt
• Azure Network Security Group blockiert den Port
• Dienst läuft intern nicht
• Server-Gateway zeigt nicht auf die Sophos Firewall
• NAT-Regel steht unter einer anderen, die vorher greift
• Firewall-Regel nutzt bei DNAT das falsche Destination network
• Port wird bereits von einem anderen Dienst verwendet
• Loopback fehlt, wenn interne Clients den öffentlichen FQDN verwenden
• Health Check fehlt oder ist falsch, wenn Load Balancing verwendet wird
• Test erfolgt aus dem internen Netz und nicht von extern
• Der Zielserver antwortet über einen anderen Gateway zurück
• Ein Security Profile blockiert den Traffic, wird aber nicht im richtigen Log gesucht

Der Log Viewer ist bei DNAT-Problemen der wichtigste Startpunkt. Dort sieht man, ob Traffic ankommt, welche Firewall-Regel und welche NAT-Regel greifen und ob der Traffic erlaubt oder verworfen wird. Wenn der Treffer nicht zur Erwartung passt, hilft Sophos Firewall-Regel greift nicht: Ursachen prüfen.

Für tieferes Troubleshooting sollte man nicht nur die Sophos Firewall betrachten. Wenn der Log Viewer den Traffic erlaubt und Packet Capture zeigt, dass Pakete zum Server weitergehen, liegt die Ursache häufig auf dem Zielsystem: lokale Firewall, falscher Default Gateway, Dienst nicht gebunden, Zertifikatproblem, Anwendung lauscht auf anderem Port oder vorgeschalteter Reverse Proxy antwortet nicht wie erwartet.

Eine schnelle Einordnung hilft, damit man nicht an der falschen Stelle sucht:

• Im Log Viewer erscheint kein Treffer: Traffic erreicht die Firewall nicht oder die falsche WAN-IP wird angesprochen. Provider-Router, Cloud-Security-Group, öffentliche IP und Packet Capture auf WAN prüfen.
• Firewall Rule ID passt, NAT Rule ID fehlt: NAT-Regel matcht nicht oder steht zu tief. Original destination, Original service, Inbound Interface und NAT-Reihenfolge prüfen.
• NAT Rule ID passt, Dienst antwortet nicht: Zielserver oder Rückweg stimmt nicht. Server-Firewall, Default Gateway, Routing und Packet Capture Richtung Server prüfen.
• Extern funktioniert es, intern über FQDN nicht: Split DNS oder Loopback fehlt. Interne DNS-Auflösung prüfen und Loopback nur bewusst ergänzen.
• Nach Änderung des Assistenten verhält sich nur ein Teil falsch: Abgeleitete Loopback- oder reflexive Regel passt nicht mehr. Erzeugte NAT- und Firewall-Regeln einzeln prüfen.

Wann Black Hole DNAT zusätzlich hilft

Wenn ein Dienst bewusst öffentlich erreichbar bleiben muss, aber bestimmte Quellen vor der eigentlichen Veröffentlichung abgefangen werden sollen, kann eine Black-Hole-DNAT-Regel oberhalb der produktiven DNAT-Regel sinnvoll sein. Das passt zum Beispiel bei bekannten Bad-IP-Listen, dauerhaft unerwünschten Ländern oder wiederkehrenden Scanner-Quellen.

Diese Technik ersetzt keine saubere Freigabe. Die produktive DNAT-Regel muss weiterhin eng sein, Logging muss aktiv sein und der veröffentlichte Server muss aktuell gehalten werden. Black Hole DNAT ist eine zusätzliche Block-Ebene vor einer Veröffentlichung, nicht die eigentliche Sicherheitsarchitektur.

Sinnvoll ist Black Hole DNAT vor allem in diesen Fällen:

• Wiederkehrende Scanner-Quellen treffen denselben veröffentlichten Dienst: Die Quellen können vor der produktiven DNAT-Regel ins Leere laufen.
• Einzelne Länder sollen keinen Zugriff auf eine Portweiterleitung haben: Die Block-Regel kann oberhalb der eigentlichen DNAT-Regel stehen.
• Eine gepflegte Bad-IP-Gruppe existiert bereits: Die Gruppe kann als Original source der Black-Hole-Regel verwendet werden.
• Ein Dienst muss öffentlich bleiben, soll aber weniger Bot-Traffic erreichen: Die produktive Regel bleibt erhalten, unerwünschte Quellen werden vorher abgefangen.

Nicht passend ist Black Hole DNAT für lokale Firewall-Dienste wie WebAdmin, User Portal, VPN Portal oder SSH zur Firewall selbst. Dafür sind Device Access und Local Service ACL exception rules zuständig. Für Webserver über WAF sollte man zuerst die WAF-Regel, Blocked countries, Authentication und WAF-Logs prüfen.

Wichtig ist die Reihenfolge: Die Black-Hole-DNAT-Regel muss oberhalb der produktiven DNAT-Regel stehen. Danach sollte man im Log Viewer prüfen, ob blockierte Quellen wirklich die Black-Hole-Regel treffen und erlaubte Quellen weiterhin die produktive NAT- und Firewall-Regel verwenden. Der genaue Ablauf steht in Sophos Firewall: Länder und bösartige IPs blockieren.

Betriebscheck

DNAT-Regeln sollten regelmässig geprüft werden. Alte Freigaben sind ein typisches Sicherheitsrisiko, weil veröffentlichte Dienste oft noch erreichbar bleiben, obwohl die Anwendung längst umgezogen, ersetzt oder nur temporär benötigt wurde.

Für produktive DNAT-Regeln sollte mindestens dokumentiert sein:

• Zweck der Freigabe: Später muss klar sein, warum der Dienst überhaupt öffentlich erreichbar ist.
• Verantwortliche Person oder Team: Ohne Owner werden alte Freigaben selten entfernt.
• Öffentliche IP und externer Port: Erleichtert Prüfung, Monitoring und externe Scans.
• Interner Zielserver und Zielport: Wichtig bei Servermigrationen, Load Balancing und Zertifikatswechseln.
• Erwartete Quellen: Hilft zu erkennen, ob Any wirklich nötig ist.
• Schutzmassnahmen: IPS, WAF-Alternative, MFA, Threat Feeds, Logging und Patchstand sollten nachvollziehbar sein.
• Ablaufdatum oder Review-Termin: Temporäre Freigaben brauchen ein klares Ende.

Ein sinnvoller Review besteht nicht nur aus einem Blick auf die Regel. Man sollte extern prüfen, ob nur die erwarteten Ports offen sind, im Log Viewer kontrollieren, welche Quellen tatsächlich zugreifen, und auf dem Zielserver prüfen, ob die Anwendung noch gepflegt wird. Wenn der Dienst nur intern oder für wenige Partner benötigt wird, sollte VPN, ZTNA, eine Quell-IP-Einschränkung oder eine WAF-Regel neu bewertet werden.

Beim Entfernen alter DNAT-Regeln sollte man nicht nur die NAT-Regel löschen. Häufig hängen Firewall-Regeln, Host-Objekte, Service-Objekte, Loopback Rules, Reflexive Rules, DNS-Einträge, Monitoring-Checks oder Provider-Portweiterleitungen daran. Besser ist ein kurzer Decommission-Ablauf:

1. Letzte Zugriffe im Log Viewer prüfen.
2. Zuständige Person oder Fachbereich bestätigen lassen, dass der Dienst nicht mehr benötigt wird.
3. NAT-Regel und passende Firewall-Regel zunächst deaktivieren.
4. Extern testen, ob der Port geschlossen ist.
5. Monitoring und Server-Logs nach Fehlern prüfen.
6. Erst danach nicht mehr benötigte Objekte, DNS-Einträge und Provider-Regeln bereinigen.

Wenn eine Freigabe weiterhin benötigt wird, sollte der Review mit einem konkreten Ergebnis enden: unverändert belassen, enger einschränken, auf WAF umstellen, hinter VPN/ZTNA verschieben oder mit Ablaufdatum erneut prüfen.

FAQ