How to debug dropping OpenVPN connections

  • Gateway-monitors of OpenVPN client-gateways report package loss/latency for a couple of minutes every couple of hours and put the gateway offline.
    The clients themselves show online and there are no log-entries in OpenVPN that indicate that something is wrong except for some Management CMD statusses (Verbosity level: 3).

    How and where to find more detailed connection information?

  • @discy said in How to debug dropping OpenVPN connections:

    How and where to find more detailed connection information?

    By changing "Verbosity level: 3" to something higher.

    edit : a connection that seems to be off line will reopen itself, connected clients often even don't see they get disconnected : when traffic restarts, the connection is reconstructed.
    Connections over 3G/4G/LTE do get disrupted all the time, as clients move around - this is normal.

  • @Gertjan Any suggestion for what would be appropriate? 11 floods the log.

  • @discy said in How to debug dropping OpenVPN connections:

    11 is floods the log.

    That's not a problem. That's where logs are for.
    Typically, very verbose is maintained up until you found out the what happens.

  • 12:18:41 MONITOR: VPN is down
    12:18:57 MONITOR: VPN is available now


    Can you make sense of it? 😕

  • You're using the OpenVPN client, right ?
    Connecting to what / who ?

  • Yes client. To a consumer VPN service.

  • @discy said in How to debug dropping OpenVPN connections:

    To a consumer VPN service.

    That's a factor you can't control.

    You better check these two :


    and hope for best.

    Commercial VPN's are not all equal these days. Many drive their services up to 1xy precent (more then 100). And guess what happens when you fall into that xy part ^^ ;)

  • Although I cannot control them.
    Shouldn't the log provide information about what's actually happening to the connection?

  • Well, it says what happens : you see many tunnel errors (can not write to TUN ....) which means the underlying UDP (?) channel is 'broken'.
    This could be :
    Upstream traffic chapping (your ISP or above).
    The end connection, your VPN supplier, didn't reply back,
    Or even something in the middle that can't handle the load, so traffic start to drop,

    Classic old school WAN connection works well ??
    (anyway, change your VPN supplier and suddenly it start working well again .... so you know what actually happened )

  • Thanks for helping me to understand what exactly are the errors in the log!

    • Tried another VPN provider: same issue.
    • WAN works very well
    • TCP because I had issues with UDP

    Probably something related to my setup (and/or both VPN providers). Will try to dig deeper.

  • There are some spikes once in a while.
    I was unable to find the root cause. You might be right in that it's caused by the provider itself.
    To midigate I put the packet loss monitoring threshold at 50/90 and disabled latency monitoring.

    If there is anything more to do/investigate, I'd be interested to know.


  • This post is deleted!

Log in to reply