Originally created by @gyokiss on GitHub (Apr 8, 2025).
Dear all,
pangolin is promising, so I have decided to install it, mostly basic setup. I decided first to get the easyest method, docker everything, and newt on lab server.
my lab is behind mikrotik router, i think that should not be a showstopper.
Issue I'm facing: trhe newt would like to ping, but fails, handshake initiated every 5 sec, but where I can see, that is successful?
I think with newt I have issue, but even the debug option helps a little bit less, than I think required for me to get to the root of issue.
Additional infomation: the site on pangolin reports online.... ( but my site gives ofc gateway timeout)
any idea where to debug?
Originally created by @gyokiss on GitHub (Apr 8, 2025).
Dear all,
pangolin is promising, so I have decided to install it, mostly basic setup. I decided first to get the easyest method, docker everything, and newt on lab server.
my lab is behind mikrotik router, i think that should not be a showstopper.
Issue I'm facing: trhe newt would like to ping, but fails, handshake initiated every 5 sec, but where I can see, that is successful?
I think with newt I have issue, but even the debug option helps a little bit less, than I think required for me to get to the root of issue.
Additional infomation: the site on pangolin reports online.... ( but my site gives ofc gateway timeout)
any idea where to debug?
@oschwartz10612 commented on GitHub (Apr 9, 2025):
Hi thanks for trying out pangolin and I am sorry you are having this issue!
Are you installing Pangolin on the same network in which you intend to proxy resources? The network behind Mikrotik? Is so you do not need Newt because there is no reason to tunnel and you can just use local sites: https://docs.fossorial.io/Pangolin/without-tunneling
Otherwise I would make sure that UDP port 51820 is open coming into your network to Gerbil the Wireguard server. If you are still experiencing the issue could you redact and post your Newt logs and config?
@oschwartz10612 commented on GitHub (Apr 9, 2025):
Hi thanks for trying out pangolin and I am sorry you are having this issue!
Are you installing Pangolin on the _same_ network in which you intend to proxy resources? The network behind Mikrotik? Is so you do not need Newt because there is no reason to tunnel and you can just use local sites: https://docs.fossorial.io/Pangolin/without-tunneling
Otherwise I would make sure that UDP port 51820 is open coming into your network to Gerbil the Wireguard server. If you are still experiencing the issue could you redact and post your Newt logs and config?
For clarify: pangolin runs in vps (hetzner cloud), edge server in a local network, protected with mikrotik. on vps all required ports are open.
If I start newt with debug (i have removed some keys and ip's), ping fails.
Interessant pangolin webUI shows the site online.
Another test, I have created a site with basic wireguard, there the connection comes up - there is not clear how to set in pangolin the target in resource to get the service.
Hi,
update a little bit, If I start newt in host, without any docker etc. should it create an interface? where should I see the ip from newt would like to go out? My edge OS: ubuntu server 24.04.2
Even the routing table is "free" from network 100.89.128.x....
@gyokiss commented on GitHub (Apr 9, 2025):
Hi,
update a little bit, If I start newt in host, without any docker etc. should it create an interface? where should I see the ip from newt would like to go out? My edge OS: ubuntu server 24.04.2
Even the routing table is "free" from network 100.89.128.x....
@oschwartz10612 commented on GitHub (Apr 9, 2025):
Newt uses a fully user space network stack called gvisor/netstack. You will not see an interface get created. This is part of what makes it so portable! The 100.89.128.4 address is the internet Wireguard network between gerbil and newt that is pinging.
Does your pangolin<.myserver> domain resolve to the IP of the VPS? I.E. your domain is not behind Cloudflare's proxy or anything else like that? Also I would triple check your ports are open. You can use dig/nslookup to test the DNS resolution on the edge server running Newt.
This is almost always a network issue with Wireguard packets failing to make it to the VPS.
@oschwartz10612 commented on GitHub (Apr 9, 2025):
Newt uses a fully user space network stack called gvisor/netstack. You will not see an interface get created. This is part of what makes it so portable! The `100.89.128.4` address is the internet Wireguard network between gerbil and newt that is pinging.
Does your pangolin<.myserver> domain resolve to the IP of the VPS? I.E. your domain is not behind Cloudflare's proxy or anything else like that? Also I would triple check your ports are open. You can use dig/nslookup to test the DNS resolution on the edge server running Newt.
This is almost always a network issue with Wireguard packets failing to make it to the VPS.
Hi,
I have checked - dns works as expected. Looks good for me: :) dig and nslookup reports back correctly.
Not really yet understood how that should work :) I'm trying. How will be routed a package from newt to gerbil?
If I have right, first the wireguard should be connected. But in case an edge server we have internal IP- on edge. Than should be enabled/masqueraded/forwarded to be able connect. correct?
On newt (edge ) i have recognized, that tries to go out every time on a new port.
what I have found: there is no answer from public accessible server. Thats a
- is the IP of vps server,
- is the IP of Mikrotik router - hiding the edge.
It looks like that would like to have some additinal mikrotik config?
root@newtendpoint:~# sudo tcpdump -ni any udp port 51820
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
16:00:45.446382 enp1s0 Out IP 192.168.190.xxx.48643 > <publicIP>.51820: UDP, length 148
16:00:50.447556 enp1s0 Out IP 192.168.190.xxx.48643 > <publicIP>.51820: UDP, length 148
16:00:55.447870 enp1s0 Out IP 192.168.190.xxx.48643 > <publicIP>.51820: UDP, length 148
16:01:00.448236 enp1s0 Out IP 192.168.190.xxx.48643 > <publicIP>.51820: UDP, length 148
on the vps:
16:02:55.706916 br-f6e3e98296b4 In IP 172.18.0.3.51820 > <gateway>.48643: UDP, length 92
16:02:55.706957 eth0 Out IP <publicIP>.51820 > <gateway>.48643: UDP, length 92
16:03:00.706884 eth0 In IP <gateway>.48643 > <publicIP>.51820: UDP, length 148
16:03:00.706935 br-f6e3e98296b4 Out IP <gateway>.48643 > 172.18.0.3.51820: UDP, length 148
16:03:00.706945 veth7eee39c Out IP <gateway>.48643 > 172.18.0.3.51820: UDP, length 148
16:03:00.707867 veth7eee39c P IP 172.18.0.3.51820 > <gateway>.48643: UDP, length 92
16:03:00.707867 br-f6e3e98296b4 In IP 172.18.0.3.51820 > <gateway>.48643: UDP, length 92
16:03:00.707912 eth0 Out IP <publicIP>.51820 > <gateway>.48643: UDP, length 92
16:03:05.707207 eth0 In IP <gateway>.48643 > <publicIP>9.51820: UDP, length 148
16:03:05.707278 br-f6e3e98296b4 Out IP <gateway>.48643 > 172.18.0.3.51820: UDP, length 148
16:03:05.707287 veth7eee39c Out IP <gateway>.48643 > 172.18.0.3.51820: UDP, length 148
@gyokiss commented on GitHub (Apr 9, 2025):
Hi,
I have checked - dns works as expected. Looks good for me: :) dig and nslookup reports back correctly.
Not really yet understood how that should work :) I'm trying. How will be routed a package from newt to gerbil?
If I have right, first the wireguard should be connected. But in case an edge server we have internal IP- on edge. Than should be enabled/masqueraded/forwarded to be able connect. correct?
On newt (edge ) i have recognized, that tries to go out every time on a new port.
what I have found: there is no answer from public accessible server. Thats a
<publicIP> - is the IP of vps server,
<gateway> - is the IP of Mikrotik router - hiding the edge.
It looks like that would like to have some additinal mikrotik config?
```
root@newtendpoint:~# sudo tcpdump -ni any udp port 51820
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
16:00:45.446382 enp1s0 Out IP 192.168.190.xxx.48643 > <publicIP>.51820: UDP, length 148
16:00:50.447556 enp1s0 Out IP 192.168.190.xxx.48643 > <publicIP>.51820: UDP, length 148
16:00:55.447870 enp1s0 Out IP 192.168.190.xxx.48643 > <publicIP>.51820: UDP, length 148
16:01:00.448236 enp1s0 Out IP 192.168.190.xxx.48643 > <publicIP>.51820: UDP, length 148
```
on the vps:
```
16:02:55.706916 br-f6e3e98296b4 In IP 172.18.0.3.51820 > <gateway>.48643: UDP, length 92
16:02:55.706957 eth0 Out IP <publicIP>.51820 > <gateway>.48643: UDP, length 92
16:03:00.706884 eth0 In IP <gateway>.48643 > <publicIP>.51820: UDP, length 148
16:03:00.706935 br-f6e3e98296b4 Out IP <gateway>.48643 > 172.18.0.3.51820: UDP, length 148
16:03:00.706945 veth7eee39c Out IP <gateway>.48643 > 172.18.0.3.51820: UDP, length 148
16:03:00.707867 veth7eee39c P IP 172.18.0.3.51820 > <gateway>.48643: UDP, length 92
16:03:00.707867 br-f6e3e98296b4 In IP 172.18.0.3.51820 > <gateway>.48643: UDP, length 92
16:03:00.707912 eth0 Out IP <publicIP>.51820 > <gateway>.48643: UDP, length 92
16:03:05.707207 eth0 In IP <gateway>.48643 > <publicIP>9.51820: UDP, length 148
16:03:05.707278 br-f6e3e98296b4 Out IP <gateway>.48643 > 172.18.0.3.51820: UDP, length 148
16:03:05.707287 veth7eee39c Out IP <gateway>.48643 > 172.18.0.3.51820: UDP, length 148
```
@github-actions[bot] commented on GitHub (Apr 24, 2025):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
@github-actions[bot] commented on GitHub (Apr 24, 2025):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
@github-actions[bot] commented on GitHub (May 8, 2025):
This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.
@github-actions[bot] commented on GitHub (May 8, 2025):
This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.
@oschwartz10612 commented on GitHub (Jul 6, 2025):
Hi @Gater73. Sorry you are having this issue! Just triple check that:
you have the correct UDP port 51820 open on the VPS
you have no firewall rules on the VPS (ufw, iptables, nftables) blocking UDP port 51820
You do not have Cloudflare proxy on (or you are using the VPS ip in the gerbil config)
Its almost always one of these
@oschwartz10612 commented on GitHub (Jul 6, 2025):
Hi @Gater73. Sorry you are having this issue! Just triple check that:
- you have the correct UDP port 51820 open on the VPS
- you have no firewall rules on the VPS (ufw, iptables, nftables) blocking UDP port 51820
- You do not have Cloudflare proxy on (or you are using the VPS ip in the gerbil config)
Its almost always one of these
It was the protocol in Oracle Cloud, thank you!!!!
@Gater73 commented on GitHub (Jul 6, 2025):
It was the protocol in Oracle Cloud, thank you!!!!
<img width="1542" height="221" alt="Image" src="https://github.com/user-attachments/assets/b62ed15f-091f-4f5c-935a-25d701b60467" />
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 @gyokiss on GitHub (Apr 8, 2025).
Dear all,
pangolin is promising, so I have decided to install it, mostly basic setup. I decided first to get the easyest method, docker everything, and newt on lab server.
my lab is behind mikrotik router, i think that should not be a showstopper.
Issue I'm facing: trhe newt would like to ping, but fails, handshake initiated every 5 sec, but where I can see, that is successful?
I think with newt I have issue, but even the debug option helps a little bit less, than I think required for me to get to the root of issue.
Additional infomation: the site on pangolin reports online.... ( but my site gives ofc gateway timeout)
any idea where to debug?
@oschwartz10612 commented on GitHub (Apr 9, 2025):
Hi thanks for trying out pangolin and I am sorry you are having this issue!
Are you installing Pangolin on the same network in which you intend to proxy resources? The network behind Mikrotik? Is so you do not need Newt because there is no reason to tunnel and you can just use local sites: https://docs.fossorial.io/Pangolin/without-tunneling
Otherwise I would make sure that UDP port 51820 is open coming into your network to Gerbil the Wireguard server. If you are still experiencing the issue could you redact and post your Newt logs and config?
@gyokiss commented on GitHub (Apr 9, 2025):
Hi thanks for your answer,
For clarify: pangolin runs in vps (hetzner cloud), edge server in a local network, protected with mikrotik. on vps all required ports are open.
If I start newt with debug (i have removed some keys and ip's), ping fails.
Interessant pangolin webUI shows the site online.
Another test, I have created a site with basic wireguard, there the connection comes up - there is not clear how to set in pangolin the target in resource to get the service.
On pangolin side how to get logs?
Thanks
@gyokiss commented on GitHub (Apr 9, 2025):
Hi,
update a little bit, If I start newt in host, without any docker etc. should it create an interface? where should I see the ip from newt would like to go out? My edge OS: ubuntu server 24.04.2
Even the routing table is "free" from network 100.89.128.x....
@oschwartz10612 commented on GitHub (Apr 9, 2025):
Newt uses a fully user space network stack called gvisor/netstack. You will not see an interface get created. This is part of what makes it so portable! The
100.89.128.4address is the internet Wireguard network between gerbil and newt that is pinging.Does your pangolin<.myserver> domain resolve to the IP of the VPS? I.E. your domain is not behind Cloudflare's proxy or anything else like that? Also I would triple check your ports are open. You can use dig/nslookup to test the DNS resolution on the edge server running Newt.
This is almost always a network issue with Wireguard packets failing to make it to the VPS.
@gyokiss commented on GitHub (Apr 9, 2025):
Hi,
I have checked - dns works as expected. Looks good for me: :) dig and nslookup reports back correctly.
Not really yet understood how that should work :) I'm trying. How will be routed a package from newt to gerbil?
If I have right, first the wireguard should be connected. But in case an edge server we have internal IP- on edge. Than should be enabled/masqueraded/forwarded to be able connect. correct?
On newt (edge ) i have recognized, that tries to go out every time on a new port.
what I have found: there is no answer from public accessible server. Thats a
- is the IP of vps server,
- is the IP of Mikrotik router - hiding the edge.
It looks like that would like to have some additinal mikrotik config?
on the vps:
@github-actions[bot] commented on GitHub (Apr 24, 2025):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
@github-actions[bot] commented on GitHub (May 8, 2025):
This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.
@Gater73 commented on GitHub (Jul 5, 2025):
Also have the same problem, i have pangolin running in a Oracle Cloud VPS, all ports open, and newt in a local ubuntu server in my local network
INFO: 2025/07/05 23:31:14 Received: {Type:newt/wg/connect Data:map[endpoint:pangolin.{my_domain}:51820 publicKey:{pubKey} serverIP:100.89.128.1 targets:map[tcp:[] udp:[]] tunnelIP:100.89.128.4]}
INFO: 2025/07/05 23:31:15 WireGuard device created. Lets ping the server now...
INFO: 2025/07/05 23:31:15 Ping attempt 1
INFO: 2025/07/05 23:31:15 Pinging 100.89.128.1
WARN: 2025/07/05 23:31:25 Ping attempt 1 failed: failed to read ICMP packet: i/o timeout
INFO: 2025/07/05 23:31:25 Starting ping check
INFO: 2025/07/05 23:31:25 Ping attempt 2
INFO: 2025/07/05 23:31:25 Pinging 100.89.128.1
WARN: 2025/07/05 23:31:35 Ping attempt 2 failed: failed to read ICMP packet: i/o timeout
@oschwartz10612 commented on GitHub (Jul 6, 2025):
Hi @Gater73. Sorry you are having this issue! Just triple check that:
Its almost always one of these
@Gater73 commented on GitHub (Jul 6, 2025):
Hi, after verifying those points we have:
Ports 80/tcp, 443/tcp and 51820/tcp allowed via ufw
and for the gerbil config we have:
Still getting:
Edit: my bad totally, just saw the rule in Oracle Cloud is not UDP but a TCP
@Gater73 commented on GitHub (Jul 6, 2025):
It was the protocol in Oracle Cloud, thank you!!!!
@ITz-Viks commented on GitHub (Sep 27, 2025):
For me, it was Cloudflare proxy. Many thanks oschwartz10612.