Updated: Nov 20, 2019
In this article we are going to take a look at how to capture Extensible Authentication Protocol Over LAN (EAPOL) and Remote Authentication Dial-In User Service (RADIUS) packets using Wireshark.
This article can be useful for troubleshooting 802.1x within your environment and can also be used for learning purposes.
The following topology has been used to gather the required output for this article.
Note: This article will only cover the switch configurations that are required to gather EAPOL and RADIUS configuration.
Overview of the Topology
The supplicant is configured to perform 802.1x using EAP-TLS as the authentication method
The user certificate on the supplicant will be used for authentication
The supplicant has Wireshark installed
Cisco ISE is used for authentication and authorisation
The supplicant is assigned to VLAN 10 upon authentication and all other endpoint ports are assigned to VLAN 99
Sniffer device is running Wireshark in order to capture RADIUS flows via SPAN
When a supplicant sends an authentication request, the supplicant will send layer 2 EAPOL frames to the authenticator (access switch) and then the switch will repackage that into RADIUS and forward the packets at layer 3 to the authentication server.
If we further break it down we can see what happens at an high-level with the EAPOL frames and EAP packets. The below diagram is referenced from cisco.com and shows the EAPOL and EAP flows, the only difference is that we will be using EAP-TLS rather than EAP-PEAP. Nevertheless if you would like to read more about deploying 802.1x you can visit the following link where the diagram below is taken from: https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/TrustSec_1-99/Dot1X_Deployment/Dot1x_Dep_Guide.html
In order to capture the full flow of an authentication request, we need to make sure we have the following set up.
Supplicant must be configured with for EAP-TLS
Supplicant must have Wireshark installed
Authenticator configured with AAA so that authentication requests are sent to the authentication server
Authenticator configured with SPAN for the sniffer
Configued with Wireshark to capture RADIUS flows
Connected to a SPAN port in the Authenticator
Authenticator SPAN Configuration
The following configuration is required to enable the SPAN port on the authenticator switch as shown in the lab topology.
monitor session 1 source interface vlan 10 both
monitor session 1 destination interface vlan 99 encapsulation replicate
With all the other configuration elements in place, open Wireshark on both the supplicant and Sniffer device and attempt to authenticate the supplicant device. We will need to filter the Wireshark logs to just EAPOL and RADIUS.
As the supplicant is only performing EAPOL, lets start by filtering for those on the supplicants Wireshark first. You can enter one of the two following filters:
eapol && eth.addr == 48:0f:cf:dc:cb:90 && eth.addr == 64:f6:9d:01:f7:17 (Replacing the mac addresses to match your supplicant and authentication server)
Both of the filters should work however you may want to use one over the other based on results. I noticed that when the 'eapol' filter is used I can see more information and this is because the supplicant sending EAPOL frames will send the frames to the nearest destination rather than specifying a destination mac-address.
You should see the following results within the packet capture from the supplicant.
EAPOL Filter with mac addresses defined
Now we need to filter for RADIUS on the sniffer device. To do this you can enter one of the following filters
radius && ip.addr == 172.16.0.9 && ip.addr == 172.16.0.254 (Replacing the IP addresses with your authenticator IP address and authentication server IP address)
You should now have been able to capture a full authentication flow for 802.1x. If you would like to download the .PCAP files used within this lab, visit the resources page here: https://www.networkwizkid.co.uk/resources-and-tips
One of my readers reached out to me on Twitter a few days ago and asked why I decided to capture the flows on different devices rather than just using the span port. This was a very good question and one that I didn't put too much thought into while producing the lab so I wanted to add some additional information that could help you in the future.
So, when exactly would one use the above demonstration to troubleshoot their environment? Let's explain some use cases below!
Using the above demonstration, you may decide you want to use this method of troubleshooting in your environment if you have access to the supplicant and also access to the switch.
But what happens when you don't have access to the supplicant but you need to troubleshoot the flows?
What if you still have access to the supplicant but don't want to run captures on both devices?
Well you could use the same method as I've discussed above but without the supplicant device. To do this you would simply configure the authenticator span port to send the supplicant source information too. To break it down some more, lets say you had the supplicant in VLAN 10 and the source for RADIUS requests in VLAN 99, you could use the following configuration to ensure that the span port receives the desired frames and packets.
monitor session 1 source vlan 99
monitor session 1 source vlan 10
monitor session 1 destination interface Gi1/0/21 encapsulation replicate
When issuing a the show command, you should see the following output:
show monitor session 1
Type : Local Session
Source VLANs :
Both : 10,99
Destination Ports : Gi1/0/21
Encapsulation : Replicate
Ingress : Disabled
Note that you would still need somebody on site to physically plug a device into the span port that is capable of sniffing the traffic but once that's done all you need to do is play with your Wireshark filters in order to get the same information you would from the supplicant.
Your filter could be something as simple as:
radius or eapol
Which would output similar information as shown below: