[GH-ISSUE #2053] Pangolin Can’t Ping Sites #2058

New Issue

GiteaMirror · 2026-04-16T09:01:01-05:00

GiteaMirror commented

2026-04-16 09:01:01 -05:00

Originally created by @poyasyn on GitHub (Dec 12, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2053

Describe the Bug

Hi! I’ve been trying to route resources to containers on Newt connected sites using both the assigned IP and container hostnames (after confirming Newt shared network with said containers) to no avail. I decided to ping the assigned IP but got 100% packet loss; only clue is the Newt logs displaying the WG error “context deadline exceeded.” On Pangolin’s end, however, the site health checks are marked as healthy all throughout. There are no firewall conflicts, port conflicts, etc. that would imply why the pings are failing.

Environment

OS Type & Version: Ubuntu 24.04
Pangolin Version: 1.13.0
Gerbil Version: 1.3.0
Traefik Version: 3.6
Newt Version: 1.7

To Reproduce

Create a fresh Pangolin install. Set up UFW in accordance with Pangolin’s documentation. Create a site using the docker compose format. Start up Newt compose on target VPS, UFW also configured to documentation and adjusted for Newt’s organically chosen port (2112 in this case). Site should show as healthy and functional. Create a resource pointed at a known to be functional and accessible, it should show as 404 or timeout when assigned URL is attempted. Pinging assigned IP loses all packets.

Expected Behavior

Resource URL points to site resource and Pangolin VPS can ping Newt connected sites using its assigned IP.

Originally created by @poyasyn on GitHub (Dec 12, 2025). Original GitHub issue: https://github.com/fosrl/pangolin/issues/2053 ### Describe the Bug Hi! I’ve been trying to route resources to containers on Newt connected sites using both the assigned IP and container hostnames (after confirming Newt shared network with said containers) to no avail. I decided to ping the assigned IP but got 100% packet loss; only clue is the Newt logs displaying the WG error “context deadline exceeded.” On Pangolin’s end, however, the site health checks are marked as healthy all throughout. There are no firewall conflicts, port conflicts, etc. that would imply why the pings are failing. ### Environment - OS Type & Version: Ubuntu 24.04 - Pangolin Version: 1.13.0 - Gerbil Version: 1.3.0 - Traefik Version: 3.6 - Newt Version: 1.7 ### To Reproduce Create a fresh Pangolin install. Set up UFW in accordance with Pangolin’s documentation. Create a site using the docker compose format. Start up Newt compose on target VPS, UFW also configured to documentation and adjusted for Newt’s organically chosen port (2112 in this case). Site should show as healthy and functional. Create a resource pointed at a known to be functional and accessible, it should show as 404 or timeout when assigned URL is attempted. Pinging assigned IP loses all packets. ### Expected Behavior Resource URL points to site resource and Pangolin VPS can ping Newt connected sites using its assigned IP.

GiteaMirror added the stale label 2026-04-16 09:01:01 -05:00

GiteaMirror closed this issue

2026-04-16 09:01:02 -05:00

GiteaMirror commented

2026-04-16 09:01:03 -05:00

@poyasyn commented on GitHub (Dec 12, 2025):

so, I did some more checking and it seems that, even though Newt is installed correctly, the docker socket on its server is actually not listening for 51820, 2112, or the internal port the Newt container is using (39888). every other container is being listened to in accordance with their assigned ports, just not Newt

@poyasyn commented on GitHub (Dec 12, 2025): so, I did some more checking and it seems that, even though Newt is installed correctly, the docker socket on its server is actually not listening for 51820, 2112, or the internal port the Newt container is using (39888). every other container is being listened to in accordance with their assigned ports, just not Newt

GiteaMirror commented

2026-04-16 09:01:03 -05:00

@poyasyn commented on GitHub (Dec 12, 2025):

explicitly mounted docker socket and rebooted to no avail, still not being listened to

@poyasyn commented on GitHub (Dec 12, 2025): explicitly mounted docker socket and rebooted to no avail, still not being listened to

GiteaMirror commented

2026-04-16 09:01:03 -05:00

@oschwartz10612 commented on GitHub (Dec 12, 2025):

Hi! Sounds like you are trying to do a couple of things here. I think you are trying out the new clients so thank you for doing that!

On the ICMP pinging: right now that is not supported and I left a note in the docs here about it to warn people in the future. We plan to add this soon.

On the docker socket: mounting the socket is used for discovery of resources for the Pangolin dashboard and for use with blueprints.

On the port: for client connectivity and for connectivity to the Pangolin server newt generates random ports. If you would like to make that static so you can open firewall ports you could use the --port or PORT env var to set an explicit port to listen on.

I would suggest attempting a TCP or UDP connection to start. If that is not working could you please put newt into debug mode with LOG_LEVEL or --log-level and try to access the resource and send the log output here please? You can also check in the preferences > status section of the pangolin desktop application if it is connected to this site. If it is not connected that could also be causing issues.

@oschwartz10612 commented on GitHub (Dec 12, 2025): Hi! Sounds like you are trying to do a couple of things here. I think you are trying out the new clients so thank you for doing that! On the ICMP pinging: right now that is not supported and I left a note in the docs [here](https://docs.pangolin.net/manage/resources/private/destinations#why-is-icmp-pinging-not-working) about it to warn people in the future. We plan to add this soon. On the docker socket: mounting the socket is used for discovery of resources for the Pangolin dashboard and for use with [blueprints](https://docs.pangolin.net/manage/blueprints). On the port: for client connectivity and for connectivity to the Pangolin server newt generates random ports. If you would like to make that static so you can open firewall ports you could use the --port or PORT env var to set an explicit port to listen on. I would suggest attempting a TCP or UDP connection to start. If that is not working could you please put newt into debug mode with LOG_LEVEL or --log-level and try to access the resource and send the log output here please? You can also check in the preferences > status section of the pangolin desktop application if it is connected to this site. If it is not connected that could also be causing issues.

GiteaMirror commented

2026-04-16 09:01:04 -05:00

@poyasyn commented on GitHub (Dec 13, 2025):

so ! a couple notes:

-the pocket-id-pocket-id-1 container passed health checks and even loaded the site properly when initially accessed. in under a minute, visiting the page then timed out and eventually became a 404 error

-raw tcp resource on port 5335; the port is completely functionally assigned on the VPS itself

-it seems that testing local reverse proxies (i.e. Caddy, Traefik) works perfectly fine. the issue seems to be newt being denied connections or otherwise not finding the docker socket albeit it explicitly mounted in newt’s docker-compose.yml

i sanitized the logs, my apologies if there's a better way to format, i'm quite new at git


DEBUG: 2025/12/13 01:39:21 Docker not reachable via unix at /var/run/docker.sock: dial unix /var/run/docker.sock: connect: no such file or directory
DEBUG: 2025/12/13 01:39:21 Sending message: newt/socket/status, data: map[available:false socketPath:/var/run/docker.sock]
DEBUG: 2025/12/13 01:39:21 Docker socket check response sent: available=false

DEBUG: 2025/12/13 01:50:58 Sent UDP hole punch to NEWT.VPS.IP.ADD:21820: {"ephemeralPublicKey":"KPi/l7KQCYYXdzim7ahFWZgPBbQrbs9RFpGDy8U+pDA=","nonce":"/htoiT8UmzGTWQWB","ciphertext":"FS4IUEFrtIMjCmuojMUNVnujeN/YkhtpTVkjLvHRlb0puna5P75qkmAwi45/u1DEUVEBhTyNb9u4d11dR2z9OVCUnZsahjx9I0iRoYD7Tf9i7HDsMZyGzsWaQ+XuEZ2KyKmO90uZHmJcTurRLKTi1lFNqQf3Hwe7LDf0YPtjL6ip4BsnbDBHlZr0RWX9Fyb+Jgs="}

DEBUG: 2025/12/13 01:51:00 Target 1: performing health check 443 to http://NEWT.ASSIGNED.IP.ADD:5380/
WARN: 2025/12/13 01:51:05 Target 1: health check failed: Get "http://NEWT.ASSIGNED.IP.ADD:5380/": context deadline exceeded

DEBUG: 2025/12/13 01:51:19 Target 3: performing health check 44 to http://pocket-id-pocket-id-1:1411/
WARN: 2025/12/13 01:51:19 Target 3: health check failed: Get "http://pocket-id-pocket-id-1:1411/": dial tcp: lookup pocket-id-pocket-id-1 on 127.0.0.1:53: no such host

DEBUG: 2025/12/13 01:51:27 Target 4: performing health check 35 to http://dns-server:5335/
WARN: 2025/12/13 01:51:27 Target 4: health check failed: Get "http://dns-server:5335/": dial tcp NEWT.VPS.IP.ADD:5335: connect: connection refused

@poyasyn commented on GitHub (Dec 13, 2025): so ! a couple notes: -the pocket-id-pocket-id-1 container passed health checks and even loaded the site properly when initially accessed. in under a minute, visiting the page then timed out and eventually became a 404 error -raw tcp resource on port 5335; the port is completely functionally assigned on the VPS itself -it seems that testing local reverse proxies (i.e. Caddy, Traefik) works perfectly fine. the issue seems to be newt being denied connections or otherwise not finding the docker socket albeit it explicitly mounted in newt’s docker-compose.yml i sanitized the logs, my apologies if there's a better way to format, i'm quite new at git ``` DEBUG: 2025/12/13 01:39:21 Docker not reachable via unix at /var/run/docker.sock: dial unix /var/run/docker.sock: connect: no such file or directory DEBUG: 2025/12/13 01:39:21 Sending message: newt/socket/status, data: map[available:false socketPath:/var/run/docker.sock] DEBUG: 2025/12/13 01:39:21 Docker socket check response sent: available=false DEBUG: 2025/12/13 01:50:58 Sent UDP hole punch to NEWT.VPS.IP.ADD:21820: {"ephemeralPublicKey":"KPi/l7KQCYYXdzim7ahFWZgPBbQrbs9RFpGDy8U+pDA=","nonce":"/htoiT8UmzGTWQWB","ciphertext":"FS4IUEFrtIMjCmuojMUNVnujeN/YkhtpTVkjLvHRlb0puna5P75qkmAwi45/u1DEUVEBhTyNb9u4d11dR2z9OVCUnZsahjx9I0iRoYD7Tf9i7HDsMZyGzsWaQ+XuEZ2KyKmO90uZHmJcTurRLKTi1lFNqQf3Hwe7LDf0YPtjL6ip4BsnbDBHlZr0RWX9Fyb+Jgs="} DEBUG: 2025/12/13 01:51:00 Target 1: performing health check 443 to http://NEWT.ASSIGNED.IP.ADD:5380/ WARN: 2025/12/13 01:51:05 Target 1: health check failed: Get "http://NEWT.ASSIGNED.IP.ADD:5380/": context deadline exceeded DEBUG: 2025/12/13 01:51:19 Target 3: performing health check 44 to http://pocket-id-pocket-id-1:1411/ WARN: 2025/12/13 01:51:19 Target 3: health check failed: Get "http://pocket-id-pocket-id-1:1411/": dial tcp: lookup pocket-id-pocket-id-1 on 127.0.0.1:53: no such host DEBUG: 2025/12/13 01:51:27 Target 4: performing health check 35 to http://dns-server:5335/ WARN: 2025/12/13 01:51:27 Target 4: health check failed: Get "http://dns-server:5335/": dial tcp NEWT.VPS.IP.ADD:5335: connect: connection refused ```

GiteaMirror commented

2026-04-16 09:01:04 -05:00

@HearthCore commented on GitHub (Dec 14, 2025):

Also make sure to check the correct socket string. It seems there are a few additional slashes needed after I first instituted them to my compose files?

@HearthCore commented on GitHub (Dec 14, 2025): Also make sure to check the correct socket string. It seems there are a few additional slashes needed after I first instituted them to my compose files?

GiteaMirror commented

2026-04-16 09:01:05 -05:00

@poyasyn commented on GitHub (Dec 17, 2025):

Also make sure to check the correct socket string. It seems there are a few additional slashes needed after I first instituted them to my compose files?

thanks! could you elaborate a bit on the additional slashes you needed? assuming in newt container

@poyasyn commented on GitHub (Dec 17, 2025): > Also make sure to check the correct socket string. It seems there are a few additional slashes needed after I first instituted them to my compose files? thanks! could you elaborate a bit on the additional slashes you needed? assuming in newt container

GiteaMirror commented

2026-04-16 09:01:05 -05:00

@github-actions[bot] commented on GitHub (Dec 31, 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 (Dec 31, 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.

GiteaMirror commented

2026-04-16 09:01:06 -05:00

@github-actions[bot] commented on GitHub (Jan 14, 2026):

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 (Jan 14, 2026): 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.