Bug: "interface address is not set"

vdrover commented 3 months ago

Is this urgent?

No

Host OS

Ubuntu

CPU arch

x86_64

VPN service provider

NordVPN

What are you using to run the container

docker-compose

What is the version of Gluetun

3.38.0

What's the problem 🤔

When I use v3.38.0 (aka 'latest'), I get the error below. Reverting to v3.37.0 resolves the issue and the wireguard connection works as expected. Docker compose below.

Thoughts?

Share your logs (at least 10 lines)

Running version latest built on 2024-03-29T15:09:35.600Z (commit e859c60)
2024-03-29T17:28:47-05:00 WARN You are using the old environment variable HTTPPROXY_LOG, please consider changing it to 
2024-03-29T17:28:47-05:00 INFO [routing] default route found: interface eth0, gateway xxx.yyy.zzz.1, assigned IP 192.168.91.58 and family v4
2024-03-29T17:28:47-05:00 INFO [routing] local ethernet link found: eth0
2024-03-29T17:28:47-05:00 INFO [routing] local ipnet found: xxx.yyy.zzz.0/24
2024-03-29T17:28:47-05:00 INFO [firewall] enabling...
2024-03-29T17:28:48-05:00 INFO [firewall] enabled successfully
2024-03-29T17:28:48-05:00 INFO [storage] merging by most recent 19476 hardcoded servers and 19476 servers read from /gluetun/servers.json
2024-03-29T17:28:48-05:00 ERROR VPN settings: Wireguard settings: interface address is not set
2024-03-29T17:28:48-05:00 INFO Shutdown successful

Share your configuration

gluetun:
    image: qmcgaw/gluetun
    # image: qmcgaw/gluetun:v3.37.0
    container_name: gluetun
    hostname: gluetun
    restart: unless-stopped
    networks:
      npm_proxy:
        ipv4_address: xxx.yyy.zzz.21
    cap_add:
      - NET_ADMIN
    ports:
      - "34400:34400" # Threadfin
      - "8008:80" # Spedtest Tracker
      - "8443:443"  # Spedtest Tracker
      - "58085:58085" # qBittorrent
      - "40961:40961" # qBittorrent
      - "40961:40961/udp" # qBittorrent
    devices:
      - /dev/net/tun
    volumes:
      - $DOCKERDIR/appdata/gluetun:/gluetun
    environment:
      - TZ=$TZ
      - VPN_SERVICE_PROVIDER=nordvpn
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=
      - SERVER_COUNTRIES=

github-actions[bot] commented 3 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

nicandris commented 3 months ago

had the same issue and reverted to v3. looks like the issue is on the latest tag (v3.38.0 is ok), probably this commit created the issue?

erikskean commented 3 months ago

same here with latest tag. reverted with v3 and all is well.

alexkahler commented 3 months ago

I'm also on the "latest" tag and I have the same issue.

vdrover commented 3 months ago

Does the image actually support latest? I use image: qmcgaw/gluetun without any release info.

alexkahler commented 3 months ago

Replacing "latest" tag with "v.3.38" fixed it for me.

alexkahler commented 3 months ago

Does the image actually support latest? I use image: qmcgaw/gluetun without any release info.

If you dont specify a tag, then it implicitly gets the latest

Roucou commented 3 months ago

Replacing "latest" tag with "v.3.38" fixed it for me.

Thanks, that works indeed! But the tag is qmcgaw/gluetun:v3.38, i.e. without the first dot.

qdm12 commented 2 months ago

Hello everyone

The problem

How are you setting your Wireguard addresses? I just tried using the environment variable WIREGUARD_ADDRESSES=10.66.79.36/32 and it seems to work fine for me 🤔 I will have a look it might related to files/secret files loading.

Docker tags

For image tagging in general (even outside Gluetun), image:latest is the same as image without a tag.

For Gluetun, :latest points to the master branch (so latest change), not the latest release (which should be more stable, which is v3.38.0 as of today). See https://github.com/qdm12/gluetun-wiki/blob/main/setup/docker-image-tags.md

nicandris commented 2 months ago

hm tbh i wasn't setting it before... I used WIREGUARD_ADDRESSES=10.5.0.2/32 and now it works 👍

vdrover commented 2 months ago

@qdm12 Do all providers publish their wireguard IP range? I use NordVPN and didn't see this variable in the wiki.

nicandris commented 2 months ago

@qdm12 Do all providers publish their wireguard IP range? I use NordVPN and didn't see this variable in the wiki.

im also using nordvpn. what i did was start v3.38.0 check the boot logs for the range in there and just use it with latest

vdrover commented 2 months ago

im also using nordvpn. what i did was start v3.38.0 check the boot logs for the range in there and just use it with latest

Won't this change if I am using a series of of countries in my environment variables?

Roucou commented 2 months ago

Also using nordvpn, and never had to set WIREGUARD_ADDRESSES. If this is now required, what should it be set to? I.e. where could we find this info?

qdm12 commented 2 months ago

TLDR: Fixed in 982100782c9c8b1024f0dfb15a2c6ab3b11eb4f0 + thanks @nicandris

Found it, and it seems like @nicandris found all the relevant bits as well, congrats!

The problem was introduced in https://github.com/qdm12/gluetun/commit/e859c603430628c7cfbf84d29bcc66878a0632be as stated in https://github.com/qdm12/gluetun/issues/2197#issuecomment-2028004696
https://github.com/qdm12/gluetun/issues/2197#issuecomment-2029926072 was a good workaround 👍

Now the reason behind this is... NordVPN uses the same Wireguard address 10.5.0.2/32 for all users and servers. Gluetun was, for NordVPN only, defaulting the "list of addresses" to [10.5.0.2/32] if it was not set (aka "null" or "nil"). That was working fine until that problematic commit, which initializes the list of addresses to an empty list [] even if no user setting is set for it. That caused the default to no longer trigger, and thus it would error out stating no interface address was set. It was a very nifty detail, and I'm not even blaming myself for not catching it earlier, that's how nifty this detail was 😄!

Anyway, thank you all for your patience and participation!

github-actions[bot] commented 2 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.

qdm12 / gluetun