[Openswan Users] Openswan + RHES 2.6 IPSEC strange problem

Matt Dainty matt at xrefer.com
Fri Mar 26 17:11:38 CET 2004


Hi list,

I'm trying to use Openswan 2.1.1 on a Whitebox 3.0 (RHEL 3ES-alike)
system and I'm hitting a weird problem in usage.

I've built the userland RPM from the openswan26.spec file and this is
installed and running with no errors. I've turned off OE as I don't
want/need it. I have the ipsec-tools RPM installed, and the whole system
is up-to-date, running the 2.4.21-9.0.1.EL kernel.

I'm trying to create a simple X.509'd subnet<->subnet tunnel to a
FreeS/WAN ~1.99 box with the usual X.509 patches, NAT-T, etc. which has
been serving other connections for ages, nice and solid. Both boxen have
iptables firewalls and perform SNAT for external-bound traffic not
travelling through an IPSEC tunnel.

I can start up Openswan and the tunnel gets created, and I can ping
boxen back and forth from each side, but if I try and launch say an HTTP
request from a client on the Openswan side to a webserver in the
FreeS/WAN-protected network, the tunnel just freezes part-way through
the client receiving the content from the webserver.

I thought it was just Openswan until I realised all traffic on the same
NIC freezes too. It appears to take a random amount of time and other
non-IPSEC traffic and things unfreeze again. At no time is there any log
messages from the kernel or anywhere else. There are two other NICs in
the machine which are bridged together and these continue working
throughout.

Sniffing traffic on each endpoint from each other yields packets
occasionally from the FreeS/WAN end to the Openswan end:

Y.Y.Y.Y > X.X.X.X: ESP(spi=...,seq=...)
truncated-ip - 16 bytes missing! Y.Y.Y.Y > <some weird IP> bad-hlen 12
(ipip-proto-4)
X.X.X.X > Y.Y.Y.Y: ESP(spi=...,seq=...)

I wasn't sure what the issue was with 2.6 IPSEC + SNAT, I presumed it
was just a case of making sure the rules don't SNAT traffic destined
over a tunnel, I've sniffed the ping traffic between the subnets and no
SNAT is performed. I do the SNAT in the POSTROUTING chain in the nat
table, so presumably, it's already been encapsulated in ESP by then?
Someone please correct me if this issue is more serious than that.

Does anyone have any idea why this happens? I accept that this
particular combination is not terribly well tested.

Cheers

Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/users/attachments/20040326/60e77927/attachment.bin


More information about the Users mailing list