Monday, 18 February 2013

Testing Cisco 802.1X Authentication with VMWare & GNS3

Yet another snappy blog title. I had reason recently to test 802.1X interface authentication using a GNS3 emulated Cisco 3725 and Freeradius, so here it is, delightfully pointless and true to the spirit of Pointless Posts; I did this merely as I wanted to see how it worked. Creating the topology, as ever, is almost as much fun as actually making it work: I have used a VMWare virtual adapter to get the 802.1x compatibility; the virtual Cisco router acts as the authenticator joining the vmware adapter to the physical network. This is NOT very reliable on a wireless adapter, but it proves the point.

First of all I created a VMWare virtual adpater which we were going to use for 802.1X authentication.  See the below screenshots.

VMWare Virtual Adpater Settings

This is connected to a Cisco 3725 running virtually on GNS3. The other interface of this connects to wireless adapater, thus can connect to the radius:



 The Cisco config itself is really easy :
hostname Cisco3725
aaa new-model
aaa authentication dot1x default group radius
!
dot1x system-auth-control
!
##this interface connects to LAN of radius server
interface FastEthernet0/0
 ip address 192.168.1.10 255.255.255.0
 duplex auto
 speed auto
!
##this interface connects to client
interface FastEthernet0/1
 no ip address
 duplex auto
 speed auto
 dot1x pae authenticator
 dot1x port-control auto
!
radius-server host 192.168.1.74 auth-port 1812 acct-port 1813 key testing123
Once the interfaces can see each other it asks for authentication details:

Network Authentication dialogue appears

However there was an initial failure, so followed the debug:
[suffix] No '@' in User-Name = "nicholas", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] EAP packet type response id 3 length 6
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] returns updated
[files] users: Matched entry nicholas at line 205
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING: Auth-Type already set.  Not setting to PAP
++[pap] returns noop
Found Auth-Type = EAP
# Executing group from file /usr/local/etc/raddb/sites-enabled/default
+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] EAP NAK
[eap] NAK asked for unsupported type PEAP
[eap] No common EAP types found.
[eap] Failed in EAP select
++[eap] returns invalid
Failed to authenticate the user.
        expand: Bad! -> Bad!
Login incorrect: [nicholas/] (from client 192.168.1.10 port 0 cli 0050.56c0.0001) Bad!
Using Post-Auth-Type Reject
No common EAP type seemed to be the issue. This was caused by not compiling Freeradius with OpenSSL libraries so PEAP/TLS requirements were actually ignored in eap.conf. PEAP needs TLS needs OpenSSL. It was required then to install Openssl then recompile Freeradius from source. This was done and when run as root a certificate generated – if its not then there is your alarm bell – make sure to get the right key in eap.conf to match the “whatever” in server.crt (I did not first time…!) Eap.conf needs a few minor changes to make it work:
Eap {
default_eap_type = peap
}
Check TLS configuration too:
       tls {
                        #
                        #  These is used to simplify later configurations.
                        #
                        certdir = /etc/raddb/certs
                        cadir = /etc/raddb/certs

                        private_key_password = whatever
                        private_key_file = /etc/raddb/certs/server.pem
Finally it all works, the windows adaptor authenticates using mschapv2 through PEAP on the radius through the Cisco:

Successful authentication,

No comments:

Post a Comment

Found this pointless and feel you must comment? Really, there is no need, we are fully aware of the pointlessness of this article. But if you must...

Google+ Followers