Capturing EAPOL and RADIUS Using Wireshark

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

802.1x Overview

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 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:


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.

conf t
monitor session 1 source interface vlan 10 both
monitor session 1 destination interface vlan 99 encapsulation replicate

Wireshark Captures

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
  • 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

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
  • radius && ip.addr == && ip.addr == (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.

Update 20/11/19

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!

Use Cases

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
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:


Kelvin is a Cyber Security professional with years and experience working with organisations in different verticals, both large and small. He enjoys contributing to the Network Wizkid knowledge base and he also creates technical content. Kelvin enjoys learning new things and often does this by working on achieving new technical certifications. He holds many professional certifications and academically, he has achieved a Bachelors and Master's degree in both Computer Networks and Cyber Security.

Leave a Reply