Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
The Meraki Community is Moving
We're migrating to the Cisco Community on March 29. The Meraki Community will enter read-only mode starting on March 26.
Learn more- About Mike-M
About Mike-M
Mike-M
Here to help
Member since Jul 12, 2019
Thursday
Community Record
12
Posts
2
Kudos
0
Solutions
Badges
3 weeks ago
2 Kudos
Thanks! That was definitely part of the problem. Adding the route to the spoke VNet and enabling VPN was absolutely necessary. As for the other part of the problem, there was an Azure User Defined Route table linked to the VMX's LAN subnet in the hub VNet. I think that was creating a loop for traffic heading from the spoke to on prem. At this point, the UDR table (defining CIDR range for the on premises networks, next hop being the VMX LAN interface) are only linked to subnets in the spokes. Traffic is flowing now, both ways. Thanks again for your response! I appreciate it. Enjoy the weekend! -Mike
... View more
3 weeks ago
Hello, I am pulling my hair out and hoping someone can help provide some guidance. Following the "VMX in Azure" deployment guide, I deployed a VMX to an Azure Hub Vnet and it checked into the Meraki Dashboard and AutoVPN is up, and from on premise I can ping the LAN IP of the VMX; all good so far. Should it matter, the VMX is in Routed mode (I want to use if for Auto-VPN and want it to be the NAT Internet gateway for Azure resources). I continued to peer a spoke Vnet and then deployed a VM to one of its subnets to test connectivity by pinging the VM from on-prem (fail). The subnet that the VM is on has a User Defined Route that routes all traffic destined for on-prem networks to the LAN IP of the VMX. To continue troubleshooting, from the VM in the spoke VNET, I can ping the WAN IP (not the public IP, but the WAN IP assigned to the NIC on the VMX's WAN subnet) of the VMX and get a reply all day long. However, I cannot ping the LAN IP of the VMX. Of course, if the VM can't reach the VMX LAN IP, I won't be able to reach the on prem networks or the Internet for that matter. I can't figure out why the WAN IP would reply to the VM (over the VNET peering) but not the LAN IP. Note that... Since the I can ping the VMX WAN IP from the VM in the spoke, it's an indicator that the peering is solid There are no NSG's in the way on the VMX, any subnets anywhere, or the VM NIC so confident it's not a NSG thing Both WAN and LAN NIC's on the VMX VM have IP Forwarding enabled The user defined route on the VM's subnet is 100% pointing to the VMX LAN IP as next hop A few oddities to mention, that may or not be related... When I deployed the VMX, the LAN IP was 192.168.128.1 and of course that didn't work as that default IP didn't jive with the VMX-LAN-Subnet IP range in the hub Vnet. I changed it to match the IP that Azure assigned the LAN interface of the VMX. This allowed the VPN to form and I could reach it from on premise. I was very much expecting to have to define the spoke networks on the VMX in order to enable them for auto-VPN but that does not appear to be possible and so the only VPN enabled Subnet is the LAN subnet. The VMX is in Single VLAN configuration, as deployed. I am really puzzled why the VM in the spoke VNET cannot ping the LAN IP of the VMX but can reach the VMX WAN IP. I feel that this is clearly what the issue is but cannot find any reasonable way to resolve it. The spoke subnets clearly need a path to the VMX's LAN IP. If anyone has any input, advise, suggestions, I would very much any help anyone can offer. Thanks, Mike
... View more
Jan 9 2024
6:13 AM
Hi DawieKabouter, Thanks for reaching out again and best wishes to you as well! Since we last connected, I was ultimately able to open a collaborative support case between Cisco, Meraki, and DUO to hopefully get to the bottom of this. With that said, I had a call with the Cisco Support team yesterday, as a result of me informing them about the suggested work-around of adding the above-mentioned registry key. Long story short, they concur that trying the above step, as part of our continued troubleshooting, makes sense. I have informed my team to implement this on a case-by-case basis, as the issue occurs. I will definitely report back with an update on how that goes for us. Your prior recommendation (to log in as local admin and run VPN client) has been our go-to move (continued thanks for that!). However, this reg key, providing it works for us, would be much simpler to implement globally. If of any value, I was supplied with link below that provide some details on the change in AnyConnect 4.10.05095 that resulted in the AnyConnect embedded browser defaulting to WebView2 runtime, providing that it's installed. The new registry key above reverts the AnyConnect browser to use the legacy embedded browser control. https://www.cisco.com/c/en/us/td/docs/security/vpn_client/anyconnect/anyconnect410/release/notes/release-notes-anyconnect-4-10.html#Cisco_Reference.dita_41127f2b-432f-4cc8-8978-c12a9f7db890 I hope this works out as it's been many months!!! Again, thank you for your continued feedback and follow up on this and I'll respond back with our findings. Sincerely, Mike
... View more
Oct 2 2023
9:48 AM
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
... View more
Sep 28 2023
6:20 AM
Understood, thank you.
... View more
Sep 28 2023
5:08 AM
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.
... View more
Sep 27 2023
10:41 AM
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.
... View more
Aug 3 2023
9:24 AM
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?
... View more
Aug 2 2023
6:05 AM
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: Uninstall the AnyConnect Client (appwiz.cpl) Delete the "c:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client" 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!
... View more
Labels:
- Labels:
-
Client VPN
Apr 4 2022
1:30 PM
Again, thank you. After some additional testing, with the CA Server set to not allow the private key to be exported and with the user certificate installed to user certificate store, things seem to be functioning as expected.
... View more
Apr 4 2022
10:41 AM
Thanks for the helpful feedback. During my initial testing with the self-signed certificates, I installed those to the Machine certificate store. Since AnyConnect worked in that configuration, I proceeded to install the CA signed certificates to the Computer store as well. In hindsight, I suspect that I was signed into the machine as an admin which made those self-signed certificates in the Computer store accessible to AnyConnect. What you suggested (installing the CA certs to User certificate store) worked so thank you for pointing me in the right direction. With the new understanding that the User certificate store is where the CA certificates need to be, is there a best practice approach to prevent a non-privileged user from exporting the User certificates for install on a non-approved device? In the end, we're aiming to limit AnyConnect VPN to just corporate assets. With AnyConnect/ASA, I recall that Dynamic Access Policies could further "inspect" the endpoint but that feature doesn't exist in Meraki's AnyConnect implementation.
... View more
Apr 1 2022
4:54 PM
Hi I'm stumped so wanted to reach out to the community in hopes that someone has some wisdom or guidance to share. I'm testing AnyConnect VPN with Certificate Authentication. This is on a MX250 running v16.16 firmware and AnyConnect Client v4.10.05085 for Windows. Using a self-signed root certificate (uploaded to MX as a pem file) and a self-signed client certificate (installed to the Windows PC in Computer/Personal certificate store), it works like a champ! However, for better certificate management and deployment experience, there's a preference to try and use Microsoft CA Services to deploy the client certificates. With this in mind, I: Exported the root certificate from the Microsoft CA Server (exported as Base64, renamed extension to pem) Uploaded the root certificate to the MX Installed a client certificate from the same CA server that signed the root certificate. It was installed to my test PC's Computer/Personal Certificate Store. The CA Root Certificate is also installed on this PC Attempted to establish an AnyConnect Client VPN - FAILS with "no valid certificate" dialogue. If anyone has had any success with using an exported CA root certificate from a Microsoft CA server (Server 2016) and client certificate issued from same CA server , I'd appreciate any thoughts on how you got it working or if I've overlooked something. Thanks!
... View more
Labels:
- Labels:
-
Client VPN
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 2 | 685 |
© 2026 Cisco Systems, Inc.
