Bug: MTU auto-discovery finds MTU too high causing DNS timeouts

[jtechbyte]

Is this urgent?

None

Host OS

Ubuntu 24.04.3 LTS

CPU arch

x86_64

VPN service provider

NordVPN

What are you using to run the container

docker-compose

What is the version of Gluetun

latest

What's the problem 🤔

When running Gluetun with WireGuard in userspace, the MTU auto-discovery feature always sets tun0 to 1440, ignoring the WIREGUARD_MTU environment variable. This causes DNS timeouts and breaks any container using network_mode: service:gluetun. Even setting WIREGUARD_MTU has no effect.

A manual workaround is to reset the MTU after startup:

docker exec -it gluetun sh -c "ip link set tun0 mtu 1360"

This fixes DNS and restores network functionality.

fully automatic workaround is to run Gluetun in userspace mode with a small command wrapper that sets the MTU after tun0 comes up. For example:

environment:

• WIREGUARD_IMPLEMENTATION=userspace
  volumes:
• ./wireguard:/gluetun/wireguard
  entrypoint: /gluetun-entrypoint
  command: []

This ensures tun0 always uses MTU 1360, fixing DNS and network functionality for containers using network_mode: service:gluetun, and persists across restarts without manual commands.

Share your logs (at least 10 lines)

2026-01-23T17:03:07Z INFO [routing] default route found: interface eth0, gateway 172.21.0.1, assigned IP 172.21.0.2 and family v4
2026-01-23T17:03:07Z INFO [dns] using plaintext DNS at address 1.1.1.1
2026-01-23T17:03:07Z INFO [healthcheck] listening on 127.0.0.1:9999
2026-01-23T17:03:07Z INFO [firewall] allowing VPN connection...
2026-01-23T17:03:07Z INFO [wireguard] Using available kernelspace implementation
2026-01-23T17:03:07Z INFO [wireguard] Connecting to 185.172.52.134:51820
2026-01-23T17:03:07Z INFO [wireguard] Wireguard setup is complete
2026-01-23T17:03:29Z ERROR [vpn] getting public IP address information: fetching information: all fetchers failed: ipinfo: Get "https://ipinfo.io/": dial tcp: lookup ipinfo.io on 127.0.0.1:53: i/o timeout
2026-01-23T17:03:29Z ERROR [vpn] ifconfig.co: Get "https://ifconfig.co/json": dial tcp: lookup ifconfig.co on 127.0.0.1:53: i/o timeout
2026-01-23T17:03:29Z ERROR [vpn] ip2location: Get "https://api.ip2location.io/": dial tcp: lookup api.ip2location.io on 127.0.0.1:53: i/o timeout

Share your configuration

---

services:
  gluetun:
    image: qmcgaw/gluetun:latest
    container_name: gluetun
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    ports:
      - "9000:9000" # comet
    environment:
      - VPN_SERVICE_PROVIDER=custom
      - VPN_TYPE=wireguard
      - WIREGUARD_CONF_FILE=wg0.conf
      - FIREWALL=off
      - WIREGUARD_IMPLEMENTATION=userspace
    volumes:
      - ./wireguard:/gluetun/wireguard
    entrypoint: /bin/sh
    command: -c "/gluetun-entrypoint & while ! ip link show tun0 >/dev/null 2>&1; do sleep 1; done; ip link set tun0 mtu 1360; wait"

  postgres:
    image: postgres:17.7
    container_name: comet_postgres
    restart: unless-stopped
    environment:
      POSTGRES_USER: postgres_user
      POSTGRES_PASSWORD: <REDACTED>
      POSTGRES_DB: cometdb
    volumes:
      - comet_postgres_data:/var/lib/postgresql/data

  comet:
    container_name: comet
    image: ghcr.io/g0ldyy/comet:latest
    network_mode: service:gluetun
    restart: unless-stopped
    depends_on:
      - gluetun
      - postgres
    env_file:
      - .env
    volumes:
      - ./data/comet:/app/data
    healthcheck:
      test: wget -qO- http://127.0.0.1:9000/health
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s

volumes:
  comet_postgres_data:

[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

[jtechbyte]

EDIT by qdm12: I recommend just using v3.41 for a few days until PMTUD is fixed.

A fully automatic solution can be applied by using userspace WireGuard with a command wrapper that sets the MTU after the interface is up. Example docker-compose.yml snippet:

gluetun:
environment:
- WIREGUARD_IMPLEMENTATION=userspace
volumes:
- ./wireguard:/gluetun/wireguard
entrypoint: /bin/sh
command: -c "/gluetun-entrypoint & while ! ip link show tun0 >/dev/null 2>&1; do sleep 1; done; ip link set tun0 mtu 1360; wait"

This ensures tun0 always comes up with MTU 1360.

DNS and networking for containers using network_mode: service:gluetun work automatically.

The fix persists across container restarts — no manual commands needed.

[qdm12]

For future readers: just revert to image tag v3.41 for the coming few days until PMTUD is fixed, if this causes you issues.

On it, there is definitely an issue with PMTUD (#2586 recently merged). Can you please share your full logs running with LOG_LEVEL=debug? On my side it does work with

gluetun  | 2026-01-24T21:23:37Z INFO [MTU discovery] finding maximum MTU, this can take up to 4 seconds
gluetun  | 2026-01-24T21:23:37Z DEBUG [MTU discovery] VPN interface tun0 MTU temporarily set to 1440
gluetun  | 2026-01-24T21:23:37Z DEBUG [MTU discovery] finding IPv4 next hop MTU
gluetun  | 2026-01-24T21:23:37Z INFO [MTU discovery] setting VPN interface tun0 MTU to maximum valid MTU 1380

PS: I edited your issue Gluetun version to latest since v3.41 does not have MTU auto-discovery.

[jtechbyte]

For future readers: just revert to image tag v3.41 for the coming few days until PMTUD is fixed, if this causes you issues.

On it, there is definitely an issue with PMTUD (#2586 recently merged). Can you please share your full logs running with LOG_LEVEL=debug? On my side it does work with

gluetun  | 2026-01-24T21:23:37Z INFO [MTU discovery] finding maximum MTU, this can take up to 4 seconds
gluetun  | 2026-01-24T21:23:37Z DEBUG [MTU discovery] VPN interface tun0 MTU temporarily set to 1440
gluetun  | 2026-01-24T21:23:37Z DEBUG [MTU discovery] finding IPv4 next hop MTU
gluetun  | 2026-01-24T21:23:37Z INFO [MTU discovery] setting VPN interface tun0 MTU to maximum valid MTU 1380

PS: I edited your issue Gluetun version to latest since v3.41 does not have MTU auto-discovery.

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

[jtechbyte]

Here’s my debug log from running Gluetun with LOG_LEVEL=debug. You’ll see the Wireguard connection, MTU auto-discovery, and firewall setup:

2026-01-24T22:37:22Z INFO [routing] default route found: interface eth0, gateway 172.22.0.1, assigned IP 172.22.0.3
2026-01-24T22:37:22Z DEBUG [firewall] /usr/sbin/iptables --policy INPUT DROP
2026-01-24T22:37:22Z DEBUG [firewall] /usr/sbin/iptables --append OUTPUT -o tun0 -j ACCEPT
2026-01-24T22:37:22Z DEBUG [wireguard] Connecting to 152.89.206.15:51820
2026-01-24T22:37:22Z INFO [MTU discovery] finding maximum MTU, this can take up to 4 seconds
2026-01-24T22:37:22Z DEBUG [MTU discovery] VPN interface tun0 MTU temporarily set to 1440
2026-01-24T22:37:22Z DEBUG [MTU discovery] finding IPv4 next hop MTU
2026-01-24T22:37:22Z INFO [MTU discovery] setting VPN interface tun0 MTU to maximum valid MTU 1440
2026-01-24T22:37:24Z INFO [ip getter] Public IP address is 155.133.4.187
2026-01-24T22:37:24Z INFO [vpn] You are running 3 commits behind the most recent latest

[qdm12]

Got it, try image tag :pr-3109 with LOG_LEVEL=debug.

Associated PR is #3109

I expect it to work correctly since I've added more MTU-test and fallback code, but I'm curious about the new debug logs to see a bit more what was wrong anyway.

[jtechbyte]

Tested with image:pr-3109, LOG_LEVEL=debug, and WIREGUARD_IMPLEMENTATION=userspace.

Relevant MTU debug output:

INFO [MTU discovery] finding maximum MTU
DEBUG [MTU discovery] VPN interface tun0 MTU temporarily set to 1440
DEBUG [MTU discovery] finding IPv4 next hop MTU
DEBUG [MTU discovery] received echo message with packet length 1420
INFO [MTU discovery] setting VPN interface tun0 MTU to maximum valid MTU 1440

PMTUD does run, but it consistently converges to 1440.

In my setup, when PMTUD sets tun0 to 1440, DNS requests start timing out and any container using network_mode: service:gluetun loses connectivity.

Manually forcing tun0 to 1360 immediately restores DNS and network access, which is why I suspect PMTUD is overestimating the usable MTU in this case (userspace WireGuard).