Dot1x radius request not reaching ise

[michalis1234]

I have c9300 16.6.4a everest ios xe.

Ihave ise 2.4 patch 4.

I have configured the mgmt interface g0/0 as the the source interface for radius requests, but it does not seem to send the requests to ise. Radius for device administration is working. Aaa servers are up, test user for radius request is working. The problem is dot1x or mab requests are not reaching ise.

The switches are pure l2 no svi only mgmt interface. Rechability to ise is fine.

Does mgmt interface support dot1x radius requests ?

[Nadav]

Hi there,

This has been discussed in the past. Since the mgmt-interface is in a VRF of its own, you'll need to use ip vrf forwarding to move the RADIUS traffic back and forth between the MGMT interface and the other interfaces. It could also be that your AAA configuration is missing something. 

1) Paste your configuration here (AAA, interfaces, ip routes, AAA groups...)

2) Take a look at:  https://community.cisco.com/t5/policy-and-access/3850-aaa-using-mgmt-vrf/td-p/3028097

[michalis1234]

I have created test user and radius is working fine. Hence i do not believe it is a vrf routing issue at all. According to the below document:

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/16-8/configuration_guide/int_and_hw/b_168_int_and_hw_9500_cg/b_168_int_and_hw_9500_cg_chapter_01.html

Cisco managment interfaces does not support features as dot1x.

I believe my issue is related to it. Do you have any opinion about that ? Because myself have not previous experience on ise dot1x.

[Nadav · Accepted solution]

Well it's like you said: your switch doesn't have any SVI's but only a Mgmt-Interface. Meaning your authenticatior's IP address for RADIUS communication with the RADIUS server must be the Mgmt interface's IP address. Can EAPOL from a switchport know how to route from the switchport to the Mgmt VRF and route back the response from the Mgmt VRF to the switchport?

A test user tests a similar data-path as device administration, which as you've said works just fine. It wouldn't test end-to-end supplicant to switch, and then switch to RADIUS server. It's basically staying within the Mgmt VRF and therefore wouldn't need any vrf forwarding. 

I think you should give the vrf forwarding as it's been discussed in previous posts a shot. Also, it would be best if you could upload the relevant configuration to this thread so others can have a look. There might be a misconfiguration. 

[michalis1234]

I have also configured an svi for mgmt vlan such that an eapol on a switchport can reach ise from main routing table. But still the request are not reaching ise... c9300 switches require the new style of dot1x configuration in order to operate correctly?

[Nadav]

IBNS 2.0 (the new form of AAA) isn't a requirement. You can still configure things in legacy mode.

It would help you down the line to configure things in IBNS 2.0 though assuming you're using 16.x software for your access devices, since it has some useful features you may want in the future. 

Check out this guide for more:  

https://community.cisco.com/t5/security-documents/ise-secure-wired-access-prescriptive-deployment-guide/ta-p/3641515

[michalis1234]

The solution to the problem was to source radius requests from main routing table through the management vlan, and correctly reference ta radius groups.

aaa group server radius RADIUS_SRV
server name ISE-1
server name ISE-2
ip radius source-interface Vlan management

radius server ISE-1
address ipv4 x.x.10.52 auth-port 1812 acct-port 1813
automate-tester username test probe-on
key cisco

radius server ISE-2
address ipv4 x.x.10.53 auth-port 1812 acct-port 1813
automate-tester username test probe-on
key cisco

on the aaa group i was not referencing radius servers with their name, thus the NAD did not initiate radius requests to ISE.

[michalis1234]

Below is the configuration elements you requested:

aaa new-model

aaa group server radius RADIUS
server x.x.10.52
server x.x.10.53
ip vrf forwarding Mgmt-vrf

aaa authentication dot1x default group RADIUS
aaa authorization network default group RADIUS

aaa accounting identity default start-stop group RADIUS

aaa server radius dynamic-author
client x.x.10.52 vrf Mgmt-vrf server-key cisco
client x.x.10.53 vrf Mgmt-vrf server-key cisco
aaa accounting update newinfo periodic 2880

interface GigabitEthernet0/0
vrf forwarding Mgmt-vrf
ip address x.x.10.6 255.255.255.0 -> same asubnet as ISE-1, ISE-2
no ip route-cache
speed 1000
negotiation auto

interface GigabitEthernet1/0/10
switchport access vlan 10
switchport mode access
switchport nonegotiate
device-tracking
authentication periodic
authentication timer reauthenticate server
access-session host-mode multi-domain
access-session port-control auto
mab
dot1x pae authenticator
dot1x timeout quiet-period 5
dot1x timeout tx-period 3

spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
spanning-tree guard root

ip default-gateway x.x.10.254

ip route vrf Mgmt-vrf 0.0.0.0 0.0.0.0 x.x10.254

ip radius source-interface GigabitEthernet0/0 vrf Mgmt-vrf

radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server attribute 31 mac format ietf
radius-server attribute 31 send nas-port-detail mac-only
radius-server dead-criteria time 10 tries 3

radius server vsa

radius server ISE-1
address ipv4 x.x.10.52 auth-port 1812 acct-port 1813
automate-tester username test probe-on
key cisco

radius server ISE-2
address ipv4 x.x.10.53 auth-port 1812 acct-port 1813
automate-tester username test probe-on
key cisco

[Nadav]

Maybe you just omitted it by accident, but where is "dot1x system-auth-control"? Without it port-based dot1x won't run.

The VRF handling seems ok as far as I can tell, assuming the gateway is reachable. You could connect to a non-dot1x port in the same VLAN and see if you can reach the Mgmt-interface from that port by ICMP. 

[michalis1234]

I have the command for dot1x.

It turns out that it should a firewalling issue to the management vlan, where vrf is connected.

I need to speak with the firewall guy.

We need to allow radius traffic to flow from user, voice vlans to ise, correct ?

Because in a conversation that i had before the deployment we decided that the radius communication will be held between nad and ise and would not involve any endpoint vlan.

According to your recommendations endpoint vlans need to have radius communication directly to ise , have i understood correctly?

Thanks in advance.

[Nadav]

Not quite,

RADIUS is between your NAD (switch) and the RADIUS server. The endpoints communicate with the switch in EAPOL, which is then encapsulated by the switch in RADIUS and sent to the RADIUS server. Here is an illustration:

https://www.cisco.com/c/dam/en/us/td/i/200001-300000/210001-220000/214001-215000/214095.eps/_jcr_content/renditions/214095.jpg

If you're seeing RADIUS drops between the Mgmt interface and RADIUS servers, that's a problem. But endpoints cannot communicate directly with the RADIUS server during dot1x authentication.

[michalis1234]

Yes indeed you are correct.

I will update you as soon as i have a solution.

Regards.

[Damien Miller]

You need to allow the switch management svi/vlan/ip to communicate directly with the ise nodes for standard radius authentication. The switch acts as the proxy for the client during authentication. 

You only have to allow user subnets if you are performing web authentication, for example using the ise guest portal. ISE will send a url redirect to the switch, the client will be redirected to a ISE node to enter credential on a web page.