802.1x over Ethernet EAP-TLS

zdawg
Comes here often

802.1x over Ethernet EAP-TLS

I have been dealing with getting this working for some time now. I am not entirely sure what you will all need from me, and I can give whatever you need to assist. 

 

We are using Cisco MS switches and want to implement 802.1x EAP-TLS over Ethernet and have our NPS authenticate the user and place that user on the VLAN they belong in, which is handled by User Group within NPS Conditions. The server has RequireMsgAuth and LimitProxyState to disabled (KB5043417: RADIUS authentication to NPS might fail with the July 2024 security update and later upda...).

 

While running a packet capture on an end point device utilizing a port with the Meraki Access Policy for 802.1x and the NPS I do see it trying to authenticate, however, it stops at "Access-Request" on the NPS Wireshark log. NPS event viewer does not show anything. Checking CAPI2 logs (certificate logs) on the end device in Event Viewer I see no certificate issues. 

 

I verified that all certs are applied, auth method is set to Smart Card... on both NPS side and 802.3 group policy side yet still cannot authenticate. The NPS is also our domain controller and yes, all computers can do what they need on the DC without issue. 

 

I am sure there is MUCH more info I could give, so please feel free to ask. 

 

Thank you! 

19 Replies 19
MartinLL
Building a reputation

Without more info its hard to say.

But, since your NPS recieves the access-request but does not return the access-challenge something might be wrong with radius clients on your NPS. Verify that the client config contains the switches management ip and verify the shared secret.

 

It could also be certificates missing from trusted root and the personal store on the server, but it sounds like you already checked that.

 

Read this article and see if you missed something. It might give you some pointers as to whats missing. Its for access points and uses PEAP, but much of it still appliens to EAP-TLS.

https://documentation.meraki.com/MR/Encryption_and_Authentication/Configuring_RADIUS_Authentication_... 

MLL
zdawg
Comes here often

Yeah, I fully verified the client IP addresses, even went as far as using individual IP addresses instead of a subnet. I also created an Authentication and Accounting template to ensure secret consistency and triple checking it is correct in the Meraki Access Policy. 

 

Yeah, the trusted root is indeed in the personal and root store on the server. 

 

I have gone through that article religiously over the last two weeks and still unable to get it to work. 

GIdenJoe
Kind of a big deal
Kind of a big deal

When you do a packet capture on port 1812 you should see access-request packets being sent from the switch and access-challenge back from the NPS server.

So first make sure the messages reach the NPS server and see if the server responds.
If the server does not respond then you will need to look purely at the server (are the switches present in the radius clients configuration?).

If you are seeing access-reject messages from the NPS server then you are probably not matching an access rule.

There are many more issues but at least start with the basics.

zdawg
Comes here often

I am not finding anything regarding port 1812 on the NPS. I will run another scan to see. 

GIdenJoe
Kind of a big deal
Kind of a big deal

You're supposed to do a packet capture on the switchport leading to the NPS server while filtering on UDP port 1812 just to see if the access-request message is even reaching the NPS server and if a response is sent back.

If you have to do a dashboard capture then you will have to coordinate a test while capturing.

zdawg
Comes here often

The Domain Controller/NPS server are in Azure. We are connected with a site-to-site VPN. I did a packet capture on "Internet 1" and "Site-to-Site VPN over Internet 1" and found no packets with port 1812.

GIdenJoe
Kind of a big deal
Kind of a big deal

So if you do the capture on the MX you would have to see it on the LAN side and in the site to site side if you are doing an AutoVPN to Azure.  So then you should also see the packet on the vMX.

So if you're are not seeing any packets you have a policy or routing issue.  That means the interface of the switch can't reach the NPS server.  So you'll have to check if the subnet of the switches is included in the VPN and all routing is correct.

zdawg
Comes here often

Well, I do know for a fact that the switch can reach the NPS. In fact, if I lower my security to MSCHAPv2, I have no issues with the supplicant reaching the NPS. We also do not use a vMX.

GIdenJoe
Kind of a big deal
Kind of a big deal

If you are sure your routing is ok and you did the capture correctly and not see anything on UDP port 1812 leaving the switch, then you should capture the EAPoL frames on the port.  Your supplicant might not be sending EAPoL frames to the switch.

KarstenI
Kind of a big deal
Kind of a big deal

If you only see the initial Access-Request of the 802.1X communication, it is still far away from anything certificate related.

If there is no answer at all, the most likely cause is a mismatch in the shared secret. First tripple-check that.

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.
zdawg
Comes here often

Yep, did that many times, this was my first assumption. 

yaypingworks
Here to help

We tried setting up certificate based authentication a while back, it did not work with MS switches, Meraki support said they dont support it, only mac based or domain creds based authentication...

 

however machine based certs do work on MR wireless... so i don't really understand what the difference is... take what i say with a grain of salt but thats what ive been told in the past.

GIdenJoe
Kind of a big deal
Kind of a big deal

That would be extremely weird since the switch is only encapsulating the EAPoL messages inside Radius and decapsulating in the return.  It does not matter what kind of EAP protocol you are using between the supplicant and the authentication server.  The only thing the switch needs in the end is an access-accept with potentially some AV pairs.

zdawg
Comes here often

Has anyone been able to get it working? I have been on support many times and got nowhere. I myself also had a Meraki rep tell me similar things saying I should make a suggestion to the product team. I just for some reason don't buy this is the case considering this is a Cisco product we are talking about. 

KarstenI
Kind of a big deal
Kind of a big deal

As @GIdenJoe said, the whole purpose of EAP is to make the Network Access Device independent of the EAP method. At the moment, I am connected with EAP-TLS to an MS220-8P.

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.
zdawg
Comes here often

Are you using machine or user authentication? 

KarstenI
Kind of a big deal
Kind of a big deal

One more thing: Does the NPS work for any other devices, for example APs?

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.
zdawg
Comes here often

I have not, although, I plan on testing that today. As well as testing just computer authentication. 

zdawg
Comes here often

I'd also like to point out while I am attempting to setup and test if this happens on AP's that the Accounting Server keeps deleting itself after it's been saved within the Wireless Access Control configuration. 

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels