mirror of
https://github.com/fosrl/newt.git
synced 2026-03-09 07:12:28 -05:00
Newt won't reconnect after server restart #24
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 @paltaio-admin on GitHub (May 9, 2025).
Originally assigned to: @oschwartz10612 on GitHub.
I'm using the latest Pangolin and Newt version (Pangolin v1.3.1, Newt v1.1.3) on both of my servers. After restarting the Pangolin VM, Newt reconnected fine, but after the second VM reboot it didn't come back and I had to manually restart the
newtcontainer.As a workaround I made a cron checking the url directly and restart newt if it gets a gateway error.
@RomRider commented on GitHub (May 14, 2025):
Same issue, running newt on K8S (happened after a connection switch between Fiber, 4G and back to Fiber):
Only solution is killing the pod and let k8s recreate it and then it works directly again (see log timestamps)
@hendyj commented on GitHub (May 16, 2025):
Same issue.
It thinks it is already connected, but it is not...
@scetu commented on GitHub (May 18, 2025):
I am facing this as well! Newt installed as
systemdservice, some of my tunnells do not connect to pangolin once machine starts.@mellow65 commented on GitHub (May 19, 2025):
I just figured out this was my issue this morning after my VPS reboot for an update. A simple reboot to the proxmox container that has newt running fixed it. I'm wondering if I could add a health check to the systemd to check if the tunnels are up or not.
@sergiors commented on GitHub (May 22, 2025):
Some error here
@bytec77 commented on GitHub (May 22, 2025):
same error here.
@sergiors commented on GitHub (May 23, 2025):
Here is my logs
@oschwartz10612 commented on GitHub (May 24, 2025):
Ill try to reproduce ASAP. Not seeing a ton in the logs that explain why the time out is happening. Could be Pangolin side with gerbil.
@sergiors commented on GitHub (May 25, 2025):
I don't why, but everything was working, out of the blue, it's happen, I tried to check if as some block from VPS (racknerd), but it didn't make any sense
@mellow65 commented on GitHub (May 25, 2025):
Misery loves company I guess. This morning my VPS rebooted for an update and newt stayed connected. 🤷♀️
@sergiors commented on GitHub (May 27, 2025):
Something new happen
@sergiors commented on GitHub (May 27, 2025):
I removed the site, and create a new, everythings works like before, but I had to add every resources again.
@oschwartz10612 commented on GitHub (May 29, 2025):
Huh thats strange. The site should not effect the connectivity from the newt side because it is just DNS.
You can also move resources if you need to in the settings before you delete the original site.
@oschwartz10612 commented on GitHub (May 29, 2025):
Will look into soon!
@horiaIon commented on GitHub (Jun 11, 2025):
I'm using pangolin:1.5.1, gerbil:1.0.0, newt:1.2.1 via docker-compose. I've added my homelab site (newt), copied the docker-compose for newt, and running it on my local server, but having a similar problem (logs from newt container):
INFO: 2025/06/11 12:36:42 Pinging 100.89.128.1WARN: 2025/06/11 12:36:52 Ping attempt 6 failed: failed to read ICMP packet: i/o timeoutI've connected to newt container, run
ping 100.89.128.1which returns ok:/ # ping 100.89.128.1PING 100.89.128.1 (100.89.128.1): 56 data bytes64 bytes from 100.89.128.1: seq=0 ttl=56 time=6.824 ms64 bytes from 100.89.128.1: seq=1 ttl=56 time=7.010 ms@horiaIon commented on GitHub (Jun 13, 2025):
I have also tried running Newt directly on the host. But the same thing, Pinging 100.89.128.1 fails with
failed to read ICMP packet: i/o timeout.Direct ping from the host like
ping 100.89.128.1is working fine.I've also tried
sudo tcpdump -i any icmpand started newt, and no ICMP traffic to/from 100.89.128.1 is seen at all during tcpdump, even while Newt claims it is pinging.What this tells us:
Is there any way to disable the ping check, maybe under a flag like
--disable-ping-check?@oschwartz10612 commented on GitHub (Jun 13, 2025):
Hi @horiaIon you are correct in all of your observations! That is how it works. The pining is pinging the internal wireguard IP address on the gerbil peer side of the connection. You would not be able to tcpdump for ICMP.
If this is not related to reconnecting after restart then this is almost always related to UDP port 51820 not being open on the VPS firewall. Sometimes this is on the VPS provider and on the linux side itself with ufw and iptables. Please triple check that this port is open.
To check if packets are making it to the VPS you can tcpdump on udp port 51820 and make sure you are getting wg packets when you start newt.
@scetu commented on GitHub (Jun 26, 2025):
Hi, I would like to add update from my side for this.
I am mostly facing this issue when I restart Pangolin stack on VPS server (i.e. for update). Once Pangolin stack is restarted, newt tunnels work, but after some time, some/all exposed services return
504 Gateway Timeout.Now the odd part. If I restart whole LXC/VM with non-responding Newt tunnel, it does not reconnects (this is strange in my opinion). But if I log into non-responsing machine, run
systemctl restart newttunnel is alway recconected sucesfully.Any update on investigation what could cause this?