NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT

NAT ist auf der Sophos Firewall eines der Themen, das in der Praxis schnell verwirrend wird. Die Begriffe klingen ähnlich, die Regelmaske arbeitet mit Original und Translated, und im Log Viewer sieht man je nach Stelle andere Adressen als erwartet.

Dieser Artikel erklärt die wichtigsten NAT-Arten, zeigt typische Praxisfälle und beschreibt ein DNAT-Beispiel mit passender Firewall Regel.

Der wichtigste praktische Punkt ist: NAT muss zusammen mit Firewall-Regel, Routing, Rückweg und Logging betrachtet werden. Viele NAT-Probleme entstehen nicht durch die Übersetzung selbst, sondern durch falsche Regelreihenfolge, ein missverstandenes Original destination, fehlendes Logging oder Tests aus dem falschen Netz.

Orientierung

Bevor man eine NAT-Regel baut, sollte zuerst klar sein, welches Problem wirklich gelöst werden soll. NAT übersetzt Adressen oder Ports, ersetzt aber keine Firewall-Freigabe und kein sauberes Routingdesign.

Welcher NAT-Artikel passt?

NAT überschneidet sich schnell mit Firewall-Regeln, Routing, WAF, VPN und Packet Capture. Je nach Aufgabe ist nicht immer dieser Grundlagenartikel der beste Einstieg:

• NAT, SNAT, DNAT, MASQ, PAT, Loopback und Reflexive Rules verstehen: Dieser Artikel.
• Internen Server per Portweiterleitung veröffentlichen: Server per DNAT auf Sophos Firewall veröffentlichen.
• HTTP- oder HTTPS-Anwendung öffentlich bereitstellen: Sophos Firewall WAF: Webserver sicher veröffentlichen.
• Firewall-Regeln und NAT gemeinsam einordnen: Sophos Firewall-Regeln verstehen und sicher konfigurieren.
• Einzelne Verbindung mit Logs und Packet Capture testen: Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.
• NAT bei IPsec, XFRM, SD-WAN oder überlappenden Netzen prüfen: Sophos Firewall IPsec VPN Troubleshooting.
• Drops, Violation, Rule ID oder NAT Rule ID analysieren: Sophos Firewall verworfene Pakete analysieren.

So bleibt die Fehlersuche enger: Erst klären, ob es um Übersetzung, Freigabe, Routing, Webserver-Schutz oder Paketfluss geht. Danach sollte nur an der betroffenen Ebene geändert werden.

NAT ist Übersetzung, keine Freigabe

Network Address Translation ändert Adressen oder Ports eines Pakets, während es durch die Sophos Firewall läuft. NAT entscheidet aber nicht alleine, ob Traffic erlaubt ist.

⚠️ Eine NAT-Regel erlaubt keinen Traffic. Die Regel übersetzt nur Adressen oder Ports. Für Traffic durch die Firewall braucht es zusätzlich immer eine passende Firewall Regel.

Typische NAT-Fälle:

• Interne Clients gehen über die öffentliche WAN-IP ins Internet.
• Ein interner Server wird über eine öffentliche IP veröffentlicht.
• Ein öffentlicher Port wird auf einen anderen internen Port übersetzt.
• Überlappende Netze werden für VPN-Verbindungen übersetzt.
• Interne Clients greifen über den öffentlichen DNS-Namen auf einen internen Server zu.

Schnellentscheidung: NAT oder kein NAT?

Viele NAT-Fehler entstehen, weil NAT als Standardlösung verwendet wird, obwohl Routing oder eine Firewall Regel reichen würde. Vor jeder neuen NAT-Regel sollte deshalb zuerst entschieden werden, ob wirklich eine Adresse oder ein Port verändert werden muss.

• Client aus dem LAN soll normal ins Internet: Meist reicht eine allgemeine SNAT- oder MASQ-Regel.
• Interner Server soll aus dem Internet erreichbar sein: DNAT verwenden oder bei HTTP/HTTPS zuerst WAF prüfen.
• Extern soll ein anderer Port verwendet werden als intern: DNAT mit PAT planen und die passende Firewall Regel ergänzen.
• Interne Benutzer greifen auf denselben öffentlichen FQDN zu: Zuerst Split DNS prüfen, Loopback NAT nur bei Bedarf einsetzen.
• Lokale und entfernte VPN-Netze sind eindeutig: Meist kein NAT verwenden, sondern Routing und Firewall-Regeln sauber bauen.
• VPN-Netze überschneiden sich oder die Gegenstelle fordert eine bestimmte Source: Gezieltes SNAT oder DNAT mit dokumentiertem Ersatznetz verwenden.
• Nur eine Firewall-Regel soll erlaubt oder eingeschränkt werden: Kein NAT bauen. Die Firewall Regel anpassen.

Wenn die Antwort auf “Was soll übersetzt werden?” nicht klar ist, sollte keine NAT-Regel erstellt werden. Dann zuerst Paketfluss, Zieladresse, Rückweg und Log Viewer prüfen. Besonders bei internen VLANs, Site-to-Site-VPNs ohne überlappende Netze und gerouteten Servernetzen ist kein NAT oft die sauberere Lösung.

NAT-Grundlagen verstehen

Die Regelmaske wird deutlich einfacher, wenn man zuerst zwischen Original-Traffic und übersetztem Traffic unterscheidet. Danach ist klarer, ob Source, Destination oder Service verändert werden muss.

Die wichtigsten NAT-Arten

• SNAT: Übersetzt die Source IP. Typisch, wenn interne Clients oder Server mit einer bestimmten öffentlichen IP ins Internet gehen sollen.
• MASQ: Übersetzt die Source IP auf die IP des ausgehenden Interfaces. Das ist der Standardfall für LAN zu WAN.
• DNAT: Übersetzt die Destination IP. Damit wird ein interner Server über eine öffentliche IP erreichbar.
• PAT: Übersetzt Port oder Service. Damit zeigt ein externer Port auf einen anderen internen Port.
• Loopback NAT: Ermöglicht internen Zugriff über öffentliche IP oder öffentlichen FQDN. Interne Clients verwenden denselben DNS-Namen wie externe Benutzer.
• Reflexive Rule: Erzeugt eine spiegelnde Source-NAT-Regel. Ein veröffentlichter Server kann dadurch für ausgehenden Traffic mit einer passenden öffentlichen Identität erscheinen.

Als Denkmodell hilft: NAT beantwortet nicht die Frage „Darf dieser Traffic?“, sondern „Wie sollen Adresse oder Port unterwegs aussehen?“

Original und Translated richtig lesen

In NAT-Regeln beschreibt Original den Traffic, wie er bei der Sophos Firewall ankommt. Translated beschreibt ihn nach der Übersetzung.

• Original source: Quelladresse vor NAT.
• Translated source (SNAT): Quelladresse nach NAT.
• Original destination: Zieladresse vor NAT.
• Translated destination (DNAT): Zieladresse nach NAT.
• Original service: Dienst oder Port vor NAT.
• Translated service (PAT): Dienst oder Port nach NAT.

Bei Fehlern sollte man zuerst notieren, wie das Paket vor NAT aussieht. Danach definiert man, was die Firewall daraus machen soll.

NAT vor der Änderung planen

Vor einer NAT-Änderung sollte man nicht nur die NAT-Regel selbst betrachten. Entscheidend ist der gesamte Paketfluss: Wo kommt das Paket an, welche Firewall Regel erlaubt den Traffic, welche NAT-Regel übersetzt ihn, wohin geht die Antwort und wie wird das Ergebnis geprüft?

Der Menüpfad lautet Rules and policies > NAT rules > Add NAT rule. Dabei muss wie bei Firewall-Regeln zuerst bewusst zwischen IPv4 und IPv6 gewählt werden. Eine saubere IPv4-NAT-Regel löst kein IPv6-Problem und schützt auch nicht automatisch vor IPv6-Traffic, der über eigene Regeln oder Routen läuft.

Diese Punkte sollten vor dem Change klar sein:

• Paket vor NAT: Source, Destination und Service müssen zur Original-Seite der NAT-Regel passen.
• Paket nach NAT: Translated source, Translated destination und Translated service müssen bewusst gesetzt sein.
• Erlaubende Firewall Regel: NAT erlaubt keinen Traffic. Ohne passende Firewall Regel bleibt die Übersetzung wirkungslos.
• Allgemeinere NAT-Regeln: Die erste passende NAT-Regel gewinnt. Eine breite SNAT- oder MASQ-Regel kann spezifischere Regeln verdecken.
• Interfaces und VPNs: Bei DNAT und VPN-Kontexten ist Any bei Inbound oder Outbound Interface oft korrekt, weil VPN-Tunnel nicht wie normale physische Interfaces behandelt werden.
• Rückweg: Viele NAT-Probleme sind eigentlich Routing-, Rückweg- oder Zielsystemprobleme.
• Testmethode: Log Viewer, Rule ID, NAT Rule ID und Packet Capture sollten vor dem Test vorbereitet sein.

Für die passende Firewall Regel hilft Sophos Firewall-Regeln verstehen und sicher konfigurieren. Wenn unklar ist, ob die Regel überhaupt greift, ist Sophos Firewall Regel greift nicht: Ursachen prüfen der bessere Troubleshooting-Einstieg.

Praxisbeispiele: Wann verwendet man was?

• Clients aus dem LAN sollen ins Internet: MASQ oder SNAT. Beispiel: 10.10.10.80 geht nach aussen mit der WAN-IP der Firewall.
• Interner Webserver soll von extern erreichbar sein: DNAT. Beispiel: Die öffentliche WAN-IP zeigt auf 172.16.16.10.
• Extern wird ein anderer Port verwendet als intern: PAT. Beispiel: Extern TCP 5555, intern TCP 443.
• Interne Benutzer verwenden denselben FQDN wie externe Benutzer: Loopback NAT. Beispiel: service.example.com zeigt intern und extern auf denselben Dienst.
• Veröffentlichter Server soll ausgehend mit bestimmter öffentlicher IP erscheinen: SNAT oder Reflexive Rule. Beispiel: Ein Mailserver sendet mit definierter öffentlicher IP.
• VPN-Netze überschneiden sich: SNAT oder DNAT. Beispiel: Standort A sieht Standort B über ein übersetztes Netz.
• Interner Traffic soll unverändert bleiben: Kein NAT. Routing und Firewall Regel reichen aus.

Nicht jeder Traffic braucht NAT. Zwischen internen VLANs, über Site-to-Site-VPNs ohne überlappende Netze oder zu direkt gerouteten Netzen ist NAT oft sogar schädlich, weil Logs, Gegenstellen und Zielsysteme die echte Source-IP verlieren. Eine gute NAT-Planung entscheidet deshalb zuerst, ob überhaupt übersetzt werden muss.

NAT-Arten in der Praxis

Die folgenden NAT-Arten lösen unterschiedliche Aufgaben. In produktiven Umgebungen sollte man bewusst auswählen, welche Übersetzung nötig ist, statt NAT als generellen Workaround für Routingprobleme zu verwenden.

SNAT: Source NAT

SNAT ändert die Quelladresse. Der klassische Fall ist ausgehender Internetzugriff aus dem LAN. Die Clients behalten intern ihre internen IP-Adressen, nach aussen erscheint aber die öffentliche Adresse der Firewall oder eine definierte öffentliche IP.

Typische SNAT-Regel für LAN zu WAN:

• Original source: internes LAN oder Servernetz.
• Translated source (SNAT): MASQ oder feste öffentliche IP.
• Original destination: Any.
• Translated destination (DNAT): Original.
• Original service: Any oder definierte Services.
• Translated service (PAT): Original.
• Inbound interface: internes Interface oder Any.
• Outbound interface: WAN-Interface.

Für einfache Umgebungen ist eine generische SNAT-Regel oft übersichtlicher als viele einzelne Linked NAT Rules.

MASQ: Masquerading

MASQ ist eine bequeme SNAT-Variante. Standardmässig übersetzt MASQ die Quelladresse auf die IP-Adresse des ausgehenden Interfaces. Bei normalem Internetzugriff ist das meistens die WAN-IP.

Die Sophos Firewall hat in der Grundkonfiguration eine Default-SNAT-Regel mit MASQ. Wenn man diese Regel nicht verwenden möchte, ist Deaktivieren meist sauberer als Löschen. Beim Anlegen oder Aktualisieren eines WAN-Interfaces kann die Default-Regel sonst wieder auftauchen.

Stolperstein: Bei route-based VPNs kann MASQ anders aussehen als erwartet. Wenn lokale und entfernte Subnetze auf Any stehen oder Dual-IP-Konfigurationen verwendet werden, kann die Firewall als übersetzte Source die XFRM-IP verwenden. In Packet Capture oder tcpdump sieht man dann die WAN-IP im äusseren Header und die XFRM-IP im inneren Kontext.

Bei policy-based IPsec gelten andere Stolpersteine. Wenn übersetzter Traffic einem bestimmten IPsec-Tunnel zugeordnet werden muss, können IPsec Routes und die Einstellung Outbound interface in SNAT-Regeln entscheidend sein. Der Ablauf steht in IPsec Route auf Sophos Firewall erstellen.

NAT bei VPN, SD-WAN und überlappenden Netzen

NAT wird in VPN- und SD-WAN-Umgebungen schnell komplexer als bei einfachem LAN-zu-WAN-Traffic. Der wichtigste Grundsatz bleibt trotzdem gleich: Zuerst muss der erwartete Pfad klar sein. Danach entscheidet man, ob NAT nötig ist.

Typische Szenarien:

• Site-to-Site-VPN mit eindeutigen Netzen: Meist kein NAT, sondern saubere Firewall-Regeln und Routing.
• Site-to-Site-VPN mit überlappenden Netzen: Gezielte SNAT- oder DNAT-Regel mit dokumentiertem Ersatznetz.
• Route-based VPN mit XFRM und SD-WAN: XFRM-Interface, Route, SD-WAN Route und NAT gemeinsam prüfen.
• Policy-based IPsec mit übersetztem Traffic: IPsec Route und SNAT-Regel mit passendem Outbound interface prüfen.
• Remote Access VPN zu internen Netzen: Normalerweise kein NAT, ausser ein Zielsystem erwartet eine bestimmte Source.

Bei überlappenden Netzen sollte NAT nicht improvisiert werden. Beide Seiten müssen wissen, welches echte Netz hinter welchem übersetzten Netz steht. Sonst funktionieren einzelne Tests, aber Applikationen, DNS, Logging oder Zugriffsregeln werden später schwer nachvollziehbar.

Wenn ein VPN-Tunnel grün ist, aber kein Nutztraffic fliesst, ist NAT nur eine von mehreren möglichen Ursachen. Dann sollten parallel IPsec-Status, Route Lookup, Firewall-Regel, SD-WAN Route und Packet Capture geprüft werden. Für den strukturierten Ablauf passen Sophos Firewall IPsec VPN Troubleshooting, SD-WAN Routing für Reply Packets und System Traffic und Sophos Firewall MTU und MSS bei VPN-Problemen prüfen.

DNAT: Destination NAT

DNAT ändert die Zieladresse. Damit veröffentlicht man zum Beispiel einen internen Server über eine öffentliche IP oder einen öffentlichen Port. Eingehender Traffic an die WAN-Adresse wird auf den internen Server übersetzt.

Typische DNAT-Regel:

• Original source: Any oder definierte Quell-IP-Netze.
• Original destination: WAN-IP oder WAN-Host-Objekt.
• Original service: externer Dienst, zum Beispiel HTTPS oder Synology_5555.
• Translated destination (DNAT): interner Server.
• Translated service (PAT): Original oder interner Zielport.
• Translated source (SNAT): meistens Original.
• Inbound interface: Any oder WAN-Interface.
• Outbound interface: meistens Any bei DNAT.

Für öffentliche Dienste sollte man nicht nur NAT bauen, sondern sofort Logging, IPS, Quell-Einschränkungen, Geo-IP-Logik und Patchstand des Zielservers prüfen. Eine ausführlichere Schritt-für-Schritt-Anleitung steht im Artikel Server per DNAT auf Sophos Firewall veröffentlichen.

Bei HTTP- und HTTPS-Anwendungen sollte zusätzlich geprüft werden, ob eine Sophos Firewall WAF besser passt als reines DNAT. DNAT ist eine Portweiterleitung. WAF kann Hostnamen, Zertifikate, Pfade, Web-Schutzprofile und optional Authentifizierung einbeziehen. Für einfache Nicht-HTTP-Dienste bleibt DNAT oft richtig, für öffentlich erreichbare Webanwendungen ist WAF häufig der bessere Startpunkt.

PAT: Port Address Translation

PAT ändert den Dienst beziehungsweise Port. Auf der Sophos Firewall ist das Feld Translated service (PAT) dafür zuständig.

Beispiel:

• Extern TCP 5555 auf intern TCP 443.
• Extern TCP 20120 auf intern TCP 22.
• Extern TCP 8443 auf intern TCP 443.

Der externe Client verbindet sich auf einen öffentlichen Port, intern wird aber ein anderer Port angesprochen.

Wichtig: Das Protokoll muss passen. TCP kann auf TCP übersetzt werden, UDP auf UDP. Eine Übersetzung von TCP nach UDP ist keine saubere Portweiterleitung.

Auch die Anzahl der Services muss passen. Wenn in Original service mehrere Services oder Any verwendet werden, sollte Translated service (PAT) normalerweise auf Original bleiben. Eine Portübersetzung funktioniert sauber, wenn ein konkreter Original-Service auf einen konkreten passenden Ziel-Service übersetzt wird.

DNAT-Beispiel mit Firewall-Regel

Das Beispiel zeigt die typische Veröffentlichung eines internen Dienstes. Entscheidend ist dabei, dass NAT-Regel und Firewall Regel zusammenpassen.

Praxisbeispiel: Synology per DNAT veröffentlichen

Im Beispiel soll ein Dienst über eine öffentliche WAN-IP erreichbar sein. Von aussen wird der Service Synology_5555 angesprochen. Intern hört der Server aber auf HTTPS. Die NAT-Regel übersetzt also die öffentliche Zieladresse auf den internen Server und den öffentlichen Service auf den internen Service.

Das Beispiel ist bewusst technisch gehalten. Management-Oberflächen wie NAS, RDP, SSH oder WebAdmin sollten nur dann direkt veröffentlicht werden, wenn es wirklich nötig ist. In vielen Fällen sind VPN oder ZTNA die bessere Lösung.

DNAT-Regel Feld für Feld

• Rule name: Eindeutig benennen, zum Beispiel DNAT_SYNOLOGY_5555.
• Description: Dokumentieren, warum die Regel existiert und wer sie erstellt hat. Das hilft später enorm.
• Rule position: Spezifische Regeln sollten oberhalb allgemeiner Regeln stehen.
• Original source: Kann in der NAT-Regel eingeschränkt werden. In der Praxis ist es oft sauberer, die Quell-Einschränkung in der Firewall Regel zu pflegen, damit dieselbe Einschränkung nicht doppelt gepflegt werden muss.
• Original destination: Die öffentliche Zieladresse vor NAT. Besser ein Host-Objekt für die WAN-IP verwenden als direkt das WAN-Interface. Ein Host-Objekt bleibt bei Interface-Wechseln oder Anpassungen meist stabiler.
• Original service: Der Service oder Port, der von aussen erreichbar ist, zum Beispiel Synology_5555.
• Translated source (SNAT): Bei klassischen DNAT-Regeln meistens Original. Nur ändern, wenn der interne Server die Firewall als Source sehen soll. Dann verliert man aber die echte Client-IP.
• Translated destination (DNAT): Der interne Server oder eine Serverliste, auf die weitergeleitet wird.
• Translated service (PAT): Der interne Service oder Port, auf den umgeschrieben wird, zum Beispiel HTTPS. Wenn kein Portwechsel nötig ist, bleibt der Service Original.
• Inbound interface: Interface, auf dem der Traffic hereinkommt. Bei DNAT oft Any oder WAN. Für VPN-Kontexte wird häufig Any benötigt, weil VPNs nicht wie normale Interfaces behandelt werden.
• Outbound interface: Bei DNAT meistens Any, da die Firewall über Routing und Zielzone entscheidet.

Firewall Regel zur DNAT-Regel erstellen

Eine DNAT-Regel reicht nicht. Zusätzlich braucht es eine Firewall Regel, welche den Traffic erlaubt.

Bei DNAT ist wichtig: Die Firewall Regel bezieht sich auf den Traffic im DNAT-Kontext. Besonders bei Zielzone und Zielnetzwerk wirkt das am Anfang ungewohnt.

• Source zones: Meist WAN, wenn der Zugriff aus dem Internet kommt.
• Source networks and devices: Möglichst nicht Any, wenn es vermeidbar ist. Besser Länder, einzelne IPs, Netze, FQDN-Hosts oder Gruppen verwenden.
• Destination zones: Die Zone des internen Ziels, zum Beispiel SERVER oder DMZ, nicht einfach WAN.
• Destination networks: Die öffentliche Zieladresse beziehungsweise das WAN-Host-Objekt aus Original destination.
• Services: Der externe Service aus Original service, also der Port, den Clients von aussen ansprechen.
• Log firewall traffic: Für veröffentlichte Dienste aktivieren. Ohne Logging ist der Log Viewer bei dieser Regel nicht hilfreich.

Wenn globale Benutzer zugreifen müssen und Source networks and devices nicht sinnvoll eingeschränkt werden kann, sollte man die Regel trotzdem härten: nur benötigte Ports öffnen, IPS aktivieren, Logging einschalten, Zielsystem aktuell halten und nach Möglichkeit MFA, VPN oder ZTNA verwenden.

💡 Öffentlich erreichbare Dienste werden oft sehr schnell von Bots gescannt. Sophos Firewall Threat Feeds helfen, bekannte bösartige IPs, Domains oder URLs früh zu blockieren. Das ersetzt keine saubere Regel, reduziert aber unnötigen Bot-Traffic deutlich.

Loopback Rule: Intern über den öffentlichen DNS-Namen zugreifen

Eine Loopback Rule wird benötigt, wenn interne Clients einen internen Server über dessen öffentliche IP oder öffentlichen FQDN erreichen sollen.

Beispiel:

• Extern zeigt service.example.com auf die öffentliche WAN-IP.
• Intern verwenden Clients denselben Namen service.example.com.
• Ohne Loopback geht der Traffic aus dem LAN zur öffentlichen IP der Firewall und muss wieder zurück zum internen Server.

In einfachen Umgebungen ist Split DNS oft sauberer: Intern zeigt service.example.com direkt auf die interne Server-IP. Dann braucht es kein Hairpin-NAT. Wenn Split DNS nicht möglich ist, kann eine Loopback Rule sinnvoll sein.

Beim Server Access Assistant kann die Sophos Firewall Loopback-Regeln automatisch erstellen. Das funktioniert aber nur unter bestimmten Bedingungen, zum Beispiel wenn als Public IP das WAN-Interface verwendet wird und externe Quellen passend allgemein definiert sind. Bei manuellen Regeln sollte man Loopback bewusst planen und danach testen.

Reflexive Rule: Ausgehenden Traffic des Servers spiegeln

Eine Reflexive Rule ist eine automatisch erzeugte SNAT-Regel zur DNAT-Regel. Diese Regel kann sinnvoll sein, wenn der veröffentlichte Server ausgehend mit einer bestimmten öffentlichen IP erscheinen soll.

Wichtig: Für normale Antworten auf eine eingehende DNAT-Verbindung braucht es in der Regel keine separate Reflexive Rule. Stateful Firewalling sorgt dafür, dass die Antwortpakete zur bestehenden Verbindung gehören.

Reflexive Rules sollte man nur aktivieren, wenn man den Zweck versteht. In Umgebungen mit mehreren WAN-IPs, mehreren DNAT-Regeln oder mehreren Servern kann eine zusätzliche SNAT-Regel sonst zu schwer nachvollziehbarem Verhalten führen.

⚠️ Automatisch erzeugte Loopback- oder Reflexive Rules bleiben eigenständige Regeln. Wenn die ursprüngliche DNAT-Regel später geändert oder gelöscht wird, werden diese abgeleiteten Regeln nicht automatisch logisch nachgezogen. Nach jeder Änderung an der Originalregel müssen die zugehörigen Loopback- und Reflexive Rules manuell geprüft werden.

Erweiterte NAT-Funktionen

Diese Optionen braucht man nicht in jeder Umgebung. Wichtig werden sie, wenn interne Clients denselben öffentlichen Namen verwenden, mehrere Zielserver beteiligt sind oder NAT-Regeln aus Firewall Regeln heraus erzeugt werden.

Server Access Assistant oder manuelle NAT-Regel?

Der Server Access Assistant kann DNAT-, Loopback-, Reflexive- und Firewall-Regeln automatisch erstellen. Das ist praktisch, wenn man schnell einen Dienst veröffentlichen möchte.

Für produktive Umgebungen sind manuelle Regeln oft besser nachvollziehbar:

• Man sieht genau, welche Regel was macht.
• Source Restrictions werden bewusst in der Firewall Regel gepflegt.
• Die NAT-Regel bleibt schlanker.
• Rule Position und Logging werden sauber gesetzt.
• Spätere Änderungen sind weniger überraschend.

Der Assistant ist also hilfreich, ersetzt aber nicht das Verständnis der einzelnen Regeln.

Linked NAT Rules

Eine Linked NAT Rule wird aus einer Firewall Regel heraus erstellt. Es handelt sich um eine Source NAT-Regel in der NAT-Regeltabelle.

Das klingt praktisch, hat aber Grenzen:

• Die meisten Matching-Kriterien kommen aus der Firewall Regel.
• In der NAT-Regel kann man nur bestimmte NAT-Felder anpassen.
• Eine allgemeinere NAT-Regel oberhalb kann trotzdem zuerst matchen.
• Viele Linked NAT Rules machen die NAT-Tabelle schnell unübersichtlich.

Für neue, einfache Konfigurationen ist meist eine eigenständige NAT-Regel in Rules and policies > NAT rules verständlicher. Linked NAT Rules sind vor allem in Migrationsszenarien oder sehr gezielten Sonderfällen nützlich.

Load Balancing und Health Check bei DNAT

DNAT kann mehr als eine simple Portweiterleitung. Wenn mehrere interne Server als Translated destination hinterlegt sind, kann die Firewall Traffic verteilen.

Mögliche Methoden:

• Round robin: einfache Verteilung ohne Session-Persistenz.
• First alive: primärer Server mit Failover.
• Random: zufällige Verteilung.
• Sticky IP: gleiche Source-Destination-Kombination bleibt beim gleichen Server.
• One-to-one: feste Zuordnung zwischen Original- und Translated-Destination.

Wenn die Firewall erkennen soll, ob ein Zielserver verfügbar ist, muss Health check aktiviert werden. Ohne Health Check hält die Firewall Server für verfügbar, auch wenn diese nicht antworten.

Das ist bei First alive, Round robin, Random, Sticky IP oder One-to-one mehr als ein Komfortthema. Ohne Health Check kann die Firewall Traffic weiter an einen nicht erreichbaren Server senden. Für produktive DNAT-Load-Balancing-Regeln sollte deshalb ein realistischer TCP- oder ICMP-Check definiert und im Wartungsfenster getestet werden.

NAT-Reihenfolge

Sophos verarbeitet NAT-Regeln von oben nach unten. Die erste passende Regel gewinnt. Danach werden weitere NAT-Regeln nicht mehr geprüft.

Empfehlung:

• Spezifische DNAT-Regeln nach oben
• Spezifische SNAT-Regeln oberhalb allgemeiner MASQ-Regeln
• Default-SNAT-Regel bewusst positionieren
• Linked NAT Rules regelmässig prüfen
• Alte Migrationsregeln entfernen oder deaktivieren, wenn sie nicht mehr benötigt werden

Eine bewährte Reihenfolge sieht in vielen Umgebungen so aus:

1. Black-Hole-DNAT- oder Block-Regeln für bekannte unerwünschte Quellen, falls solche Regeln verwendet werden.
2. Sehr spezifische DNAT-Regeln für veröffentlichte Dienste.
3. Spezielle SNAT-Regeln für einzelne Server, Partnernetze oder VPN-Sonderfälle.
4. Loopback- oder Reflexive Rules, wenn sie bewusst benötigt werden.
5. Allgemeine SNAT- oder MASQ-Regeln für normalen Internetzugriff.

Das ist kein starres Gesetz, aber ein guter Prüfrahmen. Entscheidend ist immer der konkrete Testflow. Wenn eine breite MASQ-Regel oder eine alte Linked NAT Rule oberhalb einer spezifischen Regel steht, sieht die neue Regel korrekt aus, wird aber nie erreicht. Bei Änderungen sollte man deshalb nicht nur die Regel selbst prüfen, sondern auch die Regeln direkt darüber und darunter.

Für öffentliche Dienste kann eine Black-Hole-DNAT-Regel vor der produktiven DNAT-Regel sinnvoll sein, wenn bestimmte Bad-IP-Listen oder Länder früh abgefangen werden sollen. Der Ablauf ist in Sophos Firewall: Länder und bösartige IPs blockieren beschrieben.

NAT sicher ändern und prüfen

NAT-Änderungen verändern den Paketfluss. Deshalb sollte man sie wie eine produktive Änderung behandeln: vorbereiten, testen, protokollieren und bei Bedarf sauber zurückrollen.

NAT-Änderungen sicher ausrollen

NAT-Änderungen wirken oft sofort auf produktiven Traffic. Das ist besonders kritisch bei veröffentlichten Servern, VPN-Sonderfällen, mehreren WAN-IP-Adressen oder Firewall-Regeln, die von externen Partnern genutzt werden. Deshalb sollte man NAT nicht wie eine reine Objektänderung behandeln, sondern wie einen kleinen Change mit Test und Rückfallweg.

Vor einer produktiven Änderung sollte man kurz festhalten:

• Bisherige NAT Rule ID und Regelname: Im Log Viewer lässt sich danach prüfen, ob wirklich die neue Regel greift.
• Erwarteter Testflow: Source, Destination, Service und Richtung müssen vor dem Speichern klar sein.
• Abhängige Firewall Regel: NAT und Firewall-Regel müssen zusammenpassen, aber getrennt geprüft werden.
• Rückfallweg: Bei Problemen kann die neue Regel deaktiviert und die alte Regel wieder aktiviert werden.
• Testfenster: Externe Dienste, VPN-Gegenstellen oder Partnerzugriffe sollten nicht unbemerkt unterbrochen werden.

Wir empfehlen, bestehende NAT-Regeln bei grösseren Änderungen zuerst zu duplizieren oder eine neue spezifische Regel oberhalb zu erstellen, statt die einzige funktionierende Regel direkt umzubauen. Die alte Regel bleibt zunächst deaktiviert oder unterhalb als Referenz erhalten. Nach erfolgreichem Test kann sie entfernt oder sauber dokumentiert werden.

Wichtig ist auch die Regelposition: Eine neue spezifische SNAT- oder DNAT-Regel bringt nichts, wenn oberhalb bereits eine allgemeinere Regel denselben Traffic matcht. Deshalb gehört zur Änderung immer ein Log-Viewer-Test mit erwarteter Firewall Rule ID und NAT Rule ID.

Bei extern erreichbaren Diensten sollte der Test nicht nur aus dem eigenen LAN erfolgen. Ein interner Test auf den öffentlichen FQDN prüft häufig Loopback oder Split DNS, aber nicht den echten Zugriff aus dem Internet. Für DNAT-Abnahmen braucht es mindestens einen Test von ausserhalb, zum Beispiel über Mobilfunk, einen externen Standort oder einen kontrollierten Porttest.

NAT und Firewall Regel gemeinsam prüfen

Ein häufiger Denkfehler ist: „Die NAT-Regel ist korrekt, also müsste es funktionieren.“ Das stimmt nur zur Hälfte.

Für funktionierenden Traffic braucht es:

1. Routing bis zur Firewall
2. passende NAT-Regel, falls Übersetzung nötig ist
3. passende Firewall Regel
4. korrekten Rückweg
5. passende Security Profiles
6. kein vorgelagertes Blocking, zum Beispiel Provider-Router, Cloud Security Group oder Ziel-Firewall

Bei DNAT gilt zusätzlich: Firewall Regeln für DNAT-Traffic verwenden die Zielzone nach NAT, aber als Zielnetzwerk die öffentliche Zieladresse vor NAT. Genau dieser Punkt ist bei vielen Fehlersuchen entscheidend.

Die Reihenfolge unterscheidet sich je nach Richtung. Bei ausgehendem Traffic wird zuerst die Firewall-Regel ausgewertet und danach greift SNAT oder MASQ. Bei eingehendem veröffentlichtem Traffic wird zuerst die passende DNAT-Regel ermittelt, danach entscheidet die Firewall-Regel anhand der Zielzone nach NAT und der ursprünglichen öffentlichen Zieladresse. Wenn Rule ID und NAT Rule ID nicht zusammenpassen, sollte man deshalb immer die Richtung des Testflows mitdenken.

Firewall Rule ID und NAT Rule ID richtig lesen

Bei NAT-Fehlern sollte man nicht nur prüfen, ob irgendein Logeintrag existiert. Entscheidend ist, ob der Logeintrag zur erwarteten Firewall Regel und zur erwarteten NAT-Regel passt. Dafür sind Firewall Rule ID und NAT Rule ID hilfreicher als der Regelname allein, weil Namen geändert, ähnlich gewählt oder in Screenshots abgeschnitten sein können.

Eine kurze Interpretation hilft:

• Erwartete Firewall Rule ID und erwartete NAT Rule ID sichtbar: Das Regel-Matching passt grundsätzlich. Danach Rückweg, Zielsystem, Security Profile und Anwendung prüfen.
• Erwartete Firewall Rule ID sichtbar, aber falsche NAT Rule ID: Die Firewall Regel passt, aber NAT-Reihenfolge oder NAT-Kriterien passen nicht. NAT-Regelposition, Original-Felder und allgemeinere NAT-Regeln prüfen.
• Andere Firewall Rule ID sichtbar: Eine andere Firewall Regel gewinnt. Firewall-Regelreihenfolge, Zonen, Source, Destination und Service prüfen.
• Keine NAT Rule ID sichtbar, obwohl NAT erwartet wird: Es wurde keine NAT-Regel angewendet oder der falsche Logtyp beziehungsweise Flow wird betrachtet. NAT-Kriterien, Richtung und echten Testflow prüfen.
• Kein Logeintrag sichtbar: Logging fehlt oder Traffic erreicht die Firewall nicht. Regel-Logging, Provider-Router, VLAN, Gateway und Packet Capture prüfen.

Gerade bei DNAT ist ein einzelner erfolgreicher oder fehlgeschlagener Test ohne ID-Vergleich zu wenig. Man sollte notieren, welche IDs erwartet werden, den Test genau einmal ausführen und danach Log Viewer und Packet Capture vergleichen. Wenn die IDs nicht zur Erwartung passen, wird zuerst Matching und Reihenfolge korrigiert, nicht der Zielserver.

Häufige NAT-Fehlbilder

Bei NAT-Problemen ist es hilfreich, nicht sofort Regeln umzubauen. Zuerst sollte man das beobachtete Fehlbild einordnen.

• Keine Logeinträge im Log Viewer: Traffic erreicht die Firewall nicht, Logging fehlt oder der Filter ist falsch. Provider-Router, Cloud Security Group, Client-Gateway, Firewall-Regel-Logging und Filter prüfen.
• Logeintrag ohne erwartete NAT Rule ID: Die NAT-Regel matcht nicht oder eine Regel darüber gewinnt. Original source, Original destination, Service und NAT-Reihenfolge prüfen.
• DNAT-Regel matcht, Verbindung klappt trotzdem nicht: Firewall Regel, Zielserver, Rückroute oder lokale Server-Firewall blockiert. Firewall Rule ID, Packet Capture und Server-Logs vergleichen.
• Zugriff intern auf öffentlichen FQDN funktioniert nicht: Split DNS oder Loopback NAT fehlt. Interne DNS-Auflösung prüfen und entscheiden, ob Split DNS oder Loopback sauberer ist.
• Externer Client sieht falsche Source-IP: SNAT oder Reflexive Rule ändert die Quelle unerwartet. Translated source (SNAT) und automatisch erzeugte Regeln prüfen.
• VPN-Traffic nutzt unerwartete Source-IP: SNAT, XFRM, SD-WAN Route oder IPsec Route passen nicht zusammen. Route Lookup, SD-WAN Route, IPsec Route und NAT-Regelposition prüfen.
• Öffentlicher Port zeigt auf falschen internen Dienst: PAT oder Service-Objekt ist falsch gesetzt. Original service und Translated service (PAT) vergleichen.

Diese Übersicht ersetzt keine Paketflussanalyse, spart aber Zeit: Man trennt damit Probleme vor der Firewall, in der NAT-Logik, in der Firewall-Regel und auf dem Zielsystem.

Abnahmetest nach NAT-Änderungen

Nach einer NAT-Änderung sollte man nicht nur prüfen, ob ein einzelner Ping oder eine Webseite einmal funktioniert. Der Test muss zur Art der Übersetzung passen.

Für SNAT oder MASQ:

1. Testclient und Zielservice festlegen.
2. Firewall Regel mit Log firewall traffic prüfen.
3. Im Log Viewer kontrollieren, welche Firewall Rule ID und NAT Rule ID greift.
4. Auf dem Zielsystem oder externen Testdienst prüfen, welche Source-IP sichtbar ist.
5. Rückweg und Session-Verhalten bei mehreren WAN-Links testen.

Für DNAT oder PAT:

1. Test von ausserhalb des eigenen Netzes durchführen, nicht nur aus dem LAN.
2. Öffentliche Ziel-IP, externen Port und internen Zielserver vergleichen.
3. Im Log Viewer Firewall Rule ID und NAT Rule ID prüfen.
4. Mit Packet Capture kontrollieren, ob Pakete ankommen und zum internen Server weitergehen.
5. Auf dem Zielserver prüfen, ob lokale Firewall, Dienst und Rückroute passen.

Für VPN-NAT:

1. Tunnelstatus und Security Associations prüfen.
2. Einen konkreten Testflow mit Source, Destination und Service definieren.
3. NAT-Regelposition und Route Lookup kontrollieren.
4. Packet Capture auf beiden Seiten verwenden, wenn die Gegenstelle Zugriff erlaubt.
5. Logs der Anwendung oder des Zielsystems einbeziehen, damit nicht nur die Firewall-Seite bewertet wird.

Gerade bei Remote-Standorten sollte pro Änderung nur ein Testfall verändert werden. Wenn Firewall-Regel, NAT, Route, SD-WAN und Zielsystem gleichzeitig angepasst werden, ist ein erfolgreicher Test später kaum noch erklärbar.

Troubleshooting

Bei NAT-Problemen hilft diese Reihenfolge:

1. Log viewer öffnen und nach Source IP, Destination IP und Service filtern.
2. Kontrollieren, welche Firewall Rule ID und NAT Rule ID angezeigt wird.
3. NAT-Regelposition prüfen.
4. Firewall Regelposition prüfen.
5. Mit Diagnostics > Packet capture prüfen, ob Pakete ankommen und weitergehen.
6. Bei tieferer Analyse nat_rule.log, firewall_rule.log und fwlog.log prüfen.
7. Bei VPN- oder XFRM-Kontext zusätzlich charon.log, strongswan.log und xfrmi.log prüfen.

Wenn die NAT-Regel trotzdem nicht greift, helfen Firewall-Regel greift nicht: Reihenfolge, Matching und Logs prüfen und Packet Capture Tool im WebAdmin verwenden bei der Eingrenzung. Welche Service-Namen und Logdateien relevant sind, steht in Sophos Firewall Troubleshooting: Services und Logs. Für Supportfälle kann man die Logs mit Sophos Firewall Logs für Support und Analyse sichern exportieren.

Checkliste für NAT-Regeln

• NAT-Regel hat einen eindeutigen Namen und eine Beschreibung.
• Zweck, verantwortliche Person und letzter Review sind dokumentiert.
• Original- und Translated-Felder wurden gegen einen echten Testflow geprüft.
• NAT-Regel steht oberhalb allgemeinerer NAT-Regeln.
• Passende Firewall Regel ist vorhanden und Logging ist aktiv.
• Erwartete Firewall Rule ID und NAT Rule ID wurden im Log Viewer geprüft.
• Bei DNAT ist die Zielzone nach NAT und das Zielnetzwerk vor NAT korrekt gesetzt.
• DNAT wurde von extern getestet, nicht nur aus dem internen LAN.
• Bei öffentlichen Diensten wurden Source Restrictions, IPS, WAF-Alternative und Patchstand geprüft.
• Bei VPN-NAT sind Routing, IPsec Route, SD-WAN und überlappende Netze dokumentiert.
• Loopback oder Split DNS ist bewusst entschieden.
• Reflexive Rules sind nur aktiv, wenn der ausgehende Servertraffic wirklich gespiegelt werden soll.
• Alte oder temporäre NAT-Regeln sind deaktiviert oder entfernt.

FAQ