github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-07-16 06:08:33 -05:00
Code Issues 1.6k Packages Projects Releases 79 Wiki Activity

[GH-ISSUE #2692] Bug Report: Olm Client Forcibly Disconnected When Newt Site Connector Runs on the Same Machine #19296

New Issue
Open
opened 2026-05-21 20:03:25 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-05-21 20:03:25 -05:00
Owner
Copy Link

Originally created by @ylorn on GitHub (Mar 23, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2692

Describe the Bug

Actual Behavior

Pangolin immediately disconnects the Olm client after connecting. Server logs show:

[info]: Adding peer /1vFcD/oR4wbkxRPLhtuhGjAeMxb2Tqv2jRE0pOkvzY= to site 3 with endpoint 73.202.58.13:49302
[info]: Added peer /1vFcD/oR4wbkxRPLhtuhGjAeMxb2Tqv2jRE0pOkvzY= to newt 7ql49kmr3m2plxl
[info]: Disconnecting client ID: nez0ypyegk8km50 (1 connection(s))
[info]: All connections removed for OLM ID: nez0ypyegk8km50
[info]: Client disconnected - OLM ID: nez0ypyegk8km50

The Olm client reconnects in a loop, getting disconnected each time within seconds.

Root Cause Analysis

When the Olm client registers, Pangolin's handleOlmServerPeerAddMessage adds it as a WireGuard peer to the Newt site connector (newt 7ql49kmr3m2plxl). Immediately after, Pangolin disconnects the Olm websocket session, seemingly treating the Olm client as "handed off" to the Newt site.

This appears to be because both the Newt connector and the Olm client share the same public IP address (73.202.58.13), causing Pangolin to associate the Olm client with the existing Newt site on that IP and then disconnect the Olm session.

Symptoms

  • Olm client connects but immediately disconnects in a loop
  • Alias DNS records are never loaded into Olm's local DNS server (100.96.128.1 returns NXDOMAIN for all aliases)
  • Private resource routes are never pushed to the Olm client
  • dig @100.96.128.1 resource.alias.docker returns NXDOMAIN with recursive flags instead of authoritative answer:
;; flags: qr rd ra ad   ← recursive, not authoritative — Pangolin is forwarding upstream
;; SERVER: 100.96.128.1#53

vs. a working client which returns an authoritative answer:

;; flags: qr aa rd      ← authoritative — Pangolin serves alias locally
;; ANSWER SECTION:
resource.alias.docker.  300  IN  A  100.96.128.10

Workaround

Stop the Newt site connector on the machine running the Olm client. The Olm client then connects and functions correctly. However this means you cannot expose local services via a Newt site and access remote private resources via Olm on the same machine simultaneously.

Impact

This is a significant limitation for home lab / self-hosted users who want to:

  1. Expose local services publicly via a Newt site connector
  2. Access remote private resources via the Olm client

Both are common use cases on the same machine (e.g. a Mac Studio acting as both a local service host and a client for accessing a remote Docker server).

Suggested Fix

In handleOlmServerPeerAddMessage, the Olm websocket session should not be disconnected after adding the WireGuard peer to a site. The Olm client role (receiving routes and aliases) is independent of the WireGuard peer assignment to a site connector. These two operations should be decoupled.

Environment

  • OS Type & Version: Arch Linux(Linux 6.19.9-arch1-1) & macOS Tahoe 26.3.1 (a)
  • Pangolin Version: v1.16.2
  • Gerbil Version: v1.10.3
  • Traefik Version: v3.6.11
  • Newt Version: v1.10.3 (macOS)
  • Olm Version: v0.6.1 (macOS)

To Reproduce

Steps to Reproduce

  1. Set up a Pangolin server with a Newt site (e.g. "Mac Studio 2025")

  2. Run the Newt connector as a Docker container on Mac Studio:

    services:
  newt:
    image: fosrl/newt:latest
    command:
      - --id
      - <site-id>
      - --secret
      - <site-secret>
      - --endpoint
      - https://pangolin.example.com

  3. Create a Machine Client or User Client in Pangolin dashboard

  4. Install and connect Pangolin Olm GUI app on the same Mac Studio machine using the client credentials

  5. Observe Pangolin server logs

Expected Behavior

Expected Behavior

Both the Newt site connector and the Olm client should operate independently on the same machine. The Olm client should remain connected and receive alias DNS records and private resource routes.

Originally created by @ylorn on GitHub (Mar 23, 2026). Original GitHub issue: https://github.com/fosrl/pangolin/issues/2692 ### Describe the Bug ## Actual Behavior Pangolin immediately disconnects the Olm client after connecting. Server logs show: ``` [info]: Adding peer /1vFcD/oR4wbkxRPLhtuhGjAeMxb2Tqv2jRE0pOkvzY= to site 3 with endpoint 73.202.58.13:49302 [info]: Added peer /1vFcD/oR4wbkxRPLhtuhGjAeMxb2Tqv2jRE0pOkvzY= to newt 7ql49kmr3m2plxl [info]: Disconnecting client ID: nez0ypyegk8km50 (1 connection(s)) [info]: All connections removed for OLM ID: nez0ypyegk8km50 [info]: Client disconnected - OLM ID: nez0ypyegk8km50 ``` The Olm client reconnects in a loop, getting disconnected each time within seconds. ## Root Cause Analysis When the Olm client registers, Pangolin's `handleOlmServerPeerAddMessage` adds it as a WireGuard peer to the Newt site connector (`newt 7ql49kmr3m2plxl`). Immediately after, Pangolin disconnects the Olm websocket session, seemingly treating the Olm client as "handed off" to the Newt site. This appears to be because both the Newt connector and the Olm client share the same public IP address (`73.202.58.13`), causing Pangolin to associate the Olm client with the existing Newt site on that IP and then disconnect the Olm session. ## Symptoms - Olm client connects but immediately disconnects in a loop - Alias DNS records are never loaded into Olm's local DNS server (`100.96.128.1` returns NXDOMAIN for all aliases) - Private resource routes are never pushed to the Olm client - `dig @100.96.128.1 resource.alias.docker` returns NXDOMAIN with recursive flags instead of authoritative answer: ``` ;; flags: qr rd ra ad ← recursive, not authoritative — Pangolin is forwarding upstream ;; SERVER: 100.96.128.1#53 ``` vs. a working client which returns an authoritative answer: ``` ;; flags: qr aa rd ← authoritative — Pangolin serves alias locally ;; ANSWER SECTION: resource.alias.docker. 300 IN A 100.96.128.10 ``` ## Workaround Stop the Newt site connector on the machine running the Olm client. The Olm client then connects and functions correctly. However this means you cannot expose local services via a Newt site **and** access remote private resources via Olm on the same machine simultaneously. ## Impact This is a significant limitation for home lab / self-hosted users who want to: 1. Expose local services publicly via a Newt site connector 2. Access remote private resources via the Olm client Both are common use cases on the same machine (e.g. a Mac Studio acting as both a local service host and a client for accessing a remote Docker server). ## Suggested Fix In `handleOlmServerPeerAddMessage`, the Olm websocket session should not be disconnected after adding the WireGuard peer to a site. The Olm client role (receiving routes and aliases) is independent of the WireGuard peer assignment to a site connector. These two operations should be decoupled. ### Environment - OS Type & Version: Arch Linux(Linux 6.19.9-arch1-1) & macOS Tahoe 26.3.1 (a) - Pangolin Version: `v1.16.2` - Gerbil Version: `v1.10.3` - Traefik Version: `v3.6.11` - Newt Version: `v1.10.3` (macOS) - Olm Version: `v0.6.1` (macOS) ### To Reproduce ## Steps to Reproduce 1. Set up a Pangolin server with a Newt site (e.g. "Mac Studio 2025") 2. Run the Newt connector as a Docker container on Mac Studio: ```yaml services: newt: image: fosrl/newt:latest command: - --id - <site-id> - --secret - <site-secret> - --endpoint - https://pangolin.example.com ``` 3. Create a Machine Client or User Client in Pangolin dashboard 4. Install and connect Pangolin Olm GUI app on the **same Mac Studio machine** using the client credentials 5. Observe Pangolin server logs ### Expected Behavior ## Expected Behavior Both the Newt site connector and the Olm client should operate independently on the same machine. The Olm client should remain connected and receive alias DNS records and private resource routes.
GiteaMirror added the stale label 2026-05-21 20:03:25 -05:00
GiteaMirror commented 2026-05-21 20:03:32 -05:00
Author
Owner
Copy Link

@twocoolbeans commented on GitHub (Apr 1, 2026):

Similar issue, although it is not immediate. Both Olm client and New start as services on Windows. Eventually Olm client disconnects. Currently testing if Olm client will stay connected without Newt service running at all. Olm CLI v1.4.4 on Windows 10 and 11 machines.

<!-- gh-comment-id:4173121614 --> @twocoolbeans commented on GitHub (Apr 1, 2026): Similar issue, although it is not immediate. Both Olm client and New start as services on Windows. Eventually Olm client disconnects. Currently testing if Olm client will stay connected without Newt service running at all. Olm CLI v1.4.4 on Windows 10 and 11 machines.
GiteaMirror commented 2026-05-21 20:03:33 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 16, 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.

<!-- gh-comment-id:4256614378 --> @github-actions[bot] commented on GitHub (Apr 16, 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.
GiteaMirror commented 2026-05-21 20:03:35 -05:00
Author
Owner
Copy Link

@AstralDestiny commented on GitHub (Apr 18, 2026):

Will try in a bit, posting so I remember to update post.

Ran into a different issue which resulted in a bug that should be fixed soon.

Though might be an issue as both operate in the same range and most os's don't like overlapping routes.

<!-- gh-comment-id:4272454596 --> @AstralDestiny commented on GitHub (Apr 18, 2026): Will try in a bit, posting so I remember to update post. Ran into a different issue which resulted in a bug that should be fixed soon. Though might be an issue as both operate in the same range and most os's don't like overlapping routes.
GiteaMirror commented 2026-05-21 20:03:36 -05:00
Author
Owner
Copy Link

@PinkWaters00 commented on GitHub (Apr 29, 2026):

I have experienced this issue the other way around as well. created a site for the actual pangolin server on the vps, then installed the newt connector on pangolin server, then created a private resource on the pangolin server, and added my homelab host as a machine client and installed pangolin OLM. same issue.
the similar way the OP did it that also failed same way was: creating a private resource for newt connected site in my home lab (newt client was on a container that has access to the whole subnet), created a private resource on one of the containers i have on that subnet, created a machine client for pangolin and installed the pangolin OLM on pangolin server. Same issue.

<!-- gh-comment-id:4343653655 --> @PinkWaters00 commented on GitHub (Apr 29, 2026): I have experienced this issue the other way around as well. created a site for the actual pangolin server on the vps, then installed the newt connector on pangolin server, then created a private resource on the pangolin server, and added my homelab host as a machine client and installed pangolin OLM. same issue. the similar way the OP did it that also failed same way was: creating a private resource for newt connected site in my home lab (newt client was on a container that has access to the whole subnet), created a private resource on one of the containers i have on that subnet, created a machine client for pangolin and installed the pangolin OLM on pangolin server. Same issue.
GiteaMirror commented 2026-05-21 20:03:38 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (May 14, 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.

<!-- gh-comment-id:4446391760 --> @github-actions[bot] commented on GitHub (May 14, 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
api
authentication
bug
config
dependencies
docker
documentation
enhancement
good first issue
help wanted
Improvement
Look Into
needs investigating
networking
new feature
non-critical bug
potential bug
pull-request
Mirrored from GitHub Pull Request
 question
reverse proxy
Security
stale
ui
wontfix
No Label stale
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/pangolin#19296
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?