Bug: Wireguard Settings: interface address is not set

[rslalo]

Is this urgent?

No

Host OS

Synology DSM

CPU arch

x86_64

VPN service provider

NordVPN

What are you using to run the container

docker-compose

What is the version of Gluetun

Running version latest built on 2024-03-29T15:09:35.600Z (commit e859c60)

What's the problem 🤔

Getting the following error on startup after updating to the latest version:

ERROR VPN settings: Wireguard Settings: interface address is not set

Seems related to recent commits/issues. Unlike #2193 I'm not using a custom config, but this still seems related to Interface.Address.

Thank you!

Share your logs (at least 10 lines)

Running version latest built on 2024-03-29T15:09:35.600Z (commit e859c60)

2024-03-29T18:02:02-04:00 WARN You are using the old environment variable HTTPPROXY_LOG, please consider changing it to 
2024-03-29T18:02:02-04:00 INFO [routing] default route found: interface eth0, gateway 172.20.0.1, assigned IP 172.20.0.2 and family v4
2024-03-29T18:02:02-04:00 INFO [routing] local ethernet link found: eth0
2024-03-29T18:02:02-04:00 INFO [routing] local ipnet found: 172.20.0.0/16
2024-03-29T18:02:02-04:00 INFO [firewall] enabling...
2024-03-29T18:02:02-04:00 INFO [firewall] enabled successfully
2024-03-29T18:02:03-04:00 INFO [storage] merging by most recent 19476 hardcoded servers and 19472 servers read from /gluetun/servers.json
2024-03-29T18:02:03-04:00 INFO [storage] Using nordvpn servers from file which are 3 days more recent
2024-03-29T18:02:04-04:00 ERROR VPN settings: Wireguard settings: interface address is not set
2024-03-29T18:02:04-04:00 INFO Shutdown successful

Share your configuration

services:
  gluetun:
    image: qmcgaw/gluetun:latest
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    ports:
      - 8888:8888/tcp # HTTP proxy
      - 8388:8388/tcp # Shadowsocks
      - 8388:8388/udp # Shadowsocks
      - 8000:8000/tcp # control server
    volumes:
      - /volume1/docker/gluetun:/gluetun
    environment:
      - PUID=<uid>
      - PGID=<gid>
      - TZ=America/New_York
      - VPN_SERVICE_PROVIDER=nordvpn
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=<redacted>
      - SERVER_CITIES=New York
      - HEALTH_VPN_DURATION_INITIAL=30s
      - FIREWALL_OUTBOUND_SUBNETS=172.20.0.0/16,192.168.1.0/24
      - UPDATER_PERIOD=24h
      - HTTPPROXY=on
      - SHADOWSOCKS=on
      - FIREWALL_VPN_INPUT_PORTS=58181
    network_mode: dockerbridge
    security_opt:
      - no-new-privileges:true
    restart: unless-stopped

[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

[rslalo]

Just confirming that reverting to v3.38 fixes the issue, gluetun starts and reports healthy with the same config.

[nmbgeek]

Seeing the same thing on Ubuntu 22.04

[lemba23]

Same here on Debian 12.
Reverting to v3.38.0 solves the problem.

[qdm12]

How are you loading the Wireguard address? From files/secret files/environment variables?

I tried with WIREGUARD_ADDRESSES and a file at /gluetun/wireguard/wg0.conf and it seems to work fine 🤔 But there is definitely a problem introduced after v3.38.0, most likely with (fat) commit ecc80a5 but I cannot reproduce it really which is weird 🤔 🤔 ❓

[rslalo]

I'm not explicitly setting WIREGUARD_ADDRESSES at all. The only config I have is the docker compose posted above.

My mapped /gluetun directory just contains servers.json.

Here are the values of some possibly relevant env variables in the working v3.38 container:

VPN_SERVICE_PROVIDER                 nordvpn
VPN_TYPE                             wireguard
WIREGUARD_ADDRESSES 
WIREGUARD_ADDRESSES_SECRETFILE       /run/secrets/wireguard_addresses
WIREGUARD_CONF_SECRETFILE            /run/secrets/wg0.conf

[qdm12]

Thank you all, it's fixed, please see comment #2197 (comment)

[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.