You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unable to connect private resource using alias via Pangolin Client #50
When using DNS alias I cannot connect/ping remote resource.
When I use the remote IP it works just fine.
Is there something that can be done to fix the remote alias?
Aliases do not currently support ICMP ping requests. If you attempt to ping an alias, it will not respond, even if the underlying Resource is reachable. This is because the Pangolin client does not intercept ICMP packets for alias resolution.
it works. i'm am idiot... need to add the port after the alias.
is there a way in private resources to select the port in the destination like in open resources?
192.168.x.x:port was not acceepted.
it works. i'm am idiot... need to add the port after the alias. is there a way in private resources to select the port in the destination like in open resources? 192.168.x.x:port was not acceepted.
No, as the private resources are just an alias DNS lookup for convenience it doesnt act as a proxy to know if you go to "host.internal" you want to speak to a specific port.
So from the images, it seems the background process that handles DNS requests is being rejected. Do you have any filtering or firewall rules that could block requests to port 53 if its not localhost?
Looks like a compatibility issue with systemd-resolved and Pangolin as I am just using a default setup.
If there is any guidance someone can provide that would be fantastic.
@3gmgithub
In my case, /etc/resolv.conf was being managed by dhcpd, and pangolin changes made by systemd-resolv did not work.
Linking systemd-resolv generated config to /etc/resolv.conf solved the issue.
I ran into the same issue and have observed, that while connectivity works when using the destination IP addresses directly, connectivity did not work through the IPs returned by Olm/pangolin-cli DNS.
My Setup
Running Olm/pangolin-cli on a Debian 13 (trixie) VPS in a Docker container (with network_mode: host)
Pangolin instance has been running since Pangolin version 1.9.4 and has been upgrade (release by release) to 1.18.3
Started to use private resources with Pangolin version 1.14.1 and with Olm 1.3.0 as a machine client
Now switched to pangolin-cli (0.8.2) instead of Olm (1.5.0), but problem occured with both
I have two private resources configured:
foo.test (10.0.0.21)
Port restriction
TCP: 443
Access control
Machine Client: My Olm/pangolin-cli client
bar.test (10.0.0.42)
Port restriction
TCP: 443
Access control
Machine Client: My Olm/pangolin-cli client
Debugging steps
Olm/pangolin-cli has properly configured the network routes:
$ ip route
...
10.0.0.21 dev pangolin
10.0.0.42 dev pangolin
100.90.128.0/24 dev pangolin proto kernel scope link src 100.90.128.2
100.96.128.0/24 dev pangolin
...
However, when testing connectivity with telnet it was not possible to establish a connection through the IP returned by the Olm/pangolin-cli:
$ telnet 100.96.128.8 443
Trying 100.96.128.8...
telnet: Unable to connect to remote host: Connection timed out
$ telnet 100.96.128.9 443
Trying 100.96.128.9...
telnet: Unable to connect to remote host: Connection timed out
But it was possible to establish a connection through the destination IP addresses configured for the private resources:
$ telnet 10.0.0.21 443
Trying 10.0.0.21...
Connected to 10.0.0.21.
$ telnet 10.0.0.42 443
Trying 10.0.0.42...
Connected to 10.0.0.42.
The Workaround
I was able to restore connectivity by removing the machine client from the private resources access control and re-adding it. Maybe it was a display bug in Pangolin where the machine client was listed as having access, but this was not propagated to Olm/pangolin-cli? Maybe due to the incremental upgrades of the Pangolin instance?
Interestingly, I only manually updated one of the two private resources (intending to keep the second one available for debugging). However, after a few days the connectivity for the second private resource has also been restored without my intervention.
Activity
Tanki90 commentedon Feb 25, 2026
same problem :-(
kreativekrise commentedon Feb 25, 2026
The documentation says:
Source: https://docs.pangolin.net/manage/resources/private/alias#icmp-ping
miloschwartz commentedon Feb 25, 2026
@kreativekrise is correct and aliases not supporting icmp ping is currently a small quirk.
More importantly, are you able to access the resource with the alias regardless of the ping status?
3gmgithub commentedon Feb 25, 2026
When using the local IP of the remote device I can connect no problem.
Tanki90 commentedon Feb 25, 2026
it works. i'm am idiot... need to add the port after the alias.
is there a way in private resources to select the port in the destination like in open resources?
192.168.x.x:port was not acceepted.
3gmgithub commentedon Feb 26, 2026
I ran
ssh root@alias -p 22and it does not work.LaurenceJJones commentedon Feb 27, 2026
No, as the private resources are just an alias DNS lookup for convenience it doesnt act as a proxy to know if you go to "host.internal" you want to speak to a specific port.
LaurenceJJones commentedon Feb 27, 2026
Okay, can you provide these details:
pangolin status(you should see your sites and relay information)cat /etc/resolv.conf(should benameserver 100.X)3gmgithub commentedon Mar 2, 2026
I am using Linux mint, and that uses systemd-resolved...
So I added a file like this:
This seems to at least help, but does not solve the problem.
I will try adding directly to
/etc/resolv.confto see if this helps.3gmgithub commentedon Mar 2, 2026
No luck still having issues... Any suggestions?
3gmgithub commentedon Mar 3, 2026
Here are some photos of the problem...
LaurenceJJones commentedon Mar 4, 2026
So from the images, it seems the background process that handles DNS requests is being rejected. Do you have any filtering or firewall rules that could block requests to port 53 if its not localhost?
3gmgithub commentedon Mar 4, 2026
No I did not setup anything like that. This would have to be default for Linux Mint 22.3
Are there any ideas on what to check on the backend? I will test on Windows to see if I have the same problems.
github-actions commentedon Mar 19, 2026
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.
3gmgithub commentedon Mar 19, 2026
After further testing it does work with Windows, so something on the default install with Linux Mint 22.3 causes DNS issues.
3gmgithub commentedon Mar 19, 2026
Looks like a compatibility issue with systemd-resolved and Pangolin as I am just using a default setup.
If there is any guidance someone can provide that would be fantastic.
LaurenceJJones commentedon Mar 20, 2026
Transfered to cli repo so we can continue in the right repo.
Can you please test out version
0.5.3of the cli and see if its still an issue we done some work onolmthe underlying sdk.also if you run with
--attachand--log-level debugso we can see what is happening inside olm, could help us further debug.I have spin up a test mint box, and everything is working as expected.
3gmgithub commentedon Mar 20, 2026
Thank you so much! Running the test now with the options you suggested.
Here is a log for your review:
gcebollero commentedon Apr 16, 2026
@3gmgithub
In my case,
/etc/resolv.confwas being managed by dhcpd, and pangolin changes made bysystemd-resolvdid not work.Linking
systemd-resolvgenerated config to/etc/resolv.confsolved the issue.Run as root
iWangJiaxiang commentedon Apr 22, 2026
I run into same issue and I have a fix.
In my case, I used machine id to connect to pangolin and can not connect to any private resource.
What I did is using user login to pangolin. Everything works!
psrb commentedon May 19, 2026
I ran into the same issue and have observed, that while connectivity works when using the destination IP addresses directly, connectivity did not work through the IPs returned by Olm/pangolin-cli DNS.
My Setup
network_mode: host)I have two private resources configured:
Debugging steps
Olm/pangolin-cli has properly configured the network routes:
DNS resolution is working as well:
However, when testing connectivity with
telnetit was not possible to establish a connection through the IP returned by the Olm/pangolin-cli:But it was possible to establish a connection through the destination IP addresses configured for the private resources:
The Workaround
I was able to restore connectivity by removing the machine client from the private resources access control and re-adding it. Maybe it was a display bug in Pangolin where the machine client was listed as having access, but this was not propagated to Olm/pangolin-cli? Maybe due to the incremental upgrades of the Pangolin instance?
Interestingly, I only manually updated one of the two private resources (intending to keep the second one available for debugging). However, after a few days the connectivity for the second private resource has also been restored without my intervention.