WLC 9800-L - Authentication failed for client

[Marcin.Bachmatiuk]

Hi,

i have a problem with authentication in WLC 9800-L, I have configured the Radius servers and SSID, but the client cannot authenticate himself to radius.

Feb  4 16:16:34.041: %DOT1X-5-FAIL: Chassis 1 R0/0: wncd: Authentication failed for client (8086.f285.a2f5) with reason (AAA Server Down) on Interface capwap_90000016 AuditSessionID 17DC140A00000010C5851691 Username: 123456
Feb  4 16:16:34.041: %SESSION_MGR-5-FAIL: Chassis 1 R0/0: wncd: Authorization failed or unapplied for client (8086.f285.a2f5) on Interface capwap_90000016 AuditSessionID 17DC140A00000010C5851691. Failure reason: Authc fail. Authc failure reason: AAA Server Down.

Can anyone help me ??

[Rich R]

The original poster didn't actually provide a solution and claimed to not have access to the radius server so no way of knowing it's the same problem.  Basic principles apply - read through all the answers provided already.
1.  Are you *sure* it's being sent from the same IP you have configured?  Remember 9800 follows the routing table to get to the radius and source IP used is either outgoing interface or the one you specify.
2. Have you got the correct shared key configured - I reckon the wrong key could also be an invalid client?

[network_eng]

When I filter on the wireshark captures done from the 9800 for udp.port==1812 the radius access-request packets show the source address as the configured client IP I used in the radius server config. Is there another way to validate it?

I checked and re-checked the shared key, I even put in the wrong one to see the output which gave a different error message in the show aaa servers command output (it complained about bad authenticators).

I just can't get my finger on this one, I will log a ticket with Cisco today.

[network_eng]

Btw everything works fine with the old 2504 WLC in the environment but it just doesn't with the 9800 (It is a migration that I am finishing up - guest access works perfectly but not the corporate internet which relies on the radius authentication).

[network_eng]

I think this might be pointing to asymmetrical routing as I think I should at least be receiving a reject message or some other information if the policy on the server is not matching the received conditions/attributes. I created a new client with exactly what was required from the 9800 WLC but got the same result in the capture as if communication isn't getting back. I will check the routing in the environment to see what is happening. Maybe the packets are being received by the NPS but the reply is being sent back to another interface IP on the WLC that isn't reachable...investigations in progress

[Rich R]

Remember the 9800 will route the request packet according to the IP routing table so "sh ip rout" will show you whether it's going out the interface you expect it to.  If not then correct the routes as required.  Obviously the server needs to be able to route back to the source of the radius requests - not necessarily always the same interface it went out of but if it's going through a firewall or NAT then asymmetric routing is likely to cause drops so generally best to make sure the outward (request) and return (reply) routing take the same path.  The server radius reply will always go back to the same IP address that the request was sent from - not "another interface IP".

[network_eng]

That's the thing I can verify that the radius packets are going out the correct interface. I set it manually in the config and verified this in captures. I just think it is strange that the controller is getting no replies at all, nothing, not even a reject message. I can ping it but nothing comes back when a radius packet is sent across. This makes the controller believe that the AAA server is dead when in fact it isn't. The basics have been satisfied from the controller side, the NPS server and traffic flow back to the controller has to be the focus now.

[Rich R]

> That's the thing I can verify that the radius packets are going out the correct interface. I set it manually in the config and verified this in captures.

If you have indeed verified the correct outgoing interface from packet captures then that's great but setting the radius source IP (or interface) does NOT determine which interface it will be sent out of - it only determines the source IP address of the packet.  The packet will be ROUTED based on the destination IP address of the packet and that is how the outgoing interface is selected.

So you will have to trace the packets hop by hop to make sure they're getting to the server, and that the server is replying and then hop by hop back to the WLC to see where they're getting lost.  If the server isn't replying then you need to work out why on the server.  You might be missing some optional radius config on the WLC which is causing the server to ignore the packets.

[network_eng]

Agreed in that I might be missing some optional configuration (looking into this). I can see from the NPS server logs that the packets are indeed reaching the server.

I know the routing table uses the destination address in decisions however I was making sure the source address was consistent with what I saw from the captures of the old 2504 controller.

[antonismein]

@network_eng did you manage to solve the issue? I am afraid I have experienced the same error with aaa server on 9800WLC. Any further assistance will be helpful.

[network_eng]

Hello,

It was in fact solved last week, there was no issue with the routing or WLC configuration and there will be minor differences in the packet captures but to make a long story short there is one important thing you should check. I don't know the specifics of your problem but Microsoft NPS does not allow more than one radius client to have the same IP address in its configuration even if only one is enabled and the other(s) is in the disabled state. 

For the purpose of the engagement the client did not remember their shared secret for the old 2504 WLC radius communication and it wasn't documented. I did not want to erase the client in NPS as I might have had to rollback and I didn't want to configure a new password on their legacy controller (they were adamant it should not be touched in terms of configuration....only log collection etc.). I disabled the old radius client in NPS and created a new one with a new shared secret that would match the new 9800 controller radius config, the IP address and the other policies they had for access (AD group etc.). Even though the old radius client was disabled and the new client enabled the fact that the IP address was the same was what was causing the event ID 13 error. I changed the IP of the disabled client and retained the IP for the new client and the NPS then started to process the requests and issued the appropriate replies, everything worked as it should. Pretty strange on Microsoft's part as 'disabled' should in fact mean not used but clearly the server was confused and just dropped the radius packets (I did a capture from the server side as well which showed that it never even attempted to process the packets coming from the 9800).  

[wildermez]

Dear @network_eng ,

Hi, I have the same problem as you mentioned. 2 nps on ws 2019 connected to the same wlc C-9800-L. I didn't get your solution, Did you finally use 2 nps servers using the same IP address for the wlc ? or did you add another IP (svi for example) to your wlc.

I hope you can reply me.

Best regards

[Rich R]

The same answer applies - compare the radius packets from the old WLC side by side with the radius packets from the new WLC and see what is missing or different and then adjust the radius configuration accordingly.
Also use the logs on your radius server to determine what it doesn't like about the 9800 radius packets.

[sanket]

HI Can you please check once again your AAA config and make sure under :

"aaa group server radius group_name"

You have added radius server that you have created only and there is no typo or something.

Thanks.

[network_eng]

Hi Sanket, this was already solved, I posted what was occurring and the solution.

Thanks.