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:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
