Routing von VPN zu VPN zu VPN :)

JeGr

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?

hilfi2000

DEST 10.0.0.0 hatte ich auch versucht. Dachte mir aber bei any ist es auch mit dabei

Werde mal ein CAP starten

JeGr

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…

hilfi2000

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 8

CAP 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 108

Für mich sieht es so aus, ob auf dem Rückweg das Packet verschwindet :)

JeGr

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.

hilfi2000

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 108

CAP 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 108

Sieht trotzdem so aus, als würde der reply verschluckt werden.

hilfi2000

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?

JeGr

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...

hilfi2000

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 KiB

ohne 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

JeGr

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?

hilfi2000

.221 war ein c&p Fehler ;)

Wo verschwindet dann das Paket?