I'm trying to troubleshoot connectivity issues for one of our employees who's using a OpenVPN client to connect to our office infrastructure. AFAIK, he's the only one affected by this issue which basically lets him connect fine but after a few minutes up to one or two hours disconnects him.

He's using W10 via wifi with no possible way to use a LAN cable and his ovpn client log looks like this:

Thu Jan 28 11:28:05 2021 Connection reset, restarting [-1]

Thu Jan 28 11:32:21 2021 [ApplianceCertificate_xxxxxxxxxxxxx] Inactivity timeout (--ping-restart), restarting
Thu Jan 28 11:32:21 2021 SIGUSR1[soft,ping-restart] received, process restarting
Thu Jan 28 11:32:21 2021 MANAGEMENT: >STATE:1611829941,RECONNECTING,ping-restart,,,,,

Thu Jan 28 11:52:01 2021 read TCPv4_CLIENT: Connection timed out (WSAETIMEDOUT) (code=10060)
Thu Jan 28 11:52:01 2021 Connection reset, restarting [-1]
Thu Jan 28 11:52:01 2021 SIGUSR1[soft,connection-reset] received, process restarting

Thu Jan 28 13:52:17 2021 Connection reset, restarting [-1]
Thu Jan 28 13:52:17 2021 SIGUSR1[soft,connection-reset] received, process restarting
Thu Jan 28 13:52:17 2021 MANAGEMENT: >STATE:1611838337,RECONNECTING,connection-reset,,,,,

Because I wanted to test his internet connectivity too, I asked him to run a continuous ping command against google.com and while most packets went through just fine, there were a few lost packets (4 within 6 minutes with a rate of one query per second). Based on the log, I could find that Connection timed out (WSAETIMEDOUT) (code=10060) basically stands for a connectivity issue between the client and the vpn server, which is why I figured this could be caused by the few lost packets that happen every now and then. I'm just not that sure that the vpn would be that sensitive. He also tells me that everything else works fine, including calls, which is the reason why I have doubts that a few lost packets could actually be the root cause for this.

I had a look at his router configuration (router which was restarted recently too) and as far as I could tell, there was noting that screamed misconfiguration.

I'm a bit at a loss here as to what I could try to really confirm that the root cause is the internet connection. I thought of asking him to setup a hotspot wifi with his phone for a couple of hours but I'm concerned about the costs it would incur if he had to go into conference calls, so for now I haven't tried that.

Any ideas or suggestions? Thanks!


Properly configured OpenVPN is not that sensitive, not to the point it breaks for lost few packets. But your test doesn't demonstrate there is really only few packets lost. This may be interpreted as that internet wasn't accessible at all working for a few seconds, and that's not a "few packets".

If OpenVPN is configured over TCP (not recommended), it is quite sensitive. First, it is impossible for TCP connection to only lose a few bytes in the middle of the stream. TCP is a "reliable", this means either other side received timely all the data that was sent, or a connection is reset as broken. Also a connection will be reset if either side receives "TCP reset" packet or one of ICMP unreacheables. Such ICMP unreachable may be generated, for example, by the router on the intermittent short internet break (WiFi reassociation, PPPoE reconnection, etc.).

Also, if you don't have a static IP on the WiFi, or/and static public IP on the router, after reconnection you may get another IP assigned, or get SNATed into another port. If in addition VPN configuration on the remote doesn't permit "floating" clients, it'll need reconnection too.

In general, this seems to be an internet connection issue. Troubleshoot that.

  • Thanks. Yes, our vpn is indeed setup over TCP and the lost ICMP packets on the client side were not following each other (went from a minute to a few minutes in between), which is why I considered them to be a "few packets". It happened from e.g. one minute to another and while we were on a Zoom call at the same time. Obviously this was not enough of an interruption to cause overall connectivity issues otherwise our call would have shown it too. Based on these additional details, do you still think it's worth investigating the internet connection?
    – SilentSib
    Mar 1 at 10:59
  • 1
    @SilentSib The first thing I would do is switch back to UDP, though you didn't mention what bizarre circumstances led you to use TCP in the first place. Mar 1 at 18:12
  • I wasn't the one who made the choice to use TCP in the first place, so I can't say why it was done like this. What it boils down to is that this user is seemingly the only one having issues with our vpn at the moment, or at least issues important enough to complain about it, so if there's a way to fix it without making that change, I'll do it. I do get that because TCP is connection-oriented it's more sensitive than UDP. That much is clear. If troubleshooting the internet connection doesn't get the issue fixed then I'll see if we can make that change.
    – SilentSib
    Mar 2 at 8:11

I had exactely the same behavior, being the only one with this issue. It was cause by a to high MTU value for the WiFi connetion. I changed the automatic setting of the MTU of the network card to the manual setting, using 1400 as new value. Immediately the issue disappeared.

  • For some of our users, the ISP (a TV cable company) only provides IPv6, requiring IPv4-in-IPv6-encapsulation. I found that these connections have massive packet loss with crippled IP headers (looks like a bug), unless you reduce MTU on the tunnel adapter. The exact value depends on protocol details and varies with provider, but 1400 should be good (that said, we use 1300). Whether this might be the cause of your problem I can't say. But it's certainly worth a try to reduce the MTU. Oct 4 at 20:40
  • Thanks for the pointer, I'll keep this in mind if I ever see this happening again!
    – SilentSib
    Oct 5 at 7:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.