Beginner help needed #226

Closed
opened 2025-11-13 11:53:37 -06:00 by GiteaMirror · 12 comments
Owner

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?
GiteaMirror added the stale label 2025-11-13 11:53:37 -06:00
Author
Owner

@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?
Author
Owner

@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

root@newtendpoint:~# ./newt --id <> --secret <> --endpoint https://pangolin<.myserver>    -log-level DEBUG
DEBUG: 2025/04/09 07:35:00 Public key: <>
INFO: 2025/04/09 07:35:00 Sent registration message
INFO: 2025/04/09 07:35:01 Received registration message
INFO: 2025/04/09 07:35:01 Received: {Type:newt/wg/connect Data:map[endpoint:pangolin<.myserver>:51820 publicKey:<> serverIP:100.89.128.1 targets:map[tcp:[54267:<internal server to reach>:8086] udp:[]] tunnelIP:100.89.128.4]}
DEBUG: wireguard: 2025/04/09 07:35:01 Routine: handshake worker 1 - started
DEBUG: wireguard: 2025/04/09 07:35:01 Routine: encryption worker 1 - started
DEBUG: wireguard: 2025/04/09 07:35:01 Routine: decryption worker 1 - started
DEBUG: wireguard: 2025/04/09 07:35:01 Routine: handshake worker 2 - started
DEBUG: wireguard: 2025/04/09 07:35:01 Routine: encryption worker 2 - started
DEBUG: wireguard: 2025/04/09 07:35:01 Routine: decryption worker 2 - started
DEBUG: wireguard: 2025/04/09 07:35:01 Routine: event worker - started
DEBUG: wireguard: 2025/04/09 07:35:01 Interface up requested
DEBUG: wireguard: 2025/04/09 07:35:01 Routine: TUN reader - started
DEBUG: wireguard: 2025/04/09 07:35:01 UDP bind has been updated
DEBUG: wireguard: 2025/04/09 07:35:01 Interface state was Down, requested Up, now Up
DEBUG: wireguard: 2025/04/09 07:35:01 Routine: receive incoming v6 - started
DEBUG: wireguard: 2025/04/09 07:35:01 Routine: receive incoming v4 - started
DEBUG: wireguard: 2025/04/09 07:35:01 UAPI: Updating private key
DEBUG: wireguard: 2025/04/09 07:35:01 peer(7wni…MVH4) - UAPI: Created
DEBUG: wireguard: 2025/04/09 07:35:01 peer(7wni…MVH4) - UAPI: Adding allowedip
DEBUG: wireguard: 2025/04/09 07:35:01 peer(7wni…MVH4) - UAPI: Updating endpoint
DEBUG: wireguard: 2025/04/09 07:35:01 peer(7wni…MVH4) - UAPI: Updating persistent keepalive interval
DEBUG: wireguard: 2025/04/09 07:35:01 peer(7wni…MVH4) - Starting
DEBUG: wireguard: 2025/04/09 07:35:01 peer(7wni…MVH4) - Sending keepalive packet
DEBUG: wireguard: 2025/04/09 07:35:01 peer(7wni…MVH4) - Sending handshake initiation
DEBUG: wireguard: 2025/04/09 07:35:01 peer(7wni…MVH4) - Routine: sequential sender - started
DEBUG: wireguard: 2025/04/09 07:35:01 peer(7wni…MVH4) - Routine: sequential receiver - started
INFO: 2025/04/09 07:35:01 WireGuard device created. Lets ping the server now...
INFO: 2025/04/09 07:35:01 Ping attempt 1
INFO: 2025/04/09 07:35:01 Pinging 100.89.128.1
DEBUG: wireguard: 2025/04/09 07:35:06 peer(7wni…MVH4) - Sending handshake initiation
DEBUG: wireguard: 2025/04/09 07:35:11 peer(7wni…MVH4) - Sending handshake initiation
WARN: 2025/04/09 07:35:11 Ping attempt 1 failed: failed to read ICMP packet: i/o timeout
INFO: 2025/04/09 07:35:11 Starting ping check
DEBUG: 2025/04/09 07:35:11 Not adding target because not running
INFO: 2025/04/09 07:35:11 Started tcp proxy from 100.89.128.4:54267 to <internal server to reach>:8086
INFO: 2025/04/09 07:35:11 Ping attempt 2
INFO: 2025/04/09 07:35:11 Pinging 100.89.128.1
DEBUG: wireguard: 2025/04/09 07:35:16 peer(7wni…MVH4) - Sending handshake initiation
WARN: 2025/04/09 07:35:21 Ping attempt 2 failed: failed to read ICMP packet: i/o timeout
DEBUG: wireguard: 2025/04/09 07:35:21 peer(7wni…MVH4) - Sending handshake initiat
@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 ``` root@newtendpoint:~# ./newt --id <> --secret <> --endpoint https://pangolin<.myserver> -log-level DEBUG DEBUG: 2025/04/09 07:35:00 Public key: <> INFO: 2025/04/09 07:35:00 Sent registration message INFO: 2025/04/09 07:35:01 Received registration message INFO: 2025/04/09 07:35:01 Received: {Type:newt/wg/connect Data:map[endpoint:pangolin<.myserver>:51820 publicKey:<> serverIP:100.89.128.1 targets:map[tcp:[54267:<internal server to reach>:8086] udp:[]] tunnelIP:100.89.128.4]} DEBUG: wireguard: 2025/04/09 07:35:01 Routine: handshake worker 1 - started DEBUG: wireguard: 2025/04/09 07:35:01 Routine: encryption worker 1 - started DEBUG: wireguard: 2025/04/09 07:35:01 Routine: decryption worker 1 - started DEBUG: wireguard: 2025/04/09 07:35:01 Routine: handshake worker 2 - started DEBUG: wireguard: 2025/04/09 07:35:01 Routine: encryption worker 2 - started DEBUG: wireguard: 2025/04/09 07:35:01 Routine: decryption worker 2 - started DEBUG: wireguard: 2025/04/09 07:35:01 Routine: event worker - started DEBUG: wireguard: 2025/04/09 07:35:01 Interface up requested DEBUG: wireguard: 2025/04/09 07:35:01 Routine: TUN reader - started DEBUG: wireguard: 2025/04/09 07:35:01 UDP bind has been updated DEBUG: wireguard: 2025/04/09 07:35:01 Interface state was Down, requested Up, now Up DEBUG: wireguard: 2025/04/09 07:35:01 Routine: receive incoming v6 - started DEBUG: wireguard: 2025/04/09 07:35:01 Routine: receive incoming v4 - started DEBUG: wireguard: 2025/04/09 07:35:01 UAPI: Updating private key DEBUG: wireguard: 2025/04/09 07:35:01 peer(7wni…MVH4) - UAPI: Created DEBUG: wireguard: 2025/04/09 07:35:01 peer(7wni…MVH4) - UAPI: Adding allowedip DEBUG: wireguard: 2025/04/09 07:35:01 peer(7wni…MVH4) - UAPI: Updating endpoint DEBUG: wireguard: 2025/04/09 07:35:01 peer(7wni…MVH4) - UAPI: Updating persistent keepalive interval DEBUG: wireguard: 2025/04/09 07:35:01 peer(7wni…MVH4) - Starting DEBUG: wireguard: 2025/04/09 07:35:01 peer(7wni…MVH4) - Sending keepalive packet DEBUG: wireguard: 2025/04/09 07:35:01 peer(7wni…MVH4) - Sending handshake initiation DEBUG: wireguard: 2025/04/09 07:35:01 peer(7wni…MVH4) - Routine: sequential sender - started DEBUG: wireguard: 2025/04/09 07:35:01 peer(7wni…MVH4) - Routine: sequential receiver - started INFO: 2025/04/09 07:35:01 WireGuard device created. Lets ping the server now... INFO: 2025/04/09 07:35:01 Ping attempt 1 INFO: 2025/04/09 07:35:01 Pinging 100.89.128.1 DEBUG: wireguard: 2025/04/09 07:35:06 peer(7wni…MVH4) - Sending handshake initiation DEBUG: wireguard: 2025/04/09 07:35:11 peer(7wni…MVH4) - Sending handshake initiation WARN: 2025/04/09 07:35:11 Ping attempt 1 failed: failed to read ICMP packet: i/o timeout INFO: 2025/04/09 07:35:11 Starting ping check DEBUG: 2025/04/09 07:35:11 Not adding target because not running INFO: 2025/04/09 07:35:11 Started tcp proxy from 100.89.128.4:54267 to <internal server to reach>:8086 INFO: 2025/04/09 07:35:11 Ping attempt 2 INFO: 2025/04/09 07:35:11 Pinging 100.89.128.1 DEBUG: wireguard: 2025/04/09 07:35:16 peer(7wni…MVH4) - Sending handshake initiation WARN: 2025/04/09 07:35:21 Ping attempt 2 failed: failed to read ICMP packet: i/o timeout DEBUG: wireguard: 2025/04/09 07:35:21 peer(7wni…MVH4) - Sending handshake initiat ```
Author
Owner

@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....

@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....
Author
Owner

@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.
Author
Owner

@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?

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 ```
Author
Owner

@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.
Author
Owner

@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.
Author
Owner

@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

@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
Author
Owner

@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
Author
Owner

@Gater73 commented on GitHub (Jul 6, 2025):

Hi, after verifying those points we have:

Image

Ports 80/tcp, 443/tcp and 51820/tcp allowed via ufw

and for the gerbil config we have:

gerbil:
    start_port: 51820
    base_endpoint: "pangolin.{my_domain}"

Still getting:

WARN: 2025/07/06 18:29:16 Ping attempt 20 failed: failed to read ICMP packet: i/o timeout
INFO: 2025/07/06 18:29:16 Increasing ping retry delay to 10.125s
INFO: 2025/07/06 18:29:19 Pinging 100.89.128.1
INFO: 2025/07/06 18:29:27 Ping attempt 21
INFO: 2025/07/06 18:29:27 Pinging 100.89.128.1
WARN: 2025/07/06 18:29:37 Ping attempt 21 failed: failed to read ICMP packet: i/o timeout
INFO: 2025/07/06 18:29:47 Ping attempt 22
INFO: 2025/07/06 18:29:47 Pinging 100.89.128.1
INFO: 2025/07/06 18:29:49 Pinging 100.89.128.1
WARN: 2025/07/06 18:29:57 Ping attempt 22 failed: failed to read ICMP packet: i/o timeout
INFO: 2025/07/06 18:30:07 Ping attempt 23
INFO: 2025/07/06 18:30:07 Pinging 100.89.128.1

Edit: my bad totally, just saw the rule in Oracle Cloud is not UDP but a TCP

@Gater73 commented on GitHub (Jul 6, 2025): Hi, after verifying those points we have: <img width="1507" height="397" alt="Image" src="https://github.com/user-attachments/assets/bf32df5b-34dd-457a-ba3a-e4003dbdd494" /> Ports 80/tcp, 443/tcp and 51820/tcp allowed via ufw and for the gerbil config we have: ``` gerbil: start_port: 51820 base_endpoint: "pangolin.{my_domain}" ``` Still getting: ``` WARN: 2025/07/06 18:29:16 Ping attempt 20 failed: failed to read ICMP packet: i/o timeout INFO: 2025/07/06 18:29:16 Increasing ping retry delay to 10.125s INFO: 2025/07/06 18:29:19 Pinging 100.89.128.1 INFO: 2025/07/06 18:29:27 Ping attempt 21 INFO: 2025/07/06 18:29:27 Pinging 100.89.128.1 WARN: 2025/07/06 18:29:37 Ping attempt 21 failed: failed to read ICMP packet: i/o timeout INFO: 2025/07/06 18:29:47 Ping attempt 22 INFO: 2025/07/06 18:29:47 Pinging 100.89.128.1 INFO: 2025/07/06 18:29:49 Pinging 100.89.128.1 WARN: 2025/07/06 18:29:57 Ping attempt 22 failed: failed to read ICMP packet: i/o timeout INFO: 2025/07/06 18:30:07 Ping attempt 23 INFO: 2025/07/06 18:30:07 Pinging 100.89.128.1 ``` Edit: my bad totally, just saw the rule in Oracle Cloud is not UDP but a TCP
Author
Owner

@Gater73 commented on GitHub (Jul 6, 2025):

It was the protocol in Oracle Cloud, thank you!!!!

Image
@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" />
Author
Owner

@ITz-Viks commented on GitHub (Sep 27, 2025):

For me, it was Cloudflare proxy. Many thanks oschwartz10612.

@ITz-Viks commented on GitHub (Sep 27, 2025): For me, it was Cloudflare proxy. Many thanks [oschwartz10612](https://github.com/oschwartz10612).
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/pangolin#226