github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-05-06 12:55:03 -05:00
Code Issues 478 Packages Projects Releases 72 Wiki Activity

Newt tunnel stopped working for me #725

New Issue
Closed
opened 2025-11-13 12:09:17 -06:00 by GiteaMirror · 10 comments
GiteaMirror commented 2025-11-13 12:09:17 -06:00
Owner
Copy Link

Originally created by @johnsturgeon on GitHub (Oct 18, 2025).

Describe the Bug

My newt tunnel stopped working, I set up a second one and that doesn't work either, so no I have no connected / working 'site'. since upgrading to 1.11

Environment

  • OS Type & Version: (e.g., Ubuntu 22.04)
  • debian
  • Pangolin Version: 1.11 (ee)
  • Gerbil Version:
  • Traefik Version:
  • Newt Version: 1.5.2
  • Olm Version: (if applicable)

Docker compose:

name: pangolin
services:
  pangolin:
    image: docker.io/fosrl/pangolin:ee-latest
    container_name: pangolin
    restart: unless-stopped
    volumes:
      - ./config:/app/config
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3001/api/v1/"]
      interval: "10s"
      timeout: "10s"
      retries: 15

  gerbil:
    image: docker.io/fosrl/gerbil:latest
    container_name: gerbil
    restart: unless-stopped
    depends_on:
      pangolin:
        condition: service_healthy
    command:
      - --reachableAt=http://gerbil:3003
      - --generateAndSaveKeyTo=/var/config/key
      - --remoteConfig=http://pangolin:3001/api/v1/gerbil/get-config
      - --reportBandwidthTo=http://pangolin:3001/api/v1/gerbil/receive-bandwidth
    volumes:
      - ./config/:/var/config
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    ports:
      - 51820:51820/udp
      - 21820:21820/udp
      - 443:443 # Port for traefik because of the network_mode
      - 80:80 # Port for traefik because of the network_mode

  traefik:
    image: docker.io/traefik:v3.5
    container_name: traefik
    restart: unless-stopped

    network_mode: service:gerbil # Ports appear on the gerbil service

    depends_on:
      pangolin:
        condition: service_healthy
    command:
      - --configFile=/etc/traefik/traefik_config.yml
    volumes:
      - ./config/traefik:/etc/traefik:ro # Volume to store the Traefik configuration
      - ./config/letsencrypt:/letsencrypt # Volume to store the Let's Encrypt certificates
      - ./config/traefik/logs:/var/log/traefik # Volume to store Traefik logs

networks:
  default:
    driver: bridge
    name: pangolin
    enable_ipv6: true

To Reproduce

add site, follow newt instructions

Expected Behavior

site added

Originally created by @johnsturgeon on GitHub (Oct 18, 2025). ### Describe the Bug My newt tunnel stopped working, I set up a second one and that doesn't work either, so no I have no connected / working 'site'. since upgrading to 1.11 ### Environment - OS Type & Version: (e.g., Ubuntu 22.04) - debian - Pangolin Version: 1.11 (ee) - Gerbil Version: - Traefik Version: - Newt Version: 1.5.2 - Olm Version: (if applicable) Docker compose: ```yaml name: pangolin services: pangolin: image: docker.io/fosrl/pangolin:ee-latest container_name: pangolin restart: unless-stopped volumes: - ./config:/app/config healthcheck: test: ["CMD", "curl", "-f", "http://localhost:3001/api/v1/"] interval: "10s" timeout: "10s" retries: 15 gerbil: image: docker.io/fosrl/gerbil:latest container_name: gerbil restart: unless-stopped depends_on: pangolin: condition: service_healthy command: - --reachableAt=http://gerbil:3003 - --generateAndSaveKeyTo=/var/config/key - --remoteConfig=http://pangolin:3001/api/v1/gerbil/get-config - --reportBandwidthTo=http://pangolin:3001/api/v1/gerbil/receive-bandwidth volumes: - ./config/:/var/config cap_add: - NET_ADMIN - SYS_MODULE ports: - 51820:51820/udp - 21820:21820/udp - 443:443 # Port for traefik because of the network_mode - 80:80 # Port for traefik because of the network_mode traefik: image: docker.io/traefik:v3.5 container_name: traefik restart: unless-stopped network_mode: service:gerbil # Ports appear on the gerbil service depends_on: pangolin: condition: service_healthy command: - --configFile=/etc/traefik/traefik_config.yml volumes: - ./config/traefik:/etc/traefik:ro # Volume to store the Traefik configuration - ./config/letsencrypt:/letsencrypt # Volume to store the Let's Encrypt certificates - ./config/traefik/logs:/var/log/traefik # Volume to store Traefik logs networks: default: driver: bridge name: pangolin enable_ipv6: true ``` ### To Reproduce add site, follow newt instructions ### Expected Behavior site added
GiteaMirror commented 2025-11-13 12:09:18 -06:00
Author
Owner
Copy Link

@HearthCore commented on GitHub (Oct 18, 2025):

Running into the same after rebooting my Host, multiple newt nodes running on docker on debian 12 lxcs are failing with the following error:

newt | ERROR: 2025/10/18 12:56:45 Failed to ensure WireGuard interface: failed to bring up WireGuard device: listen udp4 :58140: bind: address already in use

Upgrading Pangolin and restarting pangolin did not make issues, but restarting the docker hosts (because of the virtualizer restart) does now not allow newt to connect with the above error. Pangolin does not serve any logs of this interaction as far as I can see.

@HearthCore commented on GitHub (Oct 18, 2025): Running into the same after rebooting my Host, multiple newt nodes running on docker on debian 12 lxcs are failing with the following error: `newt | ERROR: 2025/10/18 12:56:45 Failed to ensure WireGuard interface: failed to bring up WireGuard device: listen udp4 :58140: bind: address already in use` Upgrading Pangolin and restarting pangolin did not make issues, but restarting the docker hosts (because of the virtualizer restart) does now not allow newt to connect with the above error. Pangolin does not serve any logs of this interaction as far as I can see.
GiteaMirror commented 2025-11-13 12:09:18 -06:00
Author
Owner
Copy Link

@johnsturgeon commented on GitHub (Oct 18, 2025):

I ended up reverting to 10.x since there seems to be an issue with the gerbil subdomain changing and the newt tunnel unable to connect and establish a route. Hopefully devs will address this issue.

@johnsturgeon commented on GitHub (Oct 18, 2025): I ended up reverting to 10.x since there seems to be an issue with the gerbil subdomain changing and the newt tunnel unable to connect and establish a route. Hopefully devs will address this issue.
GiteaMirror commented 2025-11-13 12:09:18 -06:00
Author
Owner
Copy Link

@johnsturgeon commented on GitHub (Oct 18, 2025):

After working extensively with Claude AI to debug this and ultimately reverting, I asked Claude to give me a description of the issue we were having here it is:

Bug Report: Newt clients receive "No exit nodes provided" after upgrading to 1.11.0

Environment

  • Pangolin: 1.11.0 (EE)
  • Gerbil: latest
  • Newt: 1.5.2

Issue

After upgrading from 1.10.2 to 1.11.0, newt clients successfully establish websocket connections to pangolin but receive "No exit nodes provided" message, preventing tunnels from functioning.

Database State

  • Exit node table shows correct configuration (exitNodeId=1, address=100.89.128.1/24)
  • Sites table shows correct exit node assignment (exitNode=1) and addresses within the exit node subnet
  • Gerbil logs show it receives empty proxy mappings: "Received initial mappings: {"mappings":{}}"
  • Pangolin logs show successful websocket connections but no logs indicating exit node config is being sent to clients

Expected Behavior

Pangolin should send exit node configuration to connected newt clients so they can establish tunnels.

Actual Behavior

Newt clients connect via websocket but receive no exit node configuration, remaining offline.

Workaround

Rolling back to pangolin 1.10.2 (CE) with the same database resolves the issue - clients immediately receive exit node config and connect successfully.

Additional Context

Sites were originally created on earlier versions (1.8.0-1.10.2) and migrated through version updates. The 1.11.0 migration completed without errors.

@johnsturgeon commented on GitHub (Oct 18, 2025): After working extensively with Claude AI to debug this and ultimately reverting, I asked Claude to give me a description of the issue we were having here it is: ## Bug Report: Newt clients receive "No exit nodes provided" after upgrading to 1.11.0 ### Environment - Pangolin: 1.11.0 (EE) - Gerbil: latest - Newt: 1.5.2 ### Issue After upgrading from 1.10.2 to 1.11.0, newt clients successfully establish websocket connections to pangolin but receive "No exit nodes provided" message, preventing tunnels from functioning. ### Database State - Exit node table shows correct configuration (exitNodeId=1, address=100.89.128.1/24) - Sites table shows correct exit node assignment (exitNode=1) and addresses within the exit node subnet - Gerbil logs show it receives empty proxy mappings: `"Received initial mappings: {"mappings":{}}"` - Pangolin logs show successful websocket connections but no logs indicating exit node config is being sent to clients ### Expected Behavior Pangolin should send exit node configuration to connected newt clients so they can establish tunnels. ### Actual Behavior Newt clients connect via websocket but receive no exit node configuration, remaining offline. ### Workaround Rolling back to pangolin 1.10.2 (CE) with the same database resolves the issue - clients immediately receive exit node config and connect successfully. ### Additional Context Sites were originally created on earlier versions (1.8.0-1.10.2) and migrated through version updates. The 1.11.0 migration completed without errors.
GiteaMirror commented 2025-11-13 12:09:19 -06:00
Author
Owner
Copy Link

@HearthCore commented on GitHub (Oct 18, 2025):

I've now reverted, let everything connect and then updated again- having newt sites successfully handshaked initially, keeping up after the restart - as a workaround.

(Reverting from EE to old community edition raised licensing error flags, and I could not find my free supporters licens for the exchange, so i figured- since newt nodes connected fine with the previous upgrade they would do so now aswell)

@HearthCore commented on GitHub (Oct 18, 2025): I've now reverted, let everything connect and then updated again- having newt sites successfully handshaked initially, keeping up after the restart - as a workaround. (Reverting from EE to old community edition raised licensing error flags, and I could not find my free supporters licens for the exchange, so i figured- since newt nodes connected fine with the previous upgrade they would do so now aswell)
GiteaMirror commented 2025-11-13 12:09:19 -06:00
Author
Owner
Copy Link

@johnsturgeon commented on GitHub (Oct 18, 2025):

(Reverting from EE to old community edition raised licensing error flags, and I could not find my free supporters licens for the exchange, so i figured- since newt nodes connected fine with the previous upgrade they would do so now aswell)

I deleted my second site after the licensing issue, and it fixed it.

@johnsturgeon commented on GitHub (Oct 18, 2025): > (Reverting from EE to old community edition raised licensing error flags, and I could not find my free supporters licens for the exchange, so i figured- since newt nodes connected fine with the previous upgrade they would do so now aswell) I deleted my second site after the licensing issue, and it fixed it.
GiteaMirror commented 2025-11-13 12:09:19 -06:00
Author
Owner
Copy Link

@cku-heise commented on GitHub (Oct 18, 2025):

I had the same issue for one of my sites (the other two worked fine). I downgraded from 1.11.0-ee to 1.11.0-ce (pangolin:latest) and the issue disappeared.

@cku-heise commented on GitHub (Oct 18, 2025): I had the same issue for one of my sites (the other two worked fine). I downgraded from 1.11.0-ee to 1.11.0-ce (pangolin:latest) and the issue disappeared.
GiteaMirror commented 2025-11-13 12:09:19 -06:00
Author
Owner
Copy Link

@MohamedElashri commented on GitHub (Oct 18, 2025):

I can confirm the problem happening when upgrading to ee-latest and that moving to community edition latest docker tag fix the connection problem.

@MohamedElashri commented on GitHub (Oct 18, 2025): I can confirm the problem happening when upgrading to `ee-latest` and that moving to community edition `latest` docker tag fix the connection problem.
GiteaMirror commented 2025-11-13 12:09:19 -06:00
Author
Owner
Copy Link

@scroguard commented on GitHub (Oct 18, 2025):

i had the same issue. upgraded to ee and all sites went offline, complaining about an exit node. i meant to copy the error down but needed to get the sites back online and forgot to do so. reverting back to the latest release of the community edition fixed the sites and brought everything back online.

i look forward to upgrading once this issue is sorted out. excellent work guys, really happy to see how this project is progressing!

@scroguard commented on GitHub (Oct 18, 2025): i had the same issue. upgraded to ee and all sites went offline, complaining about an exit node. i meant to copy the error down but needed to get the sites back online and forgot to do so. reverting back to the latest release of the community edition fixed the sites and brought everything back online. i look forward to upgrading once this issue is sorted out. excellent work guys, really happy to see how this project is progressing!
GiteaMirror commented 2025-11-13 12:09:20 -06:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Oct 19, 2025):

Ahh sorry about this everyone! I think this is because the exiting exit
node is considered "offline" in the enterprise edition because that
column was never set in the previous version and it is not set in the
migration. In EE, the exit node (the internal construct) must be set to
online for it to be served to newts. This is why you get the no exit
nodes provided message.

Will work on a fix for this ASAP and update.

@oschwartz10612 commented on GitHub (Oct 19, 2025): Ahh sorry about this everyone! I think this is because the exiting exit node is considered "offline" in the enterprise edition because that column was never set in the previous version and it is not set in the migration. In EE, the exit node (the internal construct) must be set to online for it to be served to newts. This is why you get the no exit nodes provided message. Will work on a fix for this ASAP and update.
GiteaMirror commented 2025-11-13 12:09:20 -06:00
Author
Owner
Copy Link

@keonramses commented on GitHub (Oct 21, 2025):

@oschwartz10612 sorry to necro this, but the same issue still persists in ee-1.11.1.

Image
@keonramses commented on GitHub (Oct 21, 2025): @oschwartz10612 sorry to necro this, but the same issue still persists in ee-1.11.1. <img width="1797" height="445" alt="Image" src="https://github.com/user-attachments/assets/8720b234-2d3b-46a5-9e40-89b2e370b73d" />
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
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#725
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?