[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

IPsec, Strongswan und Side-to-Side



Hallo,

Ich habe ein Problem mit einem Side-to-side-VPN über IPsec und
Strongswan auf Debian stable.

Der Tunnel funktioniert eigentlich korrekt. Das linke Netz kann auf das
rechte Netz ohne Probleme zugreifen. Das Problem ist aber, wenn ich vom
Gateway, also von einem Tunneleingänge, auf das rechte Netz zugreifen
möchte, geht dieses in einen Timeout -- es sieht so aus, wenn ich
traceroute trauen darf, dass die Pakete nicht in den Tunnel geleitet
werden, sondern über das normale Netz nach außen geleitet werden.

Ethernet ist wie folgt konfiguriert:
eth0 - internes, locales Netz -> links subnet
eth1 - lokales Netz als Defaultgateway hinter NAT
eth2 - öffentliches Interface für Tunnel

Nicht so richtig schön. Hatten aber Probleme den Tunnel über Nat
aufzubauen. Wenn hier also jemand ein Vorschlag hat, würde ich mich auch
freuen.

Das linke Netz ist im Grunde 10.164.0.0/16, der Gateway, also der
Rechner mit dem Eingang zum Tunnel ist die 10.164.0.1

Das rechte Netz ist über eine öffentliche IP zu erreichen. Die dahinter
liegende Maschine kümmert sich um das Routing.

Hier mal mein aktuelles Setup um unnötige private Daten und
auskommentierte Punkte bereinigt ;)

config setup
        plutodebug=control
        plutostderrlog=/var/log/pluto.log
conn %default
        keyexchange=ikev1
        authby=secret
        dpdaction=restart
        dpdtimeout=60
conn net-net
        leftsourceip=10.164.0.1
        leftsubnet=10.164.0.0/16
        leftfirewall=yes
        rightsubnet=xx.xx.xx.0/22
        also=host-host
        auto=route
conn net-host
        rightsubnet=xx.xx.xx.0/22
        also=host-host
conn host-net
        leftsubnet=10.164.0.0/16
        also=host-host
conn host-host
        right=xx.xx.xx.xx
        left=xx.xx.xx.xx

Hat wer von Euch eine Idee, wie man das noch verbessern kann? Lösung 1
wäre, dass der Gateway auch mit dem rechten Netz reden kann, ohne die
Pakete durch 0.0.0.0/0 -> eth1 zu senden. Eine Lösung über eth1 und das
darauf stattfindende NAT wäre aber auch cool.


Gruß Frank


Reply to: