Pangolin/android connection failing

[yann117]

Describe the Bug

Running Pangolin on my own server at home and my own domain, having the whole setup working properly:

• IPv6 only server
• hosting my services on the server with the same Docker-
• using Oracle VPS to perform the IPv4 to IPv6 translation

I can properly access my resources from every situation. For better security I'd like to use now Private resources and Pangolin/VPN on my mobile.

Since private resources can only be defined on non-local node, I'm running newt (commandline) on the server as loopback to itself.

When no/zero private resources are defined, my Pangolin/mobile can connect and register properly.
As soon as I add a private resources, Pangolin/mobile client connect but is not able to register anymore.

Environment

• OS Type & Version: linux + Docker
• Pangolin Version: v1.21.0 (was also occurring in many previous versions)
• Edition (Community or Enterprise): Enterprise (single/own use)
• Gerbil Version: v1.4.1 (from sha256:7aa94231188fb9a738c9e1ab9cbf89001356da72453e57da9722d3e0fb37d196)
• Traefik Version: 3.6.23
• Newt Version: 1.15.0
• Client Version: 0.4.0

To Reproduce

When no private resources are defined, my Pangolin/mobile client can connect and register properly:

2026-07-22T19:21:19+00:00 [info]: Establishing websocket connection
2026-07-22T19:21:19+00:00 [info]: Client added to tracking - OLM ID: dfrg4iatyetu4fh, Connection ID: 480cd7cb-aea8-447a-8e7a-9dfb09c3a2bf, Total connections: 1, Config version: 0
2026-07-22T19:21:19+00:00 [info]: WebSocket connection fully established and ready - OLM ID: dfrg4iatyetu4fh
2026-07-22T19:21:20+00:00 [info]: [handleOlmRegisterMessage] Handling register olm message
2026-07-22T19:21:20+00:00 [info]: [handleOlmRegisterMessage] Public key mismatch. Updating public key and clearing session info... {"orgId":"home","clientId":4}

Once I setup one private resource BUT keep the prior Pangolin/mobile client connected (step above), then I can properly access the newly defined private resource, here http://192.168.1.7:2283:

2026-07-22T19:24:06+00:00 [info]: Created site resource 8 for org home
2026-07-22T19:24:06+00:00 [info]: Certificate already exists for domain pictures.private.mydomain.com
2026-07-22T19:24:06+00:00 [info]: Initiated 1 peer add handshake(s) to olms (batch)
INFO: 2026/07/22 21:24:06 Added target subnet from 100.90.128.0/32 to 100.96.128.8/32 rewrite to  with port ranges: [{443 443 tcp} {80 80 tcp} {0 0 udp}]
INFO: 2026/07/22 21:24:06 Added target subnet from 100.90.128.1/32 to 100.96.128.8/32 rewrite to  with port ranges: [{443 443 tcp} {80 80 tcp} {0 0 udp}]
INFO: 2026/07/22 21:24:06 Added target subnet from 100.90.128.3/32 to 100.96.128.8/32 rewrite to  with port ranges: [{443 443 tcp} {80 80 tcp} {0 0 udp}]
2026-07-22T19:24:07+00:00 [info]: ClientSitesAssociationsCache for client 4 endpoint changed to [2a02:8440:8503:2ae9:38c3:f1ff:feb0:acb2]:55253 for 1 site(s) on exit node 1
INFO: 2026/07/22 21:24:07 Triggering on-demand hole punch to 1 exit nodes
2026-07-22T19:24:07+00:00 [info]: Updated peer +KKour53wh...fyOKSCGc= on newt 7af1cumf044874j
INFO: 2026/07/22 21:24:07 Successfully sent on-demand hole punch to 1/1 exit nodes
INFO: 2026/07/22 21:24:07 Updating Endpoint for peer +KKour53wh...fyOKSCGc= to [2a02:8440:8503:2ae9:38c3:f1ff:feb0:acb2]:55253
INFO: 2026/07/22 21:24:07 Peer +KKour53wh...fyOKSCGc= updated successfully
2026-07-22T19:24:07+00:00 [info]: Handling register olm message!
INFO: 2026/07/22 21:24:07 Triggering on-demand hole punch to 1 exit nodes
2026-07-22T19:24:07+00:00 [info]: Added peer +KKour53wh...fyOKSCGc= to newt 7af1cumf044874j
INFO: 2026/07/22 21:24:07 Successfully sent on-demand hole punch to 1/1 exit nodes
INFO: 2026/07/22 21:24:07 Peer +KKour53wh...fyOKSCGc= added successfully
2026-07-22T19:24:09+00:00 [info]: Handling local olm message!
INFO: 2026/07/22 21:24:10 Triggering on-demand hole punch to 1 exit nodes
2026-07-22T19:24:10+00:00 [info]: Updated peer +KKour53wh...fyOKSCGc= on newt 7af1cumf044874j
INFO: 2026/07/22 21:24:10 Successfully sent on-demand hole punch to 1/1 exit nodes
INFO: 2026/07/22 21:24:10 Removing Endpoint for peer +KKour53wh...fyOKSCGc=
INFO: 2026/07/22 21:24:10 Peer +KKour53wh...fyOKSCGc= updated successfully
2026-07-22T19:24:10+00:00 [info]: Handling local olm message!
INFO: 2026/07/22 21:24:10 Triggering on-demand hole punch to 1 exit nodes
2026-07-22T19:24:10+00:00 [info]: Updated peer +KKour53wh...fyOKSCGc= on newt 7af1cumf044874j
INFO: 2026/07/22 21:24:10 Successfully sent on-demand hole punch to 1/1 exit nodes
INFO: 2026/07/22 21:24:10 Removing Endpoint for peer +KKour53wh...fyOKSCGc=
INFO: 2026/07/22 21:24:10 Peer +KKour53wh...fyOKSCGc= updated successfully
2026-07-22T19:24:11+00:00 [info]: Updated site resource 8
INFO: 2026/07/22 21:26:14 TCP Forwarder: Routing 100.90.128.1:50120 -> 100.96.128.8:443 to HTTP handler (https)
INFO: 2026/07/22 21:26:14 HTTP handler: GET / -> http://192.168.1.7:2283
INFO: 2026/07/22 21:26:14 HTTP handler: GET /_app/immutable/assets/GoogleSans.DGRbB7N7.ttf -> http://192.168.1.7:2283
INFO: 2026/07/22 21:26:14 TCP Forwarder: Routing 100.90.128.1:50122 -> 100.96.128.8:443 to HTTP handler (https)
INFO: 2026/07/22 21:26:14 TCP Forwarder: Routing 100.90.128.1:50138 -> 100.96.128.8:443 to HTTP handler (https)
INFO: 2026/07/22 21:26:14 TCP Forwarder: Routing 100.90.128.1:50162 -> 100.96.128.8:443 to HTTP handler (https)
INFO: 2026/07/22 21:26:14 TCP Forwarder: Routing 100.90.128.1:50136 -> 100.96.128.8:443 to HTTP handler (https)
INFO: 2026/07/22 21:26:14 TCP Forwarder: Routing 100.90.128.1:50154 -> 100.96.128.8:443 to HTTP handler (https)
INFO: 2026/07/22 21:26:14 HTTP handler: GET /_app/immutable/assets/GoogleSansCode.a41q3NA0.ttf -> http://192.168.1.7:2283
INFO: 2026/07/22 21:26:14 HTTP handler: GET /_app/immutable/entry/start.DgZvZQ22.js -> http://192.168.1.7:2283
INFO: 2026/07/22 21:26:14 HTTP handler: GET /_app/immutable/chunks/Leq4p3Ca.js -> http://192.168.1.7:2283
...
INFO: 2026/07/22 21:26:15 HTTP handler: GET /_app/immutable/chunks/NmZS8EsT.js -> http://192.168.1.7:2283
INFO: 2026/07/22 21:26:15 HTTP handler: GET /_app/immutable/chunks/DoEPtPFQ2.js -> http://192.168.1.7:2283
INFO: 2026/07/22 21:26:15 TCP Forwarder: Routing 100.90.128.1:50176 -> 100.96.128.8:443 to HTTP handler (https)
INFO: 2026/07/22 21:26:15 HTTP handler: GET /apple-icon-180.png -> http://192.168.1.7:2283
INFO: 2026/07/22 21:26:15 HTTP handler: GET /api/server/config -> http://192.168.1.7:2283
INFO: 2026/07/22 21:26:15 HTTP handler: GET /service-worker.js -> http://192.168.1.7:2283
INFO: 2026/07/22 21:26:15 HTTP handler: GET /api/server/features -> http://192.168.1.7:2283
INFO: 2026/07/22 21:26:16 HTTP handler: GET /api/server/media-types -> http://192.168.1.7:2283
INFO: 2026/07/22 21:26:16 HTTP handler: POST /api/oauth/authorize -> http://192.168.1.7:2283
INFO: 2026/07/22 21:26:34 HTTP request logger: sent 81 requests to server

If now, I disconnect my Pangolin/mobile, any new attempt to connect/register is failing with:

2026-07-22T19:28:07+00:00 [info]: All connections removed for OLM ID: dfrg4iatyetu4fh
2026-07-22T19:28:07+00:00 [info]: Client disconnected - OLM ID: dfrg4iatyetu4fh
2026-07-22T19:28:44+00:00 [info]: Establishing websocket connection
2026-07-22T19:28:44+00:00 [info]: Client added to tracking - OLM ID: dfrg4iatyetu4fh, Connection ID: fa5a92cf-11c9-4745-b2c7-bc8b69f728c0, Total connections: 1, Config version: 0
2026-07-22T19:28:44+00:00 [info]: WebSocket connection fully established and ready - OLM ID: dfrg4iatyetu4fh
2026-07-22T19:28:45+00:00 [info]: [handleOlmRegisterMessage] Handling register olm message
2026-07-22T19:28:45+00:00 [info]: [handleOlmRegisterMessage] Public key mismatch. Updating public key and clearing session info... {"orgId":"home","clientId":4}
2026-07-22T19:28:45+00:00 [warn]: [handleOlmRegisterMessage] Client last hole punch is too old and we have sites to send; skipping this register. The client is failing to hole punch and identify its network address with the server. Can the client reach the server on UDP port 21820? {"orgId":"home","clientId":4}
2026-07-22T19:28:47+00:00 [info]: [handleOlmRegisterMessage] Handling register olm message
2026-07-22T19:28:47+00:00 [warn]: [handleOlmRegisterMessage] Client last hole punch is too old and we have sites to send; skipping this register. The client is failing to hole punch and identify its network address with the server. Can the client reach the server on UDP port 21820? {"orgId":"home","clientId":4}
2026-07-22T19:28:49+00:00 [info]: [handleOlmRegisterMessage] Handling register olm message
2026-07-22T19:28:49+00:00 [warn]: [handleOlmRegisterMessage] Client last hole punch is too old and we have sites to send; skipping this register. The client is failing to hole punch and identify its network address with the server. Can the client reach the server on UDP port 21820? {"orgId":"home","clientId":4}
2026-07-22T19:28:51+00:00 [info]: [handleOlmRegisterMessage] Handling register olm message
2026-07-22T19:28:51+00:00 [warn]: [handleOlmRegisterMessage] Client last hole punch is too old and we have sites to send; skipping this register. The client is failing to hole punch and identify its network address with the server. Can the client reach the server on UDP port 21820? {"orgId":"home","clientId":4}
2026-07-22T19:28:53+00:00 [info]: [handleOlmRegisterMessage] Handling register olm message
2026-07-22T19:28:53+00:00 [warn]: [handleOlmRegisterMessage] Client last hole punch is too old and we have sites to send; skipping this register. The client is failing to hole punch and identify its network address with the server. Can the client reach the server on UDP port 21820? {"orgId":"home","clientId":4}

Once I remove the single private resource (zero remaining), then I can connect/register Pangolin/mobile again.
Below are the logs from the Pangolin/mobile app:

2026-07-24 11:15:50.176 [INFO] PangolinGo: Starting hole punch for 1 exit nodes
2026-07-24 11:15:50.176 [DEBUG] PangolinGo: Starting UDP hole punch to 1 exit nodes with shared bind
2026-07-24 11:15:50.176 [DEBUG] PangolinGo: Resolved exit node: [<IPv6_redacted>] -> [<IPv6_redacted>]:21820
2026-07-24 11:15:50.177 [WARN] PangolinGo: Failed to send initial hole punch to [<IPv6_redacted>]: failed to write to UDP: write udp [::]:56198->[<IPv6_redacted>]:21820: sendto: no route to host

It is properly picking up the IPv6 address as expected, but fails with a no route to host.

The ports (21820/51820) are open and listening and the same address:port can be reached from the same mobile using a different application, here termux, as I could confirm gerbil is receiving the messages I sent directly on the socket (socat).

As per the no route to host, the issue doesn't seem to be with the ports, but rather at another level (see below further details #3478 (comment)).

AI suggests the following hypothesis:

Why Pangolin Fails (The Go Socket Lifecycle Issue)

1. Android VPN Service Socket Protection:
   If Pangolin is running inside an Android app context (or VPN Service), sockets created by Go must be protected via Android's VpnService.protect(socket) so they bypass the VPN tunnel loop. If a shared socket is bound without proper socket protection or interface binding, Android's netd daemon drops the outbound packet with EHOSTUNREACH (no route to host).

2. Binding to 0.0.0.0 / IPv4-mapped IPv6:
   If Pangolin initializes its "shared bind" using net.ListenPacket("udp", ":0") on a system where Go's dual-stack socket behavior is restricted by Android/Linux kernel policies (IPV6_V6ONLY), attempting to write to a pure IPv6 address through that shared socket fails.

3. Stale Interface / Socket Binding:
   PangolinGo is using a shared bound socket (reusing an existing net.PacketConn or net.UDPConn instance). If that socket was created when the app started, or before your mobile device established/switched its IPv6 route, the underlying file descriptor is bound to an old routing context. In Go, calling WriteToUDP() on a stale [::] socket throws sendto: no route to host even if new sockets (like nc) work fine.

Expected Behavior

Pangolin/mobile client should be able to connect when private resources are configured.

[AstralDestiny]

Not sure what you mean honestly by having a vps handle v4 to v6 as that's not how that works, Though if relying on nat64 or dns64 then those just cause a lot of issues in the end,

As for no private resources defined and connecting it's because no holepunches are attempted if no private resources are defined,

Do you have AAAA records in place or are you relying on flimsy DNS64/NAT64?

[yann117]

what you mean honestly by having a vps handle v4 to v6

I don't know the exact wording, but in summary, I have a simple Oracle OCI instance with:

• IPv4/IPv6 stack configured
• just running NGinx
• NGinx with stream directive to my home server IPv6

In my registrar I have defined A record/IPv4 to the Oracle OCI vps, and AAAA record/IPv6 to my home server.

That setup works fine for regular public resources, not going through the complex setup (loopback newt to itself/home server). IPv4 only clients are accessing the home server through the VPS/proxy, and IPv6 client access directly the server backend.

Also, while I agree that this might add an extra complexity layer, I don't think this play a role in the current issue. It might play role but not at this point, as currently I'm only testing this with an IPv6-only client.

Even in that simple use-case/setup it is not working. If it would, then I would continue trying with an IPv4-only client, but I'm not there yet.

As for no private resources defined and connecting it's because no holepunches are attempted if no private resources are defined

Since I looked for hours on this issue (and I know you already tried to help in a different topic I highjacked), I think I read that already.
But I still can't get why it is still working perfectly fine when adding the private resources while the client is already connected.

I guess it's related to the fact the connection is already active. And ok, no "holepunch" is performed when no resources are defined, but considering that the connection can be established properly in that case, why is it (holepunch) even required ?

I can't figure the need of the whole setup, when the connection can be done, the access to the private resources is working, but just not when restarting fresh the pangolin client ...

Also, long ago, by looking in every topics I could find, I can remember someone was explaining it is due to the sub-domain / routing created for private resources, conflicting at some point or caused by some DNS issue. And that a solution was to change the IP range for "something", I can't remember the steps and can't find the topic anymore.

Initially I didn't tried, as it was requiring to reconfigure all resources (and possibly "all" meaning including the public resources, that I have more than a dozen), which I didnt want to.

[AstralDestiny]

Just the Oracle host needs the A/AAAA

[AstralDestiny]

As the ingress point is the oracle host.

[yann117]

I don't want IPv6 client only to get through the Oracle OCI, this would cap the bandwidth, and might implies traffic limitation (even if I believe Oracle ToS include huge traffic/month).

Technically, it is not required/wanted to add an unnecessary layer when both ends are in IPv6 (and I don't care revealing my server IP).

I barely need it, as I'm most of the time on IPv6 network, it is only required when I travel in countries that only have IPv4. But so the IPv4 route is the "degraded" mode for me.

I really don't want to proxy everything through the Oracle server.

[AstralDestiny]

Well the tunnel entry for gerbil is what's used for the intial hookup

[yann117]

Enabling Pangolin/mobile logs, I can see the following:

2026-07-24 11:15:50.176 [INFO] PangolinGo: Starting hole punch for 1 exit nodes
2026-07-24 11:15:50.176 [DEBUG] PangolinGo: Starting UDP hole punch to 1 exit nodes with shared bind
2026-07-24 11:15:50.176 [DEBUG] PangolinGo: Resolved exit node: [<IPv6_redacted>] -> [<IPv6_redacted>]:21820
2026-07-24 11:15:50.177 [WARN] PangolinGo: Failed to send initial hole punch to [<IPv6_redacted>]: failed to write to UDP: write udp [::]:56198->[<IPv6_redacted>]:21820: sendto: no route to host

So ok, it is properly picking up the IPv6 address, as expected, but fails with the no route to host.

Here is my Pangolin/Gerbil docker configuration on the server:

name: pangolin
services:
  gerbil:
    image: docker.io/fosrl/gerbil:latest
    container_name: gerbil
    restart: unless-stopped
    depends_on:
      pangolin:
        condition: service_healthy
    command:
      - --reachableAt=http://gerbil:3004
      - --generateAndSaveKeyTo=/var/config/key
      - --remoteConfig=http://pangolin:3001/api/v1/
    volumes:
      - ./config/:/var/config
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    ports:
      - 51820:51820/udp
      - 21820:21820/udp
      - 443:443
      - 80:80

On the server, I can validate that the ports (21820/51820) are open/listening:

ss -tulpn6 | egrep "Port|docker"
Netid State  Recv-Q Send-Q                       Local Address:Port  Peer Address:PortProcess                                   
udp   UNCONN 0      0                                     [::]:51820         [::]:*    users:(("docker-proxy",pid=2109826,fd=7))
udp   UNCONN 0      0                                     [::]:21820         [::]:*    users:(("docker-proxy",pid=2109812,fd=7))
tcp   LISTEN 0      4096                                  [::]:80            [::]:*    users:(("docker-proxy",pid=2109780,fd=7))
tcp   LISTEN 0      4096                                  [::]:443           [::]:*    users:(("docker-proxy",pid=2109796,fd=7))

I also disabled the firewall (even though Docker is already bypassing it):

systemctl stop firewalld

Important, I also opened these ports (UDP/TCP) in my ISP box security.

Next, on my mobile I went with termux and ran that command:

echo 'true' | socat - UDP6:[<IPv6_redacted>]:21820

On the server, with docker gerbil logs I can properly see it got the echo. If I send something else than true like test or some json content, the message are different. Of course gerbil is not expecting those garbage message and discard them, but the point is to prove that my mobile can properly reach the IPv6 address:port

ERROR: 2026/07/24 11:12:03 Error unmarshaling encrypted message: invalid character 'e' in literal true (expecting 'r')
ERROR: 2026/07/24 11:12:03 Error unmarshaling encrypted message: unexpected end of JSON input
..
ERROR: 2026/07/24 11:15:06 Error unmarshaling encrypted message: unexpected end of JSON input
ERROR: 2026/07/24 11:15:06 Error unmarshaling encrypted message: json: cannot unmarshal bool into Go value of type relay.EncryptedHolePunchMessage

So why is the Pangolin/mobile app not able to do the same ?

AI tell me the following:

Why Pangolin Fails (The Go Socket Lifecycle Issue)

Look at the log line again:
PangolinGo: Starting UDP hole punch to 1 exit nodes with shared bind

1.  Android VPN Service Socket Protection:
    If Pangolin is running inside an Android app context (or VPN Service), sockets created by Go must be protected via Android's VpnService.protect(socket) so they bypass the VPN tunnel loop. If a shared socket is bound without proper socket protection or interface binding, Android's netd daemon drops the outbound packet with EHOSTUNREACH (no route to host).

2.  Binding to 0.0.0.0 / IPv4-mapped IPv6:
    If Pangolin initializes its "shared bind" using net.ListenPacket("udp", ":0") on a system where Go's dual-stack socket behavior is restricted by Android/Linux kernel policies (IPV6_V6ONLY), attempting to write to a pure IPv6 address through that shared socket fails.

3.  Stale Interface / Socket Binding:
    PangolinGo is using a shared bound socket (reusing an existing net.PacketConn or net.UDPConn instance). If that socket was created when the app started, or before your mobile device established/switched its IPv6 route, the underlying file descriptor is bound to an old routing context. In Go, calling WriteToUDP() on a stale [::] socket throws sendto: no route to host even if new sockets (like nc) work fine.

[yann117]

I see the server IPv4 address as well in the log (last line). This is not expected ...

2026-05-11 21:53:27.586 [DEBUG] PangolinGo: Failed to send hole punch to [<IPv6_redacted>]: failed to write to UDP: write udp [::]:52001->[<IPv6_redacted>]:21820: sendto: no route to host
2026-05-11 21:53:27.586 [DEBUG] PangolinGo: Increased hole punch interval to 32s
2026-05-11 21:53:29.445 [ERROR] PangolinGo: websocket: Failed to connect: failed to connect to WebSocket: read tcp 100.67.54.32:57774->IPv4_redacted:443: read: connection reset by peer. Retrying in 3s...

EDIT: trying again, this is not systematic, it depends what I do with the app. In some attempt, there is only the IPv6 address. So the issue can be simplified b ruling out IPv4 clash.

Is Pangolin/mobile really designed and working in a full/only IPv6 stack?

[AstralDestiny]

Why'd you open 21820 on your isp when there's nothing running on 21820 at your isp? Are you running this on an oracle or at your home? If at your home there's zero point in having any of the pangolin ports open at home..?

[yann117]

Right, my description was not clear enough. When I say "my own server" I meant a server at home, I'm doing selfhosting.
This home server is running Pangolin and other services (Immich, ...) in Docker.
I access these services from internet, from any other computer and from my mobile.
My ISP only provide a public IPv6, therefore I added the Oracle VPS just to stream/proxy IPv4 traffic back to my home server.

Therefore I have to configure my internet box to open whatever ports are required to get through my home server.

Currently I'm only looking at the simple scenario when I'm fully on IPv6, with the following expected flow:

Other device (computer/mobile) IPv6 -> query DNS -> registrar return my home server IPv6 -> traffic goes through ISP box -> reach my home server IPv6

This is working perfectly - for (Pangolin) public resources - everything goes through the port 443.
Now that I want to add private resources, I added a local Newt client, still on that same home server, doing loopback to itself. This is currently required as Pangolin itself doesn't allow to define private resources on the local site/node (I'll open a feature enhancement some day).

And this is where I have now to play with those others ports (21820/51820).

[AstralDestiny]

Right but you also said Oracle OCI.. where's pangolin running? at home or on the oracle host?

[yann117]

I updated the description and above posts.

Pangolin is running on the home server, everything is there, Oracle OCI vps is just secondary (for IPv4), and should not play a role here ideally.

[AstralDestiny]

Right I don't see edits from the tool I'm using to respond from so I will need to add those.. fun..