Windows 10 client VPN dropping...

[CarlosCoque]

Hi everyone,

I'm having a very particular issue.

I have 2 firewalls connected to the same modem: a Meraki MX64 and another from a different brand.

About a month ago, some users complained that they could not complete the download of a 1.4GB file from one of our servers.

I haven't imagined that it could be a broader issue, so I asked them to restart their computers and try again.

Over time they'd eventually be able to download that file and stop reporting that issue.

A couple of days ago however I got that same issue with another user and decided to further investigate.

She wasn't able to download the file and would get an error after about 5 to 7 minutes of downloading the file, according to her.

I tried downloading the same file from my laptop and it did work fine.

On the following day though, when I was trying to develop a robocopy batch to help her out with the download process, the same issue started happening to me over and over.

I tried uninstalling all the security software on my laptop and it'd still drop the VPN connection during the file download.

I tried downloading other large files and would get interrupted in the same percentages for each file.

Then, I decided to try connecting to the VPN of the other firewall that is connected to the same LAN as the MX64.

Surprisingly, I got a similar issue.

I also tried checking the MX64 logs and Windows Application logs, but haven't found any clue.

Today I did some additional testing and tried downloading a 600Mb file 3 times.

All of them have failed at the same point (28% transferred, then the speed goes to 0, and a couple of minutes after the VPN connection to MX64 drops).

I suspect it can be something with Windows VPN configuration but I have to confess I'm pretty lost at the moment.

Did anyone had a similar issue before?

Thanks!

[PhilipDAth]

Check the security centre to ensure you are not tripping some IPS signature that is killing the transfer.

You may be experiencing issues with asymmetric transfer times (especially if the user has an asymmetric Internet circuit, such as 100 down and 20 up).

Try doing the below to enable timestamps (ideally, this should be done on the server and client) to see if it helps:

netsh int tcp set global timestamps=enable 

If you don't mind spending a small amount of money, Cisco AnyConnect is may better than the Windows client VPN.  Perhaps you could give that a try:

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

[CarlosCoque]

No luck.

I noticed that it usually happens at the same point of the file transfer (28% for some files, 47% for others).

What seems to be happening is that after some amount of data is transferred (or transfer time), the network adapter on the remote host where the client VPN is running simply stops working making the internet connection drop, and then it drops the VPN connection as well.

That's why I believe it's an issue with the remote client and not the MX.

After some time it gets back online.

I tried virtually everything already and it simply keeps happening with multiple laptops (not sure if all because most people don't transfer large files through the VPN link).

Here is a list of what I remember having tried:

- Uninstalling all security software

- Disabling Windows firewall

- Restarting internet modem

- Using a VPN from another firewall connected to the same modem as our main firewall

- Changing network profile (Public vs Private)

- Changing file type (exe vs dummy file)

- Changing MTU

- Changing from Wireless to Wired

- Copying using shared drives, RDP (copy from RDP and paste locally), RDP local drive configuration, and robocopy/

- Disabling "Allow the computer to turn off this device to save power" on the network adapter

and a few more...

Did anyone have anything similar?

[PhilipDAth]

Could you also try checking the home router firmware being used and ensure that is up to date?

I would try disabling IPS and AMP for a short time (under Security & SD-WAN/Threat Protection) to see if they are impacting anything.

[jbitgood]

I have been dealing with this exact issue since around the end of March without finding a resolution. It just suddenly started happening. The firmware had not changed, so the only thing I can come up with is the possiblity of a Windows patch released around that time causing it. I've tried all the settings/changes mentioned here. I'm replying here both to share that you're not alone and to receive updates.

I have been able to confirm that using AnyConnect does indeed resolve the issue, but I would far prefer to keep using the built-in client due to the expense. The ones writing the check are asking the very legitimate question of why should we shell out another 3 grand to do something we've been doing for free all this time.

[BBu]

Are there any network monitoring/logging tools that can help cast light on the root cause? If AnyConnect works, does that not rule out W11? I believe I experienced similar issue with W10. Also, I tested download of large file (>1 GB) via FTP server (connecting via VPN connection) and it worked fine.

[jbitgood]

I've done a packet capture, and the traffic just stops without any kind of warning, with Windows silently closing the connection several seconds later.

[BBu]

What about traffic logs on the MX64?

[jbitgood]

Sanitized and unrelated lines removed: https://pastebin.com/n5pm8mW0 

[jbitgood]

So the blame appears to lie with the MX64. I installed a UDM-Pro with the same L2TP/IPsec VPN setup for testing, and I can transfer multi-gigabyte files without a hitch. The obvious question coming from the client is why don't we just leave the thing in place? I'm finding it difficult to disagree at this point, because they sure aren't going to shell out thousands for AnyConnect when a $400 solution is sitting right in front of them.

[Kenny_Benzing]

It sounds like you need to open a ticket with Meraki Support.....or follow through on your last sentence. 😬

[jbitgood]

The license is up in a few months anyway, so the question is pretty much answered for me. I'm not going to waste any more time on this.

[CarlosCoque]

Hi @PhilipDAth, thanks again for another suggestion.

No luck again...

It still stops the transfer at the same point.

I also tried with the other firewall we have (non-Meraki) and had a similar issue.

That's the reason after some troubleshooting I believe it could be something not directly related to Meraki.

Since transfer speeds are around 1MB/s (very slow) I believe that it could be something related to a timeout.

It could also be a download file buffer or something similar that could be getting full.

I'm really intrigued with this issue...

[PhilipDAth]

Does the MX at the office have a public IP on it,  or is it sitting behind something else doing NAT?

I would try Cisco AnyConnect ...

[CarlosCoque]

It has a public IP, however, the issue is happening with a SonicWall firewall behind the same modem and with a different public IP address.

That's why I believe the MX is not the issue.

We also use Meraki switches all over our network.

Do you think it could be something with those switches?

Like, maybe an MX security policy applied to the switches to protect the LAN?

[BBu]

CarlosCoque, were you able to find a solution? Same basic issue here with MX64. The download simply terminates and the connection drops after downloading about 50% of large (~500Mb) file. Thanks.

[CarlosCoque]

Unfortunately not.

I expected that this was a common issue but apparently not many people have that.

We have Meraki and another brand firewall behind the same internet link and that happens with both in slightly different manners.

I also asked my ISP if that could be coming from them, but they denied it.

To be honest, I lost my hope already and I'm trying to live with that.

[Kenny_Benzing]

Check in your Windows settings to see if your connection is listed as "metered" (On Windows 10, go to Settings -> Network & Internet -> and select Properties of the connected network). You may also have to "Allow VPN over metered networks" if it's a VPN configuration issue.

With it failing at the same place, it sounds to me like metering is enabled.

[BBu]

Thanks for the input. Metered connection was off.

I then tried to set Allow VPN over metered networks to off as well (under settings for the VPN connection), booted my PC and reconnected to the VPN. I was then able to download the +500Mb file. But when proceeding to download +2GB file, download stopped at ~100Mb and the VPN connection dropped again. Only common denominator seems to be that download of large files fails.

[Kenny_Benzing]

Have you searched Microsoft forums for an answer? Perhaps this will help

https://answers.microsoft.com/en-us/windows/forum/all/wifi-disconnecting-when-downloading-large-file...

EDIT: I would like to add, I have seen this setting cause Outlook connectivity issues. I know that's not your problem, but it's food for thought.

[Kenny_Benzing]

Sorry, I just re-read the original post and realized you've tried that. How about the properties of the VPN -> Options Tab and changing the Idle time before hanging up to Never?

[CarlosCoque]

Tried that as well.

Mine was showing "never" since the beginning if I'm not wrong.

[Kenny_Benzing]

Maybe a silly question, but you don't have any type of Group Policies setup, do you?

Network-Wide -> Configure -> Group Policies

[BBu]

I don't believe Group Policies are at issue. File Explorer (SMB protocol) or an internet browser breaks the Meraki VPN connection when I download large files >500Mb. However, when I tested download via FTP, there was no issue downloading a multiple GB sized file.

[BBu]

Just to correct myself, this is not an SMB protocol issue. I believe this has to do with the inherent reliability issues surrounding the UDP protocol.

Unlike TCP, UDP can't re-transmit lost data packages. This becomes a problem when downloading large files; one lost package and the entire download fails.

When analyzing a file download using MS Network Monitor 3.4, it's apparent that the IPv4 internet protocol, together with ESP data packages (encrypted data) encapsulated within UDP data packages, are used. UDP is fast and great for streaming services, where loss of single data packages is uncritical; it's just a missing pixel on the screen.

I wish Meraki offered a TCP solution with its VPN server, which should solve this problem.