pinkisemils
commented
2 years ago I see you've posted a lot of logs about a vanilla OpenVPN, but this repository is only really meant to deal with our client. Our client doesn't pass the --persist-tun argument to our OpenVPN instance, and it isn't enabled by default. If you believe there's an issue with the generated config files, I suggest you email support.
Having tested this by just blocking traffic to a specific relay via a firewall, when using UDP and TCP, our client enters the reconnecting state and will attempt to connect to a different relay unless the user informs it to stop. And once connectivity returns, the client will end up connecting back. I also suggest using WireGuard, be it with our or regular clients, as it will help immensely with reconnecting quicker.
However, if there are issues with the app not recovering after trying to reconnect for several minutes, I suggest sending a problem report from the app as it will make it at lot easier to understand what's going on. Also, it'd be interesting to see what ip route get default returns when you've lost connectivity.
Issue report
Issue description
I've had a problem with permanent disconnections while (1) using the Mullvad app and (2) a standalone Openvpn setup without the app installed. I'm new to using Openvpn/Mullvad so this just started happening. The gateway of my client often goes down for periods longer than 5 minutes, which I cannot prevent. When this happens, specfically disconnections of a few minutes or longer, the tunnel remains up but is never able to push traffic. Either restarting the Mullvad app or
sudo service openvpn@mullvad_xx restartwill always resolve the situation, which seems to hint at the tunnel interface persisting between service restarts as the culprit. I've googled this problem and there are several lookalike problems going back several years, and the only "solution" I can find is a workaround script that pings a server and restarts openvpn if too many pings are dropped.While following the Mullvad howto tutorial to configure Openvpn on Linux, it gives instructions to use the config generator. I tried different combinations of config settings and the permanent disconnection behavior always appears when
persist-tunis enabled.I repeated these steps while running
ping 8.8.8.8andjournalctl -xfeto reveal the behavior:sudo service openvpn@mullvad_xx restartjournalctlandpingoutput and see if the tunnel connection recovers.I tallied up the instances where the connection didn't recover and did recover. I only waited about 5 minutes during testing to wait and see if it would automatically reconnect, but it'll sit there for hours disconnected, which is how I noticed the problem. After plugging the network cable of the client gateway back into the switch, with
persist-tunoff, it was able to reconnect 100% of the time, versus 0% of the time with thepersist-tunon:This seems to happen with both the app and standalone Openvpn setups, however the duration of disconnection was sometimes short enough for the connection to recover, hence my confusion. But keeping it disconnected for longer than a few minutes caused the behavior to appear.
Given that similar bugs have happened in the past due to the tap driver, which I cannot say is the cause of this issue, the persistent tunnel option seems to be a source of problems. Given the popularity of Debian 11 and Openvpn, I think it's fair to say this config option should be disabled on this setup (I didn't test other platforms) specifically in the Linux HOWTO, but perhaps on the app as well, as I feel like someone else will run into this issue. If someone absolutely needs this option enabled for some reason, I think they should be aware that this option can cause problems.
I cannot say if this will fix the disconnection behavior in the app itself as I did all config testing specifically with the Openvpn standalone setup, and I didn't look into how to alter the config of the app.
I'll file a bug report with Openvpn later as I initially thought it was a Mullvad issue, but the cause seems to be lower level. I have not tried different versions of Openvpn. Note: I did take a brief look through the openvpn sourceforge issues and couldn't see anything similar, or any changelogs with anything that stands out as related to this issue.
My setup is very simple, so I hope that it's easily reproducible for someone else.
Operating system and configuration
Operating system: Debian 11 Bullseye, kernel 5.10.0-14-amd64. Very minimal setup, is running no other software. App version: 2022-1 and 2022-2beta Resolvconf has been disabled to reduce complexity, though the bug still appears with or without it. Ipv6 has been disabled via:
Openvpn package:
/etc/network/interfaces:/etc/openvpn/mullvad_xx.conf:Example Logs with commentary added