Wrong checksums on reassembled packets after IPSec

Started by pupadmin, May 16, 2021, 12:35:23 PM

Previous topic - Next topic
Hi everyone,

I have a strange issue:

I finally found a configuration that allows for pre-fragmentation of packets sent through routed IPsec Site-2-Site VPN. All my packet captures show that IP packets are correctly fragmented *before* being encapsulated (which is important in my network setup). On the target site, packets seem to get reassembled and then sent out via LAN interface - but they have in incorrect ipv4-Checksum and get dropped by final recipient.

To be precise: The checksum value for the reassembled packet is taken from the first fragment, corrected by +0x100 for TTL. [see packet #3 in LAN_filtered.pcap (csum 0xf23e) vs. p#5 in VTI_filtered.pcap (csum 0xf13e)]

What is even more strange:
On the first reassembeld packet, everything works. Starting with the second, it fails. after approx 15-20 secs -> works again (maybe some internal reset). Non fragmented packets are not affected.

I attached a packet capture with the relevant packets. It contains two pings needing fragmentation (first works, second does not), and two pings without fragmentation (both work).

I guess this is not a directly OPNsense related bug, but may reside in the FreeBSD/HardenedBSD ipsec stack. If so, shall I file a bug report somewhere else?

Best regards,
   Stefan

PS: Checksum offloading is deactivated in all involved OPNsense instances.
PPS: pre-fragmentation is gained by simply setting a smaller MTU on VTI interface. I can provide more info on network setup on request if this is not directly forwarded to OS issues.

This might have been already fixed with FreeBSD 13.0 -> PR: 255432 (https://reviews.freebsd.org/R10:055c55abefbe19fe46a56894595af9c9dad7678c)

But I am not sure and would like to verify by checking the sources. Can someone point me in a direction how and where to find the source that is actually used for OPNsense (by version)?