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.

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. Sie ü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.

Die wichtigsten NAT-Arten

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.

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

Praxisbeispiele: Wann verwendet man was?

SNAT: Source NAT

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

Typische SNAT-Regel für LAN zu WAN:

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 Erstellen 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.

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:

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.

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:

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.

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

Passende Firewall Regel zur DNAT-Regel

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.

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. Sie 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.

⚠️ Wenn eine DNAT-Regel später geändert wird, werden automatisch erzeugte Loopback- oder Reflexive Rules nicht in jedem Fall logisch mitgedacht. Nach Änderungen sollte man die zugehörigen Regeln kontrollieren.

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. Sie ist eine Source NAT-Regel und erscheint 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:

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.

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

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.

Troubleshooting

Bei NAT-Problemen hilft diese Reihenfolge:

1. Log viewer öffnen und nach Source IP, Destination IP und Service filtern.
2. Prüfen, 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.

Weitere Informationen

• Sophos Firewall - Add a NAT rule
• Sophos Firewall - Add a DNAT rule with server access assistant
• Sophos Firewall - Create DNAT and firewall rules for internal servers
• Sophos Firewall - Create an SNAT rule