MX64 Client VPN Cloud Auth Works - Radius Auth Fails with IPsec-SA expiration

[Coupe2112]

I have configured a Client VPN on this MX device. When using Meraki Cloud authentication it works without issue. When I enable radius authentication it fails.

I have performed a packet capture on the radius server and see successful authentication requests validating that radius is functioning correctly. This is failing for both an Android client (ver. 9 build PPR2.181005.003) and Windows10 Enterprise (ver. 1709 build 16299.611)

Below are log entries. It looks to me like it's simply timing out.

Oct 29 08:28:15 Non-Meraki / Client VPN negotiation msg: ISAKMP-SA established x.x.x.x[4500]-y.y.y.y[4500] spi:f7576fb374b0f3a5:75cfbc1463066f9b
Oct 29 08:28:16 Non-Meraki / Client VPN negotiation msg: IPsec-SA established: ESP/Transport x.x.x.x[4500]->y.y.y.y[4500] spi=68336299(0x412baab)
Oct 29 08:28:16 Non-Meraki / Client VPN negotiation msg: IPsec-SA established: ESP/Transport x.x.x.x[4500]->y.y.y.y[4500] spi=125451427(0x77a3ca3)
Oct 29 08:28:21 Non-Meraki / Client VPN negotiation msg: purged IPsec-SA proto_id=ESP spi=125451427.
Oct 29 08:28:21 Non-Meraki / Client VPN negotiation msg: ISAKMP-SA expired x.x.x.x[4500]-y.y.y.y[4500] spi:f7576fb374b0f3a5:75cfbc1463066f9b
Oct 29 08:28:21 Non-Meraki / Client VPN negotiation msg: ISAKMP-SA deleted x.x.x.x[4500]-y.y.y.y[4500] spi:f7576fb374b0f3a5:75cfbc1463066f9b

My confusion is why the different behavior going from cloud auth to radius when I can confirm that radius is working.

Has anyone seen this before?  Any suggestions?

[PhilipDAth]

Is this an AD account?  Do they perhaps need to login as domain\user?

And to be specific. in your packet capture you sure the RADIUS server send an ACCESS_ACCEPT message?

[Coupe2112]

It is a domain account.  Good call on adding the domain.  I'll give that a shot.

Yes, I am seeing an 'ACCESS_ACCEPT' message.  I opened a ticket with Meraki support who said back end logs were showing authentication failure.  Obviously that doesn't make a lot of sense given that radius is confirming the password.  I've done a second capture on the MX lan port and confirmed that the MX is also receiving the 'ACCESS_ACCEPT' packet. 

UPDATE:  I had been using my email account but I tested with 'username', 'public_domain\username', and 'private_domain\username' with no luck.  In all three cases, the radius 'ACCESS_REQUEST' shows the correct value and radius completes the authentication.

[PhilipDAth]

Which radius server are you using?

I don't know how important these are, but is the RADIUS server also returning Framed-Protocol and Service-Type, to say what the user is permitted to use?

On my RADIUS server, Framed-Protocol is set to PPP and Service-Type is set to Framed.

[Coupe2112]

Those are in the request, not the accept.

[PhilipDAth]

If you are using Microsoft NPS check out this guide.  Even if you are not using it, check out the guide and figure out how to apply similar settings.

https://documentation.meraki.com/MX/Client_VPN/Configuring_RADIUS_Authentication_with_Client_VPN

[Coupe2112]

LOL This is the same thing Meraki support sent me to.  I am using M$ NPS, I used the guide to configure it and I've reviewed the settings about a dozen times in the last two and half days.

I appreciate the feedback because sometimes just talking it through leads to the 'A-HAH!' moment (and I definitely could have missed something). I'm looking for something a bit deeper than the basics though.  I'm using radius authentication all over the place for access to my ASA firewalls, Cisco IOS and Nexus devices (with multiple levels of access), ASA and Firepower remote access vpns, and my open source IPAM server so I'm definitely familiar with configuring it.  🙂

[Coupe2112 · Accepted solution]

So I was finally able to get this working.  Upon the suggestion of Meraki's support, I simplified the PSK for radius authentication between radius client and server by removing any non-alphanumeric characters.  I made it extremely long to try to keep it secure (24 characters) but at least it's working now.

It seems like a shortcoming to me but at the very least I think it should be documented to not use non-alphanumeric in that PSK.

Anyway, there it is.  Thanks for reading.