Client cannot resolve exit node endpoint on IPv6-only networks — hole punch never starts, registration fails with HOLEPUNCH_MISSING

[WuestenGeeko]

Describe the Bug

Summary

On a mobile network that hands out only IPv6 DNS servers, the Android client fails to resolve the exit node hostname for UDP hole punching. No hole punch packet is ever sent, so the server aborts registration with HOLEPUNCH_MISSING and the app hangs in the "registering" state indefinitely.

The same device, app version and server work fine as soon as the network provides an IPv4 DNS server — including full relay fallback.

The server's error message ("ensure your client can reach the server on UDP port 21820") is misleading here: the client never attempts to reach it, because name resolution failed first.

Environment

App	Pangolin Android 0.4.1
olm version reported	0.4.1
Device	Pixel 8a, Android 17, aarch64
Pangolin server	1.21.1 (enterprise build)
newt (site)	1.15.0
Exit node	hostname, UDP 21820
Failing network	mobile data on APN internet.v6.telekom (IPv6-only APN, Telekom Germany / its MVNOs), DNS servers 2a01:598:7ff:0:10:74:210:221 / :222
Working network	same SIM on APN internet.telekom (dual-stack), or any network providing an IPv4 resolver

Hostnames, org id, keys and tokens are redacted below as pangolin.example.com, <redacted> etc.

To Reproduce

Failing case (IPv6-only DNS)

12:59:30.608  Applying system DNS: [[2a01:598:7ff:0:10:74:210:221]:53 [2a01:598:7ff:0:10:74:210:222]:53]
12:59:30.612  Created shared UDP socket on port 63563 (refcount: 2)
12:59:30.662  Got exit nodes for hole punching: [{pangolin.example.com 21820 <redacted> [1]}]
12:59:30.662  Starting hole punch for 1 exit nodes
12:59:30.662  Starting UDP hole punch to 1 exit nodes with shared bind
12:59:30.666  Failed to resolve endpoint pangolin.example.com: DNS lookup failed using all
              upstream servers: lookup pangolin.example.com on [::1]:53:
              dial udp [2a01:598:7ff:0:10:74:210:222]:53: connect: no route to host
12:59:30.666  No exit nodes available yet, waiting for nodes to be added
12:59:30.849  Websocket Connected
12:59:31.350  Sending registration message to server with public key: <redacted> and relay: false
              ... olm/wg/register repeated every 2s ...
13:00:05.556  Received olm error message: map[code:HOLEPUNCH_MISSING
              message:Unable to coordinate client P2P connection. Please ensure your client
              can reach the server on UDP port 21820 and try registering again.]

The key detail: the websocket connects to the same hostname 183 ms after the resolver failed on it. The platform resolver works; only the client's internal resolver on [::1]:53 fails.

This reproduced 8 times in a row over ~40 minutes, byte-identical each time.

Working case (IPv4 DNS available)

Same device, same app version, same server, same session of the log, ~45 minutes earlier:

12:13:21.175  Applying system DNS: [9.9.9.9:53 149.112.112.112:53]
12:13:21.639  Got exit nodes for hole punching: [{pangolin.example.com 21820 <redacted> [1]}]
12:13:21.639  Starting hole punch for 1 exit nodes          ← no resolve error
12:13:21.737  Websocket Connected
12:13:22.239  Sending registration message to server with public key: <redacted> and relay: false
12:13:22.603  The tunnel IP is: 100.90.128.2/20             ← registration completes
12:13:22.603  Set IPv4 addresses: [100.90.128.2], subnet masks: [255.255.240.0]
12:13:22.603  Set MTU: 1280
12:13:22.613  Configured peer <redacted>
12:13:33.081  Local endpoint 192.168.178.200:63131 for site 1 failed 3 times,
              falling back to public/relay logic
12:13:35.899  Rapid fallback test: site 1 unreachable on public endpoint after local
              fallback, requesting relay
12:13:35.943  Received relay-peer message: map[relayEndpoint:pangolin.example.com
              relayPort:21820 siteId:1]
12:13:35.987  Adjusted peer 1 to point to relay!
12:13:41.138  WireGuard connection to site 1 is CONNECTED

The device was not on the site's LAN in this session — the local endpoint probe failed and the client correctly fell back to relay. So relay works; the only variable between working and failing is whether an IPv4 DNS server is present.

Suspected cause

The tunnel interface is IPv4-only. Across the whole 9119-line log there is not a single Set IPv6 line; every session configures only Set IPv4 addresses: [100.90.x.x].

Android's VpnService makes IPv6 destinations unreachable (no route to host) for traffic subject to a VPN that has no IPv6 address/route. The internal DNS proxy's upstream socket appears not to be protected with VpnService.protect(), so once the TUN is established its queries to IPv6 resolvers are blackholed.

On a dual-stack network this is invisible, because the IPv4 resolver in the same list still answers. On an IPv6-only network there is no fallback and hole punching never starts.

Expected Behavior

The exit node hostname should resolve regardless of the network's address family — e.g. by protecting the resolver socket, resolving before the TUN is established, or falling back to the platform resolver (which demonstrably succeeds, as the websocket connection proves).

Additional note: the DNS setting in the app does not reach this code path

Setting a custom DNS server (9.9.9.9) in the app's settings does not help. The value never appears in the tunnel config. Across all 8 failing attempts:

UpstreamDNS:[]  PublicDNS:[]  DNS:

The only field that changed after editing the setting was TunnelDNS: true → false. So there is currently no user-side workaround within the app.

Full tunnel config of a failing session:

{Endpoint:https://pangolin.example.com ID:<redacted> Secret:<redacted>
 UserToken:<redacted> MTU:1280 DNS: UpstreamDNS:[] PublicDNS:[] InterfaceName:
 MatchDomains:[] Holepunch:true TlsClientCert: PingIntervalDuration:10s
 PingTimeoutDuration:30s OrgID:<redacted> FileDescriptorTun:146 FileDescriptorUAPI:0
 EnableUAPI:false OverrideDNS:true TunnelDNS:false ... DisableRelay:false
 PreferLocalRoutes:false}

[mazarian]

I'm hitting this same thing on a different carrier and a newer app version.

Pixel 9 Pro on Android 17, Pangolin Android 0.5.0, server 1.22, newt 1.16.0 at my sites. Phone is on Google Fi (T-Mobile US). On mobile data the carrier hands out IPv6 only resolvers, fd00:976a::9 and fd00:976a::10. On my home wifi I get IPv4 resolvers (192.168.2.5 and .6) and it connects fine.

Same error you posted (hostname redacted):

[WARN] PangolinGo: Failed to resolve endpoint pangolin.example.com: DNS lookup failed
using all upstream servers: lookup pangolin.example.com on [::1]:53:
dial udp [fd00:976a::10]:53: connect: no route to host

Then olm/wg/register every 2 seconds until the server gives up:

[ERROR] PangolinGo: Olm error (code: HOLEPUNCH_MISSING): Unable to coordinate client
P2P connection. Please ensure your client can reach the server on UDP port 21820 ...
[INFO]  PangolinGo: OLM tunnel stopped

and on the server:

[warn]: [handleOlmRegisterMessage] Client last hole punch is too old and we have sites
to send; skipping this register.

Then it starts over and does the same thing again.

Your note about the interface holds up on my end too. Set IPv4 addresses: shows up on every tunnel start and Set IPv6 doesn't appear once in the whole log.

From what I can tell, it's not really wifi vs cellular. It comes down to whether the DNS list has an IPv4 server in it:

• system DNS 192.168.2.5, 192.168.2.6 -> Sent UDP hole punch to <server>:21820, works
• system DNS fd00:976a::9, fd00:976a::10 -> Failed to resolve endpoint, no punch

Resolution only happens when the hole punch starts, so if the DNS list flips to IPv6 while a punch loop is already running it keeps going until the tunnel restarts. That threw me off for a while.

I checked the server side too. UDP 21820 arrives fine over both IPv4 and IPv6, tested with probes from another VPS. And when the lookup succeeds the client logs Sent UDP hole punch and registers normally. So it looks like the UDP path is fine and it's just the name lookup failing. That's also how I ruled out fosrl/olm#108 for my case - there the punch starts and no packet leaves. Here nothing gets sent because there's no address to send to.

On the DNS setting in the app, my log looks a little different from yours. Yours showed UpstreamDNS:[] in the tunnel config, mine has the value I set in it:

[INFO]  UpstreamDNS is statically configured ([192.168.2.5:53]); automatic system DNS
        detection will only update PublicDNS ...
[INFO]  Applying system DNS: [[fd00:976a::9]:53 [fd00:976a::10]:53]
[WARN]  Failed to resolve endpoint pangolin.example.com: ... dial udp [fd00:976a::10]:53

So it does get applied on 0.5.0, maybe that changed since 0.4.1. Doesn't help though, because it isn't what the endpoint lookup uses. Normal app queries go to it - the internal proxy logs forwarding upstream to [1.1.1.1:53] and those work fine while the tunnel is up, since the upstream is IPv4. The exit node lookup goes to the system DNS list instead, so it lands on the IPv6 servers that can't be reached. Same end result you got, no way to work around it from the app.

I don't know the code, but using the configured upstream for the endpoint lookup might be enough to fix this, without having to deal with socket protection or adding IPv6 to the tunnel.

Two other notes:

1. This isn't specific to Telekom or Germany. You're on Telekom, I'm on T-Mobile US. Most US carriers are IPv6 only on mobile data now.
2. olm#108 reports the same end result on iOS and macOS, so this might need to be fixed in the shared Go core instead of the Android app.

I can post the full log or test anything else if it helps.