IPSec + large packets being corrupted

["Chris Audley" <chris@navaho.co.uk>]

I've been using the 2.6 kernel ipsec system for some time and have always
had to work around issues with large packets not traversing the VPN by
setting the LAN interface MTU size to something like 1400.

Because I always thought this was a hack and not a proper fix, I've spent
a few days trying to work out exactly why large packets aren't traversing
the VPN and have found something which may well be the cause. I really
don't know the kernel networking code that well so I was hoping that
someone can either verify that what I've found is really an issue, or
whether I'm doing something wrong.

This has been seen in the field with P4/e100+e1000 systems running 2.6.12
and in testing on Geode/dp8381x systems running 2.6.17, all using IPv4.
VPN is Racoon based, using x509 certs and ESP/AH (3DES/SHA1).


This is my understanding of how large packets get corrupted:

Large packet (eg. 1600 byte ping) received by VPN server A.
Packet encrypted and fragmented then sent from Server A to Server B.
Packet received by network subsytem on B and frag_list created
ah_input() strips the AH header -- frag sizes are not changed!
esp_input() decrypts data
ip_fragment() uses existing frag_list sizes from before the AH
  header being stripped, and sends too much data (16 bytes extra). This
  breaks the checksum and packets get dropped by destination host.

By setting the MTU on the local interface, this breaks one of the
checks for using the pre-existing frag list in ip_fragment() (MTU is now
smaller than the largest frag size), so the packet fragments are
re-generated from scratch and the large packet gets through.

If I disable the valid frag_list check in ip_fragment(), again large
packets traverse the VPN with no problems at all since the fragments are
re-generated from scratch.

If my analysis of the above is correct, then my feeling is that either
ah_input() should re-calculate the fragment sizes, or some flag should be
set to tell ip_fragment() to use the slow method and recreate the
fragments.

Does this sound like a real problem, or have I missed something obvious?

Regards,
-- 
Chris Audley             mailto:chris@navaho.co.uk