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:
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?
@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.
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?
@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.
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).
@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.
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 @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 returning100.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:
Which makes me think something is collecting the wrong exit node data, pressumably its the pangolin server?
@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.
@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?
@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.
@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).
@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.