Meraki VPN Some users get 691 error when authenticating with Radius

[BulletCatcher]

Good afternoon, 

I have a situation where I can use my orgs VPN from any device outside the network. Works great. 

Given a computer that I can use the VPN and successfully authenticate with my username and password, a few specific users receive an error 691 about incorrect credentials when they attempt to use the VPN from the same exact computer. 

I have verified the credentials are not the problem. 

Any thoughts? 

[SoCalRacer]

This is a good place to start

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

Error 691

Possible causes and solutions:

• Invalid user credentials
  Solution: Confirm user credentials are correct. When using Meraki authentication, usernames should be in e-mail format (ex. user@example.com). When using AD or RADIUS authentication, be sure to enter the username in a format that will be recognized by the server, including the domain if needed (ex. DOMAIN\user).
• User not authorized
  Solution: If using Meraki Authentication, ensure that the user has been authorized to connect to the VPN.
• No certificate on AD server
  Solution: If using Active Directory authentication with Client VPN, make sure the AD server has a valid certificate for TLS.
• Incorrect DNS name resolution from the MXs upstream DNS server

        Solution: If the MX is configured with an ISP DNS server, change this to a Non-ISP public DNS server such as Google 8.8.8.8

• Alternatively, this message can be caused when a mismatch of pre-shared secrets between a RADIUS server and MX results in bad encryption of the password. Test this by changing the pre-shared secret in Dashboard and for the RADIUS client on the server to something simple, such as "Meraki". If the error disappears, verify the secret used is correct on both devices, and simplify the password if needed. 

[BulletCatcher]

Thank you for providing feedback.

Here are my findings. 

• Invalid User Credentials
  I have changed the user's credentials and verified they're correct by successful authenticating to other systems that use LDAP. The user receives an error when attempting to connect to the VPN while I and others are able to use the same computer and the same VPN configuration to connect to the network.
• User Not Authorized
  This doesn't apply as we are using RADIUS for authentication. 
• No Cert on AD Server
  Also not applicable as I'm using RADIUS for Client VPN Authentication
• Incorrect DNS name resolution from the MXs upstream DNS server
  Im not sure where I can find this setting (I still learning about Meraki)
  Also, if this were the problem, wouldn't all users experience the issue? Only two specific users are unable to connect to the VPN. The vast majority of other users have no problem at all. 
• Mismatch Pre Share Keys
  I created a new VPN connection on a new computer. I manually entered all configuration settings and the pre-shared key, which I verified was correct within my documentation and Meraki dashboard. I was able to successfully authenticate with my credentials, but not with this user having a problem. The same error that has been thrown during this process, was thrown again. Error 691. 

On my Radius Server I have verified the users meet the conditions for windows groups for the network policy. 

One thing I have noticed is these users having problems have been at the company for a long time. They have older AD accounts. I was curious if there was anything that could cause a problem related to that? 

IAS Logs

CLIENTCOMP

ServiceName

RecordDate

RecordTime

PackeyType

UserName

FQDN of UserName

CallingStationID

Client IP Addr

ClientFriendlyName

ServiceType?

AuthenticationType

PolicyName

ReasonCode

MS_RAS-Client-Name

MS-RAS-Client-Version

NPS_Server

IAS

6/21/2019

7:38:42

1

me@mydomain

FQDN of AD User Object, as expected

CLIENTVPN

same value

3

0

expected IP

Meraki

1

2

1

Meraki_VPN

0

311 1 10.2.1.2 05/30/2019 02:55:51 1501

Meraki_VPN

1

NPS_Server

IAS

6/21/2019

7:38:42

2

FQDN of AD User Object, as expected

0

expected IP

Meraki

1

2

1

Meraki_VPN

0

311 1 10.2.1.2 05/30/2019 02:55:51 1501

Meraki_VPN

1

NPS_Server

IAS

6/21/2019

7:40:18

1

other_user@mydomain

FQDN of AD User Object, as expected

CLIENTVPN

same value

3

0

expected IP

Meraki

1

1

Meraki_VPN

0

311 1 10.2.1.2 05/30/2019 02:55:51 1502

Meraki_VPN

1

NPS_Server

IAS

6/21/2019

7:40:18

2

FQDN of AD User Object, as expected

0

expected IP

Meraki

1

4

1

Meraki_VPN

0

311 1 10.2.1.2 05/30/2019 02:55:51 1502

Meraki_VPN

1

The first thing I notice is the different service types.

me@mydomain can access the VPN no problem. 

other_user@mydomain cannot access the VPN at all. 

Any thoughts or observations? What am I missing? 

[Nash]

Okay, sounds like you're sure that these users are members of the necessary AD users group?

If you clone one of the problem users and create a new account based off of them, can you replicate 691? Or does it work?

[BulletCatcher]

in AD U&C I copied the problem user account, gave it name and pass. saved.

Attempted to connect to VPN. The 691 error is replicated.

[Nash]

Interesting. 

I'd:

a) remove the user from the VPN user group. Apply. Give it a few min. Add user back to the VPN user group. Test.

b) If A is a no go, remove the user from all groups but the VPN user group and test. If it works, start adding back in other groups until it breaks.

[BulletCatcher]

myUser can connect to VPN otherUser can't. 

I copied both accounts and created two new accounts. 

vpntest copied from otherUser

vpntest2 copied from myUser

Both these accounts have the same password and that password is in compliance with domain policy. 

I removed all AD security groups except the one needed for Merkai authentication as defined in the NPS policy, and the Domain Users group. 

Given the same computer, using iPhone hotspot (off corp network), vpntest cannot connect (691 error) to VPN vpntest2 can connect to VPN. 

Even newly created users are able to access the VPN. It just seems to be with specific users who have been with the company for a very long time. Even their usernames are different naming convention. Is there an attribute some where that maybe acting as an alias for another attribute? 

I'm just trying to think outside the box on this one. Very strange. 

[Nash]

Oh, I have a thought.

Are those users allowed to dial-in remotely? Here's a goodish screenshot: https://gtacknowledge.extremenetworks.com/articles/Solution/RADIUS-Authorization-not-working-due-to-...

[BulletCatcher · Accepted solution]

Huzzah! I found the solution. 

Thank you Nash, your recommendation wasn't the solution, but it put me on the right path. 

The users having problems had an msRADIUSServiceType value equal to 4, while users with no problem had a value for the same attribute of <not set>. 

After clearing this value with ADSI Edit, the user was able to access the VPN as expected. 

The following powershell cmdlet helped me proactively identify other users who may not have experienced this problem yet. 

get-aduser -Filter * -Properties * | Select SAMAccountName, msRADIUSServiceType, Enabled | Where-Object {$_.Enabled -eq $true -and $_.msRADIUSServiceType -ge 1}

Thanks again for your help. 

[Magamus]

While this may be old, Nash also provided a golden nugget when everything else wasn't working because we were so focused on the error code that we forgot to check the basic settings.  There are times when settings don't pass correctly or some profile was made incorrectly.

CHECK THE DARN DIAL-IN FIELD IN ACTIVE DIRECTORY!  

Not sure how or why it defaulted to Deny Access for us but it's such a small flag to notice.  Much frustration and sobbing.  But easy to miss.  The dangers of relying too much on third-party services.

Thank you, Nash, for reminding me that the Dial-In tab exists!!