A Wireshark trace can provide insight into the authentication flow when troubleshooting RADIUS integrations. This article explains how to use Wireshark to capture RADIUS packets.
- Okta RADIUS Agent
- Wireshark
- Download Wireshark on the machine running the Okta RADIUS agent. Follow the installation prompts, leaving the default options checked.
- Click on the Start Capturing packets option button, or choose Capture > Start from the menu.
- Please do not filter the search. Wireshark needs to capture all traffic, including all communications with Okta (that is, TLS handshakes). As such, it is not recommended to filter to only RADIUS.
- Open the file in Wireshark and perform RADIUS authentication - the requests and responses are captured in Wireshark.
- To decrypt the passwords, enter the shared secret. Right-click a packet, choose Protocol Preferences > RADIUS Protocol > Shared Secret …, and enter the app’s shared secret.
For RADIUS with PAP (default) capture
- If a non-standard port is used, the network packets will not show the expected ACCESS-REQUEST / ACCESS-ACCEPT / ACCESS-REJECT packet. This is because Wireshark expects RADIUS traffic only on port 1812 by default.
- To resolve this:
-
- Click WireShark from the toolbar on Mac or Edit in Windows > Choose Preferences.
- Expand protocols on the left-hand pane.
- Scroll to RADIUS.
- In the RADIUS UDP port (s) field, add the non-standard RADIUS port number as a comma-separated value (see screenshot below).
- Click OK and then apply the filter
- Alternatively, use Decode As... :
-
- Right-click a packet in the Capture and choose Decode As...
- This should bring up the "decode as" control panel. Ensure the Field is "UDP port" and the Value is the non-standard RADIUS UDP port number (shown below as 51812 - it should be set by default, but if it is not, use the + button to add it).
- Double-click where it shows (none) under the current field, and choose RADIUS from the dropdown (type RAD and it should snap to it as a selection).
- Click Save and then OK.
Once the password is decoded, packet details will show in the capture:
NOTE:
- If user input is tunneled within TLS (Like with Okta's EAP-TTLS Integrations), the packets will be encrypted and look generic because all the details are encrypted and cannot be viewed, even with the shared secret. For example:
-
- These captures are still helpful for troubleshooting SSL/TLS handshakes and connection establishment.
- There are many ways this traffic may be decrypted and the application data reviewed. Common methods include using the Server's SSL Private Key or capturing the TLS Session Keys into an SSLKEYLOGFILE file on the client and using it to decrypt the traffic.
- These captures are still helpful for troubleshooting SSL/TLS handshakes and connection establishment.
- For EAP traffic, it is a good idea to capture traffic at the VPN server/WiFi router or at the supplicant. Non-RADIUS traffic will be seen, such as the EAP start and the key exchange messages at the end of the authentication:
-
Use “eapol” or “eap” as the display filter.
-
- Download the Wireshark colorization profile from the Wireshark Configuration Profile to highlight the various parts of the EAP conversation in different colors. This profile removes the “Info” column. Add it back for easier readability.
