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

[GH-ISSUE #997] Gerbil Key Managment Issue #14601

New Issue
Closed
opened 2026-05-16 02:29:52 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-05-16 02:29:52 -05:00
Owner
Copy Link

Originally created by @Stetsed on GitHub (Jul 1, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/997

Originally assigned to: @oschwartz10612 on GitHub.

Hey lads, well after spending way to long I was able to find the issue, thanks to Astra in the discord.

There is currently an issue with how Pangolin keeps track of the public keys that belong to Gerbil. This issue can manifest when for example the path for Gerbil is incorrect, or if the key is deleted. What this causes is if the rest of the details specifically it seems like the host field(so http://gerbil:(port) on docker), it will log both keys as diffrent enteries.

The problem with this is it will only ever return the first entry from the database, so even though it might have a bunch of enteries it will only give the oldest, but this one might(and probally isn't) used anymore by Gerbil. This means it will report this outdated wireguard key to the Newt client, which means it will forever be stuck on the handshake step.

This can be seen because while the network itself will work, and the wireguard test packets can be seen using "tcpdump udp port 51820", specificially of size 148, this will only be going from Newt Server --> Gerbil, and as such Wireguard will never be able to connect.

Reproduce:

  1. Setup Pangolin and Gerbil as you usually would
  2. Change the path that Gerbil uses for it's key to a non-persistant place(This could be done by a user by accident).
  3. Restart Gerbil
  4. Attempt to connect a newt client, it will fail to connect with no seemingly usable error, the only thing it gives is an i/o timeout error this is because the wireguard interface never finishes it's initialization.
  5. Check the database, this can be done with "select * from exitNodes;" using the sqlite3 CLI program. You will see alot of entries, and you will see that the key newt is getting is the one equal to the lowest ID, even though this might not be the key that's being used anymore this can be checked by adding the wireguard-tools package to the container.

Fix

The problem right now is that it doesn't update the key for the same instance and instead adds it to the database as another entry, while still returning the old key from the database as the public key that Newt should use to connect to Gerbil. The easiest fix for this would be that if you get a client that has the same reachable address, you either delete the old entry and make a new one, or you update the previous entry.

Another solution would be to instead of grabbing the first from the index to grab the last one, because this is the one that was most recently added, but you would have a bunch of dead entries within the database so this solution isn't super useful.

Originally created by @Stetsed on GitHub (Jul 1, 2025). Original GitHub issue: https://github.com/fosrl/pangolin/issues/997 Originally assigned to: @oschwartz10612 on GitHub. Hey lads, well after spending way to long I was able to find the issue, thanks to Astra in the discord. There is currently an issue with how Pangolin keeps track of the public keys that belong to Gerbil. This issue can manifest when for example the path for Gerbil is incorrect, or if the key is deleted. What this causes is if the rest of the details specifically it seems like the host field(so http://gerbil:(port) on docker), it will log both keys as diffrent enteries. The problem with this is it will only ever return the first entry from the database, so even though it might have a bunch of enteries it will only give the oldest, but this one might(and probally isn't) used anymore by Gerbil. This means it will report this outdated wireguard key to the Newt client, which means it will forever be stuck on the handshake step. This can be seen because while the network itself will work, and the wireguard test packets can be seen using "tcpdump udp port 51820", specificially of size 148, this will only be going from Newt Server --> Gerbil, and as such Wireguard will never be able to connect. ## Reproduce: 1. Setup Pangolin and Gerbil as you usually would 2. Change the path that Gerbil uses for it's key to a non-persistant place(This could be done by a user by accident). 3. Restart Gerbil 4. Attempt to connect a newt client, it will fail to connect with no seemingly usable error, the only thing it gives is an i/o timeout error this is because the wireguard interface never finishes it's initialization. 5. Check the database, this can be done with "select * from exitNodes;" using the sqlite3 CLI program. You will see alot of entries, and you will see that the key newt is getting is the one equal to the lowest ID, even though this might not be the key that's being used anymore this can be checked by adding the wireguard-tools package to the container. ## Fix The problem right now is that it doesn't update the key for the same instance and instead adds it to the database as another entry, while still returning the old key from the database as the public key that Newt should use to connect to Gerbil. The easiest fix for this would be that if you get a client that has the same reachable address, you either delete the old entry and make a new one, or you update the previous entry. Another solution would be to instead of grabbing the first from the index to grab the last one, because this is the one that was most recently added, but you would have a bunch of dead entries within the database so this solution isn't super useful.
GiteaMirror added the non-critical bug label 2026-05-16 02:29:52 -05:00
GiteaMirror commented 2026-05-16 02:29:53 -05:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Jul 3, 2025):

Yep this is very true. Will work on a fix ASAP.

<!-- gh-comment-id:3032834755 --> @oschwartz10612 commented on GitHub (Jul 3, 2025): Yep this is very true. Will work on a fix ASAP.
GiteaMirror commented 2026-05-16 02:29:54 -05:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Sep 28, 2025):

I think this was fixed in 1.9.0

<!-- gh-comment-id:3342143460 --> @oschwartz10612 commented on GitHub (Sep 28, 2025): I think this was fixed in 1.9.0
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 non-critical bug
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#14601
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?