Troubleshooting Tip: Checking RADIUS error 'authentication failure' using Wireshark

SAJUDIYA · ‎11-25-2022

Description

This article describes the RADIUS server authentication failure error in a working configuration where RADIUS server connectivity is successful.

In most of the cases where the existing configurations interrupt or got errors with no changes, or issues with the radius server certificate, it is necessary to check the server certificate from RADIUS.

Scope

FortiGate 6.X and 7.X.

Solution

Follow the steps below to identify the issue:

diagnose test authserver radius <radius server_name> <authentication scheme> <username> <password>

authenticate ‘<user>’ against 'pap' failed(no response), assigned_rad_session_id=562149323 session_timeout=0 secs idle_timeout=0 secs! <- This output indicates the server is unresponsive.

Run Radius debug for more details:

# diagnose debug application fnbamd 255
# diagnose debug console timestamp enable
# diagnose debug enable

Output sample:

51:1812) code=1 id=39 len=135 user="<user>" using PAP
2022-10-18 06:15:37 [319] radius_server_auth-Timer of rad 'AWS_MFA_NPS' is added
2022-10-18 06:15:37 [755] auth_tac_plus_start-Didn't find tac_plus servers (0)

2022-10-18 06:15:44 [378] radius_start-Didn't find radius servers (0)

2022-10-18 06:15:44 [2855] handle_auth_timeout_with_retry-retry failed

2022-10-18 6:15:44 [2912] handle_auth_timeout_without_retry-No more retry

Check whether the RADIUS Access-Request arrives at the server. Either run a packet capture on the server to verify the receipt AND response packet. If there is no response, check on the server logs why.
Run the packet capture from Network -> Packet Capture and Sniffer from CLI and filter traffic for server IP and Port 1812 or 1813. Filtering for the right interface will show you an Access-Request at least.

If there is none, then the FortiGate may send the Access-Request from a wrong interface. In these cases, check which packet the FortiGate is sending the packet from:

diag debug console timestamp enable
diag debug flow filter port 1812
diag debug flow show iprope enable
diag debug enable
diag debug flow trace start 20

Check the general routing information to confirm whether the interface is correct:

get router info routing-table details <server-IP>

The following example shows an actual Access-Reject, which however is a response packet and will not lead to a timeout message as before.

Below is pcap output which shows the following:

10.232.98.1 (FortiGate) is requesting access and 10.71.9.251 (radius server) is sending an access-reject(3), which means the issue is from radius sever.

'Access-Reject: If any value of the received Attributes is not acceptable, then the RADIUS server will transmit an Access-Reject packet as a response'.

If the access-rejected(3) error is received from the Wireshark capture, authentication failure is received from the FortiGate GUI, and authentication fails with authenticating ‘user’ against 'pap' failed(no response): verify from the RADIUS server.

Related articles: