Skip to content

How to fix OpenVPN randomly disconnecting on Windows 10


After the anniversary update of Windows 10, many OpenVPN users saw their clients randomly disconnecting.

The issue is that the anniversary release of Windows 10 conflicts with the TAP driver used by OpenVPN.  You’d think with the size and technical ability of Microsoft they would fix this issue with OpenVPN.



Step 1 – Change Adapter Settings

Network & sharing centre > Change Adapter Settings

openvpn fix 1

Step 2 – Select the Tap Adapter (used by OpenVPN)

Right click on the Tap Adapter > Properties

openvpn fix 2

Step 3 – Internet Protocol V4

Properties Button

openvpn fix 3

Step 4 – Advanced Button

openvpn fix 4

Step 5 – Turn off Automatic

Windows 10 defaults to “Automatic Metric”.   You do not want automatic.

You may need to calculate the correct MTU (or pack size).

openvpn mtu

Here’s the MTU set to 1420

openvpn 1420


Your OpenVPN interface/connection should now become stable.

Fix 2 – if the above fix fails then reinstall the TAP driver.

Search for Device Manager > Network Adapters > Tap Driver > Uninstall


Always trust OpenVPN > Installopenvpn fix always trust


Phase 2 – is your DNS not stable?

The anniversary coding for Windows 10 is utter rubbish.  If the steps above fail to correct a DNS issue when using OpenVPN – here is phase 2 fix of the DNS.

The fix for this is found at:

Windows 10 OpenVPN DNS Issues

There is a “bug” in Windows 10 where its DNS resolution uses the interface metrics assigned to it, and OpenVPN’s network interface has too high of a metric to be used for DNS.

To fix it we’ll lower the metric of the OpenVPN interface so it takes priority when you are connected to the VPN.

Identify The OpenVPN Interface Name

First open your Windows 10 Settings menu via the start menu -> Settings.  Then click the “Network & Internet” tile:

From there go to the “Ethernet” tab on the left, then click “Change adapter options” under “Related Settings”.  This will open a window with all of your network adapters, similar to the below:

The next step is to locate which out of these interfaces is the OpenVPN adapter, it will be the one with the words “TAP-Windows Adapter” on the 3rd line (selected above).  Make a note of the name of this adapter.  In the above example it is “Local Area Connection 5”, and we’ll use that moving forward but substitute your own interface’s name instead in the commands below as it is likely different.

Open An Admin Command Prompt

Press   (windows key + x) and pick “Command Prompt (Admin)”:

In the command window type in “netsh int ip show interfaces” which should present a list of all the interfaces:

The value we’re looking for is “Met” (short for “Metric”).  You can see our OpenVPN connection (“Local Area Connection 5”) has a higher or same metric as other network connections.  We need to set this metric value to a lower number than all the other interfaces.

In this case a value of 4 will be lower than all the other interfaces, so we’ll use that.  In the command window run the command “netsh int ip set interface “Local Area Connection 5″ metric=25”, substituting the OpenVPN interface you identified in the first step:

Lastly run the “netsh int ip show interfaces” command again and confirm that the OpenVPN interface is the lowest “Met” value:

Reconnect to the VPN

Attempt to reconnect to the VPN and see if DNS resolution works


My honest advice is that if you’re within the 10 days roll back period of this anniversary update – GET RID OF IT FOR HEAVENS SAKE!!

  1. Walter permalink

    You might want to mention that your ovpn file might already come with some preset value of mssfix and you need to match this value in adapter settings or you will most likely hit a BSOD .. at least thats what happened in my case.


  2. Zsolt Szabo permalink

    First, great article! Concise and helped me think about areas to investigate for troubleshooting my own problem.

    However, I believe the suggestions may defeat a VPN connection and expose traffic (possibly while seemingly fixing the problem?). In particular, step five seems to conflate interface metric and maximum transmission unit (MTU), which are unrelated concepts.

    The interface metric sets routing cost, which determines how traffic is sent when multiple routes are available. The wrong setting here will cause the system to send data the wrong way, which may bypass your VPN.

    Meanwhile, MTU specifies the maximum size of data that your local network can handle per transaction. Due to rigid lack of flexibility in this regard, the wrong setting here should not cause any “soft” problems: either the settings work, or they don’t. And since the underlying framework is equipped to handle cases where they do not, at least theoretically the wrong MTU setting should never cause something like connection drops (I’m not sure what happens if MTU is set to a very small value that effectively reduces the payload size to zero, or close to zero; too big a setting is handled by fragmentation, which technically isn’t a problem).

    The advice given appears to suggest setting the interface metric to the MTU size. My currently active metrics range from ~50-300. Setting this to 1420 on any of them would raise the cost of that route so high that the system would never choose it, if other options were available.

    Current metric and MTU settings can be shown side by side for each interface by running “netsh interface ipv4 show interface” from the command line (metric settings are under “Met”).


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: