Bug: VPN No longer connects

[qw3r7yju4]

Is this urgent?

Yes

Host OS

Unraid 6.12.8

CPU arch

x86_64

VPN service provider

ExpressVPN

What are you using to run the container

Unraid

What is the version of Gluetun

docker latest and v3.35.0

What's the problem 🤔

VPN no longer connects.

Share your logs (at least 10 lines)

2024-07-19T13:38:20-04:00 INFO [openvpn] OpenVPN 2.5.10 x86_64-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jul  2 2024
2024-07-19T13:38:20-04:00 INFO [openvpn] library versions: OpenSSL 3.1.6 4 Jun 2024, LZO 2.10
2024-07-19T13:38:20-04:00 INFO [openvpn] TCP/UDP: Preserving recently used remote address: [AF_INET]45.80.157.170:1195
2024-07-19T13:38:20-04:00 INFO [openvpn] UDP link local: (not bound)
2024-07-19T13:38:20-04:00 INFO [openvpn] UDP link remote: [AF_INET]45.80.157.170:1195
2024-07-19T13:39:16-04:00 INFO [healthcheck] program has been unhealthy for 56s: restarting VPN
2024-07-19T13:39:16-04:00 INFO [healthcheck] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md
2024-07-19T13:39:16-04:00 INFO [healthcheck] DO NOT OPEN AN ISSUE UNLESS YOU READ AND TRIED EACH POSSIBLE SOLUTION
2024-07-19T13:39:16-04:00 INFO [vpn] stopping
2024-07-19T13:39:16-04:00 INFO [vpn] starting
2024-07-19T13:39:16-04:00 INFO [firewall] allowing VPN connection...
2024-07-19T13:39:16-04:00 INFO [openvpn] OpenVPN 2.5.10 x86_64-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jul  2 2024

Share your configuration

docker run
  -d
  --name='gluetunvpn'
  --net='bridge'
  -e TZ="America/New_York"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="Mediaserver"
  -e HOST_CONTAINERNAME="gluetunvpn"
  -e 'TZ'='America/New_York'
  -e 'VPN_SERVICE_PROVIDER'='expressvpn'
  -e 'VPN_TYPE'='openvpn'
  -e 'VPN_INTERFACE'='tun0'
  -e 'VPN_ENDPOINT_PORT'=''
  -e 'VPN_ENDPOINT_IP'=''
  -e 'OPENVPN_PROTOCOL'='udp'
  -e 'OPENVPN_USER'='username'
  -e 'OPENVPN_PASSWORD'='password'
  -e 'OPENVPN_VERSION'='2.5'
  -e 'OPENVPN_VERBOSITY'='1'
  -e 'OPENVPN_FLAGS'=''
  -e 'OPENVPN_CIPHERS'=''
  -e 'OPENVPN_AUTH'=''
  -e 'OPENVPN_PROCESS_USER'='no'
  -e 'OPENVPN_IPV6'='off'
  -e 'OPENVPN_CUSTOM_CONFIG'=''
  -e 'WIREGUARD_IMPLEMENTATION'='auto'
  -e 'WIREGUARD_PRIVATE_KEY'=''
  -e 'WIREGUARD_PRESHARED_KEY'=''
  -e 'WIREGUARD_PUBLIC_KEY'=''
  -e 'WIREGUARD_ADDRESSES'=''
  -e 'SERVER_REGIONS'=''
  -e 'SERVER_COUNTRIES'='USA'
  -e 'SERVER_CITIES'='Atlanta'
  -e 'SERVER_NAMES'=''
  -e 'SERVER_HOSTNAMES'=''
  -e 'FIREWALL'='on'
  -e 'FIREWALL_VPN_INPUT_PORTS'=''
  -e 'FIREWALL_INPUT_PORTS'=''
  -e 'FIREWALL_OUTBOUND_SUBNETS'='my subnet'
  -e 'FIREWALL_DEBUG'='off'
  -e 'LOG_LEVEL'='info'
  -e 'DOT'='on'
  -e 'DOT_PROVIDERS'='cloudflare'
  -e 'DOT_PRIVATE_ADDRESS'='127.0.0.1/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,169.254.0.0/16,::1/128,fc00::/7,fe80::/10,::ffff:7f00:1/104,::ffff:a00:0/104,::ffff:a9fe:0/112,::ffff:ac10:0/108,::ffff:c0a8:0/112'
  -e 'DOT_VERBOSITY'='1'
  -e 'DOT_VERBOSITY_DETAILS'='0'
  -e 'DOT_VALIDATION_LOGLEVEL'='0'
  -e 'DOT_CACHING'='on'
  -e 'DOT_IPV6'='off'
  -e 'BLOCK_MALICIOUS'='on'
  -e 'BLOCK_SURVEILLANCE'='off'
  -e 'BLOCK_ADS'='off'
  -e 'UNBLOCK'=''
  -e 'DNS_UPDATE_PERIOD'='24h'
  -e 'DNS_ADDRESS'=''
  -e 'DNS_KEEP_NAMESERVER'='on'
  -e 'HTTPPROXY'='off'
  -e 'HTTPPROXY_LOG'='off'
  -e 'HTTPPROXY_USER'=''
  -e 'HTTPPROXY_PASSWORD'=''
  -e 'HTTPPROXY_STEALTH'='off'
  -e 'SHADOWSOCKS'='off'
  -e 'SHADOWSOCKS_LOG'='off'
  -e ':8388'=':38388'
  -e 'SHADOWSOCKS_PASSWORD'=''
  -e 'SHADOWSOCKS_CIPHER'='chacha20-ietf-poly1305'
  -e 'HEALTH_SERVER_ADDRESS'='127.0.0.1:9999'
  -e 'HEALTH_TARGET_ADDRESS'='github.com:443'
  -e 'HEALTH_VPN_DURATION_INITIAL'='6s'
  -e 'HEALTH_VPN_DURATION_ADDITION'='5s'
  -e 'UPDATER_PERIOD'='0'
  -e 'PUBLICIP_FILE'='/gluetun/ip'
  -e 'PUBLICIP_PERIOD'='12h'
  -e 'VERSION_INFORMATION'='on'
  -e 'HTTP_CONTROL_SERVER_LOG'='on'
  -e 'PUID'='1000'
  -e 'PGID'='1000'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='http://[IP]:[PORT:8000]'
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/qdm12/gluetun/master/doc/logo_256.png'
  -p '38888:8888/tcp'
  -p '8113:8080/tcp'
  -p '8000:8000/tcp'
  -v '/mnt/user/appdata/gluetun':'/gluetun':'rw'
  --cap-add=NET_ADMIN
  --restart always 'qmcgaw/gluetun:latest'
bfb60f730b49dbb22cce8d8d0e0c7adccf9b24de77c907964278c64f170980bf

[github-actions]

@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

[ehauk]

I am having this same issue as of about 6 days ago. If I set the firewall setting to 'off' then it connects, but it says only to do this for debugging purposes.

Container Variable: FIREWALL
Turn on or off the container built-in firewall. You should turn off for debugging purposes only.

[qw3r7yju4]

I am having this same issue as of about 6 days ago. If I set the firewall setting to 'off' then it connects, but it says only to do this for debugging purposes.

Container Variable: FIREWALL Turn on or off the container built-in firewall. You should turn off for debugging purposes only.

I can confirm turning firewall off and VPN connects and I am still able to access my passed thru containers and they function as advertised

[qw3r7yju4]

But I can also confirm turning off the firewall turns off the kill switch for tunnel. I was downloading on my public IP. Hopefully it wasnt for long...

[Papierkorb]

I'm facing the same issue with a different VPN provider where I use WireGuard instead of OpenVPN like you. Running exec ash and then doing nslookup www.internic.net it looks like it can't access 1.1.1.1 (Cloudflares DNS), and then just locks up retrying forever.

From the logs:

gluetun-1      | 2024-07-21T12:59:18Z 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.
gluetun-1      | 2024-07-21T12:59:21Z INFO [dns] downloading DNS over TLS cryptographic files
gluetun-1      | 2024-07-21T12:59:33Z ERROR [vpn] getting public IP address information: fetching information: Get "https://ipinfo.io/": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
gluetun-1      | 2024-07-21T12:59:36Z WARN [dns] cannot update files: Get "https://www.internic.net/domain/named.root": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
gluetun-1      | 2024-07-21T12:59:36Z INFO [dns] attempting restart in 20s
gluetun-1      | 2024-07-21T12:59:38Z INFO [healthcheck] program has been unhealthy for 16s: restarting VPN

I encountered this error with a previously well running image. Doing a docker compose pull and retrying had no effect, the logs are the same.

[goldelehr]

I am also encountering this issue suddenly. I am running three gluetun containers on a Docker host, and two of the three are experiencing these issues, while the third one is still working (all running the same image, v3.38.0).

[massijay]

I have the same problem (I'm using PIA), I also found this inside the log
ERROR [vpn] getting public IP address information: fetching information: too many requests sent for this month from https://ipinfo.io/: 403 403 Forbidden
I don't think that's the cause but a consequence of this bug. Instead of using ipinfo to get the IP address I suggest to get it from this url:
https://1.1.1.1/cdn-cgi/trace

[qw3r7yju4]

Updated server list and my VPN works again.

[massijay]

Unfortunately, in my case, refreshing the server list didn't solve the problem and neither the other steps described in the wiki

[massijay]

Ok I got it working, I had the env variable SERVER_REGIONS: Netherlands in my docker compose, I removed it and now the problem is gone

[Hasnaat-k]

Having same issue, none of the fixes here are working
Issue seems to be with wireguard. OpenVPN protocol works.

[abu-marwa]

I'm running proton vpn with wireguard protocol and port forwarding enabled and got the following error:
2024-07-25T14:14:09Z ERROR [vpn] getting public IP address information: fetching information: Get "https://ipinfo.io/": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

[qdm12]

This is a very generic issue, so closing it.

@ehauk Where did you even find Turn on or off the container built-in firewall. You should turn off for debugging purposes only.. FIREWALL is undocumented for a reason, so that you don't shoot yourself in the foot. Anyway, since this is not the first time I see this misused, I renamed the variable to be FIREWALL_ENABLED_DISABLING_IT_SHOOTS_YOU_IN_YOUR_FOOT so it's clear... you should not disable it.

@massijay

I don't think that's the cause but a consequence of this bug. Instead of using ipinfo to get the IP address I suggest to get it from this url:
https://1.1.1.1/cdn-cgi/trace

You have the alternative to use PUBLICIP_API=ip2location. https://1.1.1.1/cdn-cgi/trace does not return useful information on the location. Also this is a non-critical error, it's just the public ip information cannot be fetched because ipinfo blocked you.

Ok I got it working, I had the env variable SERVER_REGIONS: Netherlands in my docker compose, I removed it and now the problem is gone

Number 2 of the healthcheck page states: The VPN server crashed 💥, try changing your VPN servers filtering options such as SERVER_REGIONS......

@Papierkorb The log states 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.. This is exactly what you see, the connection doesn't work. Not a Gluetun problem, but a config one (i.e. credentials) or a VPN server one. Try changing server etc.

[github-actions]

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.

[ehauk]

Just for the record, I wasn't saying to run it with the firewall turned off. I was only stating that for troubleshooting information that may lead to a solution. The container was working, it updated and then it didn't.

[brunnels]

This is a very generic issue, so closing it.

@ehauk Where did you even find Turn on or off the container built-in firewall. You should turn off for debugging purposes only.. FIREWALL is undocumented for a reason, so that you don't shoot yourself in the foot. Anyway, since this is not the first time I see this misused, I renamed the variable to be FIREWALL_ENABLED_DISABLING_IT_SHOOTS_YOU_IN_YOUR_FOOT so it's clear... you should not disable it.

@massijay

I don't think that's the cause but a consequence of this bug. Instead of using ipinfo to get the IP address I suggest to get it from this url:
https://1.1.1.1/cdn-cgi/trace

You have the alternative to use PUBLICIP_API=ip2location. https://1.1.1.1/cdn-cgi/trace does not return useful information on the location. Also this is a non-critical error, it's just the public ip information cannot be fetched because ipinfo blocked you.

Ok I got it working, I had the env variable SERVER_REGIONS: Netherlands in my docker compose, I removed it and now the problem is gone

Number 2 of the healthcheck page states: The VPN server crashed 💥, try changing your VPN servers filtering options such as SERVER_REGIONS......

@Papierkorb The log states 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.. This is exactly what you see, the connection doesn't work. Not a Gluetun problem, but a config one (i.e. credentials) or a VPN server one. Try changing server etc.

@qdm12 when using gluetun in kubernetes as part of a pod vpn-gateway using cilium vxlan it is necessary to disable the firewall.
Kubernetes has it's own network policies. Even though this configuration was undocumented, changing it was still a breaking change for many people and not an easy one to debug when gluetun is a single piece of a bigger component and suddenly stops working.