Bug: DNS seems broken because of using wrong interface in container

[HasseJohansen]

Is this urgent?

No

Host OS

Ubuntu 24.04.4 LTS

CPU arch

x86_64

VPN service provider

ProtonVPN

What are you using to run the container

docker-compose

What is the version of Gluetun

Running version latest built on 2026-09-01T23:04:47.130Z (commit 0fef7b2) on Linux 6.8.0-138-generic (x86_64)

What's the problem 🤔

It seems dns fails in default config with dot+Cloudflare for me using protonvpn

From what I understand trying to debug it, it is because when doing dns lookups in the container the wrong network interface/ip is used as source and then it is denied

It should use the tun interface/ip as source

The only way I get a working DNS config is setting:
DNS_UPSTREAM_RESOLVER_TYPE=plain
DNS_UPSTREAM_PLAIN_ADDRESSES=1.1.1.1:53,8.8.8.8:53 and include the DNS ip in FIREWALL_OUTBOUND_SUBNETS

But that way I would do DNS through my host and leak all dns

So I think some changes are needed to use the tun interface ip instead of the container ip

It should be visible in the logs where you see that xxx as sour does af dns lookup and is denied

Share your logs (at least 10 lines)

2026-09-03T17:52:59+02:00 INFO [routing] default route found: interface eth0, gateway 172.18.0.1, assigned IP 172.18.0.2 and family v4
2026-09-03T17:52:59+02:00 INFO [routing] adding route for 0.0.0.0/0
2026-09-03T17:52:59+02:00 INFO [firewall] setting allowed subnets...
2026-09-03T17:52:59+02:00 INFO [routing] default route found: interface eth0, gateway 172.18.0.1, assigned IP 172.18.0.2 and family v4
2026-09-03T17:52:59+02:00 INFO [routing] adding route for 192.168.0.0/24
2026-09-03T17:52:59+02:00 INFO [healthcheck] listening on 127.0.0.1:9999
2026-09-03T17:52:59+02:00 INFO [http server] read 1 roles from authentication file
2026-09-03T17:52:59+02:00 INFO [http server] http server listening on [::]:8000
2026-09-03T17:52:59+02:00 INFO [firewall] allowing VPN connection...
2026-09-03T17:52:59+02:00 INFO [wireguard] Using available kernelspace implementation
2026-09-03T17:52:59+02:00 INFO [wireguard] Connecting to 169.150.208.246:51820
2026-09-03T17:52:59+02:00 INFO [vpn] 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.
2026-09-03T17:52:59+02:00 INFO [MTU discovery] finding maximum MTU, this can take up to 6 seconds
2026-09-03T17:53:05+02:00 INFO [MTU discovery] reverting VPN interface tun0 MTU to 1320 (due to: PMTUD failed with both ICMP and TCP)
2026-09-03T17:53:05+02:00 INFO [dns] DNS server listening on [::]:53
2026-09-03T17:53:05+02:00 INFO [dns] ready and using DNS server with dot upstream resolvers
2026-09-03T17:53:05+02:00 INFO [dns] downloading hostnames and IP block lists
2026-09-03T17:53:24+02:00 WARN [dns] getting tls connection for request IN AAAA raw.githubusercontent.com.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:57758->1.1.1.1:853: read: connection reset by peer
2026-09-03T17:53:24+02:00 WARN [dns] getting tls connection for request IN A raw.githubusercontent.com.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:57742->1.1.1.1:853: read: connection reset by peer
2026-09-03T17:53:25+02:00 WARN [dns] downloading block lists failed, skipping: Get "https://raw.githubusercontent.com/qdm12/files/master/malicious-hostnames.updated": dial tcp: lookup raw.githubusercontent.com on 127.0.0.1:53: read udp 127.0.0.1:34036->127.0.0.1:53: i/o timeout, Get "https://raw.githubusercontent.com/qdm12/files/master/malicious-ips.updated": dial tcp: lookup raw.githubusercontent.com on 127.0.0.1:53: read udp 127.0.0.1:34036->127.0.0.1:53: i/o timeout
2026-09-03T17:53:29+02:00 WARN [dns] getting tls connection for request IN AAAA raw.githubusercontent.com.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:57780->1.1.1.1:853: read: connection reset by peer
2026-09-03T17:53:29+02:00 WARN [dns] getting tls connection for request IN A raw.githubusercontent.com.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:57770->1.1.1.1:853: read: connection reset by peer

Share your configuration

services:                                           gluetun:
  container_name: gluetun
  image: qmcgaw/gluetun
  cap_add:
    - NET_ADMIN
  environment:
    - VPN_SERVICE_PROVIDER=protonvpn
    - VPN_TYPE=wireguard
    - WIREGUARD_PRIVATE_KEY=<redacted>
    - PORT_FORWARD_ONLY=on
    - VPN_PORT_FORWARDING=on
    - TZ=Europe/Copenhagen
    - UPDATER_PERIOD=24h
    - FIREWALL_OUTBOUND_SUBNETS=<my local lan>
    - UPDATER_PERIOD=24h
    - SERVER_COUNTRIES=Sweden
    - UPDATER_PROTONVPN_USERNAME=<redacted>
    - UPDATER_PROTONVPN_PASSWORD=<redacted>
  devices:
    - /dev/net/tun:/dev/net/tun
  volumes:
    - type: bind
      source: ./gluetun-config/config.toml
      target: /gluetun/auth/config.toml
  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

[qdm12]

Try clearing FIREWALL_OUTBOUND_SUBNETS there might be a conflict in ip ranges in there.

also reverting VPN interface tun0 MTU to 1320 (due to: PMTUD failed with both ICMP and TCP) might be because the connection doesn't work at all. Have you tried other servers ?

[aahmyu]

I just had the same issue, dns is not resolving inside the container. After a couple of hours of debugging, I tried generating a new proton wireguard key, and somehow this has solved the issue for me.

[somehuman60]

I just had the same issue, dns is not resolving inside the container. After a couple of hours of debugging, I tried generating a new proton wireguard key, and somehow this has solved the issue for me.

Same here:

2026-09-10T16:22:11Z WARN [dns] getting tls connection for request IN A oxapc1etz9q4m9kvakszswuxd734j269jehtgmk7-gyfahk9i9a36.ipleak.net.tailc81ff.ts.net.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:47260->1.1.1.1:853: read: connection reset by peer 2026-09-10T16:22:12Z WARN [dns] getting tls connection for request IN A github.com.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:47310->1.1.1.1:853: read: connection reset by peer 2026-09-10T16:22:12Z WARN [dns] getting tls connection for request IN A cloudflare.com.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:47324->1.1.1.1:853: read: connection reset by peer 2026-09-10T16:22:15Z INFO [MTU discovery] reverting VPN interface tun0 MTU to 1320 (due to: PMTUD failed with both ICMP and TCP) 2026-09-10T16:22:15Z WARN [dns] getting tls connection for request IN A oxapc1etz9q4m9kvakszswuxd734j269jehtgmk7-h4w9757wtsnc.ipleak.net.tailc81ff.ts.net.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:47330->1.1.1.1:853: read: connection reset by peer 2026-09-10T16:22:15Z WARN [dns] getting tls connection for request IN AAAA oxapc1etz9q4m9kvakszswuxd734j269jehtgmk7-gyfahk9i9a36.ipleak.net.tailc81ff.ts.net.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:47370->1.1.1.1:853: read: connection reset by peer 2026-09-10T16:22:15Z WARN [dns] getting tls connection for request IN AAAA oxapc1etz9q4m9kvakszswuxd734j269jehtgmk7-noehxter52ub.ipleak.net.tailc81ff.ts.net.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:47332->1.1.1.1:853: read: connection reset by peer 2026-09-10T16:22:15Z WARN [dns] getting tls connection for request IN AAAA oxapc1etz9q4m9kvakszswuxd734j269jehtgmk7-zwwdzqi38jln.ipleak.net.tailc81ff.ts.net.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:47334->1.1.1.1:853: read: connection reset by peer 2026-09-10T16:22:15Z WARN [dns] getting tls connection for request IN A oxapc1etz9q4m9kvakszswuxd734j269jehtgmk7-gyfahk9i9a36.ipleak.net.tailc81ff.ts.net.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:47374->1.1.1.1:853: read: connection reset by peer 2026-09-10T16:22:16Z WARN [dns] getting tls connection for request IN A oxapc1etz9q4m9kvakszswuxd734j269jehtgmk7-noehxter52ub.ipleak.net.tailc81ff.ts.net.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:47390->1.1.1.1:853: read: connection reset by peer 2026-09-10T16:22:16Z WARN [dns] getting tls connection for request IN A oxapc1etz9q4m9kvakszswuxd734j269jehtgmk7-zwwdzqi38jln.ipleak.net.tailc81ff.ts.net.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:47416->1.1.1.1:853: read: connection reset by peer 2026-09-10T16:22:16Z WARN [dns] getting tls connection for request IN AAAA oxapc1etz9q4m9kvakszswuxd734j269jehtgmk7-h4w9757wtsnc.ipleak.net.tailc81ff.ts.net.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:47414->1.1.1.1:853: read: connection reset by peer 2026-09-10T16:22:16Z WARN [dns] getting tls connection for request IN A oxapc1etz9q4m9kvakszswuxd734j269jehtgmk7-frf8kuy1n7a9.ipleak.net.tailc81ff.ts.net.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:47406->1.1.1.1:853: read: connection reset by peer 2026-09-10T16:22:16Z WARN [dns] getting tls connection for request IN AAAA oxapc1etz9q4m9kvakszswuxd734j269jehtgmk7-frf8kuy1n7a9.ipleak.net.tailc81ff.ts.net.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:47378->1.1.1.1:853: read: connection reset by peer 2026-09-10T16:22:17Z WARN [dns] getting tls connection for request IN A github.com.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:41990->1.1.1.1:853: read: connection reset by peer 2026-09-10T16:22:17Z WARN [dns] getting tls connection for request IN A cloudflare.com.: creating connection: running TLS handshake with 1.1.1.1:853 (cloudflare-dns.com): read tcp 10.2.0.2:41996->1.1.1.1:853: read: connection reset by peer