A Newt site that previously worked stopped carrying public-resource traffic. Pangolin still showed the site online / reconnected, but resources behind that Newt site returned 502.
The site had historical non-zero data in/out counters, so this was not a fresh setup that never worked. The same backend resources were restored immediately by moving them from the Newt site to a local Pangolin site on the VPS, reaching the same backend IPs/ports over an existing NetBird route.
I do not have a clean minimal reproducer yet. The failure was observed in this sequence:
Run Pangolin/Gerbil/Traefik on a VPS with a Newt site connected from a home network behind CGNAT.
Use the Newt site successfully for public resources for some time; the site had non-zero data in/out counters.
After the failure starts, keep the same Newt site connected. Pangolin still shows it online / reconnected.
Access public resources routed through that Newt site.
The resources return 502, while Gerbil wg0 shows no useful RX / handshake traffic.
Additional checks:
The issue reproduced with a separate bare-metal Newt test on a raspberry pi device in the same subnet.
A plain UDP probe to Gerbil 51820 reached the VPS.
Expected Behavior
If the Newt site is online/reconnected, the WireGuard data plane should recover or report a clear failed state. Previously working public resources behind the Newt site should not remain stuck at 502 with no useful wg0 RX/handshake traffic.
Originally created by @yusuf-madkour on GitHub (May 17, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/3096
### Describe the Bug
A Newt site that previously worked stopped carrying public-resource traffic. Pangolin still showed the site online / reconnected, but resources behind that Newt site returned 502.
The site had historical non-zero data in/out counters, so this was not a fresh setup that never worked. The same backend resources were restored immediately by moving them from the Newt site to a local Pangolin site on the VPS, reaching the same backend IPs/ports over an existing NetBird route.
### Environment
- Pangolin/Gerbil/Traefik host: Ubuntu 24.04.3 LTS, aarch64, Oracle VPS
- Original Newt host: Proxmox VE 9.1.4, unprivileged Ubuntu LXC 100, amd64
- Reproduction Newt host: Debian 13.2 (trixie), aarch64, bare-metal `madpi`
- Pangolin Version: 1.18.4
- Gerbil Version: 1.4.0
- Traefik Version: 3.5
- Newt Version: 1.12.5
### To Reproduce
I do not have a clean minimal reproducer yet. The failure was observed in this sequence:
1. Run Pangolin/Gerbil/Traefik on a VPS with a Newt site connected from a home network behind CGNAT.
2. Use the Newt site successfully for public resources for some time; the site had non-zero data in/out counters.
3. After the failure starts, keep the same Newt site connected. Pangolin still shows it online / reconnected.
4. Access public resources routed through that Newt site.
5. The resources return 502, while Gerbil `wg0` shows no useful RX / handshake traffic.
Additional checks:
- The issue reproduced with a separate bare-metal Newt test on a raspberry pi device in the same subnet.
- A plain UDP probe to Gerbil `51820` reached the VPS.
### Expected Behavior
If the Newt site is online/reconnected, the WireGuard data plane should recover or report a clear failed state. Previously working public resources behind the Newt site should not remain stuck at 502 with no useful `wg0` RX/handshake traffic.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @yusuf-madkour on GitHub (May 17, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/3096
Describe the Bug
A Newt site that previously worked stopped carrying public-resource traffic. Pangolin still showed the site online / reconnected, but resources behind that Newt site returned 502.
The site had historical non-zero data in/out counters, so this was not a fresh setup that never worked. The same backend resources were restored immediately by moving them from the Newt site to a local Pangolin site on the VPS, reaching the same backend IPs/ports over an existing NetBird route.
Environment
madpiTo Reproduce
I do not have a clean minimal reproducer yet. The failure was observed in this sequence:
wg0shows no useful RX / handshake traffic.Additional checks:
51820reached the VPS.Expected Behavior
If the Newt site is online/reconnected, the WireGuard data plane should recover or report a clear failed state. Previously working public resources behind the Newt site should not remain stuck at 502 with no useful
wg0RX/handshake traffic.