KLIPS not responding to 348+ byte ESP-in-UDP packets?
openswan at wintrmute.net
Fri Aug 27 12:49:36 CEST 2004
OK, I seem to have hit some rather wierd behaviour.
For this example, I have a 22.214.171.124 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
(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.
# 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
# ping -s 288 -i 3 10.23.1.1
PING 10.23.1.1 (10.23.1.1) 288(316) bytes of data.
--- 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
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
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.
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
Size: 187 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/users/attachments/20040827/3523f724/attachment.bin
More information about the Users