[Openswan Users] KLIPS not responding to 348+ byte ESP-in-UDP packets?

[Toby Corkindale]

OK, I seem to have hit some rather wierd behaviour.

For this example, I have a 2.6.8.1 machine with native IPSEC, sitting behind a
NAT firewall. It is connecting to a 2.4.27 machine running KLIPS.
Both machines are using Openswan 2.1.5.
The 2.4.27 machine was running a rather customised 2.4.26 kernel, but I've
bumped it over to a vanilla 2.4.27 for diagnosis of this problem.


After bringing up the ipsec tunnel, I try pinging the remote (2.4) box
directly (ie. not over the ipsec tunnel), and it works for normal and large
size pings.
(ie. ping hostname, and ping -s 300 hostname).
I now try pinging the host via the tunnel. Pings (up to -s 287) work fine, but
after that, it fails to respond.
ie;
# ping -s 287 -i 3 10.23.1.1
PING 10.23.1.1 (10.23.1.1) 287(315) bytes of data.
295 bytes from 10.23.1.1: icmp_seq=1 ttl=64 time=35.6 ms
295 bytes from 10.23.1.1: icmp_seq=2 ttl=64 time=35.5 ms
...etc

# ping -s 288 -i 3 10.23.1.1
PING 10.23.1.1 (10.23.1.1) 288(316) bytes of data.
^C
--- 10.23.1.1 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 11998ms


That is wierd, no?

Looking at a tcpdump on the ipsec0 interface, for the former case, I see ICMP
coming and going normally, but *nothing at all* for the latter case!

Looking at a tcpdump on the real interface , on port 4500, I see the
following for the working pings:
11:42:18.212976 IP lefthand.box.4500 > righthand.box.4500: UDP, length: 340
11:42:18.213638 IP righthand.box.4500 > lefthand.box.4500: UDP, length: 340

However when I do the slightly-larger ping, this is all I see:
11:42:24.886716 IP lefthand.box.4500 > righthand.box.4500: UDP, length: 348
(repeat until i hit ctrl-C on the ping command)

The only difference is that the UDP packets are 8 bytes larger.
Increasing the ping -s size results in even larger packets, and it still
doesn't work.

It appears that the ESP-in-UDP encapsulation is b0rked once the packets go
over a certain size?

TCP sessions exhibit the same problems - once the packets get over a (small)
size, they fail to get thru - so a telnet session will be ok, unless you cat a
large file..

Wierd, hey?

I've tried adjusting the MTU and overridemtu options on the assorted boxes in
the chain, and they're currently all set to 1200 i think, but this didn't
appear to have any effect upon the situation. Note that un-tunneled pings and
sessions work fine up to arbitrarily large packet sizes, anyway.


Has anyone else hit this, or know how to solve it?

Let me know if I can try anything else to diagnose it.

Thanks,
Toby

-- 
Turning and turning in the widening gyre/The falcon cannot hear the falconer;
Things fall apart, the centre cannot hold/Mere anarchy is loosed upon the world
(gpg --keyserver www.co.uk.pgp.net --recv-key 897E5FF3)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/users/attachments/20040827/3523f724/attachment.bin