cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2638
Views
0
Helpful
7
Replies

ISE 2.3 MAB Authentication ipv4 address

xayxa30
Level 1
Level 1

ISE v 2.3

Cisco 3850 ios-xe v 16.6.4

Supplicant RHEL v 7.5 (static IP address)

 

I am testing the MAB fallback configuration. Dot1x (using PEAP w/o certificates) is enabled on the supplicant interface. Everything looks like it is working as intended (tries dot1x and then MAB) with successful MAB authentication and in Authorized state but I am unable to get the IPv4 to show up ( IPv4 Address: Unknown)

 

So I assume the policies are fine and it might be the linux OS...

 

When dot1x is NOT enable on the supplicant interface, there is successful MAB authentication and in Authorized state, AND the ipv4 is there ( show authentication session int G1/0/x detail).

 

I read that device tracking may help but I'm not sure (the interface has device-tracking configured, and global device-tracking tracking auto-source) . However the  switch does not have the SVI, but is on upstream N9k.

 

Any insight into what is happening? or what other things we should be looking for ?

 

1 Accepted Solution

Accepted Solutions

IP address unknown still point to device-tracking issues.

 

remember connectivity   has nothing to do with ip address unknown, the problem will happen when you have dacl pushed,

the switch will not be able to enforce this because it doesn't know the ip address of the connected host.

 

you need to troubleshoot the device-tracking.

 

i like those document

 

https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/8021x/116529-problemsolution-product-00.html

https://www.cisco.com/c/en/us/support/docs/ip/address-resolution-protocol-arp/118630-technote-ipdt-00.html

 

please take a look at them if you still have issues, best thing to address this on a case with TAC.

 

 

 

View solution in original post

7 Replies 7

hslai
Cisco Employee
Cisco Employee

In case you meant IPv4 address not showing up in ISE Active Sessions page, then likely RADIUS accounting not configured to send requests to ISE. Please take a look at ISE Secure Wired Access Prescriptive Deployment Guide.

yalbikaw
Cisco Employee
Cisco Employee

hello, 

by any chance did you try to use other device, like windows for example ?

 

and what about the output show device-tracking database all when the MAB is connected do you see some entry ?

if yeah, then there must be something on that machine not responding to switch probes.

 

please check and let me know to proceed on the next action plan,

 

it will be nice if you showed us the configuration as well for device tracking, interface config and the aaa config.

 

 

I will have to locate another pc to test.

I did run the dot1x test eapol-capable command to the RHEL box and did not received anything back. So this might be causing the ipv4 unavailability when the interface is turned on for this capability. The device tracking database did not return anything.

This is pretty much the configuration of the switch, running both tacacs for the device administration and radius as authenticator.

 

aaa authentication login default group tac1 local
aaa authentication enable default group tac1 enable
aaa authentication dot1x default group radius1 local
aaa authorization exec default group tac1 local
aaa authorization network default group tac1
aaa accounting dot1x default start-stop group radius1

 

device-tracking tracking auto-source

authentication mac-move permit
dot1x system-auth-control

 

int G1/0/X
switch access vlan 230
switchport mode access
device tracking
authentication event fail action next-method
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication periodic
authentication timer reauthenticate server
mab
dot1x pae authenticator
dot1x timeout tx-period 15
spanning-tree portfast

 

 

I was able to put a windows PC online and test it. I was able to get dot1x authentication working with the current configs. So this means the RHEL 7 needs further work/configuration.

 

One other thing that baffled me was the windows pc -

Ran sh authentication sessions int gi 1/0/X detail on the switch where the windows pc is connected

BUT the ipv4 Adresss: Unknown

However I am able to ping out and connect fine. How is this possible without a layer 3 interface on the dot1x interface?

Did you check this guide? Sounds like dhcp snooping might no be configured? Need to have Mac to IP binding (arp) to work properly

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

IP address unknown still point to device-tracking issues.

 

remember connectivity   has nothing to do with ip address unknown, the problem will happen when you have dacl pushed,

the switch will not be able to enforce this because it doesn't know the ip address of the connected host.

 

you need to troubleshoot the device-tracking.

 

i like those document

 

https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/8021x/116529-problemsolution-product-00.html

https://www.cisco.com/c/en/us/support/docs/ip/address-resolution-protocol-arp/118630-technote-ipdt-00.html

 

please take a look at them if you still have issues, best thing to address this on a case with TAC.

 

 

 

Thanks for the links. It turns out we had several issues.

We determined that the RHEL 7.6 (FIPS-enabled) PEAP-MSCHAPv2  option is not compatible with ISE (FIPS-enabled).

Use PEAP-GTC instead and got dot1x working.

The MAB fallback was an issue because the RHEL Network Manager was managing the link (closing it because of fail authentication) during MAB.

Disabled the manager and the MAB works fine since the connection stays active.