EAP-TLS request not reaching FAC

Are you testing wireless or conneting wired to a Switchport?

The logs you have shared have this message as last one before disconnection:

<eh> recv IEEE 802.1X ver=1 type=1 (EAPOL_START) data len=0

At this point the Authenticator (AP/switch) should send an Identity request packet to get the Host. That is why you see nothing in FortiAuthenticator. That part comes after the identity request/response phase is completed.

So the issue is to be investigated between the Supplicant(endpoint) and the Authenticator.

It might be an issue with 802.1x settings on the Authenticator. 

So, this wireless, Client > AP > Fortigate > FAC

The Fortigate is set to use FAC as the Radius Server with WPA2 enterprise. So the issue is likely the AP? that just broadcasts the SSID , could you elaborate please?

Yes the problem is at this communication channel between Client <> AP 

Check the 802.1x setting in the AP and check its debugging if it shows any more details on why there is no EAP identity Request packet sent back.

The flow is the following:

Supplicant ---- EAPOL START ----> AP

Supplicant <---- EAP Identity Request ---- AP

Supplicant ---- EAP Identity Response ----> AP

                                                                     AP --------- Radius Acess-Request ------> FAC

Hi,

It seems like the EAP-TLS request from the client laptop is not reaching the FortiAuthenticator (FAC) despite proper configuration. The FortiGate logs indicate the EAPOL messages being exchanged but not reaching FAC. The pattern of authentication request and response loops along with client disconnection suggests a communication issue. Since SSL VPN traffic is working fine, it's not a connectivity problem. To troubleshoot further, ensure the EAP server certificate and Trusted CA are correctly configured on FAC, verify the RADIUS settings on both FAC and FortiGate, and check for any firewall rules blocking the EAP-TLS traffic. Additionally, reviewing the detailed logs on FAC using the debug interface and analyzing the network traffic with tools like Wireshark on UDP port 1812 can help pinpoint where the communication breakdown is occurring.