[Gelöst]1:1/ Outbound NAT -> IPSEC/OpenVPN
-
Hallo zusammen,
habe mich schon relativ schwer bei der Überschrift getan. :)
Was habe ich vor?Mit einem Client welcher per OpenVPN (172.20.19.6) auf die pfSense zugreift und das dahinterliegende LAN (172.20.21.0/24) problemlos erreichen kann. Nun möchte ich aber mit diesem Client weiter springen und ein Subnetz erreichen, welches per IPSEC an der pfSense angeschlossen ist (172.24.22.0/24). Nun kommt aber der Haken, ich muss in dem IPSEC Subnet (172.24.22.0) mit einer IP aus dem pfSense LAN Subnet (172.20.21.0/24) ankommen und nicht mit der OpenVPN IP. Bei Sophos nennt sich das DNAT. Ich gehe mal davon aus, dass das bei pfSense mit Outbound NAT zu bewerkstelligen ist?
Benötige ich dafür noch eine virtuelle IP aus dem LAN Subnet? Habe es auch noch mal versucht auf dem Bild im Anhang deutlich zu machen.
Könnte mich jemand bei der Umsetzung unterstützen? Eine einfache Outbound NAT Regel (Interface: IPSEC, Source Subnet: 172.20.19.0/24, Dest Subnet: 172.24.22.0/24) hat leider nicht ausgereicht um das gewünschte Ergebnis zu erzielen.Achso…eine Route auf dem Client habe ich bereits angelegt, dass Traffic in das 172.24.22.0/24 Netz über den OpenVPN Tunnel gerouted werden soll.
Danke und Grüße
m0nji
-
Hallo!
Nun kommt aber der Haken, ich muss in dem IPSEC Subnet (172.24.22.0) mit einer IP aus dem pfSense LAN Subnet (172.20.21.0/24) ankommen und nicht mit der OpenVPN IP. Bei Sophos nennt sich das DNAT. Ich gehe mal davon aus, dass das bei pfSense mit Outbound NAT zu bewerkstelligen ist?
DNAT = Destination NAT, d.h. die Ziel-IP wird umgesetzt. ???
Ist ja wohl nicht das, was gefordert ist.Könnte mich jemand bei der Umsetzung unterstützen? Eine einfache Outbound NAT Regel (Interface: IPSEC, Source Subnet: 172.20.19.0/24, Dest Subnet: 172.24.22.0/24) hat leider nicht ausgereicht um das gewünschte Ergebnis zu erzielen.
Was hast du als Translation Adress angegeben?
Ich habe das eben bei mir getestet, funktioniert wunderbar. Allerdings habe ich kein IPSec.
Grüße
-
Hi,
danke für die Antworten.
Naja doch die Ziel-IP soll ja umgesetzt werden. Ich komme ursprünglich mit der OpenVPN IP (172.20.19.2) an der pfSense an und möchte, dass dieser Client im IPSEC Netz mit einer IP aus dem pfSense Netz (172.20.21.0/24) ankommt. Hintergrund ist, dass die IPSEC Phase 2 genau nur das Netz 172.20.21.0/24 bei allen Tunnels beinhaltet.Um das besser debugen zu können, hatte ich mal eine Floating Rule auf alle Interfaces gesetzt um die Verbindung aus dem OpenVPN Netz in das Client Netz im Log zu sehen. Dabei ist heraus gekommen, dass eine Rule im WAN Interface notwendig ist und beim Outbound NAT ebenfalls das WAN Interface genutzt werden muss. In den folgenden Screenshots kannst du die Einstellungen sehen, die ich gemacht habe und laut "States" macht er auch genau das, was er soll.
Die 172.20.21.109 ist eine Virtual IP, welche in unter Firewall -> Virtual IP angelegt habe
Allerdings kommt immer noch keine Verbindung zu stande. Weder Ping noch RDP klappten. Nun weiß ich aber ehrlich gesagt nicht mehr, woran es hängt. Sieht doch eigentlich so aus als müsste es wunderbar klappen.
Was hast du genau konfiguriert?
-
Naja doch die Ziel-IP soll ja umgesetzt werden. Ich komme ursprünglich mit der OpenVPN IP (172.20.19.2) an der pfSense an und möchte, dass dieser Client im IPSEC Netz mit einer IP aus dem pfSense Netz (172.20.21.0/24) ankommt. Hintergrund ist, dass die IPSEC Phase 2 genau nur das Netz 172.20.21.0/24 bei allen Tunnels beinhaltet.
Okay, IPSec stellt ausschließlich eine Route für das LAN Subnetz bereit. Ziel ist es, mit dem OpenVPN Client über den IPSec-Tunnel zu kommen. Warum, zum Teufel, willst du da die Ziel-IP umsetzen, und auf welche??
Du musst die Quell-IP des VPN-Client umsetzen, damit Requests über den Tunnel kommen, bzw. damit die Antworten den VPN-Client erreichen, denn das ist ja das wahre Problem. Das Rücksetzen der Antworten auf die Client-IP macht pfSense dann nämlich automatisch.
Und das muss am IPSec Interface gemacht werden. Ich frag mich, wie du auf WAN kommst. Das Outbound NAT ist aber schon das richtige Mittel dafür.
Man nennt das auch masquerading, weil die Quelle hinter einer anderen IP versteckt wird.Das 10.40.0.0/16 Netz hattest du bislang nicht erwähnt, keine Ahnung, was es mit dem nun auf sich hat.
Mein Vorschlag:
Lösche die beiden gezeigten Outbound NAT Regeln, lösche die virtuelle IP, die du für den Zweck angelegt hast.Füge eine Outbound NAT Regel hinzu:
Interface: IPSec
Source: 172.20.19.0/24 (das OpenVPN Subnetz)
Destination: 172.24.22.0/24 (das Zielnetz hinter der IPSec)
Translation Address: Other
und darunter eine freie IP aus dem LAN Subnetz und Maske 32 eintragen.Ist großteils die Regel die du in deinem ersten Post geschrieben hast, allerdings hast du nicht die Translation Address verraten, auch nicht auf meine dahingehende Frage.
Bei mir hat es damit problemlos funktioniert. Die Masquerade-IP ist eine willkürlich gewählte aus dem richtigen Subnetz, die sonst nirgends auf der pfSense definiert ist, keine VIP! -
Du hast Recht, es ist nicht DNAT sondern SNAT.
Die Translation Address hatte ich ja in meinem letzten Post beschrieben.Leider hat es mit deinem Vorschlag noch nicht geklappt. Wenn der auch schlüssig erscheint. Das Problem wird aktuell noch sein, dass die pfsense nicht weiß, dass das OpenVPN Paket in den IPSEC Tunnel muss.
Zumindest erscheint es mir anhand der States so.Ein Test aus dem LAN Subnet in das IPSEC Subnet mit Translation funktioniert, wie du anhand des ersten Screenshots sehen kannst. Ich denke also, dass wohl noch eine statische Route fehlt?!
Die Translation Address ist hier 172.20.21.116 bei dem Test aus dem LAN Subnet
 -
Ok Problem gelöst. Für genau diesen Fall bietet die Phase 2 im IPSEC eine weitere Eigenschaft (BINAT). Damit muss der Tunnel nicht auf der anderen Seite angepasst werden. Es genügt eine zusätzliche Phase2 mit dem OpenVPN Netz als Source, einer LAN IP als Translation und Destination ist das IPSEC Netz. Screenshots im Anhang.
Danke trotzdem für die Tipps @viragomann
 -
Das ist genau das was ich suche. Leider finde ich den Anhang nicht.
-
Die Forumssoftware wurde letztes Jahr umgestellt, da sind die verknüpften Bilder und Anhänge nicht mit übernommen worden.
