Troubleshooting Tip: A remote wireless user using EAP-TLS has a delay on the response from RADIUS server

[arleniscg]

Description	This article describes the utility of the Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) deployment in wireless users where the RADIUS server will be reachable over an IPsec VPN, and troubleshooting the delay on the response from the RADIUS server.
Scope	FortiGate, FortiAP.
	Topology: The remote wireless user using EAP-TLS against a Radius-server remotely. IPsec VPN in between. Topology Debug on FortiGate B: to see the authentication process, debug for the remote station mac aa:bb:cc:e6:c2:c9: diagnose wireless-controller wlac sta_filter clear diagnose wireless-controller wlac sta_filter aa:bb:cc:e6:c2:c9 255 di debug console timestamp enable diag deb en diagnose wireless-controller wlac sta_filter STA Filter Index 0/1 sta aa:bb:cc:e6:c2:c9 log-enabled 255 di de en 2024-08-07 14:46:39 01589.157 aa:bb:cc:e6:c2:c9 <ih> IEEE 802.11 mgmt::assoc_req <== aa:bb:cc:e6:c2:c9 ws (1-10.136.8.131:5246) ... ... 2024-08-07 14:46:39 01589.158 aa:bb:cc:e6:c2:c9 <ih> IEEE 802.11 mgmt::assoc_resp ==> aa:bb:cc:e6:c2:c9 ws (1-10.136.8.131:5246) ... .. 2024-08-07 14:47:17 01628.998 aa:bb:cc:e6:c2:c9 cwd_sta_idle_timeout_notify sta aa:bb:cc:e6:c2:c9 2024-08-07 14:47:17 01628.999 aa:bb:cc:e6:c2:c9 cwAcProcInputLocalMsg: cwAcKernDataDelSta failed aa:bb:cc:e6:c2:c9 rId 0 wId 0 2024-08-07 14:47:17 01628.999 aa:bb:cc:e6:c2:c9 <dc> STA del aa:bb:cc:e6:c2:c9 ws (1-10.136.8.131:5246) vap GRUPO test 2024-08-07 14:47:17 01628.999 aa:bb:cc:e6:c2:c9 cwAcProcInputLocalMsg D2C_STA_DEL wl GRUPO test 2024-08-07 14:47:17 01628.999 aa:bb:cc:e6:c2:c9 <ih> IEEE 802.11 mgmt::disassoc ==> aa:bb:cc:e6:c2:c9 ... ..... 0 dd:ee:ff:05:91:08 sec WPA2 RADIUS action idle_timeout reason 0 2024-08-07 14:47:18 01628.000 aa:bb:cc:e6:c2:c9 cwAcStaRbtDel: D2C/C2C_STA_DEL remove sta aa:bb:cc:e6:c2:c9  It can be observed that the client associates with the FortiAP successfully, and then starts its authentication process. After a few minutes, RADIUS stops responding when an Access-Accept or Access-Reject message should be received. In this example, the RADIUS team performed a capture on the team's side and checked the configurations again, but no issue was found. A sniffer was performed on FortiGate B to discard RADIUS message interchange issues. Several 'Malformed packets' were observed on the RADIUS communication. Troubleshoot performed on FortiGate B: Set all devices on the way to point the same NTP server:  more data on custom NTP on the FortiGate side link: Technical Tip: Custom NTP server configuration. Increase remoteauthtimeout on FortiGate B: config system global set remoteauthtimeout 60  end On the sides of both FortiGates, on the rule that allows in/out access to this traffic, edit the tcp-mms value: config firewall policy edit ID <- ID of rule. tcp-mss-sender 1400 tcp-mss-receiver 1400 set auto-asic-offload disable set np-acceleration disable end Clear old sessions to force the new sessions to take policy modifications: diag sys session filter policy ID diag sys session cl After these modifications, 'Malformed Packets: Radius' disappeared: