Wireless EAP cert based authentication using ISE help!

[JG1978]

I have a scenario where we use ISE for EAP-TLS cert based authentication for wireless network. It has been working at our HQ for several months. Now we are trying to roll this out to our remote offices that connect to HQ over private WAN links.

The issue we are seeing is that when we try the authentication process in the remote sites, the WAP are sending the authentication information to ISE but the logs are showing it coming in as Authentication method : login.

We have a test WAN link that we used to verify our WAP configurations and it works great, the Authentication method is listed as: 802.1x and it works as it should.

I verified the WAP settings are the same, I cannot figure out why the Auth requests are coming in as Login type instead of 802.1x. This is causing the authentication policy in ISE to skip the 802.1x wireless/cert identity store process and fall to the default which is deny access.

Here are the main differences from the WAN test link and remote branch office.

The remote branch that is failing is using an older 4507 L3 switch which is what the WAP connects to, while the test WAN site is using C1000 switch for the WLC to connect ....The other variable is that the remote branch is using an ASA to serve the DHCP address to the wireless clients while that is being handled by the WAN router on the test link.  I am really at a loss on this one and hoping for any ideas or insights.

[Flavio Miranda]

Hi

 Do you have WLC or this is autonomous Access Point? 

[JG1978]

Autonomous. I pulled a packet capture from the WAN test site (working) vs the remote branch (failed) and I verified AVP attribute 6 is coming in as type "Login" on failed site vs "framed" on working site. I also realized the failing branch location is a MOE WAN link while the test WAN setup in an MPLS circuit....is that part of the issue?

The last thing I noticed in the packet captures is the MOE AVP (79) EAP message is fragmented, its entire length is listed as 1492 while the MPLS capture has AVP (79) as length=35 and not fragmented.

Does the type of WAN circuit effect the EAP ability?

[Flavio Miranda]

For EAP-TLS which seems to be your case,  MTU can be a problem but on this case it would prevent clients from authenticate.

But in your case, seems to be a configuration problem. Did you compared the configuration from one working AP to the non-working one ?

[JG1978]

Yes, 2 of us went over it in detail, the WAP are configured the same. I am focused on the WAN links causing the issue, I don't know enough about the difference from MOE to MPLS but EAP-TLS but I feel that seems to be the culprit....

[Flavio Miranda]

If the AP have the exactly same config, then, it could be the link. I got into a problem related to the MTU in the past but, in that case, the behavior was a bit different. But, it was WLC and not WAP.

 The problem was fragmentation  on the Load Balancer and we had a IPS in between. 

[JG1978]

OK thanks, still digging.

I found in the packet capture the failed attempt is showing VSA (vendor specific attribute) is sending t=WISPr-location-name val=(site name) while the successful one is sending t=Cisco-AVPair val=service-type-framed.

trying to find the reason why.

[Flavio Miranda]

I saw this information and that's why I think that the config is not ok, but as you said they are the same on both sides.  I would correlated this parameter change to a link. 

 I will waiting on your new findings

[JG1978 · Accepted solution]

I am pretty sure its this:

https://bst.cisco.com/bugsearch/bug/CSCuf16911

I am waiting to do some testing to confirm. I noticed the successful WAP has that command on it, the one failing does not.

[Flavio Miranda]

Sounds promissor. But then you have differents AP versions? Otherwise this would affect your whole network

[JG1978]

That was the problem, one of those famous "undocumented features". The reason it doesn't affect the entire network is because we are using WLC in our main HQ LAN. We are only using autonomous WAP in our branch locations. The command was already on the WAP we had on the WAN test lab, it must have been a newer WAP that was shipped with the command.

We did compare the radios though GUI but this is an undocumented command as a workaround to the bug i listed so we had to enable it on the WAP that is at the branch location.

[Rich R]

For anyone reading this thread later the command is:
dot11 aaa authentication attributes service framed

So lesson learned - don't glance at a GUI and say "they're configured the same"!  Always look at the actual config and compare them side by side, or use any of the numerous file compare tools to diff the configs.  Apart from expected differences like IP addresses and descriptions you'd expect the configs to be more or less identical and you'll quickly spot any difference that way.

Just to add - while WAN links can make a difference to radius because it's UDP and MTU can come into play - a WAN link would never change the contents of a radius packet so if different parameters are being sent that must always be from the source of the packet.