Repository navigation
Olm still reports relay after packets start going directly to Newt #141
Description
Describe the Bug
I have two Newt sites on the same private network as my Mac. They use host networking and fixed UDP ports. The Mac is on a separate routed subnet and can reach both Newt addresses directly.
After fully restarting the Pangolin macOS client, both sites showed:
{
"endpoint": "pangolin.example.com",
"isRelay": true,
"isLocal": false
}About a minute later, tcpdump showed the Pangolin PacketTunnel process sending and receiving packets directly with one of the Newt LAN addresses:
192.168.10.11.55000 > 192.168.30.16.52143: UDP, length 128
192.168.30.16.52143 > 192.168.10.11.55000: UDP, length 96
lsof confirmed that source port 55000 belonged to the PacketTunnel process. The 25-byte local test request and reply also succeeded for both Newt addresses.
The status still showed isRelay: true and isLocal: false. lastSeen stopped updating for those sites at the time they changed to relay, while other peers continued updating.
I found #72, but I do not have an overlapping private-resource route for either Newt address.
Am I misunderstanding what isRelay and isLocal are intended to report, or should they change when the UDP socket starts using the local Newt address?
Environment
- OS Type & Version: macOS 26.6, build 25G72
- Pangolin Version: 1.22.0
- Edition: Enterprise
- Gerbil Version: 1.5.0
- Traefik Version: 3.7
- Newt Version: 1.16.0
- Client Version: Pangolin macOS 0.11.0
To Reproduce
- Run a Newt site with host networking and a fixed UDP port.
- Make the Newt LAN address reachable from the client.
- Fully restart the Pangolin macOS client.
- Check
/statusthrough/var/run/olm.sock. - Capture packets between the client and Newt LAN addresses.
Expected Behavior
I expected the status to show the local Newt address with isLocal: true once packets started going directly to it. If these fields describe something other than the address actually in use, clarification would be helpful.
Activity
AstralDestiny commentedon Aug 31, 2026
You can reach your newt locally and there's no vlan seperation with rules to stop you? And is the tunnel ip the cgnat range and not something overlapping a local range? (it shouldn't be a local range for the tunnel)
Can you try to use an ipvlan in l2 mode for those newt clients by chance? I've not had luck on host networking but just want to rule it out.
rinseaid commentedon Sep 1, 2026
There is VLAN separation. Explicit UDP rules allow the client VLAN to reach each Newt’s fixed port, with stateful return traffic.
The tunnel ranges are RFC1918 rather than CGNAT:
They do not overlap my LAN, pod, or service networks.
I tested ipvlan L2 and fully restarted the macOS client. The issue still reproduces.
tcpdumpshowed the local probes succeeding against both Newts, followed by sustained bidirectional UDP traffic directly to both ipvlan endpoints./statuscontinued to reportisRelay: true,isLocal: false, andholepunchConnected: false. ThelastSeenvalues stopped updating when direct traffic began and remained frozen through the rest of the capture.For comparison, Linux Olm 1.9.0 in an OrbStack container on the same Mac selected both ipvlan endpoints directly and correctly reported
isRelay: falseandisLocal: true.oschwartz10612 commentedon Sep 1, 2026
@rinseaid would 77C6 you be able to confirm that the wireguard connections are actually using the local path so I can narrow this down to the reporting being wrong vs it not actually connecting locally? Maybe you could do a ipfer or simple ping and if the latency is not great with it being local then we know it is still actually relaying. If this is the case would you be able to capture some --log-level debug logs to review?
rinseaid commentedon Sep 2, 2026
Hey @oschwartz10612 yep of course.
I restarted with debug logging on, plus
/statuspolled every 10 s and a packet capture on the LAN interface. Reproduced straight away.Startup, trimmed to the lines that mention the sites, with repeats collapsed into a count:
Sites 1 and 2 get one "Started monitoring" line each. Sites 4 and 5 get 35 and 14, all within 30 ms. I don't know whether that's expected.
Packet capture over the 90 seconds after the restart: 3765 WireGuard packets went direct to the two local endpoints and 65 to the Pangolin server.
First
/statuspoll after startup, 19:10:59:Ten seconds later, and unchanged for the 1h49m since:
Those two
rttvalues are the same numbers as the CONNECTED lines at 19:10:59, andlastSeenhasn't moved off that second either. I polled/statusevery 10 s for nearly two hours, 666 samples 🙈 , and after 19:11:09 not one field on either site changed. Sites 1 and 2 are the other way round,lastSeenupdates every couple of seconds andrttstays 0.