IPSEC VPN mit Remote Subnetz im public IP-Adressbereich wird nicht über vpn gero

[niklas_g]

Hallo zusammen,

ich stecke schon seit einigen Tagen bei einem Problem mit meiner IPsec VPN fest und hoffe, hier vielleicht Hilfe zu finden. Hier eine kurze Zusammenfassung meiner Konfiguration:

Remote Gateway: 185.181.20.20
Remote IPsec Subnetz: 194.138.39.16/29

Lokales Gateway: 91.106.127.15
Lokales eigentliches Subnetz: 192.168.10.0/24
Lokales IPsec Subnetz: 10.41.5.95/32 und 10.41.5.96/32

Die Adressen 10.41.5.95/32 und 10.41.5.96/32 sollen jeweils zu 192.168.10.95/32 bzw. 192.168.10.96/32 umgeschrieben werden und umgekehrt. Dies habe ich über Firewall->NAT->Outbound (Hybrid outbound)
   
Interface   Source       Source Port         Destination       Destination Port   NAT Address   
IPsec       192.168.10.95/32    *         194.138.39.16/29          *           10.41.5.95/32
IPsec       194.138.39.16/29    *         10.41.5.95/32          *           192.168.10.95/32

Die Firewall ist so eingestellt, dass sie ISAKMP und ESP für eingehende und ausgehende Verbindungen erlaubt. Die VPN-Verbindung selbst und die Phase 2 sind erfolgreich eingerichtet. Mein Problem ist jetzt, dass der Traffic, der zum Subnetz 194.138.39.16/29 gehen sollte, nicht über die VPN läuft. Ich habe versucht, Firewall-Regeln mit dem Gateway 185.181.20.20 zu erstellen, aber es sieht so aus, als würden keine ESP-Pakete gesendet werden. Auch manuelle SPD-Einträge mit dem lokalen Subnetz als Quelle und dem Remote-Netz als Ziel haben nichts gebracht.

Ich habe schon online gesucht, aber keine Lösung für mein Problem gefunden. Hat jemand von euch vielleicht eine Idee oder einen Tipp, was ich noch versuchen könnte? Ich bin für jede Hilfe unglaublich dankbar!

[viragomann]

Hallo!

Die Adressen 10.41.5.95/32 und 10.41.5.96/32 sollen jeweils zu 192.168.10.95/32 bzw. 192.168.10.96/32 umgeschrieben werden und umgekehrt.

Was ist der Sinn der Sache?

Du möchtest ein NAT auf der Verbindung einrichten, so dass nur die beiden Hosts 192.168.10.95/32, 192.168.10.96/32 aus deinem LAN mit den jeweiligen Masquerading-IPs auf das Remote-Netz zugreifen können?
Und die Remote-Seite auch nur auf die beiden IPs?

Ist das Tunnel Mode (policy-based) oder VTI?

Wie sehen die Phase 2 aus?

Mein Problem ist jetzt, dass der Traffic, der zum Subnetz 194.138.39.16/29 gehen sollte, nicht über die VPN läuft.

Hast du das überprüft? Wie?

[niklas_g]

Hi!
Warum man öffentliche IPs nur über eine VPN erreichbar macht erschließt sich mir selbst nicht, ist aber vorgabe des Anbieters. Das NAT kommt daher, dass beim Anbieter das echte Netzwerk schon verwendet wird. Da ich die Betreuung auch nur übernommen habe ist es aktuell nicht möglich das LAN Netz zu ändern, da es zu viele kosten verursachen würde.

Sinn ist, dass die gegenstelle von 194.138.39.16/29 kommend über die VPN auf entweder 10.41.5.95/32 oder 10.41.5.96/32 zugreifen kann und die beiden echten Hosts 192.168.10.95/32 bzw 192.168.10.96/32 Daten an 194.138.39.16/29 pushen können.
Abgesehen davon soll keine Kommunikation möglich sein.

Die VPN ist im Tunnel Mode.
Phase 2 ist installed, welche Informationen brauchst du genau?

Hast du das überprüft? Wie?

Überprüft habe ich das mit einem tcpdump. Wenn ich versuche das Netz zu erreichen verlassen die Pakete das WAN Interface. Meiner meinung nach müssten die Pakete über enc0 (IPSEC) Interface laufen und auf WAN Seite nur noch ESP-Pakete zu sehen sein mit dem remote GW als Ziel und nicht dem angepingtem Host.

[Patrick M. Hausen]

Auf der Seite, auf der geNATet werden soll, brauchst du einen manuellen SPD-Eintrag, weil die IPsec Policy vor NAT greift und die Pakete daher nicht in den Tunnel geleitet werden. VPN > IPsec > Security Policy Database > Manual.

Über die ReqID verbindest du diesen manuellen Eintrag mit der Phase 2 SA, die du ja schon definiert hast.
Bei Source Network trägst die ungeNATeten IP-Adressen auf deiner Seite ein, bei Destination Network nichts, dann wird das aus der SA übernommen.

[niklas_g]

Auf der Seite, auf der geNATet werden soll, brauchst du einen manuellen SPD-Eintrag, weil die IPsec Policy vor NAT greift und die Pakete daher nicht in den Tunnel geleitet werden. VPN > IPsec > Security Policy Database > Manual.

Über die ReqID verbindest du diesen manuellen Eintrag mit der Phase 2 SA, die du ja schon definiert hast.
Bei Source Network trägst die ungeNATeten IP-Adressen auf deiner Seite ein, bei Destination Network nichts, dann wird das aus der SA übernommen.

Aktuell kann ich es nicht testen, da jetzt blöderweise die Peer Seite offline ist.

Nochmal zum verständnis:
Die ReqID aus Phase 2 muss mit der ReqID aus der SPD übereinstimmen?`
Wäre das dann so richtig wie hier auf den Screenshots?
You cannot view this attachment.You cannot view this attachment.

[Patrick M. Hausen]

Sieht für mich erstmal sinnvoll aus.

[niklas_g]

Hier mal ein Paar Sreenshots meiner Konfiguration. Vielleicht liegt es an den NAT Regeln?
Habe das vorher immer auf der CLI mit iptables gemacht, das ist mir leichter gefallen als hier über die grafische Oberfläche.

Phase 2
You cannot view this attachment.
NAT
You cannot view this attachment.
SPD
You cannot view this attachment.
You cannot view this attachment.

[Patrick M. Hausen]

Was liegt an den NAT Regeln? Was ist denn der Status? Du hast noch nicht berichtet, ob die manuellen SPD-Einträge denn nun geholfen haben oder nicht.

[niklas_g]

Die SPD Regeln haben leider nichts gebracht. Der traffic mit Ziel 194.138.39.16/29 verlässt immernoch regulär das WAN Interface statts "eingepackt" in ESP Paketen.
Eine vermutung von mir war, dass die NAT Regeln falsch sind oder irgendwie nicht greifen was dazu führt, dass die Pakete nicht encapsulated werden.