Security

Hello,

We have set up ethernet ports 1 and 2 to use 802.1x auth for our wired users. We have the ports configured as trunks and we are trunking down vlans 42 and 44. We also have a user derivation rule that allows devices with certain MAC OUI's to match the rule and get a 'cisco phones' rule. This is because we use ip phones that will not do 802.1x. So, the phone plugs into the RAP5 ethernet port 1 or 2, and the 802.1x enabled Windows7 laptop plugs into the phone (Cisco 7940). The phone is configured to accept and process vlan 44 traffic and pass vlan 42 traffic on to the laptop.

What is happening is that the laptop won't reply to the eapreq packets from the controller until we unplug the ethernet from the laptop and plug it back in. Then it responds and the authentication works perfectly. By the way, disabling and then enabling the NIC on the laptop or stopping and then restarting the Wired AutoConfig also makes it work.

The initial role is logon, I also read here to use the denyall role which I tried but that did not fix the problem.

Once the user disconnects and reconnects the ethernet cable everything works fine until the next time the laptop is reconnected the same issue occures.

We are connecting to a 3600 controller running 6.1.2.3 code with another 3600 running the same code as the master behind it.

This is likely a windows thing but we can't figure out what to change.

Any ideas would be greatly appreciated.

Michael

Please do this:

config t
aaaauthentication wired
profile "employee-laptop”

Don't ask why, but it might work after that.

Make sure that you see the user in the user-table with authentication 802.1x-wired to know that it works.

Thanks,

I already had the following in my config:

aaa authentication wired
   profile "aaa_prof-nhp39"

Just for fun, I deleted it and added it again. I still have the same issue.

Is there a way I can capture what the client is trying to do on that ethernet port? I could capture when it works and when it doesn't and compare them.

It's almost like the client needs some set of connectivity in order for the client to load the 802.1x capability. Then it does the eap and passes.

Any other ideas?

The output of "show auth-tracebuf mac <mac of device>" will give you what you are looking for.

Here are the results of the show auth-tracebuf mac :

Jan 19 16:19:24 eap-start -> 00:27:13:b3:19:b5 01:80:c2:00:00:03 - -
Jan 19 16:19:24 eap-id-req <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 48 5
Jan 19 16:19:29 eap-id-req <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 48 5
Jan 19 16:19:34 eap-id-req <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 48 5
Jan 19 16:19:39 eap-failure <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 48 4 station timeout
Jan 19 16:19:39 eap-id-req <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 49 5
Jan 19 16:19:44 eap-id-req <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 49 5
Jan 19 16:19:49 eap-id-req <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 49 5

Clearly the client isn't responding to the eap-id-req from aruba device. We've tried changing many of the auth settings on the windows 7 client with no success. Still very puzzeling is why simply unplugging, and then plugging back in the ethernet cable causes the authentication to attempt and succeed immediately. 

It sure seems the problem is on the windows side, but I was hoping someone would have seen this before and had a solution.  

---

@thompmik wrote:

Here are the results of the show auth-tracebuf mac :

 

Jan 19 16:19:24 eap-start -> 00:27:13:b3:19:b5 01:80:c2:00:00:03 - -
Jan 19 16:19:24 eap-id-req <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 48 5
Jan 19 16:19:29 eap-id-req <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 48 5
Jan 19 16:19:34 eap-id-req <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 48 5
Jan 19 16:19:39 eap-failure <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 48 4 station timeout
Jan 19 16:19:39 eap-id-req <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 49 5
Jan 19 16:19:44 eap-id-req <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 49 5
Jan 19 16:19:49 eap-id-req <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 49 5

 

Clearly the client isn't responding to the eap-id-req from aruba device. We've tried changing many of the auth settings on the windows 7 client with no success. Still very puzzeling is why simply unplugging, and then plugging back in the ethernet cable causes the authentication to attempt and succeed immediately. 

It sure seems the problem is on the windows side, but I was hoping someone would have seen this before and had a solution.  

---

On the Microsoft Page over here:  http://technet.microsoft.com/en-us/library/cc749352(WS.10).aspx please enable tracing for the wired interface to see what is going on.

Hi, do you all think it is related to the power settings of the port, or how the port is getting powered?  i.e. PoE, power supply.  Cisco is funny like that!   Can you check to see what the status is on that port where the laptop is connected when it is not getting a reply?   It's like the port or your NIC is going to sleep..

The only windows related power is the power management where it allows windows to shut down your NIC to conserve power so I don't think that would affect it, but worth a check?  ;O)

Good Luck, and let me know what you find!

** M.T.

---

@cjoseph wrote:

---

@thompmik wrote:

Here are the results of the show auth-tracebuf mac :

 

Jan 19 16:19:24 eap-start -> 00:27:13:b3:19:b5 01:80:c2:00:00:03 - -
Jan 19 16:19:24 eap-id-req <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 48 5
Jan 19 16:19:29 eap-id-req <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 48 5
Jan 19 16:19:34 eap-id-req <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 48 5
Jan 19 16:19:39 eap-failure <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 48 4 station timeout
Jan 19 16:19:39 eap-id-req <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 49 5
Jan 19 16:19:44 eap-id-req <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 49 5
Jan 19 16:19:49 eap-id-req <- 00:27:13:b3:19:b5 01:80:c2:00:00:03 49 5

 

Clearly the client isn't responding to the eap-id-req from aruba device. We've tried changing many of the auth settings on the windows 7 client with no success. Still very puzzeling is why simply unplugging, and then plugging back in the ethernet cable causes the authentication to attempt and succeed immediately. 

It sure seems the problem is on the windows side, but I was hoping someone would have seen this before and had a solution.  

---

On the Microsoft Page over here:  http://technet.microsoft.com/en-us/library/cc749352(WS.10).aspx please enable tracing for the wired interface to see what is going on.

 

---

Come to think of it. the Auth-tracebuf says EAP-Failure.  Has this wired port ever passed 802.1x authentication successfully?

when the laptops that are failing try to authenticate and then fail.. is there anything logged on the IAS or NPS server?? Please check this out so we can have a starting point. Or if your AP's are configured as radius clients which i think they are, make sure you dont have too many AP's close together in one place which could cause inteference or hopping between AP's by the laptop... if roaming is configured on your AP's.. the user might start the connection attempt with one AP (radius client) and then the laptop finds a much better signal from a nearby AP and before auth is finished with the first AP the machine has moved on to another AP and the auth fails.. please make sure this is not the case in your network and if its not just check the logs for any suspicious looking logs :) also check to see if the failed auth requests are localised to one area could be a prob with one AP or intefernce from nearby AP's or hoppin btwn AP's (the AP theory assumes that you use one SSID for all your AP's :] )

---

@arnoldanderio12 wrote:

when the laptops that are failing try to authenticate and then fail.. is there anything logged on the IAS or NPS server?? Please check this out so we can have a starting point. Or if your AP's are configured as radius clients which i think they are, make sure you dont have too many AP's close together in one place which could cause inteference or hopping between AP's by the laptop... if roaming is configured on your AP's.. the user might start the connection attempt with one AP (radius client) and then the laptop finds a much better signal from a nearby AP and before auth is finished with the first AP the machine has moved on to another AP and the auth fails.. please make sure this is not the case in your network and if its not just check the logs for any suspicious looking logs :) also check to see if the failed auth requests are localised to one area could be a prob with one AP or intefernce from nearby AP's or hoppin btwn AP's (the AP theory assumes that you use one SSID for all your AP's :] )

---

Arnoldanderio, This is wired 802.1x authentication, not wireless...

Has the issue solved?

We are facing a similar issue. I think it's something to do with Windows OS. Please see below post:

https://social.technet.microsoft.com/Forums/en-US/c5885f5f-29cf-4afe-a875-bdcc01d6a314/8021x-environment-problems-with-authentication-after-1903-update?forum=win10itpronetworking

Thank you.