OpenSwan: Nur Probleme... (Routing läuft schief)

[Criena]

Hallo zusammen.

Ich stehe vor einem Problem und weiß nach drei Tagen googeln und Doku wälzen nicht mehr weiter. Es wäre nett wenn jemand sein Know-How zur Problemlösung einsetzen würde.

Folgendes Szenario:

Code: Alles auswählen

Netz1 - Sarge (Linux 2.6.8 + OpenSwan) <--> IPCop (v1.4.6, OpenSwan mit KLIPS) - Netz2

Von Netz2 aus ist alles in Netz1 vollständig erreichbar. Von Netz1 aus läßt sich Netz2 wunderbar pingen; sndere Verbindungen (TCP) kommen aber nicht zustande. Und genau das ist mein Problem.

Ein bißchen Sniffen hat ergeben, daß die Pakete von Netz1 in Netz2 wandern und dort vom angesprochenen Rechner auch beantwortet werden. Der IPCop schickt die Antworten an Sarge aus Netz1, dort gehen sie dann verloren. Die Antworten kommen also nicht beim Client in Netz1 an.

Laut Logdateien werden keine Pakete verworfen. Da die Firewall stateful ist, sollte es aber auch keine diesbezüglichen Probleme geben.

Ich weiß leider nicht mehr weiter. Es hapert schon daran, wo ich überhaupt suchen muß. Ich hoffe jemand hat den rettenden Einfall.

Grüße,
Criena

P.S. Bisher funktionierte die Kopplung mit Woody und unverändertem IPCop einwandfrei (das zum Thema "never touch a running system"). Extrem ungewohnt war bei der Umstellung das Fehlen von ipsec0, vielleicht liegt da der Hund begraben?

[mistersixt]

Als ich meine VPNs von FreeSwan auf OpenSwan umstellte, hatte ich immer ein heftiges MTU-Problem: ich konnte zwar TCP-Connects machen (mach doch mal ein "telnet pc-im-anderen-netz 22" um zu sehen, ob wirklich gar kein TCP geht), aber wenn ein paar Daten geflossen sind, hat sich die TCP-Verbindung aufgehängt. Was gebracht hat ist ein:

Code: Alles auswählen

/sbin/ip route add A.B.C.D via E.F.G.H mtu 1412

A.B.C.D ist das GW vom anderen Netz, E.F.G.H das GW vom eigenen Netz. Diesen Tip mit dem ip route habe ich mal vom Herbert Xu bekommen, früher mal Debian-Kernel-Packager, jetzt Linux-Kernel- und OpenSwan-Entwickler.

Kann das bei Dir evlt. auch der Fall mit der falschen MTU-Size sein?

Gruss, mistersixt.

PS: "ip" ist im Paket "iproute", also "apt-get install iproute".

[Criena]

Denke nicht das das problem bei der MTU liegt, in die andere Richtung läuft ja alles einwandfrei. Habe es aber dennoch mal ausprobiert, leider ohne Erfolg. Ich habe auch nicht das Problem, daß Verbindungen abbrechen, sondern in besagter Richtung kommen sie gar nicht zu Stande, da Sarge sie IMHO nicht weiterleitet

[mistersixt]

Tja, dann fällt mir leider so von remote auch erstmal nix mehr ein - ausser halt tonnenweise Log-Meldungen beim iptables eintragen und weitersniffen, um zu sehen, wo die Pakete verschwinden. Ich habe einige VPNs mit OpenSwan und 2.6.8 laufen, bis auf das erwähnte MTU-Problem (wobei es kein Problem mehr ist, wenn man weiss, dass man eine Extra-Route eintragen muss) loift es quasi einwandfrei.

Gruss, mistersixt.

[Criena]

Ok, Problem gelöst. Nachdem ich nochmal mit anderen Regeln gesnifft hatte, kamen neue Erkenntnisse ans Licht. Die führten mich zu identischen Problembeschreibungen und letztlich zur Lösung.

Es war ein NAT Problem. Ich hatte oben ja bereits geschrieben, daß keine Antwortpakete beim Client ankamen. Das war so nicht ganz richtig, sie kamen an. Allerdings nicht vom korrekten Port. Das brachte mich dann auf die Idee, daß es sich wohl um ein NAT Problem handelt. Und siehe da, ein einfaches

Code: Alles auswählen

iptables -A POSTROUTING -p esp -j ACCEPT -t nat

brachte die Lösung.

Auf jden Fall danke für die Unterstützung!

[mistersixt]

Auf jden Fall danke für die Unterstützung!

Ich trinke ein Veltins !

Gruss, mistersixt