Strongswan Konfigurationsfrage Site-to-Site

Hallo Zusammen,

ich habe folgende VPN-Tunnel zu realisieren:

Niederlassung A <---- LAN 192.168.1.0/24 ----> VPN Server A ( 192.168.1.243) <----> Router (192.168.1.1 | statische IP aaa.aaa.aaa.aaa)<--- Internet --->VPN Server B (IP bbb.bbb.bbb.bbb) <--- LAN 192.1.254.0/24 ---> Head Office

Das Head Office möchte dass der Server ein SNAT auf der IP 192.168.44.24 macht. Ich habe dem VPN Server A noch die IP 192.168.44.24 auf eth0:0 gebunden und IP_FORWARD ist aktiviert. Ist der Ansatz so richtig oder besser ein Device ipsec0 vom Typ xfrm anlegen?

Die entscheidenden Parameter in der ipsec.conf lauten:
left=aaa.aaa.aaa.aaa
leftsubnet=192.168.1.0/24
leftsourceip=192.168.44.24
leftfirewall=yes
right=bbb.bbb.bbb.bbb
rightsubnet=192.1.254.0/24

Der Tunnel baut sich aber nicht auf, denn der Fehler lautet:
[NET] error writing to socket: Network is unreachable

Hat jemand eine Idee?

Besten Dank,
Roadmax

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 666303

Url: https://administrator.de/forum/strongswan-konfigurationsfrage-site-to-site-666303.html

Ausgedruckt am: 02.01.2025 um 22:01 Uhr

2 Kommentare

Neuester Kommentar

Dein Grundproblem ist zuallererst der nicht etablierte IPsec Tunnel ! Bevor du also alles andere machst musst du das erstmal fixen. Also strategisch vorgehen und den Tunnel zum Testen erstmal manuell aufbauen (auto=add) und erstmal eine einfach Standard Konfig nutzen.
Sehr wahrscheinlich wird dein Server "VPN B" wohl der IPsec Responder sein und der Server "VPN A" hinterm NAT Router der Initiator, richtig ? Leider ist da deine o.a. Beschreibung wie auch Log Outputs und Inhalt der Konfig Dateien sehr lückenhaft und zwingt uns hier zum Raten.

Eine sehr einfache IKEv2 Konfigdatei ipsec.conf für einen IKEv2 Site 2 Site Tunnel die fehlerfrei rennen sollte, sieht dann für beide Tunnelenden so aus:

VPN Server A (Initiator hinter NAT Router):

conn s2s
  keyexchange=ikev2
  authby=secret
  ike=aes256-sha256-modp2048
  esp=aes256-sha256-modp2048
  type=tunnel
  auto=add
  right=bbb.bbb.bbb.bbb 

Die Datei ipsec.secrets für den PSK sieht dann ganz einfach so aus:

: PSK "geheim1234"

VPN Server B (Responder):

conn s2s
    fragmentation=yes
    keyexchange=ikev2
    type=tunnel
    authby=secret
    rightsubnet=192.168.1.0/24
    auto=add 

Die PSK Datei ist identisch zu oben.
Soll der Server B auch gleichzeitig Intitiator sein musst du ein "right=aaa.aaa.aaa.aaa" der Konfig hinzufügen.

Wenn die Konfig so (oder so ähnlich) eingegeben ist, machst du auf beiden Seiten ein:
ipsec restart
Dann baust du mit
ipsec up s2s
manuell den Tunnel auf der Initiator Seite auf und siehst dir mal die Konsolen Messages dazu an.
Auf dem Responder findest du die IPsec Messages in /var/log/syslog.
Der Tunnel sollte dann mit einem
CHILD_SA s2s{1} established with SPIs ca9f7930_i c074d734_o and TS 192.168.1.243/32 === bbb.bbb.bbb.bbb/32
received AUTH_LIFETIME of 9911s, scheduling reauthentication in 9371s
connection 's2s' established successfully
erfolgreich aufgebaut werden.
Ein ipsec status sollte dann sowas zeigen:

 root@debiansrv:/etc# ipsec status
Security Associations (1 up, 0 connecting):
         s2s[1]: ESTABLISHED 11 seconds ago, 192.168.1.243[192.168.1.243]...bbb.bbb.bbb.bbb[bbb.bbb.bbb.bbb]
         s2s{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: ca9f7930_i c074d734_o
         s2s{1}:   192.168.1.243/32 === bbb.bbb.bbb.bbb/32 

Auf dem Responder kannst du jetzt die lokale LAN IP Adresse des Initiators 192.168.1.243 pingen.

Erst dann kannst du mit dem Rest weitermachen...
Dazu solltest du dann oben mal klären WIE genau die Connection der Server ins Internet aussieht ? Sprich ob dort noch ein NAT Router beidseitig dazwischen ist oder die Server direkt im Internet exponiert sind und selber als Router agieren und auch wer Initiator und Responder ist. Auch das ist aus der etwas oberflächlichen Zeichnung oben leider nicht wirklich ersichtlich.

Zu dem Thema das du für dich nicht registrierte IP Netze nutzt (192.1.254.0 /24 und gehört der Fa. BBN Communications in den USA) erstmal gar nicht zu reden. Oder ist das ein Tippfehler im Eifer des Gefechts ?!