[GH-ISSUE #2901] Adding a private resource breaks hole-punch for already-connected clients; cache never repopulates #15149

Open
opened 2026-05-16 03:27:54 -05:00 by GiteaMirror · 1 comment
Owner

Originally created by @andrewixl on GitHub (Apr 24, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2901

Describe the Bug

Creating any private resource (siteResources) and once created, if an Olm client is registered (connected) puts the client into a permanent "last hole punch is too old" loop. The client never reaches connected state, and no amount of reconnecting, restarting, or deleting/recreating the resource restores it.

Environment

  • Ubuntu 24.04
  • Pangolin: ee-1.17.1
  • Gerbil: 1.31
  • Traefik: 3.6
  • Newt: 1.11.0
  • Olm Windows: 0.9.0

To Reproduce

Reproduction:

  1. No private resources.
  2. Create a new client. Pair it with a Windows Pangolin client. Confirm connected.
  3. Add ONE private resource pointing at any LAN IP.
  4. Immediately: logs show "handleOlmServerPeerAddMessage: No endpoint found for client N"
  5. Client enters permanent "Client last hole punch is too old" loop
  6. clientSitesAssociationsCache rows for that client have endpoint=NULL, publicKey=NULL
  7. clients.lastHolePunch remains NULL
  8. Deleting the resource restored the client to connectivity.

Expected Behavior

Expected behavior should allow the client to register and connect to the private resources.

Originally created by @andrewixl on GitHub (Apr 24, 2026). Original GitHub issue: https://github.com/fosrl/pangolin/issues/2901 ### Describe the Bug Creating any private resource (siteResources) and once created, if an Olm client is registered (connected) puts the client into a permanent "last hole punch is too old" loop. The client never reaches connected state, and no amount of reconnecting, restarting, or deleting/recreating the resource restores it. ### Environment - Ubuntu 24.04 - Pangolin: ee-1.17.1 - Gerbil: 1.31 - Traefik: 3.6 - Newt: 1.11.0 - Olm Windows: 0.9.0 ### To Reproduce Reproduction: 1. No private resources. 2. Create a new client. Pair it with a Windows Pangolin client. Confirm connected. 3. Add ONE private resource pointing at any LAN IP. 4. Immediately: logs show "handleOlmServerPeerAddMessage: No endpoint found for client N" 5. Client enters permanent "Client last hole punch is too old" loop 6. clientSitesAssociationsCache rows for that client have endpoint=NULL, publicKey=NULL 7. clients.lastHolePunch remains NULL 8. Deleting the resource restored the client to connectivity. ### Expected Behavior Expected behavior should allow the client to register and connect to the private resources.
Author
Owner

@Byolock commented on GitHub (May 2, 2026):

From my personal experience and some other comments here, that could be a DNS Issue. It looks like you are using windows as a client? Try adding

192.168.1.10 pangolin.yourdomain.com

to C:\Windows\System32\drivers\etc\hosts for a quick and easy test. Replace the IP and domain to match your setup.

If it works after this you have a DNS issue. I've read reports that blocking outbound DNS for clients in your firewall does this. I just experienced it also happens when you rely on your local DNS Server in a Split DNS Setup. Every device in my lan uses an adguard dns server and resolves my "pangolin.mydomain.com" record correctly to my lan address of the pangolin installation. But using public DNS "pangolin.mydomain.com" resolves to a different address. I needed to put a A-record for "pangolin.mydomain.com" to my local address in the public DNS and then it worked, even though I was only testing everything inside my lan.

<!-- gh-comment-id:4363217046 --> @Byolock commented on GitHub (May 2, 2026): From my personal experience and some other comments here, that could be a DNS Issue. It looks like you are using windows as a client? Try adding `192.168.1.10 pangolin.yourdomain.com` to C:\Windows\System32\drivers\etc\hosts for a quick and easy test. Replace the IP and domain to match your setup. If it works after this you have a DNS issue. I've read reports that blocking outbound DNS for clients in your firewall does this. I just experienced it also happens when you rely on your local DNS Server in a Split DNS Setup. Every device in my lan uses an adguard dns server and resolves my "pangolin.mydomain.com" record correctly to my lan address of the pangolin installation. But using public DNS "pangolin.mydomain.com" resolves to a different address. I needed to put a A-record for "pangolin.mydomain.com" to my local address in the public DNS and then it worked, even though I was only testing everything inside my lan.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/pangolin#15149