The premiere source of truth powering network automation. Open and extensible, trusted by thousands.

NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.

A simple wired 802.1X lab

By stretch | Wednesday, August 6, 2008 at 2:18 a.m. UTC

IEEE 802.1X is a very cool security feature. It was developed to provide real security for wired and wireless networks at layer two. A client connected to an 802.1X-protected port can't send any traffic other than EAP to the switch until he successfully authenticates with the proper credentials or certificate. This article demonstrates how you can setup a simple 802.1X lab using a Windows XP-based client and RADIUS server.

802.1X Operation

A network switch acts as the middleman between an authenticating client and an authentication server. The switch implements two protocols: EAP is used to communicate with the client at the network perimeter, while RADIUS is used to relay authentication details to the server inside the network. EAP offers a number of authentication mechanisms, but our setup will use simple username/password authentication with an MD5 challenge. The flow of a successful authentication is illustrated here:


For a better idea of what this exchange looks like on the wire, check out these packet captures of 802.1X and RADIUS traffic.

Server Configuration

For my setup, I chose to install FreeRADIUS on my Gentoo Linux workstation, but any RADIUS service should work. The configurations in this section correspond to a bare FreeRADIUS deployment using cleartext credentials stored in a text file. Obviously, real-world deployments would dictate a much more robust and secure authentication method such as LDAP.

The base server configuration is located in radiusd.conf (on Linux, this file should reside in /etc/raddb/), but we shouldn't need to change any of the default values for this lab. However, we will need to add the subnet address from which we expect to receive authentication requests ( in clients.conf. Remember that although the 802.1X client resides in VLAN 10, the RADIUS client (the switch) will be sending requests from its interface. Copy and paste this block to enable the network with the shared secret of MyRadiusKey:

client {
    secret      = MyRadiusKey
    shortname   = Lab

We'll also define a user/password combination for testing. I've created the user John.McGuirk with the password S0cc3r. Feel free to pick your own username and password, but make sure to maintain the spacing in the configuration file (the reply message is optional):

John.McGuirk    Cleartext-Password := "S0cc3r"
                Reply-Message = "Hello, %u"

After completing this configuration remember to (re)start the RADIUS service.

Switch Configuration

Port-based 802.1X authentication allows for some really cool security measures (like dynamic VLAN assignment and per-user ACLs), but for this lab we'll establish a base configuration just for demonstration's sake.

A preliminary step, if you haven't done so already, is to enable IP routing on the switch:

Switch(config)# ip routing

Before diving into the actual 802.1X configuration, we'll need to enable Authentication, Authorization, and Accounting (AAA) for the switch (this step can be skipped if AAA is already active). A word of caution: enabling AAA changes the authentication method used by the VTY (telnet) lines to fit the AAA model. It's a good idea to define a local username and password to authenticate to the switch if you haven't done so (this account is unrelated to our 802.1X configuration, just a way for us to log in again if we need to).

Switch(config)# aaa new-model
Switch(config)# username admin secret MyPassword

Next we'll configure the switch with the address and shared key of our RADIUS server. By default, Cisco switches will use UDP port 1645 for RADIUS authentication and port 1646 for accounting. Depending on the RADIUS daemon you chose to implement, you may need to modify these ports to match those used by your RADIUS daemon. FreeRADIUS, for example, uses the more recent port specification defined in RFC 2138, and requires additional configuration on the switch to reflect the port changes:

Switch(config)# radius-server host auth-port 1812 acct-port 1813 key

Now we'll tie these two components together by configuring AAA to reference the RADIUS server for 802.1X authentication requests:

Switch(config)# aaa authentication dot1x default group radius

This takes care of the RADIUS portion of the configuration. Configuring 802.1X from this point is simple: enable it globally for the switch, and individually per interface:

Switch(config)# dot1x system-auth-control
Switch(config)# interface g0/12
Switch(config-if)# switchport mode access
Switch(config-if)# dot1x port-control auto

Note that the interface must be set to static access mode. If left in dynamic mode (where DTP is used to negotiate the port's function as either access or trunking), the switch will issue an error message stating that 802.1X cannot be configured on dynamic ports.

If you're inquisitive like me and issue a question mark to invoke the context-sensitive help in the midst of issuing a new command, you might have noticed that the dot1x port-control interface command has three options. These are:

  • auto - Normal 802.1X authentication
  • force-authorized - No 802.1X authentication is used (this is the default setting, to prevent service interruption while deploying 802.1X)
  • force-unauthorized - Ignores authentication attempts, port is always unauthorized

You can use the show dot1x command to verify the configuration of your client-facing interface:

Switch# show dot1x interface g0/12
Supplicant MAC 
   AuthSM State      = N/A
   BendSM State      = N/A
PortStatus        = N/A
MaxReq            = 2
MaxAuthReq        = 2
HostMode          = Single
PortControl       = Auto
QuietPeriod       = 60 Seconds
Re-authentication = Disabled
ReAuthPeriod      = 3600 Seconds
ServerTimeout     = 30 Seconds
SuppTimeout       = 30 Seconds
TxPeriod          = 30 Seconds
Guest-Vlan        = 0

Client Configuration

The last element to configure is the supplicant software on the client. If your client is currently connected, unplug it temporarily before continuing (reconnecting after the configuration has been completed will make it easier to observe the 802.1X behavior). For my lab, I used a Windows XP box with SP2.

To enable the Windows 802.1X service, open Services from the control panel, and select and start the Wireless Zero Configuration service. ("But isn't this a wired connection?" I hear you ask. Thank you, Microsoft.) (Edit: Wired 802.1X is enabled by a separate service, Wired AutoConfig, in XP SP3. Thanks to Dude for pointing this out!) Next, open Network Connections from the control panel and open the Connection Properties dialog for the adapter you're using. You should have an Authentication tab within this window; if not, the 802.1X service isn't running and you'll need to do some troubleshooting.


Enable 802.1X authentication and set the EAP type to MD5-Challenge. This will allow us to use basic username/password credentials instead of a more secure (and much more complex) PKI scheme. You can safely deselect the "authenticate as computer" and "authenticate as guest" options.


If everything is configured correctly, you should now be able to authenticate via 802.1X. Verify your IP addressing and connect your client to the switch. After roughly thirty seconds you should be prompted for authentication credentials by a little balloon. (In a more ideal setup, your Windows credentials and/or a client certificate would be sent without your interaction and 802.1X authentication would occur transparently.) Your prompt may differ from the example shown here.


Enter the username and password you configured on the RADIUS server in the authentication dialog.


Your client will notify you after a bit if the authentication fails. If you receive no notification, authentication has succeeded and you should be able to send traffic through the switch port (try pinging through to the RADIUS server to verify this). Issue the show dot1x command on the switch again to verify that the port is now in the "authorized" state.

Switch# show dot1x interface g0/12
Supplicant MAC 0014.22e9.545e
   AuthSM State      = AUTHENTICATED
   BendSM State      = IDLE
PortStatus        = AUTHORIZED
MaxReq            = 2
MaxAuthReq        = 2
HostMode          = Single
PortControl       = Auto
QuietPeriod       = 60 Seconds
Re-authentication = Disabled
ReAuthPeriod      = 3600 Seconds
ServerTimeout     = 30 Seconds
SuppTimeout       = 30 Seconds
TxPeriod          = 30 Seconds
Guest-Vlan        = 0

One other detail to note: Initially, the client's port on the switch will only transition to up/down (interface up, line protocol down) when you first connect. Only after successfully authenticating via 802.1X will it transition fully to up/up.

If authentication fails for some reason you'll have to do some sleuthing to determine the cause. Keep the following tips in mind:

  • Ensure that the switch is trying to authenticate to the correct RADIUS server on the correct UDP port
  • Ensure the RADIUS server is configured to accept authentication requests from the correct subnet
  • Review the RADIUS daemon logs for messages concerning failed authentication or misconfiguration
  • Use a variation of the debug dot1x command on the switch or a packet sniffer to verify EAP and RADIUS traffic
  • Try using the free NTRadPing RADIUS Test Utility to independently verify operation of the RADIUS server

Posted in


August 6, 2008 at 2:56 a.m. UTC

Great, I am waiting this info. long time ago.

August 6, 2008 at 7:28 a.m. UTC

Great !!!

August 6, 2008 at 11:52 a.m. UTC

Very nice post, thank you.

August 6, 2008 at 3:53 p.m. UTC

I have tinkered with the guest vlan when a user is not authenticated and that works pretty good. It would be a nice addition to this write up. Nice Post, Thanks!

August 6, 2008 at 11:02 p.m. UTC

What is the purpose of enabling IP routing? It's not required to do dot1x.

August 6, 2008 at 11:06 p.m. UTC

veeery nice

August 6, 2008 at 11:53 p.m. UTC

@Marcus: Good idea!

@Robert: ip routing is only needed if you set up your lab like I did, with a multilayer switch separating two subnets.

August 7, 2008 at 5:17 a.m. UTC

Thanks. I'll read a little more before I post next time. Glad there's other people out there using dot1x and guest vlans Marcus. If you do cover guest vlans please try and cover auth-fail vlans as well.

Watch out for Bug ID CSCsc06286 if you have an older IOS. It didn't make it into any of the release notes. The biggest problem we faced with dot1x in production was re-imaging computers. I've documented our solution, if you are interested I could email the doc.

Thanks for the postings I enjoy reading the blog.

August 7, 2008 at 1:31 p.m. UTC

How much tweaking is necessary to allow your Windows credentials to be sent without your interaction and 802.1X authentication would occur transparently?

August 7, 2008 at 4:07 p.m. UTC

Good Post.

The dynamic vlan assignment function is neat (Works with FreeRadius aswell). It's almost always pleasant too assign vlan's based on user login instead of a mac-address.

August 9, 2008 at 3:34 a.m. UTC

Have you tried to do this using certificates? I tried awhile back with a large number of Windows XP supplicants and it was somewhat unreliable. Just wondering if anyone has had better luck.

August 10, 2008 at 1:03 p.m. UTC

Hy I have a strange problem. I Do not have the Authentication TAB in my LAN adapter properties. . I have only general and Advanced. I have enable WZC in registry. IT is a wired LAN. Thanks

August 14, 2008 at 7:37 a.m. UTC

I had the same issue. In SP3 there is a separate service called "Wired AutoConfig" for wired connections. It is not started by default. Just enable it.

August 18, 2008 at 7:58 p.m. UTC

thanks. it's working.

September 29, 2008 at 10:41 a.m. UTC


I use dot1x with few hundreds of xp-s(SP2/SP3) with freeradius. Everything works fine until the pc goes to stanby or hibernate..after this the the reauthentication process takes couple of minutes if I don't do shutdown/no shutdown on the affected switch port.

Anybody has some experience/maybe solution for this.


October 9, 2008 at 2:52 p.m. UTC

Hi! Thanks, great article! Could you please give the models of several switches that support your configuration? I know it should work with Cat3550, but I've no idea whether it'll go with i.e. Cat 29xx or non-Cisco switches. Is it sufficient for switch to support just 802.1x or it has to have additional features that causes it can dynamically assign vlan to users, based on radius server?

December 11, 2008 at 2:18 p.m. UTC

we are using Cisco Secure Services client and c2950 switches , with cisco ACS with an AD in order to perform Machine and User authentication. We see a problem on laptops with WINXP SP3. After a while they they are unable to make a connection to the LAN. After debugging it looks like that the machine account password change (after 30 days) causes a problem --> the ACS get an answer from the AD that the password is not correct --> no access anymore to the network. When we force the laptop into the VLAN where he should normally be assigned --> problem resolved and we can use again a 802.1x port to connect the laptop.

I'm wondering if anyone has seen this before and how they solved this problem.

Thx in advance,


November 2, 2009 at 4:00 p.m. UTC

I there a method from the client to test if the port it is connected to is 802.1x enabled other than going to the switch to look? I would like to test a port to validate the netwroking folks actually enabled the port for 802.1x

March 30, 2010 at 3:46 a.m. UTC

Good Post.It was very helpful for me.

March 30, 2010 at 5:05 a.m. UTC

Hi..Can you please explain this process with a freebsd machine with free RADIUS and with nortel switch... wired authentication Thank you..

August 5, 2010 at 4:52 a.m. UTC

Hi.. Could you please explain me how to configure linux PC as Authentication server for TLS certificate.

802.1X authentication works fine when I tried with MD5 Authentication(i.e by configuring username and password)


October 16, 2010 at 10:12 a.m. UTC

hi my lan card does not support 802.1x . how can i add authentication tab on lan card...??? help me plzzz

A guest
September 6, 2011 at 7:11 p.m. UTC


September 27, 2011 at 8:14 a.m. UTC

Word of caution: EAP-MD5 is very easy to configure and works like a charm but its support is limited in Windows 7. The option in Windows 7 are MS PEAP, Cisco LEAP, Cisco PEAP, EAP-FAST, EAP-TTLS. Almost all of them requires a secure channel between Radius and NAS i.e switch. This is based on certificates.
Configuring that on FreeRadius is challenging.
I am currently working on it as part of my job (yes). Once I am done, I will post a step-by-step How-TO. Idea is that each client/laptop should be have a certificate and user should be able to use windows credentials either manually or it should be automatic.

May 10, 2012 at 7:50 a.m. UTC

@shoaib did you done it ? is anywhere How-TO about WINXP/WinVista/Win7 + ActiveDirectory + Cisco + 802.1X and PKI transparent ?

July 13, 2012 at 5:59 p.m. UTC


is there any tool which can simulate the machine authentiation. i want to simulate 1000 machine authentication requests for my testing purpose.


September 20, 2012 at 7:52 a.m. UTC

Excellent Post.

January 31, 2013 at 5:28 p.m. UTC

Hi, is there a way to authenticate with 802.1X and Windows server radius only PC joined in the domain?
My goal is to block domain user that want to connect their PCs to my office's lan and have (of course) a valid login. This user can come in office with their PCs, enable 802.1x insert in the pop-up user and password and their personal Pc is authenticated.
the best solution is to authenticate PC already joined in the domain and with popup only the group of admin user in the domain. Not the normal one.
Anyone have try this setup?

April 18, 2013 at 1:03 p.m. UTC

sorry for the late Response, but just for documentation...
you can add the authentication tab as follows:
go to Services and start the Service "Wired AutoConfig"

September 18, 2013 at 2:50 a.m. UTC

How is it possible that Radius server grants authentication which is being sent as a MD5 hash while username/passwords are configured in a plain text on server?

Is there a setting in your cfg file that lists MD5 as default?

Also, what would happen if supplicant client is connected to a shared network segment? Would successful authentication of one client implicate access for other computers connected to a segment?

Great post.


November 16, 2013 at 7:41 a.m. UTC

thank you . It is very nice post

Anil Kumar A
December 27, 2013 at 4:10 a.m. UTC

Very nice. Please add packet transactions when client sends wrong credentials and add GUEST_VLAN, SERVER_FAIL_VLAN and SERVER_REJECT_VLAN info as well.

krishna kanth
July 15, 2014 at 7:06 a.m. UTC

It's very helpful. thanks a lot...

May 7, 2015 at 9:04 p.m. UTC

Nice simple post on such a complex topic. Perhaps a second part can include guest and restricted vlans?

May 15, 2015 at 7:07 p.m. UTC

Thanks for great tutorial. I have one question however. What if the client on my LAN authenticates and then removes his/her laptop and goes lets say to the meeting room and plugs the cable in there? and what if someone else comes and plugs in previously authenticated port? shortly , is the authentication active as long as the client is connected or it stays authenticated even if client disconnects (this allowing someone else to plug in without auth)

August 12, 2015 at 3:57 a.m. UTC

Nice topic. Really useful and got more understanding.


September 19, 2015 at 6:26 a.m. UTC

Thank you for this topic. Is it possible to store usernames & passwords locally on the switch instead of a RADIUS server? I mean using the switch as my network RADIUS server! I have to do this in my network, because it is not possible to add a RADIUS yet. Thank you

November 3, 2015 at 4:27 p.m. UTC

I have read a few of your article and I have to say, thank you! You write in a very simple way so it is easy to understand it. Bravo!

Viet Le
February 1, 2016 at 9:24 p.m. UTC

That works like a charm!

April 27, 2016 at 5:05 a.m. UTC


could you please explain with some example, under what situations one should use force-authorized and force-unauthorized.

August 10, 2016 at 2:59 p.m. UTC

Still a valuable tutorial years later, thanks.

While trying to duplicate this lab again myself after a couple of years, I noticed after entering “dot1x port-control auto” the config has two other commands under the interface. I’ll assume they are defaults but I have not come across anything stating that yet.

dot1x pae authenticator

dot1x violation-mode protect

Another thing that I temporarily struggled with was the availability of this command in other IOS versions. This lab was apparently done on a Catalyst 3560 with 12.2(25).

What I soon discovered is if you don’t see the “dot1x port-control auto” command, which I didn't on a 3560 with 15.0(2)SE8 but did on a 3550 with 12.2(44)SE6, the first thing to check is if the trunking mode is set to access on the interface. If it is and the command is still not there, the command for some IOS versions is:

authentication port-control auto

This new command doesn’t add the other commands automatically. So you need to enter

dot1x pie authenticator

authentication violation protect

Comments have closed for this article due to its age.