Disconnections on a WPA2-Enterprise SSID

your issue sounds kinda complex.

i would open a support ticket if you havent already

Yes. And the uncomfortable answer is this: it does not mainly look like EAP-TLS. It looks far more like an interoperability / roaming / Wi-Fi 6 issue between FortiAP K-series and Intel AX201/AX211 clients, which gets worse under load. The fact that a USB adapter works cleanly while Intel cards drop is your strongest clue. The APIPA address is very likely just the aftermath of reassociation or connectivity loss, not the root cause. Fortinet itself documents throughput-related instability as a cause of link drops, and Intel community cases describe very similar enterprise symptoms with AX201/AX211: unnecessary roaming, reauth or roam events, then “connected, no internet” or loss of IP connectivity.

The most sensible immediate action is not more tuning of PMF, WPA3, or 802.11r. The fastest way out is to isolate the fault hard:

1. Build a test SSID on the same VLAN/DHCP, but with WPA2-PSK instead of 802.1X/EAP-TLS.
   If the disconnect still happens during a file transfer, then EAP-TLS is not your root problem and you should focus on RF, AP, and client interoperability. If PSK is stable, only then is it worth putting 802.1X/RADIUS back in the centre. This kind of clean isolation is exactly how Fortinet recommends narrowing client connection issues.

2. Disable 802.11ax for testing, ideally on a dedicated test SSID or on the affected AP/radio profile.
   Do not theorise. Measure it: same laptop, same AP, same file transfer, once with ax enabled and once with ax disabled. Because of the strong Intel correlation, this is the highest-value test you can run.

3. Run 5 GHz only, 20 or 40 MHz channels, no DFS, no band steering, no AP handoff, no load balancing on the test SSID.
   You need to strip variables out aggressively. If that setup becomes stable, the problem is in roaming or RF feature interaction, not certificates. Fortinet explicitly documents client steering and load balancing as mechanisms that can affect behaviour, so they should be out of the picture during A/B testing.

4. De-tune the Intel client for proof testing:

   • Roaming aggressiveness: Lowest

   • Preferred band: 5 GHz

   • 802.11ax: Disabled

   • U-APSD / WMM power save: disable for testing if exposed

   • Test both OEM driver and Intel generic driver

This is not a nice final fix, but it is a valid proof. If these settings stop the drops, you are dealing with interoperability, not RADIUS.

The second area you need to look at is infrastructure stability under load. The detail that Laptop A starts a file transfer and Laptop B on the same AP also gets knocked off is a major warning sign against “this is just certificates”. That points more toward AP radio behaviour, AP uplink, CAPWAP/controller stability, switchport issues, or PoE problems. Fortinet explicitly says that when AP connectivity issues occur, you need to verify the AP-to-controller path. They also note that LLDP is required for a stable FortiAP environment in some deployment cases, especially where profiles or settings were migrated or reused.

So, in parallel, check this:

• LLDP enabled in the FortiAP profile

• AP switchport for errors, drops, flaps, EEE, and PoE events

• If this is on FortiSwitch, check port errors, CRC, queue drops, and power budget

• Test one problematic AP in isolation, with neighbouring AP influence reduced

• Test a single AP on a different switch or uplink path

What I do not think is likely: that EAP-TLS itself is the primary fault. If EAP-TLS were the real issue, you would expect mainly authentication failures. Your pattern is different: under load it becomes unstable, clients reassociate frequently, sometimes to the same AP, USB adapters remain stable, and other clients can be affected at the same time. That fits interoperability or AP/uplink behaviour much better than a certificate problem. Fortinet’s own troubleshooting guidance lists client-device interoperability as a common cause of connection problems.

So the practical order should be:

A. Do this first

• New test SSID: 5 GHz only, WPA2-PSK, 20/40 MHz, 802.11ax off, all roaming/handoff/load-balancing features off

• Same laptop, same AP, same file transfer

• In parallel, test the original enterprise SSID with 802.11ax disabled

B. Read the result properly

• PSK also unstable: EAP-TLS is innocent. Focus on AX, client/AP interoperability, and AP uplink

• PSK stable, enterprise unstable: then debug 802.1X properly

• Enterprise stable as soon as AX is off: you have effectively proven an interoperability bug or feature interaction

C. Only then do deep debug

• Wireless client event logs on FortiGate/FortiAP

• RADIUS debug only during a reproducible file transfer

• DHCP/sniffer in parallel, to confirm that APIPA appears only after reassociation

My honest assessment is this:
The most likely real-world fix is a workaround, either by disabling 802.11ax or by heavily simplifying RF and roaming behaviour, until you find a Fortinet firmware and Intel driver combination that is actually stable. Everything else you already tried was mostly lateral movement.

Guys, I had the same problem, but with the 431G.

The system only became stable after we disabled the following items:

Radio resource provisioning

Frequency Handoff

We also had to set the channels and power levels to manual mode.

It seems that whenever the AP changes channel or frequency, the AX210/211 client gets lost and does not request a new IP, assuming the APIPA.