IPSec passthrough an-/abschalten

[gm]

Hallo,

aus der Produktdoku und dem Forum hier geht für meine Begriffe hervor, daß LANCOM Router (z.B. LC1724, LCOS 6.28 ) "IPSec passthrough" beherrschen.
Gibt's eine Möglichkeit diese Funktion gezielt an- bzw. abzuschalten?

Szenario:
Road-Warrior (192.168.2.X/24) <-----> LC10-I-DSL (NAT-Router, Clientseite) <-----> Internet <-----> LC1724 (NAT-Router, Serverseite) <-----> Openswan (192.168.3.2/24) <-----> Internes LAN

Der LC1724 leitet die UDP-Ports 500 und 4500 an den Openswanserver 192.168.3.2 weiter. Der Server hängt an einem Netzwerkport des Routers, der als DMZ konfiguriert wurde.
Es kommt eine stabile Verbindung zwischen Client und Server zu stande. Auch die Datenübertragung vom Server zu den Clients funktioniert tadellos (z.B. größerer FTP-Download). Das Problem ist "nur", daß Datenpakete (IPSec, UDP-Encap) von den Clients mit mehr als ca. 240 Byte auf dem Server eine Fehlermeldung erzeugen.
Ist es vielleicht möglich, daß sich der LANCOM Router ab einer bestimmten IPSec-Paketgröße (UDP-Encap) plötzlich anderes verhält (im Bezug auf das Weiterleiten der Pakte)? Habe nämlich ab einer Paketgröße von ca. 240 Byte (wenn sie vom Client kommen) recht komische Meldungen im Log von OpenSwan:
"12:50:31 srvipsec pluto[23345]: packet from 84.147.104.102:4500: recvfrom 84.147..104102:4500 has no Non-ESP marker"
Datenpakete oberhalb diese Größe erzeugen die genannte Meldung und gehen verloren, da sie für Openswan scheinbar nicht gültig sind. Wenn ich den Roadwarrior testhalber direkt an das DMZ-Netz anschließe und mich auf den IPSec-Server verbinde funkioniert alles 1a.

Deshalb möchte ich jetzt zunächst mal sicherstellen, daß der LANCOM-Router nur folgendes macht (und nicht mehr):
- 1:1 Weiterleitung der beiden UDP-Port's 500 und 4500 (Habe ich in die Portforwarding-Tabelle eingetragen, denke das stimmt auch so, sonst würde gar nichts gehen)
- kein IPSec-Passthrough

Vielen Dank für Eure Hilfe.

Grüße
Gerhard Massenbichler

[backslash]

Hi gm

Deshalb möchte ich jetzt zunächst mal sicherstellen, daß der LANCOM-Router nur folgendes macht (und nicht mehr):
- 1:1 Weiterleitung der beiden UDP-Port's 500 und 4500 (Habe ich in die Portforwarding-Tabelle eingetragen, denke das stimmt auch so, sonst würde gar nichts gehen)

das reicht aus, das LANCOM mischt sich da auch gar nicht ein.

- kein IPSec-Passthrough

IPSec-Passthrough wird hier gar nicht verwendet, da beide beteiligten NAT-T machen.

Das einzige, was IPSec-Passthrough überhaupt macht, ist in dem Fall, indem die beteiligten kein NAT-T machen, die ESP-Pakete korrekt weiterzuleiten. Es werden keine Pakete verändert.

Meldungen im Log von OpenSwan:
"12:50:31 srvipsec pluto[23345]: packet from 84.147.104.102:4500: recvfrom 84.147..104102:4500 has no Non-ESP marker"
Datenpakete oberhalb diese Größe erzeugen die genannte Meldung und gehen verloren, da sie für Openswan scheinbar nicht gültig sind

da macht der Roadwarrior offenbar einen Fehler und untertützt NAT-T nicht korrekt.

Wenn ich den Roadwarrior testhalber direkt an das DMZ-Netz anschließe und mich auf den IPSec-Server verbinde funkioniert alles 1a.

Dann geht's auch nicht durch die NAT-Router und es wird kein NAT-T gemacht...

Versuch doch einfach mal beim Road-Warrior (oder wenn das nicht geht beim OpenSWan) NAT-T zu deaktivieren

Gruß
Backslash

[gm]

Hallo Leute,

nur falls jemand anders auch Probleme mit NAT-T in Verbindung mit OpenSwan hat, bitte folgendes lesen. Der Router, LANCOM 1724 in meinem Beispiel, war an dem Problem gar nicht schuld. Ursache ist ein Bug im Linux-Kernel:

Der folgende Patch ist im Linux-Kernel ab 2.6.19 enthalten und behebt das von mir beschriebene Problem. Es tritt nur bei Intelnetzwerkkarten (e1000-Treiber) auf der OpenSwan-Seite mit NAT-T (UDP-Encap.) auf:

commit 3cb204502cafebf346cdb7d7db750811550fa53c
Author: Olaf Kirch <okir@suse.de>
Date: Tue Nov 28 20:36:46 2006 -0800

[PATCH] UDP: Make udp_encap_rcv use pskb_may_pull

IPsec with NAT-T breaks on some notebooks using the latest e1000 chipset,
when header split is enabled. When receiving sufficiently large packets, the
driver puts everything up to and including the UDP header into the header
portion of the skb, and the rest goes into the paged part. udp_encap_rcv
forgets to use pskb_may_pull, and fails to decapsulate it. Instead, it
passes it up it to the IKE daemon.

Signed-off-by: Olaf Kirch <okir@suse.de>
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>


...Linux-Kernel-Patch einspielen und alles läuft wie geschmiert. Bei mir synct jetzt nur der LANCOM-Router noch zu oft mit dem Infineon-DSLAM, als daß ich die Verbindung wirklich brauchen könnte, aber das wird sicher mit den neuen Firmwares für den LANCOM besser werden (hoffe ich).


Viele Grüße
Gerhard Massenbichler