In this post I will show you again the power of GNS3 in doing laboratories to test new features. I will provide you a Lab example to configure and test port-based 802.1X authentication over a wired connection having a Windows Server 2012 configured as AD, DHCP and NPS/Radius, a switch running on IOU Layer 2 image and a Windows 7 Client. The topology looks like this:
As you can see I have 1 server and 2 clients, one of them is a GNU/Linux PC. You don’t really need the GNU/Linux PC for this lab, I used it exclusively to run some personal tests.
I have to tell you that I decided to run Windows Server in VmWare Workstation (I used version 11). I decided to go for that for 2 reasons: first GNS3 is going to be very soon updated with full support to VmWare so we will be able to use guests in VmWare more or less in same way we are doing now with VirtualBox. Second reason is that I wanted to have an overview of the current interaction between VmWare and GNS3 under GNU/Linux, also because this is slightly different than how it works using Windows as Host.
The goal of this blog post will be to show you how to configure your GNU/Linux box to use Windows Server with VmWare and how to configure the switch and Windows Client to use port based 802.1x authentication. In particular we want that the PC client will get access to the Network ONLY if the user is authenticated toward the Active Directory. This will give the opportunity to better understand the protocols and how to manage them in case you will be asked to implement them in a real world. I will not cover the configuration of the Windows Server and I will not show you how to have Win7 PC joining the Windows domain. For that I will only give you some links that will guide you through the necessary steps if you don’t know what to do.
Let’s start, then, preparing our GNU/Linux Host to have VmWare “talking” to GNS3. As you probably know at the moment the only way to achieve this goal is to use the GNS3 Cloud. Actually I am using Fedora 21 as Linux Host but commands I will use in the Terminal are valid also with other distributions.
By default, when you install VmWare, it creates 3 new network interfaces (vmnet0, vmnet1, vmnet8). You can double check your current interfaces typing the command “ifconfig” in your GNU/Linux console/terminal.
For my lab I used a new dedicated VmNet host-only interface that I then linked to my Windows Server. The creation of the new interface is very easy. In VmWare Workstation click on Menu “Edit –> Virtual Network Editor”. You will be asked for your root password and then a new window will open. There you need to click on button “Add Network” and you will create a new interface (I used vmnet6) as host-only network. The final result you want to have is the following:
It is important to unselect the option to use DHCP. For the Subnet IP you can use whatever you prefer because we are going to remove the configuration very soon.
Now, select your Windows Server Virtual Machine in VmWare, click the mouse right button and then “Settings“. In the window that will open, add (or select for the one already there) the VmNet6 network interface:
Save the change and open a Terminal in GNU/Linux. Login as root user and type the following commands:
# tunctl -u <your_username> -t tap6
# ifconfig tap6 0.0.0.0 promisc up
# ifconfig vmnet6 0.0.0.0 promisc up
# brctl addbr br6
# brctl addif br6 tap6
# brctl addif br6 vmnet6
It is possible that you receive a message of error when you try to use tunctl. If so, you need to install tunctl utility. The same will be with brctl and in that case you will need to install bridge-utils package. Please refer to your GNU/Linux distribution for that.
Moreover, in the first command please change <your_username> with the name of the user that will run GNS3.
We are now ready to add the link between our Windows Server running under VmWare and GNS3. If you are using my lab you will just need to open the proper file, otherwise you can simply create a new project from scratch, and add a Cloud in your project:
I also changed the name of the Cloud to Windows Server 2012-AD+NPS in the “Misc.” Tab as well as the symbol of the Cloud to the one of a Server.
Now, you are ready to add in your topology a Switch and the Windows 7 Client. Once you do this, you can start Windows Server in your VmWare and then start all other devices (Switch and Win7 CLient) in GNS3. In my LAB I used the network 172.16.134.0/24 and I assigned the static IP 172.16.134.128 to Windows Server. I configured then Win7 to obtain the address from DHCP Server configured as well on Win Server. The Ip address assignment worked fine (so the communication between the Cloud/Windows Server 2012 was properly configured) and then I had Win7 joining the AD Domain previously configured on the Server
At this time the switch configuration is not touched at all. Links are in the default VLAN 1 and there is no security configuration or any other feature active. Is now time to configure 802.1x!
I assume you already know what 802.1x is and how it works more or less. If it’s not the case, please read at least this document from Cisco.com pages. Our goal is to configure all components – and especially the switch – to have the feature working:
In our LAB we will have Win7 as Supplicant, IOU Layer2 switch as Authenticator and Windows Server 2012 as Authentication Server. It’s worth to mention that a very important role will be the one of the Windows Server that will act as a Radius server for the authentication and will at the same time provide authorized username/password from Active Directory that is configured on same virtual machine. As I told you before I will not cover the configuration of Windows Server but you can follow this guide to prepare your virtual machine (even if it is for Windows Server 2008 and for WiFi authentication, you can adapt for your scope without issues as I did for myself).
Is now time to finally configure the switch! It is possible to configure several features thanks to 802.1x but what we are going to do is a very simple one where the switch will keep the port in non-authorized state until the authentication with EAPOL will positively occur.
Let’s jump on our switch console and add the following global config commands:
# conf t
(config) # dot1x system-auth-control
(config) # aaa new-model
(config) # aaa authentication dot1x default group radius
Till now we only added to the switch the dot.1x capabilities. It’s now time to configure 1 SVI, the radius server to query for authorization and the port(s) we want to be authorized before they get access to the network:
(config) # int vlan1
(config-if) # ip address 172.16.134.5 255.255.255.0
(config-if) # exit
(config) # radius-server host <IP_of_RADIUS_Server> key <Password_of_Radius>
(config) #ip radius source-interface vlan1
(config) # interface eth2/0
(config-if) # switchport mode access
(config-if) # authentication host-mode multi-host
(config-if) # dot1x pae authenticator
(config-if) # authentication port-control auto
Above commands I guess are quite intuitive regarding their role. I used vlan1 as SVI and access vlan because I wanted to keep things simple. The result of what we did is that now the port eth2/0, even if will be UP/UP will not give access to the network to the device that is connected to it (in our lab Win7 client). We will start receiving some messages on the console like this one:
%AUTHMGR-5-FAIL: Authorization failed for client (Unknown MAC) on Interface Et2/0 AuditSessionID AC1086050000000200C7A9C1
It is clear that this is what we wanted to have as a result before the client will be authenticated!
We can also check the status of the port and authorization with the commands:
#show authentication interface eth2/0
#show authentication sessions interface eth2/0
The last step is to “teach” to our Windows 7 client to authenticate using 802.1x. You can use this guide to have that. After everything is configured, the EAP protocol will work properly:
We can of course also double check the status of the authorization on the switch port:
#show authentication sessions interface eth2/0
MAC Address: 0800.2706.b87e
IP Address: Unknown
Status: Authz Success
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: multi-host
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: N/A
Session timeout: N/A
Idle timeout: N/A
Common Session ID: AC1086050000000800F72E6E
Acct Session ID: 0x0000000A
Runnable methods list:
dot1x Authc Success
If you would like to be informed about new posts I will publish on the blog you can subscribe to the newsletter: