cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1208
Views
0
Helpful
8
Replies

Struggling to get Cisco Nexus 5548 802.1x MAC Auth-Bypass working with FreeRadius

I've spent all day today trying to get this working. I've got it working perfectly on a Cisco 3750-G but can't get it to work on a Nexus 5548. I'm simply configuring 802.1x MAC Authentication Bypass with a FreeRADIUS server running 2.2.6. I've defined the clients and users on the FreeRADIUS server. I first got this working on the 3750-G and now I'm progressing on to the Nexus 5548. Whenever I attempt to connect a device to the port that I'm using for this test (Eth2/16) it goes into an "Authorization Pending" state. I've noticed also that no packets are sent to the RADIUS server on ports 1812 or 1813 using tcpdump. On the other hand when I connect something to the 3750-G it's very clear that a request has been sent to the server. The server is running in debug mode (radiusd -X). On the switch I can enter: "test aaa server radius 192.168.101.11 50f7222df327 50f7222df327" and it comes back stating it's successful. And when I use that command I do indeed see a request come into the RADIUS server. Just never when I attempt to plug a device into the port.

 

To make things a little more complicated I've got TACACS+ running on the same server; but that is working fine. It's just some extra configuration settings on the switch that hopefully won't cause confusion.

 

Here's the relevant configuration settings I've applied to the switch:

 

feature dot1x
tacacs-server host 192.168.101.11 key 7 "XXXX"
aaa group server tacacs+ SSVR
    server 192.168.101.11
    source-interface Vlan101
radius-server host 192.168.101.11 key 7 "XXXX" authentication accounting
aaa group server radius NetMan1
    server 192.168.101.11
    source-interface Vlan101
aaa authentication login default group SSVR local
aaa authentication login console group SSVR local
aaa authorization config-commands default group SSVR local
aaa authorization commands default group SSVR local
aaa authentication dot1x default group NetMan1
aaa accounting default group SSVR
aaa authentication login error-enable
vlan 40
    name Workstations
vlan 101
    name Servers
vlan 118
    name Dot1x_Clients
interface Vlan101
    no shutdown
    ip address 192.168.101.2/24
interface Ethernet2/16
    description 802.1x Test
    dot1x port-control auto
    dot1x pae authenticator
    dot1x mac-auth-bypass
    no cdp enable
    switchport access vlan 40
    speed 1000
ip radius source-interface Vlan101

On the FreeRADIUS server I have the following defined in the Clients.conf file:

client 192.168.101.1 {
    secret = XXXX
}

client 192.168.101.2 {
    secret = XXXX
}


In the Users file is have:

 

50f7222df327 Cleartext-Password := "50f222df327"
    Service-Type = "Framed-User",
    Tunnel-Type = 13,
    Tunnel-Medium-Type = 6,
    Tunnel-Private-Group-ID = 118

 

What weirds me out about Nexus is that I can't define an authentication priority (mab first) like I could with the IOS switch. What's also weird is that I can't seem to define a guest-vlan on the interface either; it's not an available option on the interface.

If anything jumps out at you please let me know. Thanks!

8 Replies 8

balaji.bandi
Hall of Fame
Hall of Fame

Personally Nexus is more of DataCenter environment, here we expect more of Servers and Printers, This is not like Access Switch where the end devices connected.

 

There is are limited features you can expect to work here.

 

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus6000/sw/security/602_N1_2/b_6k_Security_Config_602N12/b_6k_Security_Config_602N12_chapter_0111.pdf

 

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

I get that they're typically used in a datacenter.  And for the most part that's what we're using ours for with some minor exceptions.  I've setup my 5548 per the guide that you linked.  Well, actually the one specifically written for the 5500 series Nexus devices found here.  The thing though is; while yes they're typically used for datacenters, there's nothing in the document that indicates this shouldn't work.  In fact, most of what's in that document indicates that this should indeed work.  So based on what's in that document, and what I've included in my post, do you see anything I've done wrong?

Can you think of any reason why it wouldn't even attempt to send any packets of any kind to the RADIUS server when a device (I'm plugging in a Cisco VoiP phone) gets plugged into the port?

Also, I'd like to get away from using a phone to test this with (it's the only thing that seems to allow the switch port to come up) and simply plug in a laptop but when I plug in a laptop that I know is capable of 1000BaseT/Full Duplex, it doesn't come up for some reason. I'm using a GLC-T SFP and I've included "speed 1000" on the interface. Is there something else I'm missing that's preventing me from connecting a laptop?

I'm kind of suspecting that the fact that I'm using a phone is causing MAB to behave differently.

Okay, so I was finally able to get a laptop to come up on the port.  I was trying old laptops before and they wouldn't negotiate correctly.  I did not have to change anything on the switch interface as long as "speed 1000" was defined.

 

So now with a Windows 7 laptop connected using Wireshark I can see the EAP-request/identity frame come in from the nexus switch to the laptop but I do not see an EAP-response/identity frame go out from the laptop to the nexus switch in response.  I think that is correct since I am not configuring the supplicant for full 802.1x but trying to configure MAC Authentication Bypass.  No configuration with respect to 802.1x has been made on the laptop. 

 

According to the documentation, "if 802.1X authentication times out while waiting for an EAPOL response from the supplicant, the Cisco NX-OS device tries to authorize the client by using MAC authentication bypass."  So as long as my laptop doesn't respond to the EAP-request/identity frame then the switch should eventually resort to using "the MAC address as the supplicant identity" and send "the authentication server" (my RADIUS server 192.168.101.11) "a RADIUS-access/request frame with a username and password based on the MAC address."  This is not happening.  I am not seeing any traffic from the nexus switch come into my RADIUS server.  The only time I do is when I use the "test aaa server radius <username> <password>" command on the Nexus switch.

I've made progress on this. After my last post it occurred to me that the switch was never giving up trying request the identity of the laptop. I needed to make it give up (or timeout) and then resort to MAB. So I added "dot1x timeout supp-timeout 5" to my eth2/16 interface. That's when I started seeing actual requests come into the RADIUS server. But the RADIUS server was replying with an ACCESS-REJECT message. I then noticed that the Nexus switch was sending the username and password in all caps and the user account was defined in lower case. So I adjusted the Users file to include all caps MAC address and password. At this point it's now authenticating successfully and authorizing access to the port.

The only thing that remains is getting it to assign the proper VLAN. As you can see on my eth2/16 interface it's configured for "switchport access vlan 40". The RADIUS server is supposed to put this user in VLAN 118. So far this isn't happening so that's what I'm working to figure out next.

Glad and Good effort, agreed some exceptional cases we do not option than delvery as technical consultant.

 

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

I'm not there yet.  "Dynamic VLAN assignment based on MAC-Based Authentication" is really what we've been striving for.  The port is not getting assigned to the VLAN as indicated in the Access-Accept Message.  I've confirmed in my Users file that the following is defined:

50f7222df327    ClearText-Password := "50f7222df327"
    Tunnel-Type=13,
    Tunnel-Medium-Type=6,
    Tunnel-Private-Group-ID=118

 

I can see on the Radius server's debug output that when the client gets authenticated the Access-Accept Message gets sent.  The output shows:

Sending Access-Accept of id 74 to 192.168.101.2 port 43920
     Tunnel-Type:0 = VLAN
     Tunnel-Medium-Type:0 = IEEE-802
     Tunnel-Private-Group-ID:0 = "118"

I even setup a span port on the nexus switch and used WireShark to capture the Access-Accept packet to ensure that the switch is receiving it.  The Access-Accept packet in WireShark has the following Attribute Value Pairs:

AVP: t=Tunnel-Type(64) l=6 tag=0x00 val=VLAN(13)
AVP: t=Tunnel-Medium-Type(65) l=6 tag=0x00 val=IEEE-802(6)
AVP: t=Tunnel-Private-Group-ID(81) l=5 val=118

So I know that the switch is receiving the Access-Accept packet with the proper tunnel attributes.  But the switch doesn't appear to be reading them or applying them as it should.

 

I turned on "debug radius aaa-request" and then ran: "dot1x re-authenticate int eth2/16". 

Here's the output I saw:

NexusFiveKLab# dot1x re-authenticate int eth2/16
NexusFiveKLab# 2019 Jan 9 21:38:44.550973 radius: get_radius_server_info_from_group:
2019 Jan 9 21:38:44.551038 radius: radius_update_request_state_for_server(1439):retrieved the global-conf.
2019 Jan 9 21:38:44.551087 radius: is_intf_up_with_valid_ip(1347):Proper IOD is found.
2019 Jan 9 21:38:44.551146 radius: is_intf_up_with_valid_ip(1350):Port is up.
2019 Jan 9 21:38:44.551258 radius: radius_update_request_state_for_server(1519):Using if_index Vlan101
2019 Jan 9 21:38:44.551296 radius: radius_update_request_state_for_server(1594):Server-shared-secret encryption-type is PROTO_NO_ENCRYPTION.
2019 Jan 9 21:38:44.551328 radius: radius_update_request_state_for_server(1652):Server-shared-secret is present in plain.
2019 Jan 9 21:38:44.551397 radius: radius_update_request_state_for_server(1679): request->id : 74
2019 Jan 9 21:38:44.551509 radius: num_inet_addrs: 1 first s_addr: 40216768 2.101.168.192 s6_addr : c0a8:6502::
2019 Jan 9 21:38:44.551546 radius: radius_get_ip_local_from_src_index(413):interface ip_type: IPV4
2019 Jan 9 21:38:44.551580 radius: s_addr no: 0, numeric_ip: 40216768, ip: 2.101.168.192
2019 Jan 9 21:38:44.551614 radius: get_destination_socket: last_id = 74
2019 Jan 9 21:38:44.551645 radius: getaddrinfo serv_port 1812
2019 Jan 9 21:38:44.551676 radius: get_destination_socket(271): Setting context id to 1
2019 Jan 9 21:38:44.552222 radius: radius_set_src_intf(1944):setsockopt success, using src-intf:for server: 192.168.101.11 for sock: 44 Error returned:0x0 errno string:No such file or directory
2019 Jan 9 21:38:44.553524 radius: radius_request_process: DATA_AVAILABLE
2019 Jan 9 21:38:46 NexusFiveKLab %DOT1X-3-AUTH_SUCCESS: Authorization successfull Dot1x authentication on interface Ethernet2/16

I'm concerned about the 3rd from the bottom and the 2nd from the bottom lines.  I'm thinking that's where the switch is failing to read the tunnel attributes or to apply them.  I'm interested in knowing what it means on the 2nd from the bottom line about DATA_AVAILABLE.  I'm feeling like this is getting to the point where I need genuine Cisco support and that this has got to be hitting on a bug in their software.

I'm not there yet.  "Dynamic VLAN assignment based on MAC-Based Authentication" is really what we've been striving for.  The port is not getting assigned to the VLAN as indicated in the Access-Accept Message.  I've confirmed in my Users file that the following is defined:

50f7222df327    ClearText-Password := "50f7222df327"
    Tunnel-Type=13,
    Tunnel-Medium-Type=6,
    Tunnel-Private-Group-ID=118

 

I can see on the Radius server's debug output that when the client gets authenticated the Access-Accept Message gets sent.  The output shows:

Sending Access-Accept of id 74 to 192.168.101.2 port 43920
     Tunnel-Type:0 = VLAN
     Tunnel-Medium-Type:0 = IEEE-802
     Tunnel-Private-Group-ID:0 = "118"

I even setup a span port on the nexus switch and used WireShark to capture the Access-Accept packet to ensure that the switch is receiving it.  The Access-Accept packet in WireShark has the following Attribute Value Pairs:

AVP: t=Tunnel-Type(64) l=6 tag=0x00 val=VLAN(13)
AVP: t=Tunnel-Medium-Type(65) l=6 tag=0x00 val=IEEE-802(6)
AVP: t=Tunnel-Private-Group-ID(81) l=5 val=118

So I know that the switch is receiving the Access-Accept packet with the proper tunnel attributes.  But the switch doesn't appear to be reading them or applying them as it should.

 

I turned on "debug radius aaa-request" and then ran: "dot1x re-authenticate int eth2/16". 

Here's the output I saw:

NexusFiveKLab# dot1x re-authenticate int eth2/16
NexusFiveKLab# 2019 Jan 9 21:38:44.550973 radius: get_radius_server_info_from_group:
2019 Jan 9 21:38:44.551038 radius: radius_update_request_state_for_server(1439):retrieved the global-conf.
2019 Jan 9 21:38:44.551087 radius: is_intf_up_with_valid_ip(1347):Proper IOD is found.
2019 Jan 9 21:38:44.551146 radius: is_intf_up_with_valid_ip(1350):Port is up.
2019 Jan 9 21:38:44.551258 radius: radius_update_request_state_for_server(1519):Using if_index Vlan101
2019 Jan 9 21:38:44.551296 radius: radius_update_request_state_for_server(1594):Server-shared-secret encryption-type is PROTO_NO_ENCRYPTION.
2019 Jan 9 21:38:44.551328 radius: radius_update_request_state_for_server(1652):Server-shared-secret is present in plain.
2019 Jan 9 21:38:44.551397 radius: radius_update_request_state_for_server(1679): request->id : 74
2019 Jan 9 21:38:44.551509 radius: num_inet_addrs: 1 first s_addr: 40216768 2.101.168.192 s6_addr : c0a8:6502::
2019 Jan 9 21:38:44.551546 radius: radius_get_ip_local_from_src_index(413):interface ip_type: IPV4
2019 Jan 9 21:38:44.551580 radius: s_addr no: 0, numeric_ip: 40216768, ip: 2.101.168.192
2019 Jan 9 21:38:44.551614 radius: get_destination_socket: last_id = 74
2019 Jan 9 21:38:44.551645 radius: getaddrinfo serv_port 1812
2019 Jan 9 21:38:44.551676 radius: get_destination_socket(271): Setting context id to 1
2019 Jan 9 21:38:44.552222 radius: radius_set_src_intf(1944):setsockopt success, using src-intf:for server: 192.168.101.11 for sock: 44 Error returned:0x0 errno string:No such file or directory
2019 Jan 9 21:38:44.553524 radius: radius_request_process: DATA_AVAILABLE
2019 Jan 9 21:38:46 NexusFiveKLab %DOT1X-3-AUTH_SUCCESS: Authorization successfull Dot1x authentication on interface Ethernet2/16

I'm concerned about the 3rd from the bottom and the 2nd from the bottom lines.  I'm thinking that's where the switch is failing to read the tunnel attributes or to apply them.  I'm interested in knowing what it means on the 2nd from the bottom line about DATA_AVAILABLE.  I'm feeling like this is getting to the point where I need genuine Cisco support or an engineer to look into the guts of the software.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: