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

NAT ändert Adressen oder Ports eines Pakets. Es entscheidet aber nicht, ob die Verbindung erlaubt ist, und erzeugt keine Route. Für einen funktionierenden Datenfluss müssen NAT-Regel, Firewall-Regel, Routing und Rückweg zusammenpassen.

Der schnellste Einstieg ist deshalb nicht die Frage «Welche NAT-Art brauche ich?», sondern: Welche Adresse oder welcher Port soll sich zwischen Eingang und Ausgang verändern? Wenn darauf keine klare Antwort folgt, liegt die Lösung meist bei Routing oder der Firewall-Regel und nicht bei NAT.

⚠️ Eine NAT-Regel ist keine Freigabe. Erlaubt die Firewall-Regel den Traffic und passt keine NAT-Regel, leitet SFOS das Paket unübersetzt weiter. Fehlt die passende Firewall-Regel, wird es verworfen und protokolliert.

Für welche Aufgabe ist NAT richtig?

• LAN-Clients sollen ins Internet: meist SNAT mit MASQ.
• Ein interner Dienst soll über eine öffentliche Adresse erreichbar sein: DNAT; bei HTTP/HTTPS zuerst WAF prüfen.
• Externer und interner Port unterscheiden sich: Serviceübersetzung über Translated service (PAT).
• Interne Clients verwenden den öffentlichen Namen eines internen Servers: Split DNS bevorzugen oder gezielt eine Loopback Rule einsetzen.
• Eindeutige Netze kommunizieren über ein Site-to-Site-VPN: normalerweise Routing und Firewall-Regeln ohne NAT.
• Netze überschneiden sich: NAT abhängig vom VPN-Typ planen; nicht mit einer allgemeinen MASQ-Regel improvisieren.
• Nur Zugriff erlauben oder sperren: Firewall-Regel ändern, keine NAT-Regel bauen.

Für die konkrete Veröffentlichung eines Servers führt Server per DNAT auf Sophos Firewall veröffentlichen durch Assistent, manuelle Regel, Härtung, Go-live und Rückbau. Dieser Artikel erklärt das NAT-Modell, damit man solche Regeln lesen und Fehler eingrenzen kann.

Weitere enge Sonderfälle sind NAT64 mit Direct Web Proxy, Proxy ARP für zusätzliche öffentliche IPv4-Adressen und NAT bei IPsec-Problemen.

Original und Translated richtig lesen

Unter Rules and policies > NAT rules > Add NAT rule beschreibt Original das Paket, wie es an der Firewall ankommt. Translated beschreibt die Änderung, die SFOS darauf anwendet.

Die Regel wird anhand dieser Felder ausgewählt:

• Original source
• Original destination
• Original service
• Inbound interface
• Outbound interface

Die Felder Translated source (SNAT), Translated destination (DNAT) und Translated service (PAT) sind das Ergebnis, keine weiteren Match-Kriterien. NAT-Regeln werden von oben nach unten ausgewertet; die erste passende Regel gewinnt.

Zwei Paketbeispiele

Ein Client 10.10.10.80 verbindet sich über Port2 zu 198.51.100.20:443. Eine SNAT-Regel kann nur die Source auf MASQ ändern. Destination und Service bleiben Original.

Bei einer Veröffentlichung verbindet sich ein externer Client zu 203.0.113.10:5555. DNAT ändert die Destination auf 172.16.16.10; PAT ändert den Service auf 443. Das Regelbild lautet dann:

• Original destination: 203.0.113.10
• Original service: TCP 5555
• Translated destination (DNAT): 172.16.16.10
• Translated service (PAT): TCP 443

PAT ist damit kein eigener Adress-NAT-Typ neben SNAT und DNAT, sondern die Port- oder Serviceübersetzung innerhalb einer NAT-Regel.

SNAT und MASQ für ausgehenden Traffic

SNAT ändert die Quelladresse. Eine typische LAN-zu-WAN-Regel verwendet das interne Netz als Original source, das WAN-Interface als Outbound interface und MASQ als Translated source. Ziel und Service bleiben Original oder werden auf den tatsächlich benötigten Umfang begrenzt.

MASQ verwendet standardmässig die Adresse des ausgehenden Interfaces. In der Werkskonfiguration existiert dafür Default SNAT IPv4. Wird sie nicht benötigt, empfiehlt Sophos, sie zu deaktivieren statt zu löschen: Beim Erstellen oder Aktualisieren eines WAN-Interfaces kann sie erneut angelegt werden.

Nach einer Migration von SFOS 17.5 oder älter kann zusätzlich am Tabellenende eine deaktivierte Default-SNAT-Regel erscheinen. Sie ist für den Ersatz bereinigter Linked-MASQ-Regeln gedacht und darf nicht mit einer aktiv genutzten Werksregel verwechselt werden.

Wichtige Grenzen von SNAT

• Ein Bereich unter Translated source bildet keine feste Eins-zu-eins-Zuordnung. SFOS verwendet die jeweils nächste freie Adresse aus dem Bereich.
• Ein öffentliches Interface, das Mitglied einer Bridge ist, kann nicht als Source-NAT-Interface dienen. Wird ein verwendetes Interface nachträglich Bridge-Member, löscht SFOS die betroffenen SNAT-Regeln.
• Override source translation for specific outbound interfaces erlaubt in einer SNAT-Regel unterschiedliche übersetzte Quellen pro Ausgangsinterface. Über Expand kommen weitere Zuordnungen hinzu.
• Bei route-based VPNs mit Any als lokalen und entfernten Subnetzen oder mit Dual-IP-Konfiguration kann MASQ die XFRM-Adresse als innere Source verwenden. Im äusseren Tunnel-Header bleibt die WAN-Adresse sichtbar.

Vor einer Bridge-Umstellung oder einer Änderung an produktiven SNAT-Pools müssen die betroffenen Regeln deshalb dokumentiert und danach mit einem echten neuen Datenfluss geprüft werden.

DNAT, PAT, Loopback und Reflexive Rules

DNAT ändert die Zieladresse. PAT ändert zusätzlich den angesprochenen Service oder Port. Das Protokoll muss dabei gleich bleiben: TCP lässt sich auf einen anderen TCP-Port und UDP auf einen anderen UDP-Port übersetzen, nicht TCP auf UDP.

Werden mehrere Original-Services oder Any ausgewählt, bleibt Translated service (PAT) normalerweise auf Original. Eine eindeutige Portweiterleitung verwendet einen konkreten Original-Service und einen konkreten übersetzten Service.

Die passende Firewall-Regel zu DNAT

Bei eingehendem Traffic bestimmt SFOS zuerst die passende DNAT-Regel. Danach wird die Firewall-Regel ausgewertet. Dabei gilt die ungewohnte, aber wichtige Zuordnung:

• Destination zone: Zone des internen Ziels nach DNAT, etwa DMZ.
• Destination networks: öffentliche Zieladresse vor DNAT.
• Services: ohne PAT der angesprochene Service. Bei PAT nimmt das offizielle Sophos-Beispiel sowohl den Original-Service als auch den übersetzten Service in die Firewall-Regel auf.

In der Gegenrichtung wird zuerst die Firewall-Regel ausgewertet; danach wendet SFOS die passende SNAT-Regel an.

Eine NAT-Regel ersetzt diese Firewall-Regel nicht. Für einen vollständigen DNAT-Aufbau einschliesslich Source-Einschränkung, IPS, Logging und externem Abnahmetest dient das DNAT-Runbook.

Loopback Rule

Eine Loopback Rule kann internen Clients den Zugriff über die öffentliche IP oder den öffentlichen FQDN ermöglichen. Split DNS ist häufig transparenter: Intern löst derselbe Name direkt auf die interne Serveradresse auf, sodass kein Hairpin-NAT nötig ist.

Der Server Access Assistant erstellt eine Loopback Rule nur, wenn als öffentliche Adresse ein Firewall-WAN-Interface ausgewählt ist und External source networks and devices auf Any steht. Eine eingegebene öffentliche IP oder engere externe Quelle erzeugt diese automatische Loopback-Regel nicht.

Reflexive Rule

Eine Reflexive Rule erzeugt eine umgekehrte SNAT-Regel zu einer DNAT-Regel. Sie kehrt deren Match-Kriterien um und kann ausgehenden Servertraffic mit der passenden öffentlichen Identität übersetzen. Ist die ursprüngliche Destination keine IP-Adresse oder wird sie übersetzt, verwendet die Reflexive Rule MASQ als translated source.

Loopback- und Reflexive Rules bleiben eigenständige Regeln. Änderungen oder das Löschen der ursprünglichen DNAT-Regel aktualisieren beziehungsweise entfernen sie nicht automatisch. Nach einer Änderung an öffentlicher Adresse, internem Ziel oder Service müssen die abgeleiteten Regeln separat geprüft werden.

Verteilt eine DNAT-Regel auf mehrere interne Ziele, gelten diese ohne Health check als verfügbar. Für First alive ist der Health Check erzwungen; bei den anderen Verteilungsmethoden muss er bewusst aktiviert und mit ICMP oder TCP passend zum Dienst konfiguriert werden, damit SFOS keinen neuen Traffic an einen ausgefallenen Server sendet.

Linked NAT Rules und Server Access Assistant

Eine Linked NAT Rule ist immer eine SNAT-Regel, die mit einer Firewall-Regel verknüpft ist. Alle Match-Kriterien der Firewall-Regel gelten weiter, einschliesslich Benutzer und Zeitplan. In der NAT-Regel lassen sich nur translated sources und interface-spezifische translated sources ändern.

Die Verknüpfung schützt nicht vor der normalen NAT-Reihenfolge: Eine höher platzierte eigenständige NAT-Regel kann zuerst passen. Wenn eine generische SNAT-Regel denselben Traffic bereits abdeckt, empfiehlt Sophos keine zusätzliche Linked NAT Rule. Im MTA-Modus erstellt SFOS hingegen automatisch eine solche Regel.

Der Server access assistant (DNAT) erzeugt eine DNAT-, eine Reflexive und eine Firewall-Regel. Eine Loopback Rule kommt nur bei der zuvor beschriebenen Kombination aus WAN-Interface und externer Quelle Any hinzu. Der Assistent setzt die Regeln oben in die Tabellen und aktiviert sie. Danach müssen Quellen, Regelposition, erzeugte Zusatzregeln und Alias-IP-Verwendung kontrolliert werden. Bei einer Alias-IP setzt der Assistent in Reflexive beziehungsweise Loopback Rules zunächst das physische Interface als translated source; falls die Alias-Adresse erscheinen soll, muss ein entsprechender IP Host manuell gewählt werden.

NAT, VPN und SD-WAN auseinanderhalten

NAT ändert keine Routingentscheidung. Auch nach der Übersetzung braucht SFOS eine Route zum Ziel. Bei VPN-Traffic hängt ausserdem der richtige Konfigurationsort vom Tunneltyp ab:

• Policy-based IPsec: Für die Übersetzung der lokalen und entfernten Subnetze, insbesondere bei Überlappungen, die NAT-Einstellungen der IPsec-Verbindung verwenden. Soll eine zusätzliche SNAT-Regel policy-based Traffic erfassen, muss ihr Outbound interface auf Any stehen; mit konkreten WAN-Interfaces greift sie nicht.
• Route-based IPsec mit ausgewählten lokalen und entfernten Subnetzen: Für die Übersetzung dieser Subnetze die NAT-Einstellungen der IPsec-Verbindung verwenden.
• Route-based IPsec mit Any/Any: NAT-Regeln für den weitergeleiteten Traffic verwenden.

Eindeutige Netze brauchen in der Regel kein NAT. Bei überlappenden Netzen müssen echte und übersetzte Netze auf beiden Seiten dokumentiert sein; sonst werden DNS, Regeln und Logs später mehrdeutig.

Für DNAT zu einem Server hinter einem route-based IPsec-Tunnel dokumentiert Sophos einen besonderen SD-WAN-Aufbau: Die DNAT-Regel verwendet MASQ als Translated source, damit Antworten zur Firewall zurücklaufen. Die SD-WAN-Route matcht als Ziel die ursprüngliche WAN-Adresse beziehungsweise das WAN-Interface und bei PAT den externen Port. Das Gatewayobjekt verweist auf das XFRM-Interface. Dieser Sonderfall darf nicht als allgemeines DNAT-Muster auf lokale Server übertragen werden.

Firewall-eigenen Traffic mit sys-traffic-nat übersetzen

NAT-Regeln im WebAdmin übersetzen weitergeleiteten Traffic. Für von der Firewall erzeugten Traffic und für die Übersetzung von Firewall-Interface-Adressen dient die Device Console mit sys-traffic-nat.

Das folgende Muster übersetzt Traffic zum einzelnen Ziel 192.0.2.10, der über Port1 läuft, auf die Alias-Adresse 203.0.113.10:

show advanced-firewall
set advanced-firewall sys-traffic-nat add destination 192.0.2.10 netmask 255.255.255.255 interface Port1 snatip 203.0.113.10
show advanced-firewall

Ziel, Netzmaske, Interface und SNAT-Adresse müssen zur eigenen Umgebung passen. Für einen Host ist 255.255.255.255 erforderlich; eine breitere Maske erfasst das ganze passende Zielnetz. Ohne interface gilt der Eintrag für Traffic über jedes Firewall-Interface zum angegebenen Ziel.

⚠️ Dieser Device-Console-Befehl verändert systemgenerierten Traffic. Vorher die vollständige Ausgabe von show advanced-firewall sichern. CLI-NAT-Einträge werden in der dort angezeigten Reihenfolge verarbeitet.

Für den Rückbau wird dieselbe vollständige Zuordnung mit delete verwendet:

set advanced-firewall sys-traffic-nat delete destination 192.0.2.10 netmask 255.255.255.255 interface Port1 snatip 203.0.113.10
show advanced-firewall

Systemgenerierter Traffic verwendet standardmässig WAN Link Load Balancing. Bei einer Alias-IP bleibt für die Routingentscheidung das Hauptinterface massgeblich; sys-traffic-nat sorgt nur dafür, dass die gewünschte Alias-Adresse als Source erscheint. Ein sichtbarer Eintrag bestätigt daher die Konfiguration, nicht Route, Rückweg oder Dienst.

NAT-Regeln sicher ändern und testen

SFOS wertet NAT nur für das erste Paket einer Verbindung aus. Bestehende Sessions behalten ihre bisherige Übersetzung, wenn eine Regel geändert oder verschoben wird. Ein Test nach dem Change muss deshalb eine neue Verbindung erzeugen; andernfalls beurteilt man möglicherweise den alten Zustand.

Ein belastbarer Test beginnt mit einem notierten Flow: Source, Destination, Service, Eingangs- und Ausgangsinterface sowie erwartete Firewall Rule ID und NAT Rule ID. Danach:

1. Neue Verbindung erzeugen und im Log Viewer nach Source, Destination und Service filtern.
2. Erwartete Firewall Rule ID und NAT Rule ID vergleichen.
3. Bei einer falschen NAT Rule ID die Regeln oberhalb sowie alle Original-Felder und Interfaces prüfen.
4. Unter Diagnostics > Packet capture kontrollieren, ob das Paket ankommt und mit den erwarteten Adressen weitergeht.
5. Route, Rückweg, Zielsystem und dessen lokale Firewall prüfen.

Für DNAT muss mindestens ein Test von ausserhalb erfolgen. Ein interner Zugriff auf den öffentlichen Namen prüft nur Split DNS oder Loopback, nicht die echte Veröffentlichung aus dem Internet.

Befunde richtig einordnen

• Firewall Rule ID und NAT Rule ID stimmen: Matching passt; danach Zielsystem, Rückweg und Security Profiles untersuchen.
• Firewall Rule ID stimmt, NAT Rule ID ist falsch: Eine andere NAT-Regel gewinnt oder die Original-Kriterien passen nicht.
• Keine NAT Rule ID, obwohl Übersetzung erwartet wird: Keine NAT-Regel passt; erlaubt die Firewall-Regel den Flow, läuft er unübersetzt weiter.
• Andere Firewall Rule ID: Zonen, Netzwerke, Service und Firewall-Regelreihenfolge prüfen.
• Kein Logeintrag: Logging fehlt oder der Traffic erreicht die Firewall nicht. Dann auf WAN beziehungsweise Eingangsinterface capturen und vorgelagerte Router oder Cloud-Regeln prüfen.
• DNAT trifft, Server antwortet nicht: Serverdienst, lokale Firewall, Default Gateway und asymmetrischen Rückweg prüfen.

Für eine tiefere Analyse helfen Firewall-Regel testen, Regel-Matching untersuchen, verworfene Pakete einordnen und Packet Capture im WebAdmin.

FAQ