Bug: Cannot get version info and IP Getter

kingofhteseas commented 7 months ago

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

github-actions[bot] commented 7 months ago

@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
:+1: 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

dathbe commented 7 months ago

Did you find a solution? I'm getting effectively the same error messages.

kingofhteseas commented 6 months ago

Did you find a solution? I'm getting effectively the same error messages.

No, just gotta be patient which is okay with me :)

dathbe commented 6 months ago

Yeah. Not a problem. But please post here if you find a solution and I’ll do the same.

mattchan8 commented 6 months ago

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.

stealthvette commented 6 months ago

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 https://github.com/docker/for-mac/issues/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.

stealthvette commented 6 months ago

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.

dathbe commented 6 months ago

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.

stealthvette commented 6 months ago

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.

dathbe commented 6 months ago

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.

stealthvette commented 6 months ago

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

dathbe commented 6 months ago

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.

kingofhteseas commented 6 months ago

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

qdm12 commented 6 months ago

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.

github-actions[bot] commented 6 months ago

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.

dathbe commented 6 months ago

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.

qdm12 / gluetun