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 newt container.
INFO: 2025/05/08 23:55:00 Ping latency: 5.016142ms
INFO: 2025/05/08 23:55:30 Pinging 100.89.128.1
INFO: 2025/05/08 23:55:30 Ping latency: 3.178125ms
INFO: 2025/05/08 23:56:00 Pinging 100.89.128.1
INFO: 2025/05/08 23:56:00 Ping latency: 3.272988ms
INFO: 2025/05/08 23:56:30 Pinging 100.89.128.1
INFO: 2025/05/08 23:56:30 Ping latency: 5.639195ms
INFO: 2025/05/08 23:57:00 Pinging 100.89.128.1
INFO: 2025/05/08 23:57:00 Ping latency: 4.697367ms
ERROR: 2025/05/08 23:57:30 Ping failed: use of closed network connection
INFO: 2025/05/08 23:57:30 Pinging 100.89.128.1
WARN: 2025/05/08 23:57:40 Connection to server lost. Continuous reconnection attempts will be made.
WARN: 2025/05/08 23:57:40 Please check your internet connection and ensure the Pangolin server is online.
WARN: 2025/05/08 23:57:40 Newt will continue reconnection attempts automatically when connectivity is restored.
INFO: 2025/05/08 23:57:50 Sent registration message
INFO: 2025/05/08 23:57:50 Received registration message
INFO: 2025/05/08 23:57:50 Already connected! But I will send a ping anyway...
INFO: 2025/05/08 23:57:50 Ping attempt 1
INFO: 2025/05/08 23:57:50 Pinging 100.89.128.1
WARN: 2025/05/08 23:58:00 Ping attempt 1 failed: failed to read ICMP packet: i/o timeout
INFO: 2025/05/08 23:58:00 Ping attempt 2
INFO: 2025/05/08 23:58:00 Pinging 100.89.128.1
INFO: 2025/05/08 23:58:00 Ping latency: 5.045469ms
INFO: 2025/05/08 23:58:00 Ping succeeded after 2 attempts
INFO: 2025/05/08 23:58:00 Pinging 100.89.128.1
INFO: 2025/05/08 23:58:00 Ping latency: 4.374875ms
INFO: 2025/05/08 23:58:00 Connection to server restored!
INFO: 2025/05/08 23:58:00 Successfully re-registered with server after reconnection
INFO: 2025/05/08 23:58:00 Received registration message
INFO: 2025/05/08 23:58:00 Already connected! But I will send a ping anyway...
INFO: 2025/05/08 23:58:00 Ping attempt 1
INFO: 2025/05/08 23:58:00 Pinging 100.89.128.1
INFO: 2025/05/08 23:58:00 Ping latency: 3.838229ms
INFO: 2025/05/08 23:58:30 Pinging 100.89.128.1
INFO: 2025/05/08 23:58:30 Ping latency: 5.230547ms
ERROR: 2025/05/08 23:58:50 Ping failed: use of closed network connection
INFO: 2025/05/08 23:59:00 Pinging 100.89.128.1
INFO: 2025/05/08 23:59:02 Sent registration message
WARN: 2025/05/08 23:59:10 Connection to server lost. Continuous reconnection attempts will be made.
WARN: 2025/05/08 23:59:10 Please check your internet connection and ensure the Pangolin server is online.
WARN: 2025/05/08 23:59:10 Newt will continue reconnection attempts automatically when connectivity is restored.
INFO: 2025/05/08 23:59:30 Pinging 100.89.128.1
INFO: 2025/05/09 00:00:00 Pinging 100.89.128.1
INFO: 2025/05/09 00:00:30 Pinging 100.89.128.1
INFO: 2025/05/09 00:01:00 Pinging 100.89.128.1
INFO: 2025/05/09 00:01:30 Pinging 100.89.128.1
INFO: 2025/05/09 00:02:00 Pinging 100.89.128.1
INFO: 2025/05/09 00:02:30 Pinging 100.89.128.1
INFO: 2025/05/09 00:03:00 Pinging 100.89.128.1
INFO: 2025/05/09 00:03:30 Pinging 100.89.128.1
... after waiting for a while I had to `docker restart newt`
As a workaround I made a cron checking the url directly and restart newt if it gets a gateway error.
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 `newt` container.
```
INFO: 2025/05/08 23:55:00 Ping latency: 5.016142ms
INFO: 2025/05/08 23:55:30 Pinging 100.89.128.1
INFO: 2025/05/08 23:55:30 Ping latency: 3.178125ms
INFO: 2025/05/08 23:56:00 Pinging 100.89.128.1
INFO: 2025/05/08 23:56:00 Ping latency: 3.272988ms
INFO: 2025/05/08 23:56:30 Pinging 100.89.128.1
INFO: 2025/05/08 23:56:30 Ping latency: 5.639195ms
INFO: 2025/05/08 23:57:00 Pinging 100.89.128.1
INFO: 2025/05/08 23:57:00 Ping latency: 4.697367ms
ERROR: 2025/05/08 23:57:30 Ping failed: use of closed network connection
INFO: 2025/05/08 23:57:30 Pinging 100.89.128.1
WARN: 2025/05/08 23:57:40 Connection to server lost. Continuous reconnection attempts will be made.
WARN: 2025/05/08 23:57:40 Please check your internet connection and ensure the Pangolin server is online.
WARN: 2025/05/08 23:57:40 Newt will continue reconnection attempts automatically when connectivity is restored.
INFO: 2025/05/08 23:57:50 Sent registration message
INFO: 2025/05/08 23:57:50 Received registration message
INFO: 2025/05/08 23:57:50 Already connected! But I will send a ping anyway...
INFO: 2025/05/08 23:57:50 Ping attempt 1
INFO: 2025/05/08 23:57:50 Pinging 100.89.128.1
WARN: 2025/05/08 23:58:00 Ping attempt 1 failed: failed to read ICMP packet: i/o timeout
INFO: 2025/05/08 23:58:00 Ping attempt 2
INFO: 2025/05/08 23:58:00 Pinging 100.89.128.1
INFO: 2025/05/08 23:58:00 Ping latency: 5.045469ms
INFO: 2025/05/08 23:58:00 Ping succeeded after 2 attempts
INFO: 2025/05/08 23:58:00 Pinging 100.89.128.1
INFO: 2025/05/08 23:58:00 Ping latency: 4.374875ms
INFO: 2025/05/08 23:58:00 Connection to server restored!
INFO: 2025/05/08 23:58:00 Successfully re-registered with server after reconnection
INFO: 2025/05/08 23:58:00 Received registration message
INFO: 2025/05/08 23:58:00 Already connected! But I will send a ping anyway...
INFO: 2025/05/08 23:58:00 Ping attempt 1
INFO: 2025/05/08 23:58:00 Pinging 100.89.128.1
INFO: 2025/05/08 23:58:00 Ping latency: 3.838229ms
INFO: 2025/05/08 23:58:30 Pinging 100.89.128.1
INFO: 2025/05/08 23:58:30 Ping latency: 5.230547ms
ERROR: 2025/05/08 23:58:50 Ping failed: use of closed network connection
INFO: 2025/05/08 23:59:00 Pinging 100.89.128.1
INFO: 2025/05/08 23:59:02 Sent registration message
WARN: 2025/05/08 23:59:10 Connection to server lost. Continuous reconnection attempts will be made.
WARN: 2025/05/08 23:59:10 Please check your internet connection and ensure the Pangolin server is online.
WARN: 2025/05/08 23:59:10 Newt will continue reconnection attempts automatically when connectivity is restored.
INFO: 2025/05/08 23:59:30 Pinging 100.89.128.1
INFO: 2025/05/09 00:00:00 Pinging 100.89.128.1
INFO: 2025/05/09 00:00:30 Pinging 100.89.128.1
INFO: 2025/05/09 00:01:00 Pinging 100.89.128.1
INFO: 2025/05/09 00:01:30 Pinging 100.89.128.1
INFO: 2025/05/09 00:02:00 Pinging 100.89.128.1
INFO: 2025/05/09 00:02:30 Pinging 100.89.128.1
INFO: 2025/05/09 00:03:00 Pinging 100.89.128.1
INFO: 2025/05/09 00:03:30 Pinging 100.89.128.1
... after waiting for a while I had to `docker restart newt`
```
As a workaround I made a cron checking the url directly and restart newt if it gets a gateway error.
GiteaMirror
added the bug label 2025-11-19 07:12:11 -06:00
newt-1 | ERROR: 2025/05/16 22:09:36 Failed to connect: failed to get token: failed to request new token: Post "https://pangolin.elevationengine.com/api/v1/auth/newt/get-token": dial tcp 107.172.142.108:443: connect: no route to host. Retrying in 10s...
newt-1 | ERROR: 2025/05/16 22:09:46 Failed to connect: failed to get token: failed to request new token: Post "https://pangolin.elevationengine.com/api/v1/auth/newt/get-token": dial tcp 107.172.142.108:443: connect: no route to host. Retrying in 10s...
newt-1 | INFO: 2025/05/16 22:09:55 Pinging 100.89.128.1
newt-1 | INFO: 2025/05/16 22:09:58 Sent registration message
newt-1 | INFO: 2025/05/16 22:09:58 Received registration message
newt-1 | INFO: 2025/05/16 22:09:58 Already connected! But I will send a ping anyway...
newt-1 | INFO: 2025/05/16 22:09:58 Ping attempt 1
newt-1 | INFO: 2025/05/16 22:09:58 Pinging 100.89.128.1
newt-1 | WARN: 2025/05/16 22:10:08 Ping attempt 1 failed: failed to read ICMP packet: i/o timeout
newt-1 | INFO: 2025/05/16 22:10:08 Ping attempt 2
newt-1 | INFO: 2025/05/16 22:10:08 Pinging 100.89.128.1
It thinks it is already connected, but it is not...
@hendyj commented on GitHub (May 16, 2025):
Same issue.
```
newt-1 | ERROR: 2025/05/16 22:09:36 Failed to connect: failed to get token: failed to request new token: Post "https://pangolin.elevationengine.com/api/v1/auth/newt/get-token": dial tcp 107.172.142.108:443: connect: no route to host. Retrying in 10s...
newt-1 | ERROR: 2025/05/16 22:09:46 Failed to connect: failed to get token: failed to request new token: Post "https://pangolin.elevationengine.com/api/v1/auth/newt/get-token": dial tcp 107.172.142.108:443: connect: no route to host. Retrying in 10s...
newt-1 | INFO: 2025/05/16 22:09:55 Pinging 100.89.128.1
newt-1 | INFO: 2025/05/16 22:09:58 Sent registration message
newt-1 | INFO: 2025/05/16 22:09:58 Received registration message
newt-1 | INFO: 2025/05/16 22:09:58 Already connected! But I will send a ping anyway...
newt-1 | INFO: 2025/05/16 22:09:58 Ping attempt 1
newt-1 | INFO: 2025/05/16 22:09:58 Pinging 100.89.128.1
newt-1 | WARN: 2025/05/16 22:10:08 Ping attempt 1 failed: failed to read ICMP packet: i/o timeout
newt-1 | INFO: 2025/05/16 22:10:08 Ping attempt 2
newt-1 | INFO: 2025/05/16 22:10:08 Pinging 100.89.128.1
```
It thinks it is already connected, but it is not...
I am facing this as well! Newt installed as systemd service, some of my tunnells do not connect to pangolin once machine starts.
@scetu commented on GitHub (May 18, 2025):
I am facing this as well! Newt installed as `systemd` service, some of my tunnells do not connect to pangolin once machine starts.
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.
@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.
@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.
@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.
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.
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
@sergiors commented on GitHub (May 25, 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.
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
ERROR: 2025/05/27 21:33:57 Failed to resolve endpoint: DNS lookup failed: lookup sergio.run on 127.0.0.11:53: no such host
@sergiors commented on GitHub (May 27, 2025):
Something new happen
```
ERROR: 2025/05/27 21:33:57 Failed to resolve endpoint: DNS lookup failed: lookup sergio.run on 127.0.0.11:53: no such host
```
I removed the site, and create a new, everythings works like before, but I had to add every resources again.
@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):
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.
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.1 WARN: 2025/06/11 12:36:52 Ping attempt 6 failed: failed to read ICMP packet: i/o timeout
I've connected to newt container, run ping 100.89.128.1 which returns ok: / # ping 100.89.128.1 PING 100.89.128.1 (100.89.128.1): 56 data bytes 64 bytes from 100.89.128.1: seq=0 ttl=56 time=6.824 ms 64 bytes from 100.89.128.1: seq=1 ttl=56 time=7.010 ms
@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.1`
`WARN: 2025/06/11 12:36:52 Ping attempt 6 failed: failed to read ICMP packet: i/o timeout`
I've connected to newt container, run `ping 100.89.128.1` which returns ok:
`/ # ping 100.89.128.1`
`PING 100.89.128.1 (100.89.128.1): 56 data bytes`
`64 bytes from 100.89.128.1: seq=0 ttl=56 time=6.824 ms`
`64 bytes from 100.89.128.1: seq=1 ttl=56 time=7.010 ms`
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.1 is working fine.
I've also tried sudo tcpdump -i any icmp and 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:
Newt is not using the kernel's IP stack or default network interface (e.g., wlo1).
It uses userspace WireGuard (via wireguard-go) and creates a virtual network stack internally.
ICMP echo requests/replies never touch the Linux network stack, so:
tcpdump doesn't see them
Replies don’t get routed properly
Newt’s ping logic using raw sockets fails
Is there any way to disable the ping check, maybe under a flag like --disable-ping-check?
@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.1` is working fine.
I've also tried `sudo tcpdump -i any icmp` and 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:
1. Newt is not using the kernel's IP stack or default network interface (e.g., wlo1).
2. It uses userspace WireGuard (via wireguard-go) and creates a virtual network stack internally.
3. ICMP echo requests/replies never touch the Linux network stack, so:
- tcpdump doesn't see them
- Replies don’t get routed properly
- Newt’s ping logic using raw sockets fails
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.
@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.
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 newt tunnel is alway recconected sucesfully.
Any update on investigation what could cause this?
@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 newt` tunnel is alway recconected sucesfully.
Any update on investigation what could cause this?
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 @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?