01-09-2019 06:19 AM - edited 03-08-2019 04:59 PM
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!
01-09-2019 07:24 AM
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.
01-09-2019 07:39 AM
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?
01-09-2019 08:41 AM
01-09-2019 09:49 AM
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.
01-09-2019 11:22 AM
01-09-2019 12:12 PM
Glad and Good effort, agreed some exceptional cases we do not option than delvery as technical consultant.
01-09-2019 03:17 PM - edited 01-09-2019 03:21 PM
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.
01-09-2019 03:23 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide