Bei einer entsprechenden Anforderung der Gegenseite kann ein ausgehendes, einseitiges NAT (Source NAT) beim Zugriff auf ein Remote Netzwerk notwendig sein. In meinem Fall möchte ich für Support Zugriffe lediglich auf die Remote Site B zugreifen, aber keinen Zugriff von der Remote Site B auf meine Umgebung (Site A) zulassen. Um bei lokalen Änderungen der Netze nicht immer alle IPSec Phase 2 Selektoren anpassen zu müssen, verwende ich Source NAT (ausgehendes NAT). Entscheidend hierbei, es ist lediglich augehender Traffic von Site A nach Site B notwendig. Sollte ein beiderseitiger Zugriff notwendig sein, empfehle ich auf beiden Seiten NAT einzusetzen und diesem Artikel der Fortinet Cookbook Reihe zu folgen.
Technisch bedeutet ausgehendes NAT, dass die Pakete, bevor sie in den Tunnel nach Site B geschickt werden, in eine bestimmte IP „übersetzt“ werden. Mit dem entsprechenden statischen Routing Eintrag werden die Zielpakete dann in den Tunnel geroutet. Bei einer Fortigate ist die Konfiguration von SNAT und DNAT, speziell wenn man andere IPSec Gateways oder Firewalls kennt, etwas gewöhnungsbedürftig. Deshalb hier mal ein Beitrag, um diese Konfiguration etwas zu beleuchten.
Hinweis
Ich gehe in diesem Beitrag davon aus, dass sämtliche Eckdaten (IKE Version, Encryption, Authentication, Phase 2 Proposals, Key Lifetimes, PSK) zum IPSec Tunnel ausgetauscht, konfiguriert und dokumentiert wurden. Hier gehe ich nicht weiter auf die Details ein, denn der Fokus dieses Beitrags liegt auf der reinen IP Konfiguration. Diese Konfiguration funktioniert übrigens auch, wenn ein Tunnel zu einer speziellen VDOM hergestellt werden muss.
Zum Thema
Das Schema stellt das Beispiel eines ausgehenden, einseitigen NAT dar. Heißt, in Site A werden wir die Pakete „umschreiben“, in Site B nicht. Die IP’s aus dem Beispiel sind dann natürlich an die eigenen Gegebenheiten anzupassen. Die Komplexität ergibt sich aus der Tatsache, dass in Site A zunächst ausgehendes NAT (SNAT) für den Zugriff von Site A nach Site B, ABER auch eingehendes NAT (DNAT) für den umgekehrten Zugriff konfiguriert werden muss. Wir bekamen die Vorgabe, dass wir das NAT Netz 172.24.0.0/29 verwenden dürfen und die Gegenseite erwartet eingehende IP Pakete von der IP 172.24.0.1. Diese Vorgaben haben wir im Schema viasualisiert und setzen sie jetzt in der Konfiguration um.
Die einzelnen Steps, um das o.g. Schema umzusetzen…
Konfiguration für Site A
- Erstelle einen IPSec Tunnel, mit der Gateway IP 10.131.131.10 und wähle das WAN Interface für die Bindung
- Verwende in Phase 2 als Local Subnet das NAT Netzwerk 172.24.0.0/29 und als Remote Netzwerk das Subnet 192.168.20.0/24
- Erstelle nun die notwendigen Adressobjekte für die Firewall Policy
- Local-Net-A: 192.168.1.0/24
- Remote-Net-B: 192.168.20.0/24
- Erstelle einen IP Pool „SiteB-SNAT-IP“ mit der IP 172.24.0.1
- Erstelle eine statische Route mit dem Zielnetz 192.168.20.0/24 und wähle als Interface das Phase 1 Interface des zuvor erstellten IPSec Tunnel, ohne jedoch ein Gateway einzutragen
- Erstelle nun eine Firewall Policy für den Zugriff Site A -> Site B:
- Source-Interface -> Internes Interface des Subnetz 192.168.1.0/24
- Destination Interface -> Phase 1 Gateway des IPSec Tunnels
- Source Network -> Local-Net-A
- Destination Network -> Remote-Net-B
- Aktiviere NAT und wähle in der IP Pool Configuration den eben erstellten IP Pool „SiteB-SNAT-IP“
(Hier erfolgt jetzt SNAT -> Wie oben beschrieben, werden die IP Pakete vor dem Transport in den Tunnel „übersetzt“.) - Lege die gewünschten Services fest oder verwende „ALL“
Damit ist die Konfiguration in Site A schon abgeschlossen…
Konfiguration für Site B
- Erstelle einen IPSec Tunnel, mit der Gateway IP 10.212.212.4 und wähle das WAN Interface für die Bindung
- Verwende in Phase 2 als Local Subnet das Netzwerk 192.168.20.0/24 und als Remote Netzwerk das SNAT Subnet 172.24.0.0/29
- Erstelle eine statische Route mit dem Zielnetz 172.24.0.0/29 und wähle als Interface das Phase 1 Interface des zuvor erstellten IPSec Tunnel, ohne ein Gateway einzutragen
- Erstelle nun die Adressobjekte für die Policy
- Local-Net-B: 192.168.20.0/24
- Remote-Net-A: 172.24.0.0/29 (Alternativ kann hier die IP 172.24.0.1/32 verwendet werden, da ja an Site A nur auf diese IP „übersetzt“ wird.)
- Erstelle eine Firewall Policy für den Zugriff Site A -> Site B:
- Source-Interface -> Phase 1 Gateway des IPSec Tunnels
- Destination Interface -> Internes Interface des Subnetz 192.168.20.0/24
- Source Network -> Remote-Net-A
- Destination Network -> Local-Net-B
- NAT bleibt deaktiviert
- Lege die gewünschten Services fest oder verwende „ALL“
Damit ist auch die Konfiguration für Site B abgeschlossen und es kann getestet werden! Versuche von einem System an Site A und dem lokalen Netz 192.168.1.0/24 auf ein System im Remote Netz 192.168.20.0/24 zuzugreifen.