EAP-TLS Fragmentation over IPSec VPN Tunnels

You guys are my last resort here. This is my third day on this and I'm pulling my hair out trying to figure out what is going wrong and where.

We have a Windows 2016 NPS server acting as a RADIUS server for wifi traffic. When this guy was local in the office, it worked beautifully. Client machines have a cert, they authenticate to wifi, all is right with the world.

The problems started when we moved this server up into the cloud last week with an IPSec Site to Site VPN connection.

EAP-TLS packets are not being registered by the NPS server. I can see them make it through the VPN tunnel, but they are never registered in NPS logs (yes, I have advanced logging turned on). If i switch this to PEAP, things work fine - just EAP-TLS due to cert size, I am guessing.

In testing MTU Thresholds over the VPN tunnel with a do-not-fragment ping switch, the max MTU that gets me a reply is 1472. 1473 fails with a message that it needs to be fragmented.

I have NPS with a custom MTU rule set to 1344 (also tried this at 1400, no go).

The IPSec Tunnel has an MTU of 1400 set on it (This is Barracuda <-> Pfsense).

APs are Unifi, switches are Meraki (This client is not brand-loyal)

Here is the output from a packet capture on the AP's switch port.

16:11:25.931050 IP (tos 0x0, ttl 64, id 39144, offset 0, flags [+], proto UDP (17), length 1500) 172.16.1.242.60808 > 10.2.34.10.1812: RADIUS, length: 1472 Access-Request (1), id: 0xb5, Authenticator: 6649788cadda9431fdef46d132dcd5f2 User-Name Attribute (1), length: 9, Value: CENSORED NAS-Identifier Attribute (32), length: 14, Value: c6fbe4c25386 Called-Station-Id Attribute (30), length: 23, Value: C6-FB-E4-C9-51-87:CORPORATE NAS-Port-Type Attribute (61), length: 6, Value: Wireless - IEEE 802.11 Service-Type Attribute (6), length: 6, Value: Framed Calling-Station-Id Attribute (31), length: 19, Value: 64-5D-86-46-6D-C8 Connect-Info Attribute (77), length: 23, Value: CONNECT 0Mbps 802.11b Acct-Session-Id Attribute (44), length: 18, Value: DC46B5523AE7683F Acct-Multi-Session-Id Attribute (50), length: 18, Value: 73D2557C01ED5ED7 Unknown Attribute (186), length: 6, Value: Unknown Attribute (187), length: 6, Value: Unknown Attribute (188), length: 6, Value: Framed-MTU Attribute (12), length: 6, Value: 1400 EAP-Message Attribute (79), length: 255, Value: [|radius] EAP-Message Attribute (79), length: 255, Value: [|radius] EAP-Message Attribute (79), length: 255, Value: [|radius] EAP-Message Attribute (79), length: 255, Value: [|radius] EAP-Message Attribute (79), length: 255, Value: [|radius] EAP-Message Attribute (79), length: 229 (bogus, goes past end of packet) 16:11:25.931091 IP (tos 0x0, ttl 64, id 39144, offset 1480, flags [none], proto UDP (17), length 288) 

And from Wireshark opening the PCAP file -

[2 IPv4 Fragments (1748 bytes): #23(1480), #24(268)] [Frame: 23, payload: 0-1479 (1480 bytes)] [Frame: 24, payload: 1480-1747 (268 bytes)] [Fragment count: 2] [Reassembled IPv4 length: 1748] [Reassembled IPv4 data: e9ea071406d46e99012c06ccf4bc3bbf4d09625bbf3f83ed5e236a270109616365746563…] 

I need this first frame to be under 1472 bytes in size - I don't know where else I'd need to configure this MTU to get the packets fragmented correctly.