Route based IPSec loses 802.1x packets

[GaardenZwerch]

Hi,
I have route-based IPSec tunnels from my branches to the center, and I have trouble with remote switches doing 802.1x with EAP, as  the packets seem to get too large (the switch tries to send 1472 bytes to the radius server) (see attached schema).
I have found that on the central Firewall, the (larger) requests seem to arrive on enc0, but are somewhere lost before they are passed to the ipsec<n> interface. Smaller packets go on fine, and for example mac-based auth on the same switch, against the same radius succeeds. The packets seem to disappear silently as I find no ICMP unreachables anywhere which could help PMTUD to work.

tcpdump on Central FW's enc0

Code: [Select]

14:54:46.500486 (authentic,confidential): SPI 0xc9334317: IP 172.27.5.18.1812 > 10.3.137.200.1812: RADIUS, Access-Challenge (11), id: 0x90 length: 1368
14:54:46.500516 (authentic,confidential): SPI 0xc9334317: IP 172.27.5.18 > 10.3.137.200: ip-proto-17
14:54:46.509256 (authentic,confidential): SPI 0xc06ab719: IP 10.3.137.200.1812 > 172.27.5.18.1812: RADIUS, Access-Request (1), id: 0x91 length: 414
14:54:46.511684 (authentic,confidential): SPI 0xc9334317: IP 172.27.5.18.1812 > 10.3.137.200.1812: RADIUS, Access-Challenge (11), id: 0x91 length: 819
14:54:46.535993 (authentic,confidential): SPI 0xc06ab719: IP 10.3.137.200.1812 > 172.27.5.18.1812: RADIUS, Access-Request (1), id: 0x92 length: 1368
14:54:46.536032 (authentic,confidential): SPI 0xc06ab719: IP 10.3.137.200 > 172.27.5.18: ip-proto-17
14:54:46.671825 (authentic,confidential): SPI 0xc06ab719: IP 10.3.137.200.1812 > 172.27.5.18.1812: RADIUS, Access-Request (1), id: 0x93 length: 363
14:54:47.673778 (authentic,confidential): SPI 0xc9334317: IP 172.27.5.18.1812 > 10.3.137.200.1812: RADIUS, Access-Reject (3), id: 0x93 length: 20


tcpdump on Central FW's ipsec<n> you see that the id 0x92 goes missing

Code: [Select]

14:54:46.497772 IP 10.3.137.200.1812 > 172.27.5.18.1812: RADIUS, Access-Request (1), id: 0x90 length: 414
14:54:46.500484 IP 172.27.5.18.1812 > 10.3.137.200.1812: RADIUS, Access-Challenge (11), id: 0x90 length: 1368
14:54:46.500515 IP 172.27.5.18 > 10.3.137.200: ip-proto-17
14:54:46.509260 IP 10.3.137.200.1812 > 172.27.5.18.1812: RADIUS, Access-Request (1), id: 0x91 length: 414
14:54:46.511681 IP 172.27.5.18.1812 > 10.3.137.200.1812: RADIUS, Access-Challenge (11), id: 0x91 length: 819
14:54:46.671829 IP 10.3.137.200.1812 > 172.27.5.18.1812: RADIUS, Access-Request (1), id: 0x93 length: 363
14:54:47.673775 IP 172.27.5.18.1812 > 10.3.137.200.1812: RADIUS, Access-Reject (3), id: 0x93 length: 20

looking at what goes into the firewall at the switch's side, I see that the original size of 0x90 is 1390 bytes, which get split and correctly reassembles, 0x92 is 1472 bytes, gets split and is then somehow lost at the 'end' of the tunnel.

Any ideas what I could do to get this to work?

Thanks and regards,
Frank

[mimugmail]

Sadly a known problem with route-based IPsec in BSD:
https://github.com/opnsense/core/issues/3674

What you can try would be a new plugin called radsecproxy, in germany they already use it for EDUroam in production. Might be easier to overcome MTU issues, but no guarantee