1821 VPN gateway + VPN client parallel verwenden

[djennerj]

Hallo allerseits,

habe einen Lancom 1821 als VPN gateway im Netz. Der Zugriff von außerhalb mittels Netgear ProSafe VPN client funktioniert. Nun soll zusätzlich aus dem internen Netz (über den Lancom Router) mittels Symantec VPN client auf ein Symantec VPN gateway zugegriffen werden. Der Symantec client ist in einer VMware-Instanz installiert. Der Tunnel wird erfolgreich aufgebaut, ein Ping scheitert jedoch. Im Trace sieht man folgendes:

[IP-Router] 2007/02/27 16:52:45,850
IP-Router Rx (LAN):
DstIP: 213.xxx.yyy.2, SrcIP: 192.168.2.107, Len: 112, DSCP/TOS: 0x00
Prot.: ESP (50), SPI: 8e1cd0b0, Seq: 00000028
Route: WAN Tx Peer: T_ONLINE

[VPN-Packet] 2007/02/27 16:52:45,900
received: 213.xxx.yyy.2->62.aaa.bbb.ccc 112 ESP SPI[44ae54cd]

[IP-Router] 2007/02/27 16:52:45,900
IP-Router Rx (T_ONLINE):
DstIP: 192.168.2.107, SrcIP: 213.xxx.yyy.2, Len: 112, DSCP/TOS: 0x00
Prot.: ESP (50), SPI: 44ae54cd, Seq: 0000002a
Route: LAN Tx

213.xxx.yyy.2->62.aaa.bbb.ccc ist interessant. Die (leicht veränderte 62.aaa.bbb.ccc entspricht der von uns verwendeten dynDNS IP-Adresse. Also versucht der Lancom, die VPN-Pakete umzuleiten?

Scheitert VPN-passthrough, wenn der Router auch als VPN gateway funktioniert? Habe auch mit NAT Traversal experimentiert. Kein Erfolg

Ihr seht: Habe nur wenig Ahnung, doch mittlerweile viel Zeit und Nerven investiert. Wenn jemand eine Antwort hat, schicke ich eine Tafel Schokolade

Vielen Dank,
Dirk

[backslash]

Hi djennerj

also laut dem Trace funktioniert doch alles: Dein Client versendet ein Paket an die 213.xxx.yyy.2. Das wird natürlich maskiert und verläßt das LANCOM mit der Absenderadresse 62.aaa.bbb.ccc 112 (kleine Anmerkung: hier ist ein ccc zuviel)...

Nun antwortet die Gegenseite und schickt das Paket natürlich an die Adresse inter der maskiert wird. Da das LANCOM ja auch selbst IPSec-Gateway ist, wird das Paket zunächst an den internen IPSec-Stack gegeben, der dann die Ausgabe

[VPN-Packet] 2007/02/27 16:52:45,900
received: 213.xxx.yyy.2->62.aaa.bbb.ccc 112 ESP SPI[44ae54cd]

erzeugt. Da der interne IPSec-Stack aber keine SA für das Paket hat, leitet er es weiter an die Demaskierung und das Paket taucht im Router-Trace auf:

[IP-Router] 2007/02/27 16:52:45,900
IP-Router Rx (T_ONLINE):
DstIP: 192.168.2.107, SrcIP: 213.xxx.yyy.2, Len: 112, DSCP/TOS: 0x00
Prot.: ESP (50), SPI: 44ae54cd, Seq: 0000002a
Route: LAN Tx

und der Router leitet es an deinen Client weiter.
Warum der Client diese Antwort nicht sieht, kann ich dir nicht sagen - das LANCOM jedenfalls verhält sich korrekt.

Gruß
Backslash

[djennerj]

Hi Backslash,

vielen Dank, Du hast mich auf die richtige Fährte gebracht! Der Router war nicht das Problem! Der Symantec client läuft in einer VMware-Instanz. Auf dem VMware host ist ein ProSafe client installiert. Dessen security policies scheinen bzgl. des bridged networkings zugeschlagen, sich die Pakete für das Gastsystem geschnappt zu haben. Ein Deaktivieren der Security Policies auf dem Host war die Lösung!

Und wo schicke ich jetzt Schokolade hin?

Saludos und Danke,
Dirk