How to debug dropping OpenVPN connections
-
@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 nowCan 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,
etc.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!
