strongswan VPN site-to-site und mobile Clients

Ein freundliches HALLO in die Runde!

Ich habe folgende Konstallation:
Site A (Lancom-Router) ist mit Site B (strongswan) per VPN (IKEv1) verbunden, das läuft A sieht B und umgekehrt.
Die Verbindung mobiler Clients (IKEv2) erfolgt nach Site B, auch das läuft ebenfalls, ich kann alle Netze/Hosts an Site B erreichen.
Weiterhin erreiche ich vom Gateway in Site B (ist auch der VPN Server) alle Hosts an Site A.

Was nicht geht:
Der mobile Client soll auch Site A erreichen.
Die Routen im Client sind gesetzt Gateway ist jeweils der in Site B, ein trace zeigt, das die Anfrage an das Gateway von Site B geht.
Clientseitige Anfragen auf das Netz von Site A werden meiner Meinung nach im Gateway B "falsch" geroutet, diese gehen in die weite Welt und nicht auf das Gateway von Site A.

Ich möchte im Prinzip eine VPN-Verbindung der mobilen Clients nach Site B, die es möglich macht, sowohl auf Site A als auch auf Site B zuzugreifen.
Da mir nicht wirklich etwas dagegen einfällt nun meine Bitte an Euch...

Besten Dank vorab!

Könntest Du in der Konfiguration der Netze (IP, Mask, Routen, Fehlermeldung) ein wenig konkreter werden?

Auf den ersten Blick sieht's nach einem einfachen Routing-Problem aus...

Routing ist auch mein Verdacht.

Site A: lokales Netz 192.168.0.0/23, GW: 192.168.0.254
Site B: lokales Netz 192.168.70.0/24, GW 192.168.70.1

Tunnel 192.168.0.0/23 === 192.168.70.0/24 (IKEv1)

mobile Clients:
nutzen Windows-VPN (IKEv2)
verbinden sich nach Site B
IP-Pool 10.9.3.0/24
Das läuft auch, ich erreiche 192.168.70.0/24.

ipsec.conf, Abschnitt für IKEv2:
leftsubnet 192.168.70.0/24, 192.168.0.0/23

Routen in Windows:
192.168.70.0 gw 10.9.3.1
192.168.0.0 gw 10.9.3.1

tracert in Windows nach 192.168.70.2:
1 192.168.70.1
2 192.168.70.2

tracert in Windows nach 192.168.0.2:
1 192.168.70.1
2 Zeitüberschreitung....

eine Route von 192.168.70.0 nach 192.168.0.0 existiert auf 192.168.70.1?
die Rück-Route gibt es auch?

ggf. auch mal au den jeweiligen Systemen schauen, wie der Traffic dort ankommt und prüfen, ob für die jeweilgen IPs auch passende Routing-Einträge vorhanden sind.

Hallo Marce,

das Routing an Site B macht der IPSec Dienst in Routingtabelle 220, da steht folgendes drin:

ip route show table 220
10.9.3.1 via <PUB-IP des mobilen Clients> dev ppp0 proto static src 192.168.70.1
192.168.0.0/23 via <PUB-IP des Routers an Site A> dev ppp0 proto static src 192.168.70.1

An Site B gefragt, wie geroutet wird passt auch:
ip route get 192.168.0.3 > Das ist ein Rechner an Site A hinter dem Gateway, der auch auf Pings antwortet
192.168.0.3 via <PUB-IP des Routers an Site A> dev ppp0 src 192.168.70.1

ein Trace ergibt:
tracepath 192.168.0.3
1?: [LOCALHOST] pmtu 1480
1?: [LOCALHOST] pmtu 1406
1: 192.168.0.254 27.388ms pmtu 1400
1: 192.168.0.254 27.190ms asymm 5
2: 192.168.0.3 28.134ms reached
Resume: pmtu 1400 hops 2 back 2

Ich meine, was von 10.9.3.0/24 kommt wird nicht korrekt in Richtung Site A geroutet.
Wenn ich direkt vom GW Site B nach Site B pinge sehe ich dies im Ergebnis und im Trace an Site A.
Von 10.9.3.0/24 kommt der Ping erst garnicht an Site A an.

Grüße

Thema gelöst!

Das Netz der mobilen Clients musste mit dem an Site A verbunden werden, also 10.9.3.0/24 === 192.168.0.0/23

An Site A den Rückweg definiert aud alles läuft wie gewünscht.
Im Prinzip genau das, was weiter oben schon gesagt wurde, das Routing wird nun vom IPSec Dienst definiert in Routingtabelle 220.


Besten Dank!