Created attachment 289597 [details] packet capture According to RFC 4302[1]: > As mentioned in Section 2.6, the ICV field may include explicit > padding if required to ensure that the AH header is a multiple of 32 > bits (IPv4) or 64 bits (IPv6). If padding is required, its length is > determined by two factors: > > - the length of the ICV > - the IP protocol version (v4 or v6) [...] > Inclusion of padding in excess of the minimum amount required to > satisfy IPv4/IPv6 alignment requirements is prohibited. However, in the Linux implementation padding is always added (and expected) so that the Authentication Header (AH) is a multiple of 64 bits, independent of the IP version used. This is an issue when the IPsec AH with IPv4 is used with HMAC authentication e.g. HMAC-sha256-128. In this case the ICV field is 128 bits long, which results in an AH length of 96 + 128 = 224 bits. Even though this is a multiple of 32 bits, Linux adds an additional 32 bits of padding. Additionally, Linux drops incoming packets that do not have this padding. In the attached file the outgoing packets, that are wrongfully padded can be seen. [1] https://tools.ietf.org/html/rfc4302#section-3.3.3.2.1
To avoid the incorrect padding/alignment, IPv4 AH states have to be marked with the XFRM_STATE_ALIGN4 flag.
Yes this was fixed years ago, please use XFRM_STATE_ALIGN4: commit fa9921e46fd52b78070dc67ce0d27ec301a90410 Author: Nicolas Dichtel <nicolas.dichtel@6wind.com> Date: Wed Feb 2 06:29:02 2011 +0000 ipsec: allow to align IPv4 AH on 32 bits
Thank you for your replies, using the align4 flag indeed solves the problem.