Bug Report: Olm Client Forcibly Disconnected When Newt Site Connector Runs on the Same Machine #81

New Issue

MrUnknownDE · 2026-04-05T17:00:49+02:00

MrUnknownDE commented

2026-04-05 17:00:49 +02:00

Originally created by @ylorn on 3/23/2026

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:

Expose local services publicly via a Newt site connector
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

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

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

Create a Machine Client or User Client in Pangolin dashboard
Install and connect Pangolin Olm GUI app on the same Mac Studio machine using the client credentials
Observe Pangolin server logs

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 3/23/2026* ### 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.

Sign in to join this conversation.

Branches Tags

main

dev

dependabot/npm_and_yarn/dev-minor-updates-b4e5d6b9c5

revert-2766-feature/systemd-install-instructions

dependabot/npm_and_yarn/prod-patch-updates-05702d39f2

dependabot/npm_and_yarn/next-16.2.1

dependabot/npm_and_yarn/recharts-3.8.1

alerting-rules

private-site-ha

dependabot/docker/docker/library/node-25-slim

ssh

delete-account

msg-delivery

org-only-idp

cicd

patch

site-targets-auto-login

No Label

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/pangolin#81