mirror of
https://github.com/fosrl/pangolin.git
synced 2026-05-08 05:39:49 -05:00
[GH-ISSUE #1006] Basic Wireguard connections not working after Pangolin restart #8486
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/pangolin#8486
Reference in New Issue
Block a user
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?
Originally created by @sstickel on GitHub (Jul 3, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1006
Originally assigned to: @oschwartz10612 on GitHub.
Hello everybody.
As I was having trouble getting decent speeds using Newt I tested the Basic Wireguard Tunnel to connect my Nextcloud and Jellyfin to Pangolin. This worked almost flawlessly and the down speed is way higher now (Jellyfin Movie Download in the sub 5MB/s range using Newt and now almost hitting my upload limit at around 22MB/s)
The problem that I am facing is that all the Wireguard tunnels are dead after I restart the Pangolin stack. Pangolin no longer answers the handshake requests of all my Wireguard clients.
I found a workaround: Switch the resources that use Wireguard Sites to a different site and back to the original and the tunnels work again.
A second problem occurred today testing around a little bit. I installed Wireguard on my openWRT router at home and set up a raw tcp forward for testing with iperf3. I got a handshake but was unable to even ping 100.89.128.1. Pinging from the client side just did nothing, pinging the client IP (100.89.128.32) from inside the gerbil container resulted in this.
/ # ping 100.89.128.32PING 100.89.128.32 (100.89.128.32): 56 data bytesping: sendto: Required key not availableDon't ask me what brought up the idea to test the following, but it worked: As soon as I created another (bogus) resource which was NOT raw tcp but a proxy to that openWRT wireguard site the raw forward started to work properly. Ping was possible from both sides, also the iperf forward worked.
If I can help out with logs, testing a dev version or whatever, please tell. If you think these are two independent bugs I will happily create another one and edit the other one out here.
Best,
Sebastian
@oschwartz10612 commented on GitHub (Jul 3, 2025):
Hum I bet this is because for some reason Gerbil is not getting the config correctly from pangolin after a restart - or I am missing something to get the connection back up again. I will look into it.
It would help if you could give a log sample of when this occurs from the pangolin & gerbil side. I would want to see if Gerbil is creating the peers correctly with the right public key of the wireguard client on your network. Would you be able to provide that?
@sstickel commented on GitHub (Jul 3, 2025):
Sure. Is sufficient to save the output of the compose up or do you need more logs than that? I'm fit with Linux and server stuff but still new to docker.
@oschwartz10612 commented on GitHub (Jul 3, 2025):
I think that should be good!
@sstickel commented on GitHub (Jul 4, 2025):
Here are the requested logs.
Before the line break is the startup of pangolin. The gerbil log lines showing the public keys match the sqlite db entries for my Newt peers. Strange to me is to see these four pub keys again being added by gerbil, but I have no idea if that is a problem. More interestingly the wireguard peers do not appear here!
The block after the line break is when I switched one of my resources that use a (non functioning) Wireguard peer to a Newt site. (from
wW+jNXjVmPDtuJtoTYNFisWGRJ) In the moment I changed the resource to the Newt Site the public key of the Wireguard peer suddenly appears! (wW+jNXjVmPDtuJ)Then after the next line break I changed the resource back to the Wireguard Site which then started to work as expected.
Here is the list of public keys from my sqlite db:
There is also one error in the log regarding the client IP 100.89.128.16. This is a Newt raw TCP socket that works as expected, so I think I can safely ignore this error.
Hope this helps, if you need more information I will happily provide them.
@oschwartz10612 commented on GitHub (Jul 4, 2025):
Hum yeah it feels like its not adding the wg peers when it boots up like it needs to. Will look into it ASAP!
@sstickel commented on GitHub (Jul 4, 2025):
If I can support you in any way, please tell me.
And dont be in extreme hurry because of me, please. I have a workaround. ;)
@reans commented on GitHub (Jul 17, 2025):
same issue of mine. after adding port in config file and restart the old peers cannot back it seems the assign IP is not saving in pangolin.
@oschwartz10612 commented on GitHub (Jul 17, 2025):
I think this will be fixed in the next release!
@radokristof commented on GitHub (Sep 9, 2025):
This issue still persist? I have a similar issue and I don't know if its related
@sstickel commented on GitHub (Sep 10, 2025):
Haven't tried to restart Pangolin since. Pretty sure this is still an issue.
@oschwartz10612 ?
@sstickel commented on GitHub (Jan 14, 2026):
So, it is now a little bit more than 6 months since my journey into Panglin. Beside the mentionted two bugs (OP) the system ran without any hickups, but the machine was never restarted. As it
was really time to jump onto the latest Linux Kernel I pulled the Pangolin stack, did a full-upgrade and rebooted.
Unfortunatley the issue described in OP is still persistent in the latest version. Again, all of my Wireguard tunnels did not work properly until I did the workaround sequence mentioned in the OP.
If I can assist to find the root cause of this, please tell.
@sstickel commented on GitHub (Jan 15, 2026):
I have to correct myself. I looks like the old docker-compose.yml files in the documentation had the versions of pangolin and gerbil fixed to a version, now it's set to :latest. So basically my docker compose pull did (almost) nothing.
Changed the compose file pangolin:latest, gerbil:latest and traefik:v3.6 as in the documentation and all my bugs are gone. 👍