github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-05-08 21:59:09 -05:00
Code Issues 564 Packages Projects Releases 72 Wiki Activity

[GH-ISSUE #776] Multiple exit nodes issue? #3567

New Issue
Closed
opened 2026-04-20 07:34:46 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-04-20 07:34:46 -05:00
Owner
Copy Link

Originally created by @RichyHBM on GitHub (May 24, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/776

Originally assigned to: @oschwartz10612 on GitHub.

Hello, I recently changed my VPS and as a result I moved pangolin by copying the db.sqlite, on the new server I had issues connecting and created (and setup) a new newt config.

The logs showed pangolin/gerbal giving itself the ip 100.89.130.1/24, however the logs for newt showed the config returning 100.89.128.1/24, and subsequently caused the ping to fail, presumably because the wireguard connection was never fully made.

Eventually I removed the old db, and recreated pangolin which fixed the issue, but I looked at the sql data out of curiosity and found the following in the exitNodes table:

exitNoideId       name                                  address
1                          Exit Node XHuz1LpS        100.89.128.1/24
2                          Exit Node aXvLf78h         100.89.129.1/24
3                          Exit Node 3Yjr1IJA            100.89.130.1/24

Which makes me think something is collecting the wrong exit node data, pressumably its the pangolin server?

Originally created by @RichyHBM on GitHub (May 24, 2025). Original GitHub issue: https://github.com/fosrl/pangolin/issues/776 Originally assigned to: @oschwartz10612 on GitHub. Hello, I recently changed my VPS and as a result I moved pangolin by copying the db.sqlite, on the new server I had issues connecting and created (and setup) a new newt config. The logs showed pangolin/gerbal giving itself the ip `100.89.130.1/24`, however the logs for newt showed the config returning `100.89.128.1/24`, and subsequently caused the ping to fail, presumably because the wireguard connection was never fully made. Eventually I removed the old db, and recreated pangolin which fixed the issue, but I looked at the sql data out of curiosity and found the following in the exitNodes table: ``` exitNoideId name address 1 Exit Node XHuz1LpS 100.89.128.1/24 2 Exit Node aXvLf78h 100.89.129.1/24 3 Exit Node 3Yjr1IJA 100.89.130.1/24 ``` Which makes me think something is collecting the wrong exit node data, pressumably its the pangolin server?
GiteaMirror added the needs investigating label 2026-04-20 07:34:46 -05:00
GiteaMirror commented 2026-04-20 07:34:48 -05:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (May 24, 2025):

Hum okay yeah so it created 3 exit nodes when it should really only ever have one. I think this is because the key from --generateAndSaveKeyTo changed when you moved VPS perhaps and it created new ones based on the logic. I will look into this.

<!-- gh-comment-id:2906359400 --> @oschwartz10612 commented on GitHub (May 24, 2025): Hum okay yeah so it created 3 exit nodes when it should really only ever have one. I think this is because the key from --generateAndSaveKeyTo changed when you moved VPS perhaps and it created new ones based on the logic. I will look into this.
GiteaMirror commented 2026-04-20 07:34:48 -05:00
Author
Owner
Copy Link

@RichyHBM commented on GitHub (May 24, 2025):

That is possible, I also deleted the key file, and also deleted and recreated the site before completely nuking the old instance. Would that not have caused there to be 4 entries? Or because when I recreated it I deleted the old one properly it correctly removed it from the db?

<!-- gh-comment-id:2906903404 --> @RichyHBM commented on GitHub (May 24, 2025): That is possible, I also deleted the key file, and also deleted and recreated the site before completely nuking the old instance. Would that not have caused there to be 4 entries? Or because when I recreated it I deleted the old one properly it correctly removed it from the db?
GiteaMirror commented 2026-04-20 07:34:49 -05:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (May 27, 2025):

It could have but not 100% on the order you did everything. It creates an exit node if there is not already one matching the key sent by the Gerbil container on a restart and if the gerbil container has no key file it creates a new one. I think this is something that should change so it just updates the pub key instead of creating a new one.

<!-- gh-comment-id:2912799503 --> @oschwartz10612 commented on GitHub (May 27, 2025): It could have but not 100% on the order you did everything. It creates an exit node if there is not already one matching the key sent by the Gerbil container on a restart and if the gerbil container has no key file it creates a new one. I think this is something that should change so it just updates the pub key instead of creating a new one.
GiteaMirror commented 2026-04-20 07:34:49 -05:00
Author
Owner
Copy Link

@krzwiatrzyk commented on GitHub (Jun 28, 2025):

Had the same case right now while trying to run Pangolin in Kubernetes without using persistent storage. After Gerbil pod is recreated, it is impossible to establish proper wirguard connection (ICMP ping wont succeed).

<!-- gh-comment-id:3016099512 --> @krzwiatrzyk commented on GitHub (Jun 28, 2025): Had the same case right now while trying to run Pangolin in Kubernetes without using persistent storage. After Gerbil pod is recreated, it is impossible to establish proper wirguard connection (ICMP ping wont succeed).
GiteaMirror commented 2026-04-20 07:34:49 -05:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Jun 30, 2025):

Yeah we are working on some node stuff right now what should help this situation. But yeah you need to persist that key file for gerbil otherwise it will register a new exit node and you will be a in a sticky situation because your sites are on the old node. I would recomend editing the db and removing the new exit node and updaing the public key column to match your new key.

<!-- gh-comment-id:3019890763 --> @oschwartz10612 commented on GitHub (Jun 30, 2025): Yeah we are working on some node stuff right now what should help this situation. But yeah you need to persist that key file for gerbil otherwise it will register a new exit node and you will be a in a sticky situation because your sites are on the old node. I would recomend editing the db and removing the new exit node and updaing the public key column to match your new key.
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 needs investigating
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#3567
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?