Bug: Cannot get version info and IP Getter
kingofhteseas opened this issue Β· comments
Is this urgent?
None
Host OS
Ubuntu
CPU arch
x86_64
VPN service provider
Mullvad
What are you using to run the container
Portainer
What is the version of Gluetun
3.37.0
What's the problem π€
After Ubuntu updates I keep seeing:
ERROR [vpn] cannot get version information: Get "https://api.github.com/repos/qdm12/gluetun/releases": context canceled
and
ERROR [ip getter] Get "https://ipinfo.io/": context deadline exceeded (Client.Timeout exceeded while awaiting headers) - retrying in 5s
Usually changing the version resolves this but not this time. I have tried changing my compose by commenting out things or changing the private key to the servers public key, but still getting errors.
Share your logs (at least 10 lines)
2024-04-15T01:21:16Z INFO Alpine version: 3.18.5
2024-04-15T01:21:16Z INFO OpenVPN 2.5 version: 2.5.8
2024-04-15T01:21:16Z INFO OpenVPN 2.6 version: 2.6.8
2024-04-15T01:21:16Z INFO Unbound version: 1.17.1
2024-04-15T01:21:16Z INFO IPtables version: v1.8.9
2024-04-15T01:21:16Z INFO Settings summary:
βββ VPN settings:
| βββ VPN provider settings:
| | βββ Name: mullvad
| | βββ Server selection settings:
| | βββ VPN type: wireguard
| | βββ Countries: sweden
| | βββ Wireguard selection settings:
| βββ Wireguard settings:
| βββ Private key: Qn1...G0=
| βββ Interface addresses:
| | βββ
| βββ Allowed IPs:
| | βββ 0.0.0.0/0
| | βββ ::/0
| βββ Network interface: tun0
| βββ MTU: 1400
βββ DNS settings:
| βββ Keep existing nameserver(s): no
| βββ DNS server address to use:
| βββ DNS over TLS settings:
| βββ Enabled: no
βββ Firewall settings:
| βββ Enabled: yes
| βββ Outbound subnets:
| βββ
βββ Log settings:
| βββ Log level: INFO
βββ Health settings:
| βββ Server listening address: 127.0.0.1:9999
| βββ Target address: cloudflare.com:443
| βββ Duration to wait after success: 5s
| βββ Read header timeout: 100ms
| βββ Read timeout: 500ms
| βββ VPN wait durations:
| βββ Initial duration: 6s
| βββ Additional duration: 5s
βββ Shadowsocks server settings:
| βββ Enabled: no
βββ HTTP proxy settings:
| βββ Enabled: no
βββ Control server settings:
| βββ Listening address: :8000
| βββ Logging: yes
βββ OS Alpine settings:
| βββ Process UID: 1000
| βββ Process GID: 1000
βββ Public IP settings:
| βββ Fetching: every 12h0m0s
| βββ IP file path: /tmp/gluetun/ip
βββ Version settings:
βββ Enabled: yes
2024-04-15T01:21:16Z INFO [routing] default route found: interface eth0, gateway 172.17.0.1, assigned IP 172.17.0.3 and family v4
2024-04-15T01:21:16Z INFO [routing] adding route for 0.0.0.0/0
2024-04-15T01:21:16Z INFO [firewall] setting allowed subnets...
2024-04-15T01:21:16Z INFO [routing] default route found: interface eth0, gateway 172.17.0.1, assigned IP 172.17.0.3 and family v4
2024-04-15T01:21:16Z INFO [routing] adding route for 192.168.1.0/24
2024-04-15T01:21:16Z INFO TUN device is not available: open /dev/net/tun: no such file or directory; creating it...
2024-04-15T01:21:16Z INFO [http server] http server listening on [::]:8000
2024-04-15T01:21:16Z INFO [firewall] allowing VPN connection...
2024-04-15T01:21:16Z INFO [dns] using plaintext DNS at address 10.64.0.1
2024-04-15T01:21:16Z INFO [healthcheck] listening on 127.0.0.1:9999
2024-04-15T01:21:16Z INFO [wireguard] Using available kernelspace implementation
2024-04-15T01:21:16Z INFO [wireguard] Connecting to [2a03:1b20:5:f011:31::a03f]:51820
2024-04-15T01:21:16Z INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working.
2024-04-15T01:21:23Z INFO [healthcheck] program has been unhealthy for 6s: restarting VPN (see https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md)
2024-04-15T01:21:23Z INFO [vpn] stopping
2024-04-15T01:21:23Z ERROR [vpn] cannot get version information: Get "https://api.github.com/repos/qdm12/gluetun/releases": context canceled
2024-04-15T01:21:23Z INFO [vpn] starting
2024-04-15T01:21:23Z INFO [firewall] allowing VPN connection...
2024-04-15T01:21:23Z INFO [wireguard] Using available kernelspace implementation
2024-04-15T01:21:23Z INFO [wireguard] Connecting to 185.65.135.69:51820
2024-04-15T01:21:23Z INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working.
2024-04-15T01:21:31Z ERROR [ip getter] Get "https://ipinfo.io/": context deadline exceeded (Client.Timeout exceeded while awaiting headers) - retrying in 5s
2024-04-15T01:21:34Z INFO [healthcheck] program has been unhealthy for 11s: restarting VPN (see https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md)
2024-04-15T01:21:34Z INFO [vpn] stopping
2024-04-15T01:21:35Z INFO [vpn] starting
2024-04-15T01:21:35Z INFO [firewall] allowing VPN connection...
2024-04-15T01:21:35Z INFO [wireguard] Using available kernelspace implementation
2024-04-15T01:21:35Z INFO [wireguard] Connecting to 193.138.218.82:51820
2024-04-15T01:21:35Z INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working.
2024-04-15T01:21:51Z INFO [healthcheck] program has been unhealthy for 16s: restarting VPN (see https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md)
2024-04-15T01:21:51Z INFO [vpn] stopping
2024-04-15T01:21:51Z INFO [vpn] starting
2024-04-15T01:21:51Z INFO [firewall] allowing VPN connection...
2024-04-15T01:21:51Z INFO [wireguard] Using available kernelspace implementation
2024-04-15T01:21:51Z INFO [wireguard] Connecting to [2a03:1b20:1:f410:40::a04f]:51820
2024-04-15T01:21:51Z INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working.
2024-04-15T01:21:51Z ERROR [ip getter] Get "https://ipinfo.io/": context deadline exceeded (Client.Timeout exceeded while awaiting headers) - retrying in 10s
Share your configuration
---
version: "3.7"
services:
gluetun:
image: qmcgaw/gluetun:v3.37.0
container_name: gluetun
cap_add:
- NET_ADMIN
network_mode: bridge
ports:
redacted
volumes:
- /docker/gluetun:/gluetun
environment:
- FIREWALL_OUTBOUND_SUBNETS=<redacted>
- VPN_SERVICE_PROVIDER=mullvad
- VPN_TYPE=wireguard
- WIREGUARD_PRIVATE_KEY=<redacted>
- WIREGUARD_ADDRESSES=10.64.222.21/32
- SERVER_COUNTRIES=Sweden
# - SERVER_CITIES=Malmo
# - SERVER_HOSTNAMES=se-mma-wg-001
# - ISP=31173
# - OWNED_ONLY=yes
- DOT=off
- DNS_ADDRESS=<redacted>
restart: always
@qdm12 is more or less the only maintainer of this project and works on it in his free time.
Please:
- do not ask for updates, be patient
- π the issue to show your support instead of commenting
@qdm12 usually checks issues at least once a week, if this is a new urgent bug,
revert to an older tagged container image
Did you find a solution? I'm getting effectively the same error messages.
Did you find a solution? I'm getting effectively the same error messages.
No, just gotta be patient which is okay with me :)
Yeah. Not a problem. But please post here if you find a solution and Iβll do the same.
Had the same issue and was spinning on it for a few hours. Turns out my DNS was down and the device had no internet access. Not sure if you are having the same issue, hope this helps.
I'm also having this issue. It started after Docker Desktop for Mac updated to 4.28. I've tried downgrading Docker to earlier versions and it didn't resolve the issue. I've tried downgrading Gluetun to earlier versions (atleast the last 3 versions) and it didn't work. I tried updating servers and that didn't work. I tried changing servers with my VPN, that didn't work. Everything worked perfectly before Docker updated. So I'm convinced the issue is a DNS issue funneling traffic through a specific Container and isn't caused by Gluetun.
Looks like others are having issues too, see the ticket below filed on the Docker for Mac page
docker/for-mac#7262
My Resolve for Now: I completely removed Gluetun. Turned on my VPN (desktop app version) and am routing all Docker Containers through a Docker created network that is bridged with the Host. Everything works flawlessly like it did before the Docker updates. I'll revert back to Gluetun once all is resolved from the Docker Dev team.
Update: After more trouble shooting, I found that in v4.29-- under features under development -- an option for "Enable Host Networking". I'm not usually a fan of selecting these new features while under testing. BUT, frustrated I gave it a try. And everything suddenly went back to normal. I was able to connect to my VPN. DNS issue fixed and my setup went back to functioning normal again.
Update: After more trouble shooting, I found that in v4.29-- under features under development -- an option for "Enable Host Networking". I'm not usually a fan of selecting these new features while under testing. BUT, frustrated I gave it a try. And everything suddenly went back to normal. I was able to connect to my VPN. DNS issue fixed and my setup went back to functioning normal again.
Try turning that off and testing again. Mine suddenly started working yesterday without any (intentional) changes. I don't know why or how long it will last.
Update: After more trouble shooting, I found that in v4.29-- under features under development -- an option for "Enable Host Networking". I'm not usually a fan of selecting these new features while under testing. BUT, frustrated I gave it a try. And everything suddenly went back to normal. I was able to connect to my VPN. DNS issue fixed and my setup went back to functioning normal again.
Try turning that off and testing again. Mine suddenly started working yesterday without any (intentional) changes. I don't know why or how long it will last.
I did, here is what I found in my tests. So after I got my Container up and running connecting to the Network WITH "Enable Host Networking" turned on, I noted transfer speeds of around 40 MB/sec (normal levels). I turned off the feature and the Container miraculously would connect to VPN again (unlike before), however, transfer speeds would max out to only 1 MB / sec. I re-selected "Enable Host Networking" back and my transfer speeds returned to normal 40 MB - 60 MB / sec.
TLDR; Toggling Enable Host Networking on/off fixed the DNS / VPN connection issue I as having. However, my transfer speeds were severely limited without it turned ON, whereas, before this new feature was released I had no problem with connecting to VPN or transfer speed limitations.
Interesting. I did not toggle and mine is working, and has been for 24 hours (which has not happened in several weeks).
I also did not do any speed comparison tests, but I have not noticed a speed cap, and itβs definitely more than 1 Mb. Are you saying 1Mb or 1MB? I ask because the former is the more common speed unit. I might be under 1 MB in terms of what I have observed.
Interesting. I did not toggle and mine is working, and has been for 24 hours (which has not happened in several weeks).
I also did not do any speed comparison tests, but I have not noticed a speed cap, and itβs definitely more than 1 Mb. Are you saying 1Mb or 1MB? I ask because the former is the more common speed unit. I might be under 1 MB in terms of what I have observed.
Yeah- I was pretty baffled too. MiB / sec
I looked again, and mine was showing 3+ MiB/s ant one point, and I have no reason to think the container was the limiting factor.
Update: After more trouble shooting, I found that in v4.29-- under features under development -- an option for "Enable Host Networking". I'm not usually a fan of selecting these new features while under testing. BUT, frustrated I gave it a try. And everything suddenly went back to normal. I was able to connect to my VPN. DNS issue fixed and my setup went back to functioning normal again.
You mean for Docker for Mac? I am using Portainer which doesnt have this option
Please please please let's not mix issues. The original issue is for Ubuntu+Mullvad being unhealthy. I marked all macos comments as off-topic, please create a separate issue for it if you feel there is a need for it.
@kingofhteseas please check out https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md and if it doesn't resolve it, see #2154
I'm running a Linux Arch host with Mullvad with no problem over here.
Closing this since it's not a gluetun bug.
Closed issues are NOT monitored, so commenting here is likely to be not seen.
If you think this is still unresolved and have more information to bring, please create another issue.
This is an automated comment setup because @qdm12 is the sole maintainer of this project
which became too popular to monitor issues closed.
For what it's worth, my comments had nothing to do with MacOS. I was able to set the environment variable DOT=off
and it seems to have resolved my immediate issue. I'm sure this is not ideal and probably has side effects.