Sophos Firewall IPsec bei überlappenden Netzen mit NAT
Verwenden Zentrale und Filiale dasselbe reale Subnetz, kann keine Firewall allein anhand der Zieladresse entscheiden, ob ein Paket lokal bleiben oder durch den IPsec-Tunnel gehen soll. Der Tunnel kann dabei grün sein und trotzdem ist kein sauberer Datenpfad möglich. Die Lösung ist ein beidseitig abgestimmter Übersetzungsplan: Jeder Standort erscheint auf der Gegenstelle unter einem eindeutigen Ersatznetz.
Der entscheidende Punkt liegt beim Tunneltyp. Policy-based IPsec und route-based IPsec mit konkreten Traffic Selectors verwenden die NAT-Einstellungen direkt in der IPsec-Verbindung. Route-based Any-to-Any verwendet stattdessen DNAT- und SNAT-Regeln sowie eine Route zum übersetzten entfernten Netz. Die allgemeine Typentscheidung erklärt Site-to-Site IPsec VPN einrichten.
Die richtige Methode wählen
Sophos unterstützt für policy-based IPsec eine 1:1-, 1:n- oder n:n-Übersetzung. Bei n:n müssen Original- und Ersatznetz gleich gross sein. Ein /24 wird deshalb beispielsweise auf ein anderes /24 abgebildet, nicht auf ein /25.
Für die Auswahl reichen drei Fragen:
- Sind in der IPsec-Verbindung konkrete Local und Remote subnets eingetragen? Dann wird Network address translation (NAT) in der Verbindung verwendet.
- Stehen bei einem route-based Tunnel beide Subnetze auf
Any? Dann werden DNAT mit reflexiver SNAT-Regel und eine Route über XFRM benötigt. - Sind die Netze gar nicht überlappend? Dann ist NAT normalerweise unnötig und erschwert Logs, Regeln und Fehlersuche.
⚠️ Die beiden Verfahren werden nicht gemischt. Vor der Änderung werden beide Tunnelkonfigurationen, NAT- und Firewall-Regeln, Routen, DNS-Antworten und ein unabhängiger Adminzugang gesichert. Eine breite MASQ-Regel oder eine spontan erfundene Ersatzadresse ist kein sicherer Workaround.
Adressplan für beide Standorte erstellen
Im Beispiel verwenden Zentrale und Filiale real dasselbe Netz 192.168.2.0/24. Für den Tunnel erhalten beide Seiten ein eigenes virtuelles Netz:
HQ real: 192.168.2.0/24 → visible to branch as 192.168.1.0/24
Branch real: 192.168.2.0/24 → visible to HQ as 192.168.3.0/24
Ein Client in der Zentrale spricht einen Filialserver deshalb über dessen Adresse im Netz 192.168.3.0/24 an. Ein Client in der Filiale verwendet für einen Server in der Zentrale die entsprechende Adresse aus 192.168.1.0/24. Die reale Adresse 192.168.2.x bleibt jeweils lokal.
Die drei Netze sind Dokumentationswerte und werden gemeinsam durch freie Netze aus dem eigenen Adressplan ersetzt. Beide Ersatznetze müssen eindeutig sein, dürfen mit keinem LAN-, VLAN-, VPN-, Cloud- oder Heimnetz kollidieren und müssen auf beiden Firewalls spiegelbildlich dokumentiert werden. Wenn Anwendungen Namen statt IP-Adressen verwenden, muss DNS am jeweiligen Standort die übersetzte Adresse des entfernten Systems liefern.
Policy-based IPsec mit NAT konfigurieren
Für policy-based IPsec werden auf beiden Firewalls drei IP-Hostobjekte benötigt: das reale lokale Netz, das eigene Ersatznetz und das Ersatznetz der Gegenstelle. Im Beispiel der Zentrale sind dies HO_LAN_REAL_192.168.2.0, HO_LAN_NAT_192.168.1.0 und BO_LAN_NAT_192.168.3.0.
Zentrale einrichten
Unter Site-to-site VPN > IPsec > Add wird die Verbindung als Policy-based mit Gateway type Respond only angelegt. Profil, Authentisierung, WAN-Interface und Peer-Adresse müssen zur Gegenstelle passen. Für die Netze gelten diese Zuordnungen:
- Local subnet:
HO_LAN_NAT_192.168.1.0 - Remote subnet:
BO_LAN_NAT_192.168.3.0 - Network address translation (NAT): aktiviert
- Original subnet:
HO_LAN_REAL_192.168.2.0
Das eigene reale Netz wird damit vor dem Versand auf das lokale Ersatznetz übersetzt. Eingehender Traffic zum Ersatznetz wird wieder dem realen Netz zugeordnet.
Filiale spiegelbildlich einrichten
Auf der Filiale wird die Verbindung als Policy-based mit Gateway type Initiate the connection angelegt. Die Zuordnung wird vollständig gespiegelt:
- Local subnet:
BO_LAN_NAT_192.168.3.0 - Remote subnet:
HO_LAN_NAT_192.168.1.0 - Network address translation (NAT): aktiviert
- Original subnet:
BO_LAN_REAL_192.168.2.0
Local und Remote subnet sind also die übersetzten Netze, während Original subnet das reale lokale Netz enthält. Stimmen Netzgrösse oder Richtung nicht überein, kann Phase 2 zwar entstehen, der Nutztraffic wird aber falsch übersetzt oder erreicht keinen Rückweg.
Automatische Firewall-Regeln kontrollieren
Mit Create firewall rule erzeugt SFOS eingehende und ausgehende VPN-Regeln. Unter Rules and policies > Firewall rules werden sie in der Gruppe Automatic VPN rules geprüft. Die Regeln müssen die übersetzten Netze in der richtigen Richtung und nur die tatsächlich benötigten Dienste erlauben. Eine vorhandene allgemeine VPN-Regel kann angepasst werden; pro Tunnel ist nicht zwingend eine eigene breite Regel nötig.
Regeln werden von oben nach unten ausgewertet. Deshalb werden Rule ID, Quell- und Zielzone, Quell- und Zielnetz, Services und Logging bei einem echten Test kontrolliert. Die allgemeine Regelmechanik erklärt Firewall-Regeln auf Sophos Firewall erstellen.
Route-based Any-to-Any mit DNAT und SNAT konfigurieren
Dieser Weg setzt einen funktionierenden route-based Any-to-Any-Tunnel voraus. Das XFRM-Interface besitzt eine eindeutige Transferadresse, passende LAN-zu-VPN- und VPN-zu-LAN-Regeln sind vorhanden, und eine statische, SD-WAN- oder dynamische Route führt zum übersetzten Netz der Gegenstelle. Erst danach wird NAT ergänzt.
Route-based Verbindungen mit konkreten Traffic Selectors verwenden nicht diesen Ablauf. Sie nutzen wie policy-based IPsec die NAT-Einstellungen in der IPsec-Verbindung. Trifft ihr Traffic stattdessen eine MASQ-Regel, kann SFOS ihn verwerfen, weil diesen XFRM-Interfaces keine IP-Adresse zugewiesen wird.
NAT auf der Zentrale
Unter Rules and policies > NAT rules > Add NAT rule > New NAT rule wird eine DNAT-Regel erstellt. Sie übersetzt eingehende Pakete an das virtuelle Zentralnetz auf das reale lokale Netz:
- Original source: Ersatznetz der Filiale
192.168.3.0/24 - Translated source:
Original - Original destination: Ersatznetz der Zentrale
192.168.1.0/24 - Translated destination: reales Zentralnetz
192.168.2.0/24 - Create reflexive rule: aktiviert
- Load balancing method:
One-to-one
Für die Zuordnung werden gleich grosse Netzwerk- oder IP-Range-Objekte verwendet. Nach dem Speichern wird die erzeugte Regel Reflexive_NAT#_<DNAT_rule_name> geöffnet. Sie muss ausgehend das reale Zentralnetz auf 192.168.1.0/24 übersetzen und als Original destination das Filial-Ersatznetz 192.168.3.0/24 verwenden.
NAT auf der Filiale
Auf der Filiale wird dasselbe Prinzip gespiegelt:
- Original source: Ersatznetz der Zentrale
192.168.1.0/24 - Translated source:
Original - Original destination: Ersatznetz der Filiale
192.168.3.0/24 - Translated destination: reales Filialnetz
192.168.2.0/24 - Create reflexive rule: aktiviert
- Load balancing method:
One-to-one
Die reflexive Regel muss das reale Filialnetz ausgehend auf 192.168.3.0/24 übersetzen. Eine allgemeinere SNAT- oder MASQ-Regel oberhalb dieser Regeln darf den Traffic nicht vorher erfassen. Reihenfolge und Treffer werden deshalb über NAT Rule ID und Packet Capture belegt, nicht nur aus der Regelliste abgeleitet. NAT auf Sophos Firewall verstehen erklärt Reflexive Rules und das First-match-Prinzip.
Routing, DNS und Anwendungen gemeinsam prüfen
Auf jeder Seite muss die Route zum entfernten Ersatznetz über das richtige XFRM-Interface oder dessen überwachten Gateway führen. Eine Route zum realen gleichlautenden Netz wäre mehrdeutig und kann lokalen Traffic in den Tunnel ziehen. Bei mehreren Routen werden Route Precedence, Administrative Distance und SD-WAN-Auswahl gemeinsam geprüft.
Auch die Anwendung muss das übersetzte Ziel verwenden. Statische Konfigurationen, ACLs, DNS-Antworten, Monitoring und Serverlogs dürfen nicht weiterhin die reale entfernte Adresse erwarten. Ein NAT-Test mit Ping allein beweist deshalb noch keinen funktionierenden Geschäftsprozess.
Datenpfad in beiden Richtungen abnehmen
Die Abnahme beginnt mit je einem eindeutig bekannten Host und einem realen TCP- oder UDP-Dienst. Von der Zentrale wird die übersetzte Filialadresse aufgerufen, danach von der Filiale die übersetzte Zentraladresse. Für denselben Zeitstempel werden geprüft:
- IPsec-Verbindung und Child SA sind aktiv.
- Die erwartete Firewall Rule ID erlaubt den Flow.
- Die erwartete NAT Rule ID übersetzt Original- und Zieladresse korrekt.
- Packet Capture zeigt Eingang, Übersetzung, XFRM-Ausgang und den Rückweg.
- Der Zielserver sieht die geplante Source-Adresse und antwortet über denselben Pfad.
Erst wenn beide Richtungen funktionieren, folgen weitere Hosts, Dienste und DNS-Namen. Packet Capture auf Sophos Firewall hilft beim Vergleich vor und nach NAT; den vollständigen Tunnelcheck beschreibt Sophos Firewall IPsec Troubleshooting.
Fehler nach Symptom eingrenzen
Tunnel ist grün, das Ziel antwortet aber lokal
Der Client verwendet wahrscheinlich die reale, lokal ebenfalls vorhandene Adresse statt des entfernten Ersatznetzes. DNS-Antwort, Hosts-Datei, Applikationskonfiguration und Zielroute prüfen. Das Problem liegt dann vor dem Tunnel.
Hinweg funktioniert, Rückweg fehlt
Auf beiden Firewalls müssen die Übersetzungen spiegelbildlich sein. Original und Translated source der reflexiven Regel, Remote subnet der IPsec-Verbindung, Servergateway und Regeln der Gegenrichtung vergleichen. Eine einseitige Übersetzung kann keinen stabilen bidirektionalen Flow erzeugen.
Falsche NAT-Regel trifft
NAT Rule ID und Reihenfolge prüfen. Eine breite MASQ-, Default-SNAT- oder frühere DNAT-Regel kann vor der spezifischen VPN-Regel matchen. Nicht auf Verdacht alle NAT-Regeln deaktivieren; zuerst den einzelnen Testflow zeitlich korrelieren und dann nur die kollidierende Regel korrigieren.
Einzelne Hosts funktionieren, andere nicht
Bei n:n müssen Original- und Ersatzbereich gleich gross und positionsgleich sein. IP-Range-Objekte, Netzmasken, ausgeschlossene Adressen, Hostfirewall und den tatsächlich angesprochenen Offset kontrollieren. Ein Erfolg für .10 beweist nicht automatisch die Zuordnung für den gesamten Bereich.
Rollback und Betrieb
Vor der Umstellung gehören ein Konfigurationsbackup, Screenshots oder Exporte der Tunnel-, NAT-, Firewall- und Routenkonfiguration sowie ein unabhängiger Managementzugang zum Rückweg. Alte Regeln werden während der Migration nur deaktiviert, wenn eine eindeutige Rücknahme dokumentiert ist.
Scheitert die Abnahme, werden neue NAT-Regeln und Routen deaktiviert, die vorherige Tunnelkonfiguration wiederhergestellt und der ursprüngliche lokale Traffic erneut getestet. Ersatznetze werden erst aus DNS, Monitoring und Dokumentation entfernt, wenn keine Abhängigkeit mehr besteht.
Im Betrieb müssen die übersetzten Netze im zentralen IP-Adressmanagement geführt werden. Neue Standorte, Cloud-Netze, Remote-Access-Pools und Heimnetze werden gegen Original- und Ersatznetze geprüft. Sonst verschiebt sich die Überlappung lediglich an eine andere Stelle.