tunnel dropping ?

[simonmcnair]

I've been using Gluetun for ages in front of qbitorrent and using wireguard. I don't like to complain and I am really grateful for the product .... buuuuuuuut.

I use the 'torrent to web' plug in to add torrents, they are added in the background. I may check on them an hour/10 hours or days later and it's really frustrating to see qbittorrent stating 'downloading metadata'. A stop and start of gluetun and a restart of qbittorrent and boom. Metadata downloaded, and torrent proceeding.

I look in the log file and

2024-10-27T14:24:45Z WARN [dns] dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T14:24:47Z WARN [dns] dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T14:24:47Z WARN [dns] dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T14:24:50Z WARN [dns] dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T14:24:50Z WARN [dns] dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T14:32:11Z INFO [healthcheck] healthy!
2024-10-27T14:32:11Z WARN [dns] dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T14:32:11Z WARN [dns] dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T14:32:13Z WARN [dns] dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T14:32:13Z WARN [dns] dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T14:36:30Z INFO [healthcheck] healthy!
2024-10-27T14:36:33Z WARN [dns] dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T14:36:33Z WARN [dns] dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T14:46:33Z INFO [healthcheck] healthy!
2024-10-27T14:46:35Z WARN [dns] dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T14:46:35Z WARN [dns] dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T14:48:56Z WARN [dns] dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T14:48:56Z WARN [dns] dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T14:52:10Z WARN [dns] dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T14:52:10Z WARN [dns] dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T14:57:00Z INFO [healthcheck] healthy!
2024-10-27T14:57:03Z WARN [dns] dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T14:57:03Z WARN [dns] dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T15:00:14Z INFO [healthcheck] healthy!
2024-10-27T15:01:32Z INFO [healthcheck] healthy!
2024-10-27T15:01:35Z WARN [dns] dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T15:01:35Z WARN [dns] dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T15:08:07Z WARN [dns] dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T15:08:07Z WARN [dns] dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T15:08:09Z WARN [dns] dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T15:08:09Z WARN [dns] dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T15:08:12Z WARN [dns] dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T15:08:12Z WARN [dns] dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T15:11:19Z INFO [healthcheck] healthy!
2024-10-27T15:11:22Z WARN [dns] dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T15:11:22Z WARN [dns] dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T15:11:34Z WARN [dns] dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T15:11:34Z WARN [dns] dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T15:18:02Z WARN [dns] dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T15:18:02Z WARN [dns] dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T15:18:33Z WARN [dns] dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T15:18:33Z WARN [dns] dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T15:18:35Z WARN [dns] dial tcp 12.159.2.159:853: i/o timeout
2024-10-27T15:18:35Z WARN [dns] dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout

Now I would assume that it is probably working okay, because it if didn't it would restart the vpn. But it doesn't. I know wireguard silently fails. But I would like it if there were additional debug levels, or some control over trying to do some diagnosis ?
I looked at the healthcheck and it seems to connect to cloudflare.com:443 as a check ? I am no Go expert. I guess what I'm asking is if there is a more robust healthcheck that could be put in place and/or if the logging could be more informative ?

There may be an option to state how aggressively the health check will respond ? i.e. I am sure there are instances where people would like the link to keep retrying, rather than getting killed and restarted, but for me, I don't care if the connection goes down 10 times a day. As long as it reconnects I'm not in any hurry.

Ideas/perspectives ?

Cheers

[epic0421]

It is likely related to this issue. Try adding the WIREGUARD_MTU or OPENVPN_MSSFIX environment variable with a value of 1320 (ref) and see if that fixes it.

[qdm12]

it's really frustrating to see qbittorrent stating 'downloading metadata'. A stop and start of gluetun and a restart of qbittorrent and boom. Metadata downloaded, and torrent proceeding.

qbittorrent might not be handling VPN "auto-healing", that's why it doesn't move really. Deluge and Transmission handle VPN internal reconnection fine though.

dialing dns over tls server: dial tcp 12.159.2.159:853: i/o timeout

As @epic0421 mentioned this is due to the MTU being too high, the latest image now has a default MTU of 1320 instead of 1400 for Wireguard. You can try other values with WIREGUARD_MTU if you want.

But I would like it if there were additional debug levels, or some control over trying to do some diagnosis

There is LOG_LEVEL=debug, but apart from that that's all there is, and no plan to add other diagnosis. The aim is to have the least logs and have a working solution by default 😄 Anyway, in this particular case, other diagnosis information wouldn't be really useful, since the true reason is the high MTU and that causes everything to misbehave.

I looked at the healthcheck and it seems to connect to cloudflare.com:443 as a check
if the logging could be more informative

Correct, it does a simple TCP dial to cloudflare.com:443. Actually now that you mention it, I've just added a TLS handshake to cloudflare.com after the dialing in ef28277. It's better for the healthcheck to check the handshaking works to detect those MTU issues before the DNS-over-TLS/other-HTTPs error out. I also added 0e7bdd5 the healthcheck error to be logged out so we know why the program is unhealthy now.

if there is a more robust healthcheck that could be put in place

Unlikely 😄 This healthcheck has been refined many times over many years, but I'm happy to hear suggestions though!

There may be an option to state how aggressively the health check will respond

Already the case, and no need for an option, see this commit: 6042a9e - my philosophy here is to have the least options possible, even-though there are already quite a few out there 😄 And if a simple TCP dial (well now with tls handshake) cannot make it in max 10 seconds, the VPN is 99% guaranteed to be broken somehow 😸 Unless you are multi hoping through the entire Internet or something but I don't think anyone is!

[simonmcnair]

Sorry it took me so long to respond. I've been away. Thanks for the advice.