cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 

XMC - Authentication question

XMC - Authentication question

AntonioP
New Contributor II
Hello,

please apologize my English and tyvm for having this hub so we can discuss tech stuff.

Im having an issue regarding info i see on the XMC. Im not sure where to begin explaining this, but basicaly the XMC is showing me apipa IP for a given host even though im sure it has got the IP reserved for that MAC from the DHCP server. Im sure because i can ping the IP and the name of the host is resolved correctly.

Thing is, when this happens the policy configured to take effect does not apply and the end device lands on a different VLAN other than the one the policy is supposed to send ot he port.

Im not sure if this a XMC issue or something going on between the SW and the DHCP server.

I caught one of the end devices passing from the reserved dhcp IP to the apipa and this is what i see.

16a57d30f6084f878df1c929cd673964.png
10210e6720b4463eb1f0580b416cb88a.png
db5a3a76f03b472193663d644eac7397.png1e936509fe264b8f95bc423b6e2bf0bb.png
What im asking is if there is any relation or known issue between the way this device is following authentication, as i see it first tries to MAC auth and succeeds, but then goes dot1x and fails, and the fact that the XMC shows me apipa ip, even though im sure the end device got the dhcp reserved ip and i can ping it, but simply im having an issue with not landing on correct vlan.

Sorry if this is confusing.. 

Any ideas would be great. 

Thank you.
1 ACCEPTED SOLUTION

Hello,

Do you have any global subnets enabled for Router IP discovery? If the subnet is not defined these act as filters and can prevent showing the correct address. 

I think that screenshot is from policy "User Sessions" tab. Does it show the same 169 address in Control end systems tab as it does in the policy "User Sessions". Policy User sessions is a bit different from end system information from Control. 

If you see the same 169 address in Control you can try the following: 

Right click the NAC that will be handling the authentication for the end system --> WebView --> Diagnostics --> Appliance/Server Diagnostics

Set the following to "Verbose"

Authentication request processing - NAC

IP resolution

DHCP

Click OK. 

Then delete the end system in control and have the device re-authenticate. Once the link local address is seen, go back and disable diagnostics. The log will contain information on how IP resolution was determined. You can try to search the log for the actual IP address of the device, or the link local. 

Searching by last 3 octets of the mac address hyphen delimited will show all debug lines associated to the end system itself. 

Eg: 

If mac address is: 

12:34:56:11:AA:22

Search for: 

11-AA-22

The debug log may contain sensitive information so I would not suggest uploading it to this thread. 

Thanks
-Ryan

View solution in original post

8 REPLIES 8

Ryan_Yacobucci
Extreme Employee

Hello,

Control has a couple of different mechanisms it can use for IP resolution when integrating with EXOS switches. The only way to figure out exactly how this address was identified is to turn on debug for "IP Resolution" and check debug logs. 

Do you know if nodealias is enabled on the port? If you do a "show nodealias port" do you see the correct IP address in nodealias?

Nodealias is the primary mechanism for IP resolution for EXOS switches.

The other thing that you may be able to do is in Control --> Engines --> right click the Engine --> Engine Settings --> IP resolution set the "Use DHCP Request IPs" set the it to "Always".

As long as you are relaying DHCP requests to the NAC it can now  use them to help populate IP addresses. 

Thanks
-Ryan
 

HI Ryan, thank you very much for taking the time to reply.

Ill be juming right in.

Output of the port 
2a37a09e76e7422f9997f9ff933eae6e.png
Regarding the engine option, what kind of impact may i expect if i do enable the option? Asking because im doing it on a live environment.

bcf083088c6142bab3b12858f841cc21.png
Ill try to post any relevant info from the debug. 
Trying for the NAC also but it wont le me open webview atm...dont know why.

Ty.

TimS
New Contributor II
There is no impact for authentication devices, only information for the ip address. Please pay attention to configure dhcp relays to the nac engines. Without relaying to nac engines, they wont know the ip address informations about the client.

AntonioP
New Contributor II
Hi Tim,

ty for replying.

I will check the dhcp relay again but this is happening for end devices that have been identified as mostly printers and the other hundreds of devices are ok.

They get the correct IP address reserved for them in the dhcp server, but often i get a call saying the printer is not working again, i check the XMC and the ip listed is apipa.

I still dont know if theres is something wrong with the dynamic vlan being applied via policy to the switch port of that end device, but something is really fishy here.

When this happens im reading this in the end device event log


"The authentication request was rejected due to NTLM authentication error: No response to NTLM request"
"Authentication request became stale, challenge sent, no response received from client"


Once again, these are end devices that do get the correct ip add from the dhcp server, they work fine for a given time, but then something happens that makes them go to sleep.

TY for your time. 

GTM-P2G8KFN