I'm trying to setup 802.1x with EAP-TLS to secure wifi, but the RADIUS/connection server is a Azure VM, to which I can connect with a IPSEC tunnel.
The problem is that when trying to connect to the wifi, I get an error that I can't connect. With some help I've discovered that with Wireshark I see (on the RADIUS server) that the framed MTU is 1400, which causes the failure of sending back the client-certificate through the IPSEC tunnel.
If I understand it correctly that's because it exceeds the max packet size of 1500, or some device is forcing the packets to a size of 1400 which causes the packets to be fragmented (incorrectly)?

Now I've looked at all the devices, and as far as I can tell every device is set at the default MTU size of 1500, and I already had a firewall mangle rule (chain=forward action=change-mss new-mss=1350 passthrough=yes tcp-flags=syn prot) in place, but that doesn't seem to matter. I've searched online and found some info about clamping MSS to PMTU, so I've added the rule: chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags (and disabled the other mtu rule).

Unfortunately, that doesn't work either (even after resetting the VPN tunnel for a new connection). In my wireshark trace I still see the MTU size of 1400, so it looks as if the clamping to path-mtu is not working. Anyone got any ideas on how to proceed and get it working?

My setup is as follows:
internet > ISP-modem (configured to blindly forward everything to) > Mikrotik hEX PoE (routerOS 6.46.4) > Managed switches/Ubiquity Unifi AP's > cients.

MSS is a TCP thing, and RADIUS only supports UDP as a transport, so the rules you've mentioned will never work with RADIUS. Fragmenting large UDP datagrams should not be a problem. Unless DF bit set, of course, in which case fragmenting is forbidden. The latter usually happens during path MTU discovery, so you must make sure you do not blindly drop any ICMP messages that are vital for PMTUD to work.

viewtopic.php?f=23&t=169273&p=850595&hi ... tu#p829817

Try allowing MTU resize to be send to the client. Last item in the list.

@msatter, I don't see how you tip applies to the OP's situation.
Your link basically describes a workaround for a specific case when tunneling all (also with NAT) through IPsec prevents PMTUD to work. That is not a problem for a regular IPsec use case when IPsec is used to interconnect specific subnets.

I see that now also. Sorry.

MSS is a TCP thing, and RADIUS only supports UDP as a transport, so the rules you've mentioned will never work with RADIUS. Fragmenting large UDP datagrams should not be a problem. Unless DF bit set, of course, in which case fragmenting is forbidden. The latter usually happens during path MTU discovery, so you must make sure you do not blindly drop any ICMP messages that are vital for PMTUD to work.

Okay, the udp/tcp thing makes sense. As far as I know I haven't prohibited ICMP, let alone for PMTUD. I've changed the MTU size on the ethernet interface on my RADIUS-server, but that did not matter. MTU still forced to 1400 somehow.