mirror of
https://github.com/fosrl/pangolin.git
synced 2026-07-16 06:08:33 -05:00
[GH-ISSUE #2318] Connection Failure: "Client last hole punch is too old" on Android and CLI due to SQLITE_CONSTRAINT_FOREIGNKEY #17116
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/pangolin#17116
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @r3nor on GitHub (Jan 24, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2318
Describe the Bug
I am unable to establish a connection from Android or CLI after the first successful attempt. The server appears unable to clear the previous session, leaving the client in a broken state where it constantly fails with "Client last hole punch is too old."
I observed a FOREIGN KEY constraint failed error in the logs immediately preceding the connection issues. It appears the server fails to clean up expired sessions, preventing new connections from registering correctly.
Root Cause Log (Pangolin Container):
The server crashes when trying to clear expired sessions:
Symptom Log (Connection Attempt):
Following the SQL error, the client attempts to connect but gets rejected due to key mismatches and stale hole punch data:
Observations:
Environment
To Reproduce
Expected Behavior
Reconnections work normally
@dordijeb commented on GitHub (Jan 25, 2026):
Hi,
I am experiencing similar issue with iOS app.
After the first successful connection, it never goes past the stage of "registering...".
@Richi-78 commented on GitHub (Jan 25, 2026):
After some succesful attemps I now have the same issue both with android (0.1.3 on android 16 with OneUI 8) and windows (0.5.0 on windows 11) clients
Regardless, even when connected, clients would not view connected sites and I could not access the resources on those sites
@oschwartz10612 commented on GitHub (Jan 26, 2026):
Everyone please confirm you have UDP port 21820 open on your VPS and in the docker compose. If you have upgraded from older versions of the stack this was not the default. Also please make sure you are on the latest version of gerbil 1.3.0.
If all of these things are confirmed please report back!
@engels0n commented on GitHub (Jan 26, 2026):
Hi @oschwartz10612 ,
yes, ports are open. Gerbil is 1.3.0
VPS:
Docker-Compose
@timokluser-dev commented on GitHub (Jan 26, 2026):
I was having the same issue since a few days.
I finally found a workaroung by adding the
--port <>option to newt explicitly.The docker run command:
@oschwartz10612 I hope this helps for investigating 🙂
Have a nice day all!
@r3nor commented on GitHub (Jan 26, 2026):
@oschwartz10612 Yes, I have port 21820 open in firewall and docker compose. However, connection is still not working.
See:
And in my docker-compose.yml:
I still see this error on top of the container startup:
The android app is stuck at 'Registering', but never ends.
In the CLI I see:
This gets hanged here, waiting forever without failing.
@dordijeb commented on GitHub (Jan 26, 2026):
Hi,
I did not have port 21820 added. Even after I added it to ufw and docker-compose, the pangolin client was stuck at "registering...". What resolved the issue is restarting newt container at a site, after I have noticed these errors:
ERROR: 2026/01/26 17:35:27 Failed to connect: failed to get token: failed to request new token:@mrprofessork commented on GitHub (Jan 26, 2026):
Happening on MacOs as well.
@mrprofessork commented on GitHub (Jan 26, 2026):
I have this happening on iOS and macOS. Deleting private resources seem to resolve it, but that defeats the purpose of this feature.
The associated log entries:
@mrprofessork commented on GitHub (Jan 26, 2026):
These were all satisfied in my setup.
@spiezmaestro commented on GitHub (Jan 26, 2026):
I was experiencing the same thing (status "registering") and did not have port 21820/udp open. After opening it, the status gets to connected (both on the Android client as well as in the Pangolin admin console). However the private resource (CIDR of a network through a site) does not seem to be respected. I can't connect to anything in that LAN. In the Pangolin docker logs I can see the following error message:
2026-01-26T20:49:29+00:00 [warn]: Newt <identifier> does not have Docker socket accessHave not been able to find anything on this in other issues.
@mrprofessork commented on GitHub (Jan 26, 2026):
Maybe add this to your docker compose for newt, (assuming you run newt with docker compose);
services:
newt:
image: fosrl/newt
container_name: newt
restart: unless-stopped
environment:
- PANGOLIN_ENDPOINT=https://subdomain.domain.com
- NEWT_ID=ID
- NEWT_SECRET=secret
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
that volumes section is what you can try. Also make sure you enable docker blueprint on the site settings in the dashboard.
@lbarraga commented on GitHub (Jan 27, 2026):
I too seem to have this problem. My vpn client (linux) cant connect to the server when a private resource is registered.
no private resource
server logs:
adding a private resource
server logs
Try to connect again on client:
server logs:
versions
pangolin 1.15.1
gerbil 1.3.0
traefik: 3.3.3
pangolin cli: 0.3.0
newt on site: 1.9.0
@mrprofessork commented on GitHub (Jan 27, 2026):
Restarting the newt container eventually resolved this issue for me, I expect restart newt service if you didn't use docker might help as well.
@spiezmaestro commented on GitHub (Jan 27, 2026):
Indeed restarting the newt client service (no docker) solved it for me. Can now connect to the LAN behind the site configured in the private resource. Thx for the info.
@lbarraga commented on GitHub (Jan 27, 2026):
Reinstalling pangolin worked for me. I suspect I jumped too much versions when upgrading and something broke.
@engels0n commented on GitHub (Jan 29, 2026):
problem on my site still exists. log is green, but I am not connected to my site. still showing disconnected:
log:
But my iPhone stays at "Registering" :/
@jack9603301 commented on GitHub (Jan 29, 2026):
me too
@singularity0821 commented on GitHub (Jan 30, 2026):
I'm having the same issue and the same log messages when trying to connect from Android.
The ports are open and restarting Newt did not solve the issue for me.
@jack9603301 commented on GitHub (Jan 30, 2026):
I think this implementation has a fatal bug, because its error is bizarre, and it seems to be widely encountered by many people. I've moved to wireguard, using wg-easy, and it works perfectly.
@engels0n commented on GitHub (Feb 6, 2026):
I had hoped that the new update 1.15.2 might bring an improvement. Unfortunately, the problem still persists.
@oschwartz10612 can we expect a fix in the near future? :)
@jack9603301 commented on GitHub (Feb 6, 2026):
The certificate request of pangolin always fails, but I want to process it in the reverse proxy backend. If my proxy processes the certificate file, I prefer pangolin to support HTTP mode instead of HTTPS. Should the official website document provide the document on how to cancel the HTTPS setting?
Because pangolin's certificate is useless and its request will be in a failed state, I would like to use the nginx secondary reverse proxy to control the entire topology more flexibly.
@engels0n commented on GitHub (Feb 12, 2026):
Updated to new version:
iOS App states "registering" but nothing happens ...
Site is still disconnected.
:/
@jack9603301 commented on GitHub (Feb 12, 2026):
Are UDP traffic disrupted due to firewall policies in your country or region, or in your organization and network environment? Me too, due to Chinese GFW, I can't seem to get a good connection until I move my main server to China.
@jack9603301 commented on GitHub (Feb 12, 2026):
Are UDP traffic disrupted due to firewall policies in your country or region, or in your organization and network environment? Me too, due to Chinese GFW, I can't seem to get a good connection until I move my main server to China.
@oschwartz10612 commented on GitHub (Feb 12, 2026):
Would you be able to initiate the connection and do a tcp dump on the
server to see if the UDP traffic is making it?
tcpdump -i any -n udp port 21820
@engels0n commented on GitHub (Feb 13, 2026):
@oschwartz10612
Sure. here it is:
I am wondering why there is a dot instead of a colon before the port....
Hope it helps :)
@singularity0821 commented on GitHub (Feb 14, 2026):
I've just noticed that I can get a successful connection if I'm in my home WiFi.
When I then turn off the WiFi, Pangolin briefly loses its connection (as expected) but then it successfully reconnects and I can access my private resources.
@BombusAlpinus commented on GitHub (Feb 17, 2026):
in my case this happens as soon as i create a private ressource for an user and connecting through the latest android client:
after deleting the private ressource the connection works again.
@github-actions[bot] commented on GitHub (Mar 4, 2026):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
@AndreGilerson commented on GitHub (Mar 6, 2026):
I have the exact same problems, and cannot establish a tunnel with pangolin-cli anymore. Therefore i would like to revive the issue.
@johnmacfadyen commented on GitHub (Mar 16, 2026):
I've just hit this today as well. Updating all my newt connectors now, hopefully that will fix it.
@theorician commented on GitHub (Mar 21, 2026):
I have the same issue - all versions are up to date on latest. MacOS does not connect - however Android does - when a private resource exists. Ports are open and confirmed working.
@svandive commented on GitHub (Mar 24, 2026):
My issue is related but might not be the same. I'm able to connect using Apple-based clients, but only if I have the DNS in the client preferences configured to the default 1.1.1.1. If I try and configure an internal DNS server, then the logs show exactly what OP is seeing. Connecting with the DNS configured to any externally accessible DNS, and the client connects. I have the internal DNS server configured as a Private Resource, and can verify connectivity between the DNS server and Pangolin. All public services are working without issue.
@Viable8237 commented on GitHub (Mar 25, 2026):
Just ran into this issue as well on iOS. The Pangolin app was stuck at "Registering". Restarting neither the Pangolin server nor the Newt client helped. Surprisingly the connection was successfully established when the phone was connected to a home WiFi network where the Newt client runs. It however worked neither on mobile connection (which did work in the past) nor when connected to a different hotspot.
The site status says
Onlinein the Pangolin dashboard and Newt's logs sayClient connectivity setup. Ready to accept connections from clients!. I can see theClient last hole punch is too old and we have sites to send; skipping this registermessage in logs when trying to connect so I don't think the phone's mobile IP address is banned.Here's a JSON log from the iOS app during a connection attempt (the never-ending "Registering" phase):
Everything should be running on latest version.
@oschwartz10612 commented on GitHub (Mar 26, 2026):
This should resolve the issue. We are pushing an update now through the app store and macos release will be available shortly and we are also pushing a windows update. Please let me know if it does not fix the issue!
https://github.com/fosrl/apple/pull/30
https://github.com/fosrl/windows/pull/34
Lets reopen if not! Also make sure to take a look at this for future travelers: https://github.com/orgs/fosrl/discussions/2384
@svandive commented on GitHub (Mar 27, 2026):
I can confirm at least for me, the updated iOS version of the Client has resolved the issue!!
Thank You very much!!!
@BombusAlpinus commented on GitHub (Mar 27, 2026):
sorry, doesnt work for me. Android Client 0.1.10, pangolin version 1.16.2
as soon as i define a private ressource the connection from my mobile doesnt work properly. see my older post
@LaurenceJJones commented on GitHub (Mar 27, 2026):
Could you try restarting the Newt site and then attempt to connect?
@BombusAlpinus commented on GitHub (Mar 27, 2026):
restarted newt docker container (1.10.3). no change...
@oschwartz10612 commented on GitHub (Mar 27, 2026):
Are you good with everything in this post?
https://github.com/orgs/fosrl/discussions/2384
Its very important that port is open, in the docker compose, and gerbil
is updated.
@BombusAlpinus commented on GitHub (Mar 29, 2026):
port is open and service is listening:
@valki2 commented on GitHub (Apr 1, 2026):
hit the same problem:
pangolin log says:
Client last hole punch is too old and we have sites to send; skipping this register
client log says:
2026-04-01 10:06:50.000 [INFO] Tunnel: StartTunnel called
2026-04-01 10:06:50.000 [INFO] Tunnel: Starting tunnel with config
2026-04-01 10:06:50.000 [INFO] Tunnel state changed: registering
2026-04-01 10:06:50.000 [INFO] Pangolin logging initialized - log file: C:\ProgramData\Pangolin\logs\pangolin.log, log level: info
2026-04-01 10:06:50.000 [INFO] Pangolin version 0.8.1 starting
2026-04-01 10:06:50.000 [INFO] Starting as tunnel service with config: C:\ProgramData\Pangolin\Tunnels\olm.json
2026-04-01 10:06:50.000 [INFO] Tunnel service: Starting with config
2026-04-01 10:06:50.000 [INFO] Tunnel service: Running as Windows service
2026-04-01 10:06:50.000 [INFO] Tunnel service: Service starting
2026-04-01 10:06:50.000 [INFO] Starting status polling
2026-04-01 10:06:50.000 [INFO] Started OLM status polling (every 1 second)
2026-04-01 10:06:50.000 [INFO] Tunnel state changed: registering
2026-04-01 10:06:51.000 [ERROR] Failed to poll OLM status: failed to connect to OLM: Get "http://localhost/status": open \.\pipe\pangolin-olm: The system cannot find the file specified.
2026-04-01 10:06:51.000 [INFO] Starting HTTP server on socket \.\pipe\pangolin-olm
2026-04-01 10:06:51.000 [INFO] Starting OLM tunnel...
2026-04-01 10:06:51.000 [INFO] Created shared UDP socket on port 56759 (refcount: 2)
2026-04-01 10:06:51.000 [INFO] Starting hole punch for 1 exit nodes
2026-04-01 10:06:51.000 [INFO] Websocket Connected
2026-04-01 10:06:52.000 [INFO] Tunnel: OLM registered
Already deinstalled / cleaned / reinstalled latest clients.
hint:
And - of course - it has something todo with dns ("its always dns"):
It works when I dont use adguard like no adguard protected wifi but the 5g connection on android.
(situation: local wifi forces dns to adguard and blocks 53/udp outbound to prevent apps ignoring the DNS setting via dhcp)
@valki2 commented on GitHub (Apr 1, 2026):
Proof: when allowing 53/udp outbound for the client, then it connects/registers. Doesnt feel right as I want to decide which DNS to use - and yes, adguard IS accepting the request and is resolving correctly.
Still, the connection to the private resources wont work although the routes seem to have been created.
2026-04-01 10:21:34.000 [INFO] Connecting tunnel with config: Name=olm, Endpoint=https://pangolin.xxx.com
2026-04-01 10:21:34.000 [INFO] Tunnel: StartTunnel called
2026-04-01 10:21:34.000 [INFO] Tunnel: Starting tunnel with config
2026-04-01 10:21:34.000 [INFO] Tunnel state changed: registering
2026-04-01 10:21:34.000 [INFO] Pangolin logging initialized - log file: C:\ProgramData\Pangolin\logs\pangolin.log, log level: info
2026-04-01 10:21:34.000 [INFO] Pangolin version 0.8.1 starting
2026-04-01 10:21:34.000 [INFO] Starting as tunnel service with config: C:\ProgramData\Pangolin\Tunnels\olm.json
2026-04-01 10:21:34.000 [INFO] Tunnel service: Starting with config
2026-04-01 10:21:34.000 [INFO] Tunnel service: Running as Windows service
2026-04-01 10:21:34.000 [INFO] Tunnel service: Service starting
2026-04-01 10:21:34.000 [INFO] Tunnel state changed: registering
2026-04-01 10:21:34.000 [INFO] Starting status polling
2026-04-01 10:21:34.000 [INFO] Started OLM status polling (every 1 second)
2026-04-01 10:21:35.000 [ERROR] Failed to poll OLM status: failed to connect to OLM: Get "http://localhost/status": open \.\pipe\pangolin-olm: The system cannot find the file specified.
2026-04-01 10:21:35.000 [INFO] Starting HTTP server on socket \.\pipe\pangolin-olm
2026-04-01 10:21:35.000 [INFO] Starting OLM tunnel...
2026-04-01 10:21:35.000 [INFO] Created shared UDP socket on port 53343 (refcount: 2)
2026-04-01 10:21:35.000 [INFO] Starting hole punch for 1 exit nodes
2026-04-01 10:21:35.000 [INFO] Websocket Connected
2026-04-01 10:21:36.000 [INFO] Tunnel: OLM registered
2026-04-01 10:21:44.000 [INFO] Disconnecting...
2026-04-01 10:21:44.000 [INFO] Disconnecting tunnel
2026-04-01 10:21:44.000 [INFO] Tunnel: StopTunnel called
2026-04-01 10:21:44.000 [INFO] Tunnel state changed: stopping
2026-04-01 10:21:44.000 [INFO] Tunnel service: Service stopping
2026-04-01 10:21:44.000 [INFO] Stopping api server
2026-04-01 10:21:44.000 [INFO] Stopping tunnel process
2026-04-01 10:21:44.000 [INFO] Tunnel process context cancelled, cleaning up
2026-04-01 10:21:44.000 [INFO] Tunnel: State transitioned to stopped
2026-04-01 10:21:44.000 [INFO] Stopped OLM status polling
2026-04-01 10:21:44.000 [INFO] Disconnected tunnel
2026-04-01 10:21:44.000 [INFO] Status polling stopped
2026-04-01 10:21:44.000 [INFO] Tunnel state changed: stopped
2026-04-01 10:21:44.000 [INFO] Tunnel state changed: stopped
2026-04-01 10:21:44.000 [INFO] OLM tunnel stopped
2026-04-01 10:21:44.000 [INFO] Hole punch manager stopped
2026-04-01 10:21:44.000 [INFO] Released shared UDP bind
2026-04-01 10:21:44.000 [INFO] Olm service stopped
2026-04-01 10:21:44.000 [INFO] Cleared all network settings
2026-04-01 10:21:44.000 [INFO] Tunnel process stopped
2026-04-01 10:22:19.000 [INFO] OLM credentials verified successfully
2026-04-01 10:22:19.000 [INFO] Connecting tunnel with config: Name=olm, Endpoint=https://pangolin.xxx.com
2026-04-01 10:22:19.000 [INFO] Tunnel: StartTunnel called
2026-04-01 10:22:19.000 [INFO] Tunnel: Starting tunnel with config
2026-04-01 10:22:19.000 [INFO] Tunnel state changed: registering
2026-04-01 10:22:19.000 [INFO] Pangolin logging initialized - log file: C:\ProgramData\Pangolin\logs\pangolin.log, log level: info
2026-04-01 10:22:19.000 [INFO] Pangolin version 0.8.1 starting
2026-04-01 10:22:19.000 [INFO] Starting as tunnel service with config: C:\ProgramData\Pangolin\Tunnels\olm.json
2026-04-01 10:22:19.000 [INFO] Tunnel service: Starting with config
2026-04-01 10:22:19.000 [INFO] Tunnel service: Running as Windows service
2026-04-01 10:22:19.000 [INFO] Tunnel service: Service starting
2026-04-01 10:22:19.000 [INFO] Tunnel state changed: registering
2026-04-01 10:22:19.000 [INFO] Starting status polling
2026-04-01 10:22:19.000 [INFO] Started OLM status polling (every 1 second)
2026-04-01 10:22:20.000 [ERROR] Failed to poll OLM status: failed to connect to OLM: Get "http://localhost/status": open \.\pipe\pangolin-olm: The system cannot find the file specified.
2026-04-01 10:22:20.000 [INFO] Starting HTTP server on socket \.\pipe\pangolin-olm
2026-04-01 10:22:20.000 [INFO] Starting OLM tunnel...
2026-04-01 10:22:20.000 [INFO] Created shared UDP socket on port 50254 (refcount: 2)
2026-04-01 10:22:21.000 [INFO] Starting hole punch for 1 exit nodes
2026-04-01 10:22:21.000 [INFO] Websocket Connected
2026-04-01 10:22:21.000 [INFO] Tunnel: OLM registered
2026-04-01 10:22:22.000 [INFO] The tunnel IP is: 100.90.128.5/24
2026-04-01 10:22:22.000 [INFO] Set IPv4 addresses: [100.90.128.5], subnet masks: [255.255.255.0]
2026-04-01 10:22:22.000 [INFO] Set MTU: 1280
2026-04-01 10:22:22.000 [INFO] Configuring Windows interface: Pangolin
2026-04-01 10:22:22.000 [INFO] Adding IP address 100.90.128.5/24 to interface Pangolin
2026-04-01 10:22:22.000 [INFO] Added IPv4 included route: {DestinationAddress:100.96.128.0 SubnetMask:255.255.255.0 GatewayAddress: IsDefault:false}
2026-04-01 10:22:22.000 [INFO] Adding route to 100.96.128.0/24 via interface Pangolin
2026-04-01 10:22:22.000 [INFO] Added route for remote subnet: 100.96.128.0/24
2026-04-01 10:22:22.000 [INFO] Added IPv4 included route: {DestinationAddress:192.168.178.59 SubnetMask:255.255.255.255 GatewayAddress: IsDefault:false}
2026-04-01 10:22:22.000 [INFO] Adding route to 192.168.178.59/32 via interface Pangolin
2026-04-01 10:22:22.000 [INFO] Added route for remote subnet: 192.168.178.59/32
2026-04-01 10:22:22.000 [INFO] Added IPv4 included route: {DestinationAddress:192.168.178.1 SubnetMask:255.255.255.255 GatewayAddress: IsDefault:false}
2026-04-01 10:22:22.000 [INFO] Adding route to 192.168.178.1/32 via interface Pangolin
2026-04-01 10:22:22.000 [INFO] Added route for remote subnet: 192.168.178.1/32
2026-04-01 10:22:22.000 [INFO] Added IPv4 included route: {DestinationAddress:192.168.178.10 SubnetMask:255.255.255.255 GatewayAddress: IsDefault:false}
2026-04-01 10:22:22.000 [INFO] Adding route to 192.168.178.10/32 via interface Pangolin
2026-04-01 10:22:22.000 [INFO] Added route for remote subnet: 192.168.178.10/32
2026-04-01 10:22:22.000 [INFO] Added IPv4 included route: {DestinationAddress:192.168.178.11 SubnetMask:255.255.255.255 GatewayAddress: IsDefault:false}
2026-04-01 10:22:22.000 [INFO] Adding route to 192.168.178.11/32 via interface Pangolin
2026-04-01 10:22:22.000 [INFO] Added route for remote subnet: 192.168.178.11/32
2026-04-01 10:22:22.000 [INFO] Added IPv4 included route: {DestinationAddress:192.168.178.250 SubnetMask:255.255.255.255 GatewayAddress: IsDefault:false}
2026-04-01 10:22:22.000 [INFO] Adding route to 192.168.178.250/32 via interface Pangolin
2026-04-01 10:22:22.000 [INFO] Added route for remote subnet: 192.168.178.250/32
2026-04-01 10:22:22.000 [INFO] Started monitoring for site 2 at 100.90.128.0:56224
2026-04-01 10:22:22.000 [INFO] Configured peer NnIQXUximKdkNWzjGpN069PGReQ9frBTpyvGLVvUkCE=
2026-04-01 10:22:22.000 [INFO] Starting rapid holepunch test for site 2 at 194.208.132.65:56223 (max 5 attempts, 400ms timeout each)
2026-04-01 10:22:22.000 [INFO] Added IPv4 included route: {DestinationAddress:192.168.2.113 SubnetMask:255.255.255.255 GatewayAddress: IsDefault:false}
2026-04-01 10:22:22.000 [INFO] Adding route to 192.168.2.113/32 via interface Pangolin
2026-04-01 10:22:22.000 [INFO] Added route for remote subnet: 192.168.2.113/32
2026-04-01 10:22:22.000 [INFO] Added IPv4 included route: {DestinationAddress:192.168.2.22 SubnetMask:255.255.255.255 GatewayAddress: IsDefault:false}
2026-04-01 10:22:22.000 [INFO] Adding route to 192.168.2.22/32 via interface Pangolin
2026-04-01 10:22:22.000 [INFO] Added route for remote subnet: 192.168.2.22/32
2026-04-01 10:22:22.000 [INFO] Added IPv4 included route: {DestinationAddress:192.168.66.203 SubnetMask:255.255.255.255 GatewayAddress: IsDefault:false}
2026-04-01 10:22:22.000 [INFO] Adding route to 192.168.66.203/32 via interface Pangolin
2026-04-01 10:22:22.000 [INFO] Added route for remote subnet: 192.168.66.203/32
2026-04-01 10:22:22.000 [INFO] Added IPv4 included route: {DestinationAddress:192.168.2.111 SubnetMask:255.255.255.255 GatewayAddress: IsDefault:false}
2026-04-01 10:22:22.000 [INFO] Adding route to 192.168.2.111/32 via interface Pangolin
2026-04-01 10:22:22.000 [INFO] Added route for remote subnet: 192.168.2.111/32
2026-04-01 10:22:22.000 [INFO] Added IPv4 included route: {DestinationAddress:192.168.2.103 SubnetMask:255.255.255.255 GatewayAddress: IsDefault:false}
2026-04-01 10:22:22.000 [INFO] Adding route to 192.168.2.103/32 via interface Pangolin
2026-04-01 10:22:22.000 [INFO] Added route for remote subnet: 192.168.2.103/32
2026-04-01 10:22:22.000 [INFO] Added IPv4 included route: {DestinationAddress:192.168.2.30 SubnetMask:255.255.255.255 GatewayAddress: IsDefault:false}
2026-04-01 10:22:22.000 [INFO] Adding route to 192.168.2.30/32 via interface Pangolin
2026-04-01 10:22:22.000 [INFO] Added route for remote subnet: 192.168.2.30/32
2026-04-01 10:22:22.000 [INFO] Started monitoring for site 3 at 100.90.128.1:64597
2026-04-01 10:22:22.000 [INFO] Configured peer gHuUX0pFzOkbnGYcD9+eqbn/6SpO+UlQV7IdEjY5UBA=
2026-04-01 10:22:22.000 [INFO] Starting rapid holepunch test for site 3 at 213.47.199.78:64596 (max 5 attempts, 400ms timeout each)
2026-04-01 10:22:22.000 [INFO] Added IPv4 included route: {DestinationAddress:192.168.10.15 SubnetMask:255.255.255.255 GatewayAddress: IsDefault:false}
2026-04-01 10:22:22.000 [INFO] Adding route to 192.168.10.15/32 via interface Pangolin
2026-04-01 10:22:22.000 [INFO] Added route for remote subnet: 192.168.10.15/32
2026-04-01 10:22:22.000 [INFO] Started monitoring for site 4 at 100.90.128.3:61616
2026-04-01 10:22:22.000 [INFO] Configured peer L6D3Sypja+hXgtDRK6IvxIMcEk4xdwFoUAk0R3m1qBw=
2026-04-01 10:22:22.000 [INFO] Started monitoring peer 2
2026-04-01 10:22:22.000 [INFO] Started monitoring peer 3
2026-04-01 10:22:22.000 [INFO] Started monitoring peer 4
2026-04-01 10:22:22.000 [INFO] Started holepunch connection monitor
2026-04-01 10:22:22.000 [INFO] DNS proxy started on 100.96.128.1:53 (tunnelDNS=false)
2026-04-01 10:22:22.000 [INFO] WireGuard device created.
2026-04-01 10:22:22.000 [INFO] Starting rapid holepunch test for site 4 at 212.186.39.53:61615 (max 5 attempts, 400ms timeout each)
2026-04-01 10:22:22.000 [INFO] Tunnel: OLM connected
2026-04-01 10:22:22.000 [INFO] Tunnel state changed: running
2026-04-01 10:22:24.000 [WARN] Rapid test: site 2 holepunch FAILED after 5 attempts, will relay
2026-04-01 10:22:24.000 [INFO] Rapid test failed for site 2, requesting relay
2026-04-01 10:22:24.000 [INFO] Sent relay message for site 2 (chain 4f9baf7a50ef32c0)
2026-04-01 10:22:24.000 [INFO] Cancelled all relay senders
2026-04-01 10:22:24.000 [INFO] Adjusted peer 2 to point to relay!
2026-04-01 10:22:24.000 [WARN] Rapid test: site 3 holepunch FAILED after 5 attempts, will relay
2026-04-01 10:22:24.000 [INFO] Rapid test failed for site 3, requesting relay
2026-04-01 10:22:24.000 [INFO] Sent relay message for site 3 (chain 30c40b7dfc37c171)
2026-04-01 10:22:25.000 [INFO] Cancelled all relay senders
2026-04-01 10:22:25.000 [INFO] Adjusted peer 3 to point to relay!
2026-04-01 10:22:25.000 [WARN] WireGuard connection to site 4 is DISCONNECTED
2026-04-01 10:22:25.000 [WARN] WireGuard connection to site 3 is DISCONNECTED
2026-04-01 10:22:25.000 [WARN] WireGuard connection to site 2 is DISCONNECTED
2026-04-01 10:22:25.000 [WARN] Rapid test: site 4 holepunch FAILED after 5 attempts, will relay