Masquerading NAT - IPSec

[Oachkatze]

Hallo liebe Community,

ich habe eine spezielle Frage zur Konfiguration einer IPSEC-Verbindung.

Ausgangslage:
Ich habe eine funktionierende IPSEC-Verbindung zu einem Kunden. Dabei ist das Server-VLAN (172.16.3.0/24) IKE p2 direkt angebunden und funktioniert einwandfrei (Ping etc. möglich).
Das Client-VLAN (192.168.0.0/24) kann jedoch keine Verbindung über die IPSEC-Verbindung herstellen, da der Kunde dieses Netzwerk bereits lokal nutzt.

Netzwerkkonfiguration:

Server-VLAN: 172.16.3.0/24 (funktioniert über IPSEC)
Client-VLAN: 192.168.0.0/24 (keine Verbindung möglich)
IPSEC-Netzwerk: 10.175.16.0/16
Ziel:
Ich möchte erreichen, dass die Clients aus dem VLAN 192.168.0.0/24 über die Server-IP (z. B. NAT-Masquerading) die IPSEC-Verbindung nutzen können.

Was ich probiert habe:

Outbound NAT auf "Hybrid" umgestellt.

Schnittstelle: IPSEC
Quelle: Client-VLAN
Ziel: IPSEC-Netz
Umschreibung: Server-VLAN
Alternative: NAT über die WAN-Schnittstelle getestet (ohne Erfolg).

Firewall-Regeln auf Any/Any zum Testen konfiguriert.(IPSEC und CLient)

Problem:
Trotz der Konfiguration kann ich keine Pakete aus dem Client-VLAN über die IPSEC-Verbindung senden oder empfangen (z. B. Pings funktionieren nicht).

Frage:
Wie kann ich sicherstellen, dass die Clients im VLAN 192.168.0.0/24 mithilfe von Outbound NAT über die IPSEC-Verbindung kommunizieren können? Habe ich hier einen Denkfehler oder fehlt mir eine spezifische Konfiguration?

Vielen Dank im Voraus für eure Hilfe! 😊

[viragomann]

Hallo!

Server-VLAN: 172.16.3.0/24 (funktioniert über IPSEC)
Client-VLAN: 192.168.0.0/24 (keine Verbindung möglich)
IPSEC-Netzwerk: 10.175.16.0/16
Ziel:
Ich möchte erreichen, dass die Clients aus dem VLAN 192.168.0.0/24 über die Server-IP (z. B. NAT-Masquerading) die IPSEC-Verbindung nutzen können.

Problem:
Trotz der Konfiguration kann ich keine Pakete aus dem Client-VLAN über die IPSEC-Verbindung senden oder empfangen (z. B. Pings funktionieren nicht).

D.h., du möchtest gegenseitigen Zugriff haben?
Das würde 2 /24 Netz erfordern, die auch in der Phase 2 abgebildet sein müssten. Ist das gegeben oder gibt es die Möglichkeit, dies zu konfigurieren? Das müsste natürlich auf beiden Seiten gemacht werden.

Wenn es dir aber reicht, nur Richtung Remoteseite Verbindungen aufbauen zu können, könntest du das Client-VLAN auf eine freie IP aus dem Server-VLAN natten, für das wohl schon eine P2 existiert.
Dann müsste auf der anderen Seite nichts geändert werden.

[Oachkatze]

Hallo!

Server-VLAN: 172.16.3.0/24 (funktioniert über IPSEC)
Client-VLAN: 192.168.0.0/24 (keine Verbindung möglich)
IPSEC-Netzwerk: 10.175.16.0/16
Ziel:
Ich möchte erreichen, dass die Clients aus dem VLAN 192.168.0.0/24 über die Server-IP (z. B. NAT-Masquerading) die IPSEC-Verbindung nutzen können.

Problem:
Trotz der Konfiguration kann ich keine Pakete aus dem Client-VLAN über die IPSEC-Verbindung senden oder empfangen (z. B. Pings funktionieren nicht).

D.h., du möchtest gegenseitigen Zugriff haben?
Das würde 2 /24 Netz erfordern, die auch in der Phase 2 abgebildet sein müssten. Ist das gegeben oder gibt es die Möglichkeit, dies zu konfigurieren? Das müsste natürlich auf beiden Seiten gemacht werden.

Wenn es dir aber reicht, nur Richtung Remoteseite Verbindungen aufbauen zu können, könntest du das Client-VLAN auf eine freie IP aus dem Server-VLAN natten, für das wohl schon eine P2 existiert.
Dann müsste auf der anderen Seite nichts geändert werden.

Ich möchte das dass Client netz was nicht angegeben ist bei der Phase 2 über ein masquerting zugreifen.

Das problem isz das funktioniert nicht so richtig :(

Das prlblem ist das die gegenstelle das netzt was mein client netz ist schon in verwenunsg hat .. oder habe ich da ein denkfehler sollte das ohne prkbleme gehen wenn er auch das netzt angibt ?

[viragomann]

Meine Frage hätte auch sein können: Wie sieht die aktuelle Phase 2 aus?

Mir ist jetzt nicht klar, ob du für das Client-VLAN schon eine Phase2 konfiguriert hast oder nicht. Ich habe aber Zweifel, dass die Gegenseite es erlaubt eine P2 für ein Remotenetz zu erstellen, das mit einem lokal existierendes Subnetz überlappt.

[Oachkatze]

Meine Frage hätte auch sein können: Wie sieht die aktuelle Phase 2 aus?

Mir ist jetzt nicht klar, ob du für das Client-VLAN schon eine Phase2 konfiguriert hast oder nicht. Ich habe aber Zweifel, dass die Gegenseite es erlaubt eine P2 für ein Remotenetz zu erstellen, das mit einem lokal existierendes Subnetz überlappt.

Ja wie würde ich da sonst am besten machen ?

Nein phase ist nur für das server netzt

Desewegen auch das masquieren :-) oder wie wäre den da der besser weg dies zu machen.

Würde ja dann mit einer IP von server netz bei den IPSec melden.

Ich hoffe es ist verständlich

[viragomann]

Desewegen auch das masquieren :-) oder wie wäre den da der besser weg dies zu machen.

Das Client-VLAN ändern. :-)
Aber ich nehme an, das ist nicht gewollt. Dann führt an Masquerading kein Weg vorbei.

Es stellt sich aber immer noch die Frage, ob bidirektionaler Zugriff erforderlich ist oder einseitiger reicht.
Bidirektionaler erfordert eine zusätzlich Phase 2 für das Client-VLAN, natürlich in Verbindung mit Masqerading. Und da meine Frage vorhin, ob das schon eingerichtet ist, oder es möglich ist, eine P2 hinzuzufügen.
Auf der Remoteseite müsste da eben ein nicht genutztes "Ersatznetz" als Remotenetz angegeben werden, das auf deiner Seite 1;1 auf das Client-Netz genattet wird.

Ist das nicht möglich, weil die Remoteseite nicht gewillt ist, eine Phase 2 dafür einzurichten, ginge nur einseitiger Zugriff mithilfe einer IP aus dem Server-Netz.

[Oachkatze]

Desewegen auch das masquieren :-) oder wie wäre den da der besser weg dies zu machen.

Das Client-VLAN ändern. :-)
Aber ich nehme an, das ist nicht gewollt. Dann führt an Masquerading kein Weg vorbei.

Es stellt sich aber immer noch die Frage, ob bidirektionaler Zugriff erforderlich ist oder einseitiger reicht.
Bidirektionaler erfordert eine zusätzlich Phase 2 für das Client-VLAN, natürlich in Verbindung mit Masqerading. Und da meine Frage vorhin, ob das schon eingerichtet ist, oder es möglich ist, eine P2 hinzuzufügen.
Auf der Remoteseite müsste da eben ein nicht genutztes "Ersatznetz" als Remotenetz angegeben werden, das auf deiner Seite 1;1 auf das Client-Netz genattet wird.

Ist das nicht möglich, weil die Remoteseite nicht gewillt ist, eine Phase 2 dafür einzurichten, ginge nur einseitiger Zugriff mithilfe einer IP aus dem Server-Netz.

Haha, ja, das wäre natürlich am schönsten :-) Leider ist es nicht mehr so einfach.

Das mit "bidirektional" würde ich so nicht unterschreiben. Meine Clients sollen über RDP und eine Website mit den Kunden kommunizieren – umgekehrt eigentlich nicht.

Ich hatte allerdings schon mal versucht, das Client-Netz als Phase 2 einzurichten, inklusive Maskierung über Outbound NAT. Das hat aber nicht ganz funktioniert. Irgendwo habe ich wohl einen Denkfehler.

[viragomann]

Wie gesagt, bidirektional erfordert eine 2. Phase 2 auch beim Kunden. Ich nehme an, das ist nicht möglich, und für den Zugriff aus deinem Client-Netz auch nicht zwingend erforderlich, wenn du schon eine Phase 2 für ein lokales Netz hast.

Server-VLAN: 172.16.3.0/24 (funktioniert über IPSEC)
Client-VLAN: 192.168.0.0/24 (keine Verbindung möglich)
IPSEC-Netzwerk: 10.175.16.0/16

Ich nehme an, du hast da einen legacy Site to Site Tunnel eingerichtet, nicht eine "Connection", mit 172.16.3.0/24 als lokales und 10.175.16.0/16 als remote Netz.
Wobei, warum 10.175.16.0/16? Das sollte eine Netzwerkadresse sein. Wenn ein /16er, dann eher 10.175.0.0/16.

Als Masquerading IP kannst du eine beliebige freie im Server-VLAN nehmen oder auch die Interface-IP der OPNsense (oder eine andere VIP im Subnetz). Ich nehme hier mal 172.16.3.99 als Beispiel.

Das NAT kannst du mit einer one-to-one NAT Regel machen:
Interface: IPSec
Type: NAT
External network: 172.16.3.99/32
Source: 192.168.0.0/24
Destination: 10.175.0.0/16 (oder eben das tatsächliche entfernte Netzwerk)

Am Client-VLAN muss der Zugriff zum Remote-Netz natürlich erlaubt sein. Die Remoteseite sollte diese Zugriffe als von 172.16.3.99 kommend sehen.

[Oachkatze]

Wie gesagt, bidirektional erfordert eine 2. Phase 2 auch beim Kunden. Ich nehme an, das ist nicht möglich, und für den Zugriff aus deinem Client-Netz auch nicht zwingend erforderlich, wenn du schon eine Phase 2 für ein lokales Netz hast.

Server-VLAN: 172.16.3.0/24 (funktioniert über IPSEC)
Client-VLAN: 192.168.0.0/24 (keine Verbindung möglich)
IPSEC-Netzwerk: 10.175.16.0/16

Ich nehme an, du hast da einen legacy Site to Site Tunnel eingerichtet, nicht eine "Connection", mit 172.16.3.0/24 als lokales und 10.175.16.0/16 als remote Netz.
Wobei, warum 10.175.16.0/16? Das sollte eine Netzwerkadresse sein. Wenn ein /16er, dann eher 10.175.0.0/16.

Als Masquerading IP kannst du eine beliebige freie im Server-VLAN nehmen oder auch die Interface-IP der OPNsense (oder eine andere VIP im Subnetz). Ich nehme hier mal 172.16.3.99 als Beispiel.

Das NAT kannst du mit einer one-to-one NAT Regel machen:
Interface: IPSec
Type: NAT
External network: 172.16.3.99/32
Source: 192.168.0.0/24
Destination: 10.175.0.0/16 (oder eben das tatsächliche entfernte Netzwerk)

Am Client-VLAN muss der Zugriff zum Remote-Netz natürlich erlaubt sein. Die Remoteseite sollte diese Zugriffe als von 172.16.3.99 kommend sehen.

Ich glaub, ich spinne :-) Auf einmal geht's! Ich hatte heute schon mal ein 1:1 NAT ausprobiert, die Regel sogar deaktiviert und jetzt nur noch aktiviert – und plötzlich funktioniert es.

Ich habe jetzt bei Phase 2 auch das Client-VLAN angegeben, aber ich glaube, das kann ich weglassen, oder?

Kurze Frage: Warum funktioniert so etwas nicht mit Outbound NAT? Ich hätte nämlich gedacht, dass das der richtige Weg wäre und nicht über ein 1:1 NAT.

[viragomann]

Ich habe jetzt bei Phase 2 auch das Client-VLAN angegeben, aber ich glaube, das kann ich weglassen, oder?

Es bringt nix, wenn es nicht auf der Remoteseite auch eingerichtet ist. Und wie oben angemerkt, die Remoteseite sieht jetzt nur die NAT-IP.

Kurze Frage: Warum funktioniert so etwas nicht mit Outbound NAT? I

Outbound NAT-Regeln werden am ausgehenden Interface angewandt. IPSec im Tunnelmodus hat allerdings kein Interface in dem Sinn, es läuft im Betriebssystem-Kernel ab.
Die Frage, warum es dennoch im Outbound NAT angeboten wird, kann ich aber nicht beantworten.

Und was nun 1:1 NAT da anders macht, weiß ich auch nicht. Kann nur vermuten, dass es das Masquerading vor dem Kernel erledigt.
Diese Methode wird jedenfalls in der OPNsense Doku beschrieben. Wenn du nach "NAT before IPSec suchst", solltest du es finden.

[Oachkatze]

Ich habe jetzt bei Phase 2 auch das Client-VLAN angegeben, aber ich glaube, das kann ich weglassen, oder?

Es bringt nix, wenn es nicht auf der Remoteseite auch eingerichtet ist. Und wie oben angemerkt, die Remoteseite sieht jetzt nur die NAT-IP.

Kurze Frage: Warum funktioniert so etwas nicht mit Outbound NAT? I

Outbound NAT-Regeln werden am ausgehenden Interface angewandt. IPSec im Tunnelmodus hat allerdings kein Interface in dem Sinn, es läuft im Betriebssystem-Kernel ab.
Die Frage, warum es dennoch im Outbound NAT angeboten wird, kann ich aber nicht beantworten.

Und was nun 1:1 NAT da anders macht, weiß ich auch nicht. Kann nur vermuten, dass es das Masquerading vor dem Kernel erledigt.
Diese Methode wird jedenfalls in der OPNsense Doku beschrieben. Wenn du nach "NAT before IPSec suchst", solltest du es finden.

Dann sage ich mal vielen Dank :-) und wünsche dir noch eine schöne Weihnachtszeit

Grüße aus Tirol

[viragomann]

Freut mich, dass es, wie gewünscht, hinhaut.

Wünsche auch schöne Feiertage.

Grüße aus'm Osten, NÖ