Controllerless Networks

I replaced the customers Aerohive accesspoints with IAP-315, same SSID and AP IPs. The stations that was recently associated to Aerohive APs with 802.1X connected fine but other stations was unable to authenticate. The next day no-one could connect with 802.1x so I had to set up a new ssid with PSK.

The Radius server is on another subnet. In the attached screenshot from wireshark the AP at 192.168.100.140 sends a 1314 byte frame to the radius server at 10.100.0.71 with the More fragments bit set but it never sends the next fragment and instead seems to retransmit the first fragment. The capture is from the firewall in the AP network, there is only a Procurve 2510 in between with no special configuration.

There is nothing on the NPS log since the server never receives a full request. I have set Framed-MTU to 1100 on the Network policy but it seemed to have no effect.

Firmware 6.5.4.4_62887

Are you using EAP TLS?

Can you check MTU size in show tech. Its under the command "show datapath bridge":

# show datapath bridge

Datapath Bridge Devices
-----------------------------
Flags: F - source-filter, T - trusted, Q - tagged, I - IP
S - split-tunnel, B - bridge, M - mesh, P - PPPoE
C - content-filter, O - corp-access, h - to HAP, f - to FAP
h - dhcp-redirect b - blocked by STP

Dev Name VLANs PVID ACLs MTU FramesRx FramesTx Flags
--- ------------------------ ----- ---- ----------- ----- -------- -------- --------
3 eth1 1 3333 134/0 0 1500 0 95 FB
8 bond0 3 1 0/0 106 1500 992430 476608 FTQB
12 gre0 1 0 0/0 0 1500 4107 1106 FTQB
15 br0 0 1 105/0 0 1300 374780 0 IB
18 aruba000 1 168 109/0 0 1500 1135 2043 B
19 aruba100 1 168 109/0 0 1500 0 921 B
20 aruba001 1 166 110/0 0 1500 5669 5079 B
21 aruba101 1 166 110/0 0 1500 63572 55628 B

I was wrong, the IAP actually sends two fragments but the second doesn't reach the radius server that is in Azure behind a IKEv2 tunnel and the server responds with icmp fragment reassembly timeout. I have verified that our firewalls sends the second fragment

Yes, EAP-TLS.

MTU of all interfaces are 1500

Dev Name VLANs PVID ACLs MTU FramesRx FramesTx Flags
--- ------------------------ ----- ---- ----------- ----- -------- -------- --------
2 bond0 3 1 0/0 106 1500 23287 6903 FTQB
13 br0 0 1 105/0 0 1300 6233 0 IB
16 aruba000 1 1 100/0 0 1500 5 450 B
17 aruba100 1 1 100/0 0 1500 1 462 B
18 aruba001 1 201 136/0 0 1500 86 35 B
19 aruba101 1 201 136/0 0 1500 0 10 B
20 aruba002 1 1 138/0 0 1500 555 645 B
21 aruba102 1 1 138/0 0 1500 0 0 B

Were you able to resolve your problem? We face a very similar issue. The network is 4 IAP's configured with local VC, the IAP's plug into a Cisco 2960x and all local traffic passes through a Fortigate 100E with an IPSEC tunnel to a remote Fortigate 201E.

When clients connect to our corporate SSID configured with an enterprise role and WPA2-Enterprise they are authenticated to remote Cisco ISE RADIUS servers. Unfortunately, the authentication never completes given the fragmentation of the UDP packets. Then we noticed the UPD packets are reassembled and tagged with the IKE headers, causing the packets to be larger than the 1500 MTU on the tunnel. We believe this is causing packets to drop. We configured framed-mtu on the RADIUS server, but since the framed-mtu sits in the AUTHZ policy at the bottom of the policy set. The request never makes it past the EAP AUTHC to use the framed-mtu AV pair.

At this time we do not have a solution and are investigating options. Were hopeful moving to secure RADIUS/DTLS will resolve the problem. Has anyone else encountered an issue with EAP-TLS authentication to remote RADIUS servers over an IPSEC tunnel.

I was able to work around the problem by changing the Plaintext MTU on the ipsec tunnel to 1260B, this causes the radius packet to be sent in 3 ipsec fragments and works.

I'm not sure if you can change UDP MTU on a tunnel on Fortigate.

Thank you Anders. Unfortunately, the Fortigate is very versatile, but I cannot modify Plaintext MTU settings.