Meraki's fault? Microsoft's?

[VinceBusMaximus]

I guess it doesn't matter, because I can't very well throw away Windows 10. But I am about ready to throw this Meraki setup (MX 12.6)  in the trash.

Former set-up was old Cisco VPN and we used Shrew to establish VPN connections. Worked flawlessly every time. With Meraki, there's no dedicated client and of course Shrew doesn't work. So we have to use the native Windows 10 VPN client.

It starts out great - we add a VPN connection in the metro interface, then head to Adapter Options to finish the set-up. We select Properties for the newly-created VPN adapter and do all the settings indicated in the set-up guide:

(https://documentation.meraki.com/MX-Z/Client_VPN/Client_VPN_OS_Configuration)

Back to the Network Connections screen. Right-click the just-configured VPN adapter and select Connect/Disconnect. Windows  takes me mack into Metro. Hit the Connect button, and it works.

But now, it's starting to fail us on a regular basis. All builds of Windows 10 (1607, 1703, and 1709). Without fail in these cases, it's switching from Unencrypted PAP to Microsoft CHAP.

Ok, so I set it back to PAP, apply and close out, and back to the metro interface to sign in. Except NOW the authentication method has changed from Username and Password to General, and the user's VPN credentials are gone!  If it re-enter that stuff, sometimes it works. Sometimes, it maddeningly changes the adapter settings AGAIN (back to CHAP), and it takes 3-5 tries for this to stick.

Not feeling really confident about sending users on the road with this. Providing a how-to/workaround to have employees do what I just described is no solution. 

Anybody else experiencing this? Please tell me there's a permanent fix. Barring that, I've searched and cannot find a compatible third-party VPN client. Is this thing just not meant to work in a Windows 10 environment? (OSX and iOS work great, FWIW).

[BlakeRichardson]

It does sound like a MS issue, have you contacted support to see if there is a known issue or work around? 

I find MS built in VPN clients are awful at the best of times, have you tried any 3rd party software. The link below may work for you?

https://www.ncp-e.com/en/products/ipsec-vpn-client-suite/vpn-clients-for-windows-10-8-7-macos/

[VinceBusMaximus]

The black hole of MS support for a case like this is not appealing. They're going to send me right back to Meraki and round-and-round we go.

I've spent days researching this, to no avail. Is the bottom line here that this Meraki product doesn't support Windows 10? It's in the documentation, so I would presume it's supposed to. But here we are.

As I mentioned in my OP, I haven't been able to find any third-party VPN clients that would appear to work. 

What are other Windows 10 folks out there doing?

[JustfixitJim]

I have the exact same issue. Makes it real hard to keep the client VPN self service. 

[MRCUR]

This is definitely a Windows issue. I have seen this happen only a handful of times and only after the Win 10 build was upgraded (1607 -> 1709 for example). I'd suggest opening a case with Microsoft. 

We have a few hundred Win 10 users (all Win 10 Enterprise 1607 or 1703) connecting to Meraki MX VPN without a problem. 

[PhilipDAth]

First upgrade to 13.28, which is the current "stable" and recommended code.  No point in running old code.

You can try the Client VPN trouble shooting guide:

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

Note that some brands of machines, like Dell, ship software on those machines that break the Microsoft VPN client:

https://community.meraki.com/t5/Network-Wide/Dell-Laptops-and-VPN-access/m-p/12826#M321

Lastly, rather than configuring the Client VPN via the GI you could try using Powershell, as it produces exactly the same predictable result each time you setup a machine:

http://www.ifm.net.nz/cookbooks/meraki-client-vpn.html

[VinceBusMaximus]

Thanks Philip. Will definitely consider the update to 13.28.

Tried the troubleshooting guide, and we don't have that Dell software on our machines.

I've  done the Powershell thing too. The problem isn't setting it up in a repeatable, predictable manner and getting it to work. It's the settings changing all on their own, at random times. I can run PS scripts until the cows come home, teach users how to do it - but it won't fix what I'm pretty much convinced is a MS bug. That, and I'm not keen on exposing the PSK to everybody. 

[VinceBusMaximus]

I do wonder if there's a 'brute force' workaround, such as changing a registry key somewhere to make adapter / connection settings read-only...

[BlakeRichardson]

Sorry my suggestion was to talk to Meraki support NOT MS support, this is something they might be aware of and my have a work around. 

[Todd-rmn]

...Another company here having the exact same issue on Windows 10 machines. Users are not happy. I know Microsoft will probably do nothing, but when will Meraki release more options for client VPN?

[LV_MW_MSP]

For those still having an issue getting Windows Client VPN to work with the MX, I can shed some light on what we learned and how we fixed it.

From our experience there are two types of reasons why the client VPN will not connect:

1. For Windows 10 you must edit the registry to allow VPN traffic to pass when the machine is behind a NAT. Enable UDP Encapsulation in the registry and reboot the machine. This will fix the issue most of the time.

https://support.microsoft.com/en-us/help/926179/how-to-configure-an-l2tp-ipsec-server-behind-a-nat-t...

I have my registry key set to 2 and I can VPN into most customer networks.

2. The NAT device for whatever reason is not allowing the VPN connection. The NAT device is the firewall, or whatever device the computer is sitting behind. For example, we had a remote user behind an old SonicWALL firewall and after updating the firmware the VPN traffic was able to pass through the SonicWALL.

Another common one are those junk/crap Google WIFI mesh systems. Those WILL NOT pass VPN traffic, and if it does, it is only a matter of time until it stops working. The core issue is Google is unable to properly forward VPN traffic from the main router to the mesh WAPs properly, and they offer zero support. I got around this by opening the ports for VPN traffic and pointing it to a static IP, but that was a temp fix. We replaced the Google WIFI router system with a  Meraki and it 100% solved the issue.

At the end of the day, either your settings are wrong, you don't have UDP encapsulation enabled, or your remote device is behind a physical firewall that is not allowing the VPN to work.

[SwissAmi]

Yap!! #MeToo!!

I experience the same behaviour. For weeks it runs without any problems and all of a sudden, Microsofts Windows begins to change the settings in VPN from PAP to CHAP and from Authentication mode User/Pass to General.

Its' really annoying and IT IS AN MS-ISSUE!

Greetings

Ami

[DHAnderson]

I have a client with many users on a Meraki VPN, all with Windows 10.  I have noticed that time from time Windows 10 will not connect to any Windows based VPN, until after a reboot. 

I also noticed the VPN is much more reliable if it does not have saved credentials.  I have more times that I care to count  where the connection appeared to hang (requiring a reboot to get any VPN to work again).  I would then clear the credentials and the connection would work there after, every time.

[nealgs]

Having the same issue with Win 10 changing the Allow these protocol options from PAP to CHAP for no reason at all.

Anyone have any update on this with regards to a permanent fix.  A bit of a pain in the arm for users having to go through and manual change the settings back each time if messes up.

We may end up buying a dedicated VPN concentrator (like the sonicwall we use at one site and Dell NetExtender client software) - this works really well and without any issues.

@meraki_ - any update with regards to a Meraki VPN client or updates to enable the MX to use a 3rd party client???????????????????

[DHAnderson]

I have System Manager and when it setups the VPN connection it selects all 3 options: PAP, CHAP and CHAP V2, and I have no problem connecting to any Meraki VPN setup this way.

I do know that sometimes Windows 10 will not connect properly until one does a reboot.  That always fixes the issue for myself and my clients.

[604Consulting]

Just adding that we see this at our clients as well, with the same issues (W10 changes the settings randomly), and sometimes it just doesn't connect even when the settings are correct.

[CAquinoQGA]

We're having the exact same issue and have been experiencing it for OVER 2 years now on Windows 10 Surfaces - all models and with Win 10 latest updates and MX latest firmware. FIX THIS MERAKI!!!!!!!!!!!

[nealgs]

In Merakis defence, i don't believe the issue is their fault - it's an MS issue which MS should be sorting.

It would be nice if Meraki did listen to the populace with regards to being able to use a 3rd party client or even Ciscos own client if they wanted to keep it partially in house.

Come on Team Meraki - listen to the users, not everyone can be bothered to put it on a wish list, just make it happen, pretty please (there that should help 😉 )

Gary

[nealgs]

anyone had an update on this issue at all?  it's all gone quite, so do i assume that everyone is all sorted now and no longer having the issue 😉

Gary

[CNHRIT]

It's still plaguing me.  I submitted feedback to Microsoft via the Feedback Hub; if you can upvote it, it can't hurt.  I've actually had success with this method before with a Dell/EMC Unity SMB issue.

https://aka.ms/AA5qf83

SurfaceBook, 1903 build 18362.10006

That said, I'd sure like the see client-based alternative. Being fully dependent on the OS's VPN implementation was a risky approach, and it is hurting customers now. I've heard for years that Meraki has a client on the way.

Thanks,

Dan

[PhilipDAth]

It's a bit hard to upvote it.

[PhilipDAth]

>anyone had an update on this issue at all? 

It's still broken.  There has been about three feature updates since the issue started now.  Microsoft don't seem interested in resolving the bug.

[Nash]

There's ways to make it less painful on Windows10. I've got two scripts you can use to set it up. One you fill out the variables in the script itself and it's run-and-done. The other prompts you for input.

If you want to use these, do read the comments and tweak as necessary. 

I've checked with my help desk and they're not aware of any VPN connections that have had protocol changes, since we began using this script. They primarily use the version that prompts for input, since we have dozens of clients.

Quick tips:

1. Tell users to not save their passwords.

2. Use rasphone.exe to connect to the VPN.

3. On manual setup, set it so encryption is optional.

[SwissAmi]

Hi all,

I noticed, that in some environments this happens because of overlapping IP-Ranges.

Often, users at home have an ip address range of 192.168.0.0/24 and sometimes this is a part or an additional range of the customers ip ranges at his headquarters. If you now include this in the routing mechanism you'll have overlapping ranges.

At some locations, I could fix this simply by readdressing the users home network (just put it into a higher range such as 192.168.249.0/24). From that time on, this issue was fixed. Not everywhere, but a quite remarkable number of complaints disappeared.

Give it a try!

Greetings

[studiopeg]

I know this reply is late to the game, but we had the same thing happen over and over and over.  We all but gave up as the settings would constantly change on their own.  But we finally figured out what was going on, at least for us.

When setting up the VPN, we would use the login type as User Name and Password.  In the adapter settings under security, we would uncheck all protocols except for Unencrypted Password (PAP).  We would test, all would be fine.

Then we noticed the settings changing on their own.  The VPN login type would change to General Authentication Method.  We would change it back to User Name and Password, and it would not work.  We would then check the adapter security tab settings and it had unchecked Unencrypted Password (PAP) and checked Microsoft CHAP.  We would change that back to our required Unencrypted Password (PAP) and it still would not work and settings were changing on their own again.  Round and round this went - we would set the correct settings and it would go right back to its changes.

We finally found that AFTER the initial VPN setup and test - when it would change the login from User Name and Password to General Authentication method - if we left that setting alone, the adapter security tab settings would also be left alone (i.e., it would not be changed to Microsoft CHAP).  And the VPN would work.

It was when we changed the login method back to User Name and Password that the adapter security settings would change itself to Microsoft CHAP.

So after the initial setup with User Name as Password we checked "remember me" which retained the user name even when it reverts to General Authentication method.  We still had to enter the password again, but it worked thereafter.

We were ready to can the entire Meraki system, but finally figured this out.  I don't know if this will help anyone but sure hope so.

[CAquinoQGA]

We noticed that changing the authentication method to Username & Password would reset the adapter settings and vice versa. Changing the adapter settings first, reset the authentication method to General as well. So round and round in a circle we went. After much frustration from our users, we gave up on Microsoft issuing a fix, so we tested & deployed the previously suggested DrayTek Smart VPN Client. It's working flawlessly and our users have reported they are able to connect/disconnect and work remotely without any issues now. I recently tested it from abroad while on vacation and it worked really well. Just sharing our experience and a possible workaround.

[IT_Tropolis]

I just started seeing this issue again, on (3) different Windows 10 computers in the past 2 days.  All 3 are Windows 10 Build 19042 but that may be a coincidence. 

VPN working then all of a sudden it won't connect.  Authication method set to General Authentication.  Changing it to Username and Password caused the Adapter settings to have the Security tab option for protocols greyed out so neither PAP nor CHAP are checked.  Fixing the Adapter settings resets the VPN authentication from Username and Password to General, and round and round we go.

Was their ever a fix for this issue besides using a 3rd party VPN s/w, i.e. did MS fix it?

[PhilipDAth]

Try creating the VPN using my cookbook:

https://www.ifm.net.nz/cookbooks/meraki-client-vpn.html 

It uses the VPNv2-CSP engine in Windows 10 - which can't be configured via the GUI.  The new engine seems reliable in this area.

[SwissAmi]

Hi PhilipDAth

Your cookbook and online configurator is indeed a good tool and nice programming

[SwissAmi]

Hi IT_Tropolis

I experienced this too. The solutions for me was:

- Configure the settings according to meraki's documentation

- BUT: In the security Tab, let the option "Microsoft CHAP, Version 2 (MS-CHAP v2)" activated (Do not disable it)

With this setting applied, the configuration did not change itself anymore.

Hope this helps,

Swiss_Ami

[Dunky]

I appreciate this is an old post, but it has had some recent replies.

You are aware that the Cisco AnyConnect VPN client is now supported?

Not used it myself (have an MX64 at the one site we have client VPN and the MX64 has to the use the native MS client).

[SwissAmi]

Hi Dunky,

Thank you for your post.

I am aware that Cisco Anywhere is supported (and hopefully others too). Regardless, there are customers who want to use only Windows board resources.

But for others in this forum this is most certainly a helpful hint