Routing von VPN zu VPN zu VPN :)
-
Moin,
Danke für die Antwort, dachte ich mir schon.
Unter VPN-IPsec-Tunel-Phase2 habe ich NAT/BINAT translation "Adress" mit der IP 192.168.0.1 ausgewählt.
So geht es leider nicht.Was muss ich bei NAT einstellen?
Oder muss ich unter Firewall–-NAT etwas eintragen?
-
Wenn ich mich recht entsinne, dann musst du bei Outbound NAT für dein LAN Interface konfigurieren, dass Pakete von 192.168.3.0/24 auf Interface LAN auf die Interface Address gemappt werden. Das sollte es eigentlich sein.
-
Hallo,
nein, leider war ich damit nicht erfolgreich.
Ich habe Outbound NAT wie folgt eingestellt:
Interface LAN
Source 192.168.3.0/24
DEST any
NAT Adress: LAN AdressHabe es auch mit Interface IPsec und static Port versucht.
Alles ohne Erfolg -
DEST hätte ich jetzt die 10.0.0.0/24 vom Zielnetz erwartet?
was sagt denn ein TCPDump / packet capture auf der pfSense? Wie kommen die Pakete via IPSec an? Und wie gehen sie auf das LAN raus?
-
DEST 10.0.0.0 hatte ich auch versucht. Dachte mir aber bei any ist es auch mit dabei
Werde mal ein CAP starten
-
Stimmt natürlich. Deine Einstellungen sind:
- Outbound NAT
- Interface LAN
- Protocol any
- Source: 192.168.3.0/24
- Destination: any
- Address: Interface Address
-> das wäre mein Ansatz gewesen. Wir machen das momentan für einen Kunden ähnlich allerdings umgekehrt. Er wählt sich mit OpenVPN Clients bei uns ein und wird über seinen eigenen IPsec Tunnel zu sich ins Office Netz geroutet. Stellenweise ging das sogar noch weiter zu AWS. Deshalb sollte das eigentlich schon funktionieren…
-
ja, genauso.
Habe jetzt auf DEST 10.0.0.0 umgestellt.
Hier mein CAP mit Filter auf ICMP
CAP vom LAN
13:59:20.829563 00:0d:b9:44:f5:15 > 00:a0:f9:42:7e:a0, ethertype IPv4 (0x0800), length 42: (tos 0x0, ttl 64, id 58627, offset 0, flags [none], proto ICMP (1), length 28)
192.168.0.1 > 192.168.0.254: ICMP echo request, id 20991, seq 22093, length 8
13:59:20.829731 00:a0:f9:42:7e:a0 > 00:0d:b9:44:f5:15, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 63, id 29587, offset 0, flags [none], proto ICMP (1), length 28)
192.168.0.254 > 192.168.0.1: ICMP echo reply, id 20991, seq 22093, length 8
13:59:21.361566 00:0d:b9:44:f5:15 > 00:a0:f9:42:7e:a0, ethertype IPv4 (0x0800), length 42: (tos 0x0, ttl 64, id 43883, offset 0, flags [none], proto ICMP (1), length 28)
192.168.0.1 > 192.168.0.254: ICMP echo request, id 20991, seq 22094, length 8
13:59:21.361742 00:a0:f9:42:7e:a0 > 00:0d:b9:44:f5:15, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 63, id 29588, offset 0, flags [none], proto ICMP (1), length 28)
192.168.0.254 > 192.168.0.1: ICMP echo reply, id 20991, seq 22094, length 8CAP IPsec
13:58:00.670720 (authentic,confidential): SPI 0xc9b159a6: (tos 0x0, ttl 64, id 33140, offset 0, flags [none], proto ICMP (1), length 128)
192.168.3.1 > 10.0.0.1: ICMP echo request, id 1024, seq 37708, length 108
13:58:01.634234 (authentic,confidential): SPI 0xc9b159a6: (tos 0x0, ttl 64, id 33146, offset 0, flags [none], proto ICMP (1), length 128)
192.168.3.1 > 10.0.0.1: ICMP echo request, id 1024, seq 37908, length 108
13:58:02.658749 (authentic,confidential): SPI 0xc9b159a6: (tos 0x0, ttl 64, id 33155, offset 0, flags [none], proto ICMP (1), length 128)
192.168.3.1 > 10.0.0.1: ICMP echo request, id 1024, seq 38308, length 108
13:58:03.637518 (authentic,confidential): SPI 0xc9b159a6: (tos 0x0, ttl 64, id 33161, offset 0, flags [none], proto ICMP (1), length 128)
192.168.3.1 > 10.0.0.1: ICMP echo request, id 1024, seq 38508, length 108
13:58:04.659020 (authentic,confidential): SPI 0xc9b159a6: (tos 0x0, ttl 64, id 33165, offset 0, flags [none], proto ICMP (1), length 128)
192.168.3.1 > 10.0.0.1: ICMP echo request, id 1024, seq 38608, length 108Für mich sieht es so aus, ob auf dem Rückweg das Packet verschwindet :)
-
Ist das beide Male der gleiche Ping? Eigentlich müsste dann ja im ersten CAP schon das Ziel 10.0.0.1 sein, oder? Das irritiert mich gerade etwas.
-
du hast recht. Ich kann das ja leider nicht gleichzeitig machen ;)
jetzt aber:
CAP vom LAN
16:15:44.161450 00:0d:b9:44:f5:15 > 00:a0:f9:42:7e:a0, ethertype IPv4 (0x0800), length 142: (tos 0x0, ttl 63, id 391, offset 0, flags [none], proto ICMP (1), length 128)
192.168.0.1 > 10.0.0.1: ICMP echo request, id 34859, seq 52220, length 108
16:15:44.190036 00:a0:f9:42:7e:a0 > 00:0d:b9:44:f5:15, ethertype IPv4 (0x0800), length 142: (tos 0x0, ttl 126, id 24262, offset 0, flags [none], proto ICMP (1), length 128)
10.0.0.1 > 192.168.0.1: ICMP echo reply, id 34859, seq 52220, length 108CAP IPsec
16:13:34.411762 (authentic,confidential): SPI 0xc9b59192: (tos 0x0, ttl 64, id 65481, offset 0, flags [none], proto ICMP (1), length 128)
192.168.3.1 > 10.0.0.1: ICMP echo request, id 1024, seq 42920, length 108
16:13:35.411497 (authentic,confidential): SPI 0xc9b59192: (tos 0x0, ttl 64, id 65491, offset 0, flags [none], proto ICMP (1), length 128)
192.168.3.1 > 10.0.0.1: ICMP echo request, id 1024, seq 43020, length 108
16:13:36.411528 (authentic,confidential): SPI 0xc9b59192: (tos 0x0, ttl 64, id 65496, offset 0, flags [none], proto ICMP (1), length 128)
192.168.3.1 > 10.0.0.1: ICMP echo request, id 1024, seq 43220, length 108Sieht trotzdem so aus, als würde der reply verschluckt werden.
-
ich glaube ich muss static port aktivieren bei NAT.
Geht damit aber auch noch nicht.Muss ich vielleicht im VPN Phase 2 noch was ändern?
-
Hmm OK das sieht mir dann so aus, als würde er nicht NATten… und du bekommst dann keine Antwort, weil die Rückroute fehlt. Andere Frage: Kannst du in die State Table schauen? Hier müsste es für das Ziel 10.0.0.1 ja dann mehrere States geben (bspw. von 192.168.0.1) wo auch zu sehen sein sollte, ob bspw. genattet wird oder nicht. Ich muss nochmal nachforschen wo es da haken könnte...
-
folgendes finde ich da:
mit static port bei outbound NAT
IPsec icmp 192.168.3.1:1024 -> 10.0.0.1:1024 0:0 29 / 29 4 KiB / 4 KiB
LAN icmp 192.168.0.1:7221 (192.168.3.1:1024) -> 10.0.0.1:7221 0:0 29 / 29 4 KiB / 4 KiBohne static port:
IPsec icmp 192.168.3.1:1024 -> 10.251.74.1:1024 0:0 40 / 40 5 KiB / 5 KiB
LAN icmp 192.168.0.1:31276 (192.168.3.1:1024) -> 10.251.74.1:31276 0:0 40 / 40 5 KiB / 5 KiB -
das sieht aber im State so aus, als würde er korrekt das .3.1 in .0.1 umwandeln und NATten. Allerdings verstehe ich den zweiten Eintrag darunter nicht -> wo kommt da plötzlich die .221 her?
-
.221 war ein c&p Fehler ;)
Wo verschwindet dann das Paket?