Routing von VPN zu VPN zu VPN :)

hilfi2000 · Mar 6, 2017, 8:50 PM

Hallo Freunde des Routings und IPsec,

folgende Umgebung habe ich:

LAN 192.168.3.0/24 IP: .1 IPsec über DSL .1 LAN 192.168.0.0/24 IP .254
Client –----------------> FW1(Juniper) ---VPN-zu-FW2--------FW2-------------------------------VPN-Router (nicht in meiner Hoheit)
IP .150 | |
| |----------Client IP .150
|
|
|
FW-Dienstleiter (nicht in meiner Hoheit)
| LAN 10.0.0.0/24
|
|
Server .100

Kurze Erläuterung:

Auf FW2 läuft pfSense, die FW1 ist noch eine alte Juniper Netscreen Appliance.
Der VPN Router und die Firewall-Dienstleiter gehöhren einem Dritten, ich habe keinen Zugriff.

Vom LAN 192.168.0.0/24 kann ich über den VPN Router auf das LAN des Dienstleisters 10.0.0.0/24 zugreifen. Dazu baut der VPN Router über meine FW2 eine VPN Verbindung zur FW des Dienstleisters auf. Auf der FW2 habe ich eine statische Route für das LAN 10.0.0.0/24 mit dem Gateway 192.168.0.254 hinterlegt.

Zwischen FW1 und FW2 ist auch ein IPsec VPN aufgebaut. Ich kann von beiden Seiten alle Clients erreichen.

Problem:
Jetzt möchte ich vom Netz 192.168.3.0/24 auf den Server 10.0.0.100 zugreifen.
Auf der Firewall (Juniper, FW1) habe ich dazu eine statische Route zum VPN Router eingerichtet (10.0.0.0/24 zu 192.168.0.254).
Wenn ich jetzt z.B. versuche den Server 10.0.0.100 per ping zu erreichen, sehe ich auf der Firewall im Log "Firewall", dass 192.168.3.150 eine ICMP Verbindung aufbauen möchte und die Firewall Rules das auch zulässt. Ich bekomme aber leider keine Antwort (Zeitüberschreitung...).

Ich muss dazu sagen, dass ich bis zum Wochenende an Stelle der pfSense auch eine Juniper Netscreen hatte. Mit dieser könnte ich mit dieser Konfiguration den Server 10.0.0.100 erreichen.

Wo kann ich noch nach Fehlern suchen bzw. habt ihr eine Idee?

Kann es sein dass der Dienstleister auf dem VPN Router eine weitere Phase 2 für das LAN 192.168.3.0 einrichten muss? (bin mir nicht sicher ob er das getan hat).
Aber warum ging es dann mit der "alten Juniper"???

Habe jetzt einen ganzen Tag geforscht, leider ohne Erfolg.

Ich hoffe eine von euch hat eine ähnliche Konfig und kann mir helfen.

Danke und VG
HilFi

JeGr · Mar 7, 2017, 10:29 AM

Wo kann ich noch nach Fehlern suchen bzw. habt ihr eine Idee?

Jep. Du musst dein Netz .3.0/24 maskieren (NAT) damit als abgehende Adresse beim Dienstleister im 10.0.0.0er Netz eine 192.168.0.x Adresse auftaucht. Deren VPN Router bei dir (.254) kennt dein .3.0er Netz nicht und hat logischerweise keine Rückrouten dafür. Entweder du sagst ihm, dass er .3.0 auch zurückrouten soll, oder du maskierst deine .3.0er Adressen wenn sie nach 10.x wollen mit der IP der pfSense, also der .0.1

Grüße

hilfi2000 · Mar 7, 2017, 10:36 AM

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?

JeGr · Mar 7, 2017, 10:37 AM

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.

hilfi2000 · Mar 7, 2017, 11:11 AM

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 Adress

Habe es auch mit Interface IPsec und static Port versucht.
Alles ohne Erfolg

JeGr · Mar 7, 2017, 12:45 PM

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 · Mar 7, 2017, 12:47 PM

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 · Mar 7, 2017, 12:53 PM

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 · Mar 7, 2017, 1:03 PM

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 · Mar 7, 2017, 3:00 PM

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 · Mar 7, 2017, 3:19 PM

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 · Mar 7, 2017, 3:53 PM

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 · Mar 7, 2017, 4:04 PM

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 · Mar 7, 2017, 5:17 PM

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 · Mar 8, 2017, 10:05 AM

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 · Mar 8, 2017, 10:07 AM

.221 war ein c&p Fehler ;)

Wo verschwindet dann das Paket?