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.

NAT-Regeln sind für IPv4 und IPv6 verfügbar. Vor dem Anlegen unter Rules and policies > NAT rules die passende Adressfamilie wählen; die folgenden IPv4-Beispielwerte gehören nicht in eine IPv6-Regel. Add NAT rule > New NAT rule öffnet die manuelle Konfiguration. Neue Regeln sind standardmässig eingeschaltet. Rule position bietet Top und Bottom; später lässt sich die Reihenfolge per Drag-and-drop ändern. Vor Save deshalb Kriterien und Position prüfen, damit eine neue Regel nicht unbeabsichtigt produktiven Traffic übernimmt.

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.

Mehrere interne Clients oder Server können dieselbe öffentliche Quell-IP verwenden: SFOS unterscheidet ihre Verbindungen über unterschiedliche Portnummern. Diese Source-Port-Zuordnung ist nicht dasselbe wie eine DNAT-Serviceweiterleitung zum Server.

Eigenständige LAN-zu-WAN-SNAT-Regel anlegen

Eine unabhängige SNAT-Regel kann mehrere Firewall-Regeln bedienen. Vorher vorhandene NAT-Regeln, Route, Ausgangsinterface und Rückweg prüfen und den bisherigen Zustand samt IDs und Positionen sichern. Das Beispiel erlaubt nur HTTPS vom Clientnetz zu einem bestimmten Testziel; alle Adressen und Interfaces sind durch eigene Werte zu ersetzen.

1. Rules and policies > NAT rules öffnen, IPv4 wählen und Add NAT rule > New NAT rule auswählen. Rule name etwa LAN-Web-Standalone-MASQ setzen. Unter Rule position Top oder Bottom wählen und die Regel anschliessend gezielt über allgemeinere passende Regeln ziehen; nicht blind an die Spitze stellen.
2. Original source auf Clients_LAN (10.10.10.0/24), Original destination auf ein Hostobjekt für 198.51.100.20 und Original service auf HTTPS setzen. Das Dokumentationsziel ist kein realer Testserver. Für allgemeine Internetziele kann die Destination bewusst breiter sein; die benötigten Dienste bleiben begrenzt.
3. Translated source (SNAT) auf MASQ, Translated destination (DNAT) und Translated service (PAT) jeweils auf Original setzen. Inbound interface auf das tatsächliche LAN-Interface, im Beispiel Port2, und Outbound interface auf das tatsächliche WAN-Interface, im Beispiel Port1, setzen. Save wählen und die NAT Rule ID notieren.
4. Unter Rules and policies > Firewall rules IPv4 > Add firewall rule > New firewall rule wählen, sofern noch keine passende Freigabe existiert. Name und Position festlegen, Action Accept, Source zones LAN, Source networks and devices Clients_LAN, Destination zones WAN, Destination networks dasselbe Ziel und Services HTTPS setzen. Passende Security-Einstellungen und Log firewall traffic konfigurieren, dann Save. Keine zusätzliche Linked NAT Rule erstellen.
5. Eine neue HTTPS-Verbindung zum eigenen Testziel erzeugen und regulär beenden. Im Log Viewer beide Rule IDs vergleichen; im Packet capture muss am Ausgang die erwartete WAN-Quelladresse sichtbar sein. Bei einem falschen NAT-Match zuerst höher platzierte Regeln prüfen, bei fehlender Antwort Routing und Rückweg. Für den Rückbau nur die neu hinzugefügten Regeln deaktivieren und geänderte Positionen wiederherstellen; keine gemeinsam genutzte Freigabe entfernen. Danach mit einer neuen Session den vorherigen Zustand prüfen.

LAN-zu-WAN-Regel mit Linked NAT anlegen

Für eine gezielte IPv4-Freigabe lässt sich SNAT direkt beim Anlegen der Firewall-Regel verknüpfen. Vorher prüfen, ob eine vorhandene SNAT-Regel den Flow bereits wie gewünscht übersetzt; dann ist keine zusätzliche Linked NAT Rule nötig. Route und Rückweg müssen unabhängig davon passen.

1. Rules and policies > Firewall rules öffnen, IPv4 wählen und über Add firewall rule > New firewall rule eine Regel anlegen. Einen eindeutigen Namen, etwa LAN-Web-Out, und die passende Position wählen; Action auf Accept setzen und Log firewall traffic aktivieren.
2. Source zones auf LAN und Source networks and devices auf das tatsächlich freizugebende Clientnetz begrenzen. Als Beispiel dient ein Netzwerkobjekt Clients_LAN für 10.10.10.0/24; Name und Subnetz sind an die eigene Umgebung anzupassen. Destination zones auf WAN setzen. Unter Destination networks die benötigten Ziele und unter Services nur die benötigten Dienste wählen, etwa HTTPS für diesen Web-Flow. Any ist keine pauschale Vorgabe. DNS und weitere benötigte Dienste müssen separat berücksichtigt werden.
3. Create linked NAT rule auswählen. Der NAT-Regel einen eigenen Namen, etwa LAN-Web-MASQ, und eine passende Position geben. Translated source (SNAT) auf MASQ setzen: Für diesen Flow soll die Adresse des tatsächlichen Ausgangsinterfaces erscheinen; Quelle, Ziele und Dienste bleiben durch die Firewall-Regel begrenzt.
4. Zuerst Save innerhalb der Linked-NAT-Konfiguration wählen, danach nochmals Save für die Firewall-Regel. Nur den verschachtelten NAT-Dialog zu speichern, schliesst den Ablauf nicht ab.
5. Unter Firewall rules die Firewall-Regel und unter NAT rules die verknüpfte SNAT-Regel kontrollieren; beide Einträge und ihre Rule IDs notieren. Die Reihenfolge in beiden Tabellen separat prüfen. Eine passende NAT-Regel oberhalb kann die Linked NAT Rule überholen; die Verknüpfung garantiert keine Priorität.
6. Vom freigegebenen Client eine wirklich neue Verbindung zum erlaubten Ziel und Dienst aufbauen und die Testverbindung anschliessend regulär beenden, damit ein Session-Log entstehen kann. Im Log Viewer nach diesem Flow filtern und Firewall Rule ID sowie NAT Rule ID mit den notierten IDs vergleichen. Bei einer falschen Firewall-ID zuerst Firewall-Kriterien und -Reihenfolge prüfen, bei einer falschen NAT-ID zuerst höher platzierte NAT-Regeln. Die blosse Präsenz beider Einträge bestätigt noch keinen funktionierenden Internetzugang.

Wichtige Grenzen von SNAT

Als Translated source (SNAT) sind neben MASQ eine einzelne IP oder ein IP-Bereich möglich. Die SFOS-22-Beschreibung nennt ausdrücklich jede einem Interface zugewiesene IP als Quellwahl und Add zum Anlegen eines IP-/Bereichsobjekts. In der SFOS-23-Beschreibung der NAT-Arten bleiben einzelne IPs und Bereiche ausdrücklich vorhanden; fehlende Sätze in der dortigen Add-Beschreibung bedeuten keine entfernte Unterstützung. Die feste Adresse muss in der eigenen Umgebung erreichbar sein und zum erwarteten Rückweg passen.

• 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, muss Translated service (PAT) auf Original stehen. Eine eindeutige Portweiterleitung verwendet einen konkreten Original-Service und einen konkreten übersetzten Service. Die Translated destination (DNAT) kann eine IP-Adresse oder ein FQDN sein. Bei Serviceübersetzung sind ein einzelner Zielport oder gleich viele übersetzte wie ursprüngliche Ports möglich: etwa viele Ports eines Original-Service auf einen Port (many-to-one), oder gleich grosse Portmengen (many-to-many). Für many-to-many muss die Portanzahl gleich sein; mehrere separat ausgewählte Original-Services erlauben dagegen keine PAT-Übersetzung. Das Protokoll bleibt immer gleich.

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.

In einer manuellen DNAT-Konfiguration ist Create loopback rule eine eigene Option. Dafür muss die zugrunde liegende DNAT-Regel Original source Any, Translated source (SNAT) MASQ und eine Translated destination (DNAT) ungleich Original verwenden. Das sind nicht die Assistentenfelder. Eine externe Source-Einschränkung nicht bloss für Loopback aufheben: zuerst Split DNS oder eine getrennt geplante interne Regel prüfen. Nach dem Speichern den internen Zugriff und die externe Einschränkung getrennt testen.

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.

Bei manueller DNAT-Erstellung erzeugt Create reflexive rule diese Spiegelregel; Create loopback rule ist davon unabhängig. Die erzeugten Regeln verwenden ID und Namen der Ausgangsregel, bleiben aber eigenständig. Beim Rückbau daher alle erzeugten Einträge separat identifizieren, deaktivieren und mit neuen internen sowie externen Verbindungen prüfen.

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.

Mehrere DNAT-Ziele gezielt verteilen

Unter Load balancing method entscheidet man nach dem gewünschten Verhalten, nicht nur nach der Anzahl Server:

• Round robin: Verbindungen gehen der Reihe nach an die Ziele. Bei 10.10.10.1 bis 10.10.10.3 beginnt die vierte Anfrage wieder bei .1. Das passt zur gleichmässigen Verteilung ohne Sitzungsbindung.
• First alive: Alle Anfragen gehen an den ersten verfügbaren Server; weitere Ziele dienen als Reserve. Der Health Check entscheidet über den Wechsel.
• Random: Die Auswahl erfolgt zufällig, ohne feste Zuordnung eines Clients.
• Sticky IP: Ein Hash aus Source und ursprünglicher Destination bindet dieses Paar an einen Server. Bei aktiviertem Health Check übernimmt bei Ausfall ein verfügbares Ziel. Nach Rückkehr des ursprünglichen Servers wechseln nur neue Verbindungen zurück; bestehende Sessions bleiben bestehen.
• One-to-one: Erstes Original-Ziel auf erstes übersetztes Ziel, zweites auf zweites und so weiter. Beide Listen müssen gleich viele IP-Adressen enthalten. Das ist eine feste DNAT-Zuordnung, nicht die Vergabe aus einem SNAT-Pool.

Für Health check den Probe method ICMP oder TCP und bei TCP den tatsächlich zu prüfenden Port wählen. Probe interval legt den Abstand der Prüfungen fest, Response time-out die Antwortfrist und Deactivate host after die Zahl erfolgloser Versuche. Ein Ping bestätigt nur die Host-Erreichbarkeit, nicht einen funktionierenden Webdienst. Intervall und Timeout an den Dienst anpassen; zu empfindliche Werte können ein langsames Ziel unnötig aus der Verteilung nehmen. Vor Produktivbetrieb mit neuen Verbindungen das gewünschte Verteilungsverhalten prüfen und einen geplanten Ausfall samt Rückkehr kontrollieren. Vorherige Methode und Prüfwerte für den Rückweg sichern.

Portkonflikte vor der Veröffentlichung prüfen

Vor einer HTTPS-Weiterleitung unter Administration > Admin and user settings die tatsächlich konfigurierten Ports von WebAdmin, User Portal und VPN Portal erfassen. Nicht aus einer älteren NAT-Anleitung ableiten, welcher Dienst 443 belegt. WebAdmin und User Portal benötigen jeweils einen eigenen Port. Konflikte zuerst mit einer anderen veröffentlichten IP oder einem anderen externen Dienstport lösen; Managementports nicht unvorbereitet ändern. Falls eine Änderung nötig ist, einen unabhängigen Managementzugang sichern und danach Portal, VPN-Clients und externen DNAT-Zugriff getrennt testen. Die DNAT-Anleitung führt durch die Veröffentlichung.

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.

Migrierte Linked-MASQ-Regeln vorsichtig bereinigen

Nach einer Migration kann unter dem Regelfilter ein Bereinigungshinweis erscheinen. Delete linked NAT rules (only MASQ; Destination: WAN) entfernt nur Linked-Regeln mit übersetzter Quelle MASQ, deren Firewall-Regel ausschliesslich die Destination-Zone WAN verwendet. Das ist trotzdem keine risikofreie Aufräumaktion: Benutzer- und Zeitplanbedingungen sowie die bisherige Reihenfolge können Teil des gewollten Verhaltens sein.

Vorher Konfiguration, IDs und betroffene Flows sichern. Die deaktivierte Default SNAT IPv4 beziehungsweise Default SNAT IPv6 oder eine bewusst geplante eigenständige SNAT-Regel muss als Ersatz an der richtigen Position den benötigten Traffic abdecken. Ersatz und Firewall-Begrenzungen prüfen, aktivieren und mit neuen erlaubten sowie unerlaubten Testflows vergleichen, bevor alte Regeln entfernt werden. Bei Abweichungen den gesicherten Regelbestand und seine Reihenfolge wiederherstellen. Understood. Don’t delete rules lässt die Regeln bestehen und unterdrückt den Hinweis dauerhaft; das X blendet ihn nur vorübergehend aus. Im Zweifel erst dokumentieren, nicht löschen.

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.

Für VPN-Traffic in NAT-Regeln Inbound interface auf Any setzen. Für VPNs sowie DNAT von öffentlichen auf private IP-Adressen muss Outbound interface ebenfalls Any sein. Das ist eine Interface-Match-Vorgabe, keine Erlaubnis für beliebige Quellen oder Dienste; diese bleiben über Original-Kriterien und Firewall-Regeln begrenzt.

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.

Remote-Server über DNAT und eine SD-WAN-Route erreichen

Dieser IPv4-Ablauf gilt nur für einen Server hinter der entfernten Firewall. Vorher route-based IPsec-Verbindungen auf beiden Firewalls, Tunnelzustand, Remote-Erreichbarkeit, erlaubte Quellen, Dienst, Rückweg und vorhandene NAT-/SD-WAN-Reihenfolge prüfen. Konfiguration und betroffene Positionen sichern. Das Beispiel verwendet extern TCP 5555 und intern TCP 443, nicht öffentliches RDP; die Dokumentationsadressen sind durch eigene Werte zu ersetzen. Die separate Firewall-Freigabe und das Hardening bleiben erforderlich.

1. Unter Hosts and services > IP host > Add ein Objekt Remote_Web erstellen: IP version IPv4, Type IP, IP address die Remote-Serveradresse, beispielsweise 172.16.16.10; Save.
2. Unter Routing > Gateways, IPv4 gateway > Add, einen eindeutigen Namen wählen. Gateway IP auf die entfernte Gatewayadresse, beispielsweise 10.12.13.2, und Interface auf das zugehörige XFRM-Interface, beispielsweise xfrm1-10.12.13.1, setzen. Unter Monitoring condition die IP-Adresse eines tatsächlich erreichbaren Hosts hinter dem Gateway eingeben; Gateway-/Tunnelstatus vor der Veröffentlichung prüfen.
3. Unter Rules and policies > NAT rules > Add NAT rule > New NAT rule eine benannte IPv4-Regel erstellen. Original source auf autorisierte externe Quellen begrenzen, Original destination auf das veröffentlichte WAN-Interface, etwa #Port1, Translated source (SNAT) auf MASQ, Translated destination (DNAT) auf Remote_Web, Original service auf ein Serviceobjekt TCP 5555 und Translated service (PAT) auf TCP 443 setzen. Für diesen VPN-DNAT-Fall beide Interface-Felder auf Any setzen. Position bewusst prüfen und Save wählen. MASQ sorgt in diesem Sonderfall für den Rückweg zur Firewall.
4. Unter Routing > SD-WAN routes IPv4 > Add wählen und einen Namen setzen. Unter Destination networks Any entfernen und dasselbe ursprüngliche WAN-Interface #Port1 wählen, nicht Remote_Web. Unter Services Any entfernen und den externen Service TCP 5555 wählen, nicht TCP 443. Unter Link selection settings Primary and Backup gateways wählen und unter Primary gateway das Remote-Gateway setzen; ein Backup nur wählen, wenn dessen Remote-Pfad tatsächlich vorhanden und geprüft ist. Save wählen.
5. Von einer autorisierten externen Quelle eine neue Verbindung aufbauen. NAT-/Firewall-IDs, übersetztes Ziel und Service, XFRM-Ausgang und Antworten im Capture kontrollieren. Bei falschem Ausgang SD-WAN-Kriterien, Reihenfolge und Gatewaymonitoring prüfen; bei fehlenden Antworten Remote-Dienst und Rückweg. Für weitere Server am selben Gateway dieselbe SD-WAN-Route mit deren externen Ports/WAN-Adressen erweitern; für unterschiedliche Gateways getrennte Routen erstellen. Dadurch hinzugefügte Kombinationen müssen weiterhin durch NAT und Firewall begrenzt sein.

Bei Fehlschlag die neu angelegte Remote-DNAT-Regel deaktivieren, die neue SD-WAN-Route entfernen beziehungsweise ihren vorherigen Stand wiederherstellen und Positionen zurücksetzen. Gemeinsam genutzte Gateway-/Hostobjekte nicht löschen. Abgeleitete NAT-Regeln separat zurücknehmen und den alten Datenfluss mit einer neuen Verbindung verifizieren.

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.

Typische Entscheidungen für CLI-Source-Translation sind:

• DHCP- und Authentifizierungsanfragen der Firewall durch Site-to-Site-IPsec schicken; die Übersetzung kann auch Anfragen an Firewall-Dienste durch VPN-Tunnel unterstützen. Sie ersetzt nicht deren Dienst- und VPN-Konfiguration.
• Bei mehr WAN-Links als physischen WAN-Interfaces Alias-Adressen verwenden und das physische Interface auf den passenden Alias übersetzen.
• Mailtraffic mit der für den Upstream-Relay oder den MX-Eintrag benötigten Alias-Quelladresse senden.
• Interne Adressen gegenüber WAN-Zielen verbergen, etwa bei DHCP-Anfragen eines LAN-Interfaces; für interne MPLS-Ziele oder ausgewählte Webserver eine bestimmte Quellidentität verwenden.

Vorher Ziel, erforderliche Quellidentität, Route und Gegenstellenanforderung notieren. Danach den konkreten Dienst neu auslösen und die tatsächliche Quelladresse sowie Antwort im Capture prüfen. Ein vorhandener CLI-Eintrag allein beweist weder DHCP noch Authentifizierung oder Mailflow.

⚠️ 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.

An der Command-line console anmelden und 4 – Device Console wählen, nicht die Advanced Shell. 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.

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

Tabelle und Zähler gezielt bedienen

Unter Rules and policies > NAT rules wählt IPv4 beziehungsweise IPv6 die Regelfamilie. Disable filter blendet den Regelfilter aus, Enable filter ein; Reset filter setzt ihn zurück. Ein ausgeblendeter Filter ist keine deaktivierte NAT-Regel. Vor einer Änderung sicherstellen, dass die richtigen Einträge sichtbar sind.

Ausgewählte Regeln lassen sich über Disable gemeinsam ausschalten oder über Delete löschen. Über den Rule handle wird eine Regel verschoben; spezifische Regeln gehören vor allgemeinere. More options bietet den Ein-/Aus-Schalter, Bearbeiten, Löschen und das Hinzufügen einer benachbarten Regel. Unlink rule löst die Verknüpfung mit der Firewall-Regel; deshalb vorher die Abhängigkeit dokumentieren und nicht als Diagnose-Abkürzung verwenden.

Reset usage count unter More options setzt den Nutzungszähler zurück. Vorher Zählerstand und Zeitpunkt notieren, dann einen neuen Testflow erzeugen und den Anstieg zusammen mit Rule IDs prüfen; ein Zähler allein identifiziert nicht den Testflow. Der alte Zählerstand wird dadurch nicht wiederhergestellt. Für Regeländerungen zunächst IDs, Kriterien, Status und Reihenfolge sichern, möglichst deaktivieren statt löschen und nur ausgewählte Einträge ändern. Bei Problemen Status und Positionen zurücksetzen und mit einer neuen Session prüfen; eine gelöschte Regel muss aus der gesicherten Konfiguration wiederhergestellt werden.

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.

NATRule per XML API einordnen

Für Automationen bildet NATRule dasselbe Original-/Translated-Modell ab. Die Objektbeschreibung Add NAT policy / Edit NAT policy ist in den verglichenen SFOS-22- und SFOS-23-Referenzen identisch. Das belegt den Dokumentationsstand, nicht die erfolgreiche Ausführung auf einem bestimmten Build. Vor einem Schreibjob gelten die zentralen XML-API-Sicherheitsregeln: enger Managementzugriff, TLS-Prüfung, separates Servicekonto, geschützte Secrets, Backup, Leseabfrage und eine für Objekt und installierten Build bestätigte explizite Operation an Set. Die Objektbeschreibung allein ist kein vollständiger ausführbarer Request.

Match-Kriterien, Übersetzung und Regelidentität

• OriginalSourceNetworks enthält wiederholbare Network-Einträge für die ursprünglichen Quellen; OriginalDestinationNetworks enthält Network-Einträge für die ursprünglichen Ziele. OriginalServices enthält wiederholbare Service-Einträge. Das sind Objektbezüge für das Matching vor NAT, keine Firewall-Freigabe. Für diese Netzwerk- und Servicenamen nennt die Referenz jeweils höchstens 60 Zeichen.
• TranslatedSource, TranslatedDestination und TranslatedService sind jeweils einzelne Werte für die Übersetzung. Bei unverändertem Feld verwendet das Beispiel Original; für Quell-Masquerading MASQ. Angaben wie IPAddress, IPRange, IPList, FQDN oder TCPUDP_Service beschreiben im Beispiel die passende Objektart, nicht einen beliebigen wörtlichen Wert zum Senden. Die tatsächlich vorhandenen Host-, Bereichs-, Listen-, FQDN- und Serviceobjekte sowie deren Unterstützung im Build prüfen. Die zuvor beschriebenen PAT-Grenzen bleiben gültig. Für den Serviceobjektwert beziehungsweise -namen in TranslatedService nennt die Parametertabelle ausdrücklich höchstens 60 Zeichen; für TranslatedSource und TranslatedDestination nennt diese Tabelle keinen entsprechenden Höchstwert.
• InboundInterfaces und OutboundInterfaces enthalten jeweils wiederholbare Interface-Einträge. Sie begrenzen das Interface-Matching, erzeugen aber keine Route. Die oben erläuterten VPN-/DNAT-Bedingungen gelten auch für Automationen: VPN-Eingang und VPN-Ausgang verwenden Any; bei DNAT von öffentlichen auf private Adressen ist der Ausgang ebenfalls Any. Das hebt die Begrenzung durch Original-Kriterien und Firewall-Regeln nicht auf.
• Name direkt unter NATRule ist der Pflichtname der Regel: höchstens 60 Zeichen, UTF-8 erlaubt, kein Komma. Description ist optional und auf 255 Zeichen begrenzt. IPFamily erlaubt IPv4 oder IPv6; die Referenz nennt IPv4 als Default. Status erlaubt Enable oder Disable; der dokumentierte Default ist eingeschaltet. Familie und Status im freigegebenen Schreibpayload bewusst setzen, statt ungeprüft auf Defaults zu vertrauen.
• LinkedFirewallrule ist im Beispiel nur für das Erstellen einer Linked NAT Rule innerhalb eines Set-Requests vorgesehen. Dafür die bestehende Firewall-Regel genau identifizieren. Eine Verknüpfung macht aus der SNAT-Regel keine DNAT-Regel und gibt ihr keine garantierte Priorität; die Einschränkungen für Linked NAT bleiben bestehen.

Position und Interface-Override getrennt planen

Position zeigt im XML-Beispiel die Werte top, bottom, after und before in dieser Schreibweise. Für relative Platzierung enthält After beziehungsweise Before einen eigenen Name mit dem Namen der Bezugsregel. Dieser Name ist nicht der Pflichtname der neuen oder bearbeiteten Regel. Das Beispiel kennzeichnet beide Blöcke ausdrücklich als nur für Set-Requests anwendbar. Nur den zur gewünschten Platzierung passenden Bezug verwenden; nicht beide Musterblöcke blind kopieren. Vorher Existenz und aktuellen Platz des Ankers prüfen, danach die tatsächlich gespeicherte Reihenfolge kontrollieren. Ein erfolgreicher Objektstatus beweist noch nicht, dass der geplante Traffic diese Regel zuerst trifft.

OverrideInterfaceNATPolicy ist ein separater Schalter mit Enable oder Disable, dokumentiertem Default Disable und Bezug zur interface-spezifischen SNAT-Quellübersetzung. Nur bei eingeschaltetem Override gehört die entsprechende InterfaceNATPolicyList zum geplanten Fall. Sie enthält wiederholbare Override-Blöcke mit specific_interface für das Ausgangsinterface und specific_translatedsourceid für die dort gewünschte übersetzte Quelle. Das als Pflichtfeld beschriebene spezifische Interface ist somit eine Anforderung innerhalb dieses bedingten Override-Falls, keine Pflicht für jede NAT-Regel.

Die Musterkommentare nennen an einer Stelle abweichend OverrideInterfaceDefaultNATPolicy, während Element und Parametertabelle OverrideInterfaceNATPolicy verwenden. Daraus keinen zusätzlichen XML-Tag erfinden. Die Liste wird in der Tabelle als optional mit Default NULL beschrieben; das ist keine Anweisung, den Text NULL zu senden. Auch für das dort erwähnte monitorindex liefert das Muster keinen klaren Einbauort. Wenn eine Automation von solchen ungeklärten Details abhängt, vor dem Schreiben in API help des installierten Builds beziehungsweise mit Support klären; keine zusätzliche Syntax oder Wirkung erraten.

Load Balancing und Health Checks sind bedingte Felder

NATMethod ist für den DNAT-Verteilungsfall relevant, nicht als Pflichtwahl für eine gewöhnliche SNAT-Regel. Die API-Referenz beschreibt seine Anwendbarkeit mit der Hosted-Server-Quellzone WAN und einem Protected Server vom Typ IP Range oder IP List. Diese älteren Bezeichnungen nicht als zusätzliche, im Muster fehlende XML-Felder übernehmen. Die dokumentierten Werte sind Round-robin, First_alive, Random, StickyIP und OnetoOne; der Referenzdefault heisst Sticky IP. Die Entscheidungshilfe für die fünf Methoden und die gleiche Adressanzahl bei One-to-one stehen oben.

HealthCheck erlaubt Enable oder Disable und wird in der API-Tabelle als optional mit Default OFF sowie nur bei Load Balancing anwendbar beschrieben. Das bedeutet nicht, dass jede NAT-Anfrage Health-Check-Felder benötigt. Es ist aber auch keine Zusage, dass First_alive ohne Prüfung arbeiten soll: Die konkreten NAT-Anleitungen erzwingen für First alive den Health Check. Für diesen Fall Prüfung und Werte bewusst planen und im gespeicherten Zustand kontrollieren, statt sich auf den allgemeinen OFF-Default zu verlassen.

Bei aktiviertem Health Check stehen die Prüfwerte im Block LoadBalance:

• ProbeMethod: ICMP oder TCP. Die Pflichtkennzeichnung gilt hier für den aktiven Prüfungsfall.
• Port: nur bei TCP, Bereich 1–65535; für ICMP keine allgemeine Portpflicht ableiten.
• ProbeInterval: Prüfintervall in Sekunden, Bereich 5–65535, dokumentierter Default 60. Der Bereich stammt aus der Parametertabelle; das leere Musterelement gibt keinen eigenen Zahlenwert vor.
• ResponseTimeOut: Antwortfrist in Sekunden, Bereich 1–10, dokumentierter Default 2.
• DeactivateHostAfter: Anzahl erfolgloser Prüfversuche bis zur Deaktivierung, optional, Bereich 1–10, dokumentierter Default 3.

Die Pflichtkennzeichnungen für Methode, Intervall und Antwortfrist nicht aus ihrem aktivierten Health-Check-Kontext herauslösen. Auch diese Angaben bestätigen nur den beschriebenen API-Vertrag. Ob Probe, Dienst und gewünschter Failover funktionieren, muss mit dem oben beschriebenen neuen Datenfluss und einem geplanten Ausfall-/Rückkehrtest geprüft werden.

NATRule-Antworten objektspezifisch auswerten

Die folgenden Zuordnungen stammen aus Status Message Information für dieses Objekt. Es sind XML-Objektstatuscodes, keine HTTP-Statuscodes. Die Message.*-Werte sind unaufgelöste Meldungsschlüssel der Referenz, keine verifizierten Meldungstexte einer Firewall. Deshalb Operation, Code, tatsächliche Antwort und gespeicherten Zustand gemeinsam beurteilen; nicht aus dem Schlüsselnamen einen Grenzwert oder einen sicheren Retry ableiten.

• Add NAT policy: 200 ist mit Message.NATPolicyAddSuccess, 500 mit Message.NATPolicyAddFail und 502 mit Message.NATPolicyRecordExists verbunden.
• Edit NAT policy: 200 ist mit Message.NATPolicyUpdateSuccess, 500 mit Message.NATPolicyUpdateFail und 502 mit Message.NATRuleUpdateRecordExist verbunden. Insbesondere der 502-Schlüssel unterscheidet sich vom Anlegen.

Für beide Operationen Add NAT policy und Edit NAT policy sind zusätzlich dieselben Zuordnungen dokumentiert:

Damit darf insbesondere 504 hier nicht allein nach der allgemeinen API-Tabelle als fehlgeschlagene Löschung wegen einer Referenz interpretiert werden: Diese NATRule-Zeilen gehören zu Add/Edit und führen den Portkonflikt-Schlüssel. Auch die beiden Codes 548 und 549 belegen trotz identischem Schlüssel keine konkrete maximale Serverzahl.

Vor jedem erneuten Schreibversuch, auch bei Timeout oder vermeintlichem Erfolg, den tatsächlich gespeicherten NAT-Eintrag lesen und in Rules and policies > NAT rules prüfen: Name, Familie, Status, Original-/Translated-Werte, Interfaces, Override-Zuordnungen, bedingte Prüfwerte und Position. Antwort und vorher gesicherten Zustand abgleichen; bei Konflikten nicht durch Umbenennen, breitere Kriterien oder blindes Wiederholen ausweichen. Ungeklärte Unterschiede stoppen den Job. Erst nach Zustandsprüfung mit einer neuen Session beide Rule IDs und die tatsächliche Übersetzung kontrollieren. Für einen Rückweg den gesicherten Zustand und die Reihenfolge wiederherstellen und abgeleitete Regeln separat berücksichtigen; die praktische Serververöffentlichung bleibt im DNAT-Runbook.

FAQ