Meraki AnyConnect VPN - "Authentication failed due to problem navigating to the single sign-on URL."

[Mike-M]

Hi,

We're having some trouble with a Meraki AnyConnect deployment and wanted to check with the community to see if anyone else has encountered this random issue. The deployment is MX 250 running firmware 18.107.2 with authentication to DUO via SAML. On the client side, Meraki AnyConnect v4.10.05085.

This issue is fairly new, has impacted various users, we're unable to reproduce it, and it appears to have showed up after a recent MX firmware upgrade.  We have an open Meraki Support case on this that's not progressing.

As for the issue, when a user attempts to establish the Meraki AnyConnect VPN connection, the AnyConnect client displays this error: "Authentication failed due to problem navigating to the single sign-on URL."

When the issue occurs, we have confirmed that Internet access is good and that the user is 100% able to navigate to the SSO URL via web browser which indicates that this isn't a DNS, connectivity, or services availability issue. While this is occurring for a specific user, others are able to establish VPN's without issue.  Rebooting the client PC does not help and waiting a while and trying again does not help.  

To work around the issue, the only thing that seems to help "resolve" is to:

1. Uninstall the AnyConnect Client (appwiz.cpl)
2. Delete the "c:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client"
3. Reinstall v4.10.05085

In a few instances we've attempted to upgrade a client to Cisco Secure Client AnyConnect 5.0.02075 with same error. I have also been informed that the error condition remains if you uninstall/reinstall without deleting "c:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client".

If anyone has run into this or has any thoughts on what may be happening or a better work-around, I'd greatly appreciate any feedback.

Thanks!

[alemabrahao]

If you downgrade does it work? If yes, I suggest opening a support case.

[Yeiner]

Im having same issue, MX250 and version 18.107.2, Cisco Anyconnect Client ver 5.0.02075, authentication is against Azure AD. Have you manage to solve it?

[Yeiner]

Update, computers with Anyconnect client 4.10.05085 have no problems to log in

[Mike-M]

No, this is still an ongoing issue for us. It looks like you're running the same MX firmware version though. We've been testing AnyConnect Client v5.0.02075 but I have been reluctant to push that out until we figure what's going on with the issue on our currently deployed version v4.10.05085.  Based on your situation, looks like whatever is happening here is impacting both of these versions.

I'm unable to reproduce the issue which is what Meraki Support is asking for so I'm kind of in a jam.

For your environment, do you think this is new after upgrading your MX250 to 18.107.2?

[alemabrahao]

If you downgrade does it work? If yes, I suggest opening a support case.

[rfisher983]

Our company had the same issues. Azure domain joined workstations with intune would get the SSO issue with version 5x. Same workstation would log in under the local user account. Downgraded to version 4x resolved. 

[Mike-M]

I wish that I had some good news on this, but our issues persist, and we continue to downgrade to 4.x when it comes up.

For anyone that decides to further engage with support on this matter, my experience is that Cisco TAC will not help if the AnyConnect VPN is terminating to a Meraki MX appliance.  Meraki Support will not help as their position (as stated in my open case) is that they do not support AnyConnect. From my Meraki case, "Unfortunately, we do not have any control over Anyconnect nor support it."  To this point, there's been no level of engagement with my Meraki or Cisco team that has resulted in getting any step closer to understanding what's going on. I'd strongly suggest to anyone looking at using AnyConnect with an MX to really consider that you're doing so without support which is obviously fine until you need it. 

I'll keep trying on my end and will surely post any relevant updates.

[DawieKabouter]

Hi Mike,

I have the same issue and Meraki support referred me to Cisco TAC for further assistance. Since you've already done that there is no need for me to go through the same process.

HOWEVER, while being on the phone with Meraki support I sort of fixed the issue for myself. At least for now on only 1 PC and yet to test it on others.

My scenario explained below;

- I found that local admin users have no problem connecting and no warning. SAML auth works.

- When a non-admin user tries to connect, the error appear.

- I logged in on the troubled PC as admin user, open AnyConnect and entered the hostname. Connected and voila! 

- Logged back in as the non-admin user, opened AnyConnect, enter hostname address and voila!

Don't ask me why and unfortunately I can't confirm if this is a working  work-around on this issue. I will test it on more troubled PC's and confirm back here.

Good luck if anyone want to try this work-around in the meantime.

-DawieKabouter-

[Mike-M]

Thanks for your response. I'll relay the "AnyConnect as admin" thing to my team so they can test it the next time this comes up and will post some feedback with our findings.

[DawieKabouter]

Hi Mike, perfect. Just to be clear make sure whoever do the work-around to be logged on as a local admin. Installing the software as admin is not enough.

Good luck!

Regards,

-DawieKabouter-

[Mike-M]

Understood, thank you. 

[Mike-M]

Hi DawieKabouter,

We ran into the issue today and your work-around appeared to work as you described!

We logged into the PC as an administrator and established the VPN without any issues.  We then disconnected the VPN and logged back into the PC as the standard user and were able to make a successful VPN connection without the error. 

We're going to continue testing and I'll post an update with subsequent findings.  If this holds true going forward, then the requirement to downgrade is resolved but I'd really like to understand what's causing this issue in the first place. 

I deeply appreciate you sharing your findings here so many thanks to you.

Thanks, 

Mike

[DawieKabouter]

Hi Mike,

Thanks for getting back to me. I'm glad it worked, however, I wish to further update you on this case. It turns out my own solution was short-lived.

I had to add the domain user to the Power Users group and now the user is able to connect consistently without this erorr.

I would suggest to monitor this, if the work-around is no longer working, try adding the user with different permissions on the local system. In this case I know for a fact Power Users group works.

Kind regards,

-DawieKabouter-