[GH-ISSUE #818] Created site but its offline? #14535

Closed
opened 2026-05-16 02:24:20 -05:00 by GiteaMirror · 9 comments
Owner

Originally created by @amberleaf7 on GitHub (Jun 1, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/818

Hi everyone, I've created my first Pangolin Resource to point towards a local server ip address and port of a service running as a docker container on one of my servers in my LAN. I've also created my first Pangolin site to use Newt running on the same server on my LAN. NB I run Pangolin on a VPS. But the site shows as Offline and if I try to open the associated URL all I get is Bad Gateway.
I'm trying Pangolin as I use a 5G module for my broadband in a pretty dumb device to output the 5G data signal via a RJ45 connection. N.B. there is no functionality to enable a bridge mode on this device, nor does it have any port forwarding functionaIity, hence my trying to use Pangolin on a VPS. I have this ethernet connection connected to a Unifi Cloud Gateway Ultra that in turn is a hub to all my internal lan devices, Wifi AP, servers, switches and smart devices.
When I check the Newt logs I notice it is attempting to ping 100.89.128.1, I do not know what this address is as to the best of my knowledge it is not on a device in my local area network.
I've checked the acme.json file and Traefik has successfully obtained a Letsencrypt certificate for the site.
Clearly I'm missing something when creating a Pangolin site, can anyone help please?

Originally created by @amberleaf7 on GitHub (Jun 1, 2025). Original GitHub issue: https://github.com/fosrl/pangolin/issues/818 Hi everyone, I've created my first Pangolin Resource to point towards a local server ip address and port of a service running as a docker container on one of my servers in my LAN. I've also created my first Pangolin site to use Newt running on the same server on my LAN. NB I run Pangolin on a VPS. But the site shows as Offline and if I try to open the associated URL all I get is Bad Gateway. I'm trying Pangolin as I use a 5G module for my broadband in a pretty dumb device to output the 5G data signal via a RJ45 connection. N.B. there is no functionality to enable a bridge mode on this device, nor does it have any port forwarding functionaIity, hence my trying to use Pangolin on a VPS. I have this ethernet connection connected to a Unifi Cloud Gateway Ultra that in turn is a hub to all my internal lan devices, Wifi AP, servers, switches and smart devices. When I check the Newt logs I notice it is attempting to ping 100.89.128.1, I do not know what this address is as to the best of my knowledge it is not on a device in my local area network. I've checked the acme.json file and Traefik has successfully obtained a Letsencrypt certificate for the site. Clearly I'm missing something when creating a Pangolin site, can anyone help please?
Author
Owner

@oschwartz10612 commented on GitHub (Jun 1, 2025):

Hi!

Could you post your Newt logs? Do you see it trying to ping 100.89.128.1 and failing with a timeout or do you see a latency printed out. If you dont see a latency then newt can not connect to the Pangolin cloud instance.

Usually the ping failures are due to one or both:

  • UDP port 51820 is not open on the server
  • Something is obscuring the public IP of the server such as Cloudflare Proxy being enabled on the DNS records. You can check by making sure what you have entered in gerbil.base_endpoint in the config file resolves to the public IP of the server with dig or nslookup
<!-- gh-comment-id:2927462782 --> @oschwartz10612 commented on GitHub (Jun 1, 2025): Hi! Could you post your Newt logs? Do you see it trying to ping `100.89.128.1` and failing with a timeout or do you see a latency printed out. If you dont see a latency then newt can not connect to the Pangolin cloud instance. Usually the ping failures are due to one or both: - **UDP port 51820 is not open on the server** - Something is obscuring the public IP of the server such as Cloudflare Proxy being enabled on the DNS records. You can check by making sure what you have entered in gerbil.base_endpoint in the config file resolves to the public IP of the server with dig or nslookup
Author
Owner

@amberleaf7 commented on GitHub (Jun 2, 2025):

Thanks for your help,
Newt definitely cannot ping the VPS server - here are part of the logs:
newt | WARN: 2025/06/02 09:27:32 Ping attempt 10 failed: failed to read ICMP packet: i/o timeout
newt | INFO: 2025/06/02 09:27:32 Increasing ping retry delay to 4.5s
newt | INFO: 2025/06/02 09:27:37 Ping attempt 11
newt | INFO: 2025/06/02 09:27:37 Pinging 100.89.128.1
newt | INFO: 2025/06/02 09:27:41 Pinging 100.89.128.1
newt | WARN: 2025/06/02 09:27:47 Ping attempt 11 failed: failed to read ICMP packet: i/o timeout
newt | INFO: 2025/06/02 09:27:51 Ping attempt 12
newt | INFO: 2025/06/02 09:27:51 Pinging 100.89.128.1
newt | WARN: 2025/06/02 09:28:01 Ping attempt 12 failed: failed to read ICMP packet: i/o timeout
On my VPS server the firewall rules allow port 80/tcp port 443/tcp and 51820/udp and my Cloudflare Proxy Status settings for every record is DNS only. I'd applied these settings before I installed Pangolin.
The dig command confirms the public ip address of my VPS. I've tried to ping my VPS address and it fails too - I don't know why as I can ping other sites like google.com from my home servers.
Is there anything else I can try before I ask my VPS provider why ping requests are not being returned?

I have contacted the VPS provider and they have changed my server settings so I can now ping the public ip address from my home server via the command line. NB 100.89.128.1 is not the public IP address of my VPS, it is 217.xxx.xx.xxx. However, Newt is still failing to ping this other (internal?) ip address it is using for Pangolin purposes. So the questions I have is why isn't Newt trying to ping the public address of my VPS and using another ip address instead? And if it has to use this 100.xx.xxx.x ip address what rules do I need to apply on the VPS to enable responses etc to be sent back to devices on my home network?

<!-- gh-comment-id:2929735152 --> @amberleaf7 commented on GitHub (Jun 2, 2025): Thanks for your help, Newt definitely cannot ping the VPS server - here are part of the logs: newt | WARN: 2025/06/02 09:27:32 Ping attempt 10 failed: failed to read ICMP packet: i/o timeout newt | INFO: 2025/06/02 09:27:32 Increasing ping retry delay to 4.5s newt | INFO: 2025/06/02 09:27:37 Ping attempt 11 newt | INFO: 2025/06/02 09:27:37 Pinging 100.89.128.1 newt | INFO: 2025/06/02 09:27:41 Pinging 100.89.128.1 newt | WARN: 2025/06/02 09:27:47 Ping attempt 11 failed: failed to read ICMP packet: i/o timeout newt | INFO: 2025/06/02 09:27:51 Ping attempt 12 newt | INFO: 2025/06/02 09:27:51 Pinging 100.89.128.1 newt | WARN: 2025/06/02 09:28:01 Ping attempt 12 failed: failed to read ICMP packet: i/o timeout On my VPS server the firewall rules allow port 80/tcp port 443/tcp and 51820/udp and my Cloudflare Proxy Status settings for every record is DNS only. I'd applied these settings before I installed Pangolin. The dig command confirms the public ip address of my VPS. I've tried to ping my VPS address and it fails too - I don't know why as I can ping other sites like google.com from my home servers. Is there anything else I can try before I ask my VPS provider why ping requests are not being returned? I have contacted the VPS provider and they have changed my server settings so I can now ping the public ip address from my home server via the command line. NB 100.89.128.1 is not the public IP address of my VPS, it is 217.xxx.xx.xxx. However, Newt is still failing to ping this other (internal?) ip address it is using for Pangolin purposes. So the questions I have is why isn't Newt trying to ping the public address of my VPS and using another ip address instead? And if it has to use this 100.xx.xxx.x ip address what rules do I need to apply on the VPS to enable responses etc to be sent back to devices on my home network?
Author
Owner

@kmanwar89 commented on GitHub (Jun 2, 2025):

Thanks for your help, Newt definitely cannot ping the VPS server - here are part of the logs: newt | WARN: 2025/06/02 09:27:32 Ping attempt 10 failed: failed to read ICMP packet: i/o timeout newt | INFO: 2025/06/02 09:27:32 Increasing ping retry delay to 4.5s newt | INFO: 2025/06/02 09:27:37 Ping attempt 11 newt | INFO: 2025/06/02 09:27:37 Pinging 100.89.128.1 newt | INFO: 2025/06/02 09:27:41 Pinging 100.89.128.1 newt | WARN: 2025/06/02 09:27:47 Ping attempt 11 failed: failed to read ICMP packet: i/o timeout newt | INFO: 2025/06/02 09:27:51 Ping attempt 12 newt | INFO: 2025/06/02 09:27:51 Pinging 100.89.128.1 newt | WARN: 2025/06/02 09:28:01 Ping attempt 12 failed: failed to read ICMP packet: i/o timeout On my VPS server the firewall rules allow port 80/tcp port 443/tcp and 51820/udp and my Cloudflare Proxy Status settings for every record is DNS only. I'd applied these settings before I installed Pangolin. The dig command confirms the public ip address of my VPS. I've tried to ping my VPS address and it fails too - I don't know why as I can ping other sites like google.com from my home servers. Is there anything else I can try before I ask my VPS provider why ping requests are not being returned?

I have contacted the VPS provider and they have changed my server settings so I can now ping the public ip address from my home server via the command line. NB 100.89.128.1 is not the public IP address of my VPS, it is 217.xxx.xx.xxx. However, Newt is still failing to ping this other (internal?) ip address it is using for Pangolin purposes. So the questions I have is why isn't Newt trying to ping the public address of my VPS and using another ip address instead? And if it has to use this 100.xx.xxx.x ip address what rules do I need to apply on the VPS to enable responses etc to be sent back to devices on my home network?

Under the hood, Pangolin is setting up a Wireguard interface, and Newt is the client that is managing these connections. the 100.X IP range is reserved for Carrier-Grade NAT, which is commonly used by solutions such as Tailscale (which also does wireguard under the hood).

It sounds like your VPS does not give you full/complete root control under the hood, and you still have to work with them for some controls. A quick and easy test is spin up a cheap VPS like DigitalOcean, and you'll only pay for the short amount of time that it is online (or could even use Oracle free tier, I suppose). If you encounter the same behavior with DO, then its a config setting on your side, or maybe a bug. If you do not encounter the behavior, it's your VPS provider's settings preventing the communication.

I use both Racknerd and DO and haven't had any connectivity issues with Newt & Pangolin

<!-- gh-comment-id:2930175539 --> @kmanwar89 commented on GitHub (Jun 2, 2025): > Thanks for your help, Newt definitely cannot ping the VPS server - here are part of the logs: newt | WARN: 2025/06/02 09:27:32 Ping attempt 10 failed: failed to read ICMP packet: i/o timeout newt | INFO: 2025/06/02 09:27:32 Increasing ping retry delay to 4.5s newt | INFO: 2025/06/02 09:27:37 Ping attempt 11 newt | INFO: 2025/06/02 09:27:37 Pinging 100.89.128.1 newt | INFO: 2025/06/02 09:27:41 Pinging 100.89.128.1 newt | WARN: 2025/06/02 09:27:47 Ping attempt 11 failed: failed to read ICMP packet: i/o timeout newt | INFO: 2025/06/02 09:27:51 Ping attempt 12 newt | INFO: 2025/06/02 09:27:51 Pinging 100.89.128.1 newt | WARN: 2025/06/02 09:28:01 Ping attempt 12 failed: failed to read ICMP packet: i/o timeout On my VPS server the firewall rules allow port 80/tcp port 443/tcp and 51820/udp and my Cloudflare Proxy Status settings for every record is DNS only. I'd applied these settings before I installed Pangolin. The dig command confirms the public ip address of my VPS. I've tried to ping my VPS address and it fails too - I don't know why as I can ping other sites like google.com from my home servers. Is there anything else I can try before I ask my VPS provider why ping requests are not being returned? > > I have contacted the VPS provider and they have changed my server settings so I can now ping the public ip address from my home server via the command line. NB 100.89.128.1 is not the public IP address of my VPS, it is 217.xxx.xx.xxx. However, Newt is still failing to ping this other (internal?) ip address it is using for Pangolin purposes. So the questions I have is why isn't Newt trying to ping the public address of my VPS and using another ip address instead? And if it has to use this 100.xx.xxx.x ip address what rules do I need to apply on the VPS to enable responses etc to be sent back to devices on my home network? Under the hood, Pangolin is setting up a Wireguard interface, and Newt is the client that is managing these connections. the 100.X IP range is reserved for [Carrier-Grade NAT](https://en.wikipedia.org/wiki/Reserved_IP_addresses), which is commonly used by solutions such as Tailscale (which *also* does wireguard under the hood). It sounds like your VPS does not give you full/complete root control under the hood, and you still have to work with them for some controls. A quick and easy test is spin up a cheap VPS like DigitalOcean, and you'll only pay for the short amount of time that it is online (or could even use Oracle free tier, I suppose). If you encounter the same behavior with DO, then its a config setting on your side, or maybe a bug. If you do *not* encounter the behavior, it's your VPS provider's settings preventing the communication. I use both Racknerd and DO and haven't had any connectivity issues with Newt & Pangolin
Author
Owner

@amberleaf7 commented on GitHub (Jun 2, 2025):

Thanks for your help, Newt definitely cannot ping the VPS server - here are part of the logs: newt | WARN: 2025/06/02 09:27:32 Ping attempt 10 failed: failed to read ICMP packet: i/o timeout newt | INFO: 2025/06/02 09:27:32 Increasing ping retry delay to 4.5s newt | INFO: 2025/06/02 09:27:37 Ping attempt 11 newt | INFO: 2025/06/02 09:27:37 Pinging 100.89.128.1 newt | INFO: 2025/06/02 09:27:41 Pinging 100.89.128.1 newt | WARN: 2025/06/02 09:27:47 Ping attempt 11 failed: failed to read ICMP packet: i/o timeout newt | INFO: 2025/06/02 09:27:51 Ping attempt 12 newt | INFO: 2025/06/02 09:27:51 Pinging 100.89.128.1 newt | WARN: 2025/06/02 09:28:01 Ping attempt 12 failed: failed to read ICMP packet: i/o timeout On my VPS server the firewall rules allow port 80/tcp port 443/tcp and 51820/udp and my Cloudflare Proxy Status settings for every record is DNS only. I'd applied these settings before I installed Pangolin. The dig command confirms the public ip address of my VPS. I've tried to ping my VPS address and it fails too - I don't know why as I can ping other sites like google.com from my home servers. Is there anything else I can try before I ask my VPS provider why ping requests are not being returned?
I have contacted the VPS provider and they have changed my server settings so I can now ping the public ip address from my home server via the command line. NB 100.89.128.1 is not the public IP address of my VPS, it is 217.xxx.xx.xxx. However, Newt is still failing to ping this other (internal?) ip address it is using for Pangolin purposes. So the questions I have is why isn't Newt trying to ping the public address of my VPS and using another ip address instead? And if it has to use this 100.xx.xxx.x ip address what rules do I need to apply on the VPS to enable responses etc to be sent back to devices on my home network?

Under the hood, Pangolin is setting up a Wireguard interface, and Newt is the client that is managing these connections. the 100.X IP range is reserved for Carrier-Grade NAT, which is commonly used by solutions such as Tailscale (which also does wireguard under the hood).

It sounds like your VPS does not give you full/complete root control under the hood, and you still have to work with them for some controls. A quick and easy test is spin up a cheap VPS like DigitalOcean, and you'll only pay for the short amount of time that it is online (or could even use Oracle free tier, I suppose). If you encounter the same behavior with DO, then its a config setting on your side, or maybe a bug. If you do not encounter the behavior, it's your VPS provider's settings preventing the communication.

I use both Racknerd and DO and haven't had any connectivity issues with Newt & Pangolin

Thanks again - your help and advice is very appreciated.

It is becoming very apparent my hobby of trying to prove self hosting can be done by anyone using inexpensive standard home equipment & services is becoming very difficult. When I contacted my VPS provider although they resolved things so I could ping the VPS public ip address they told me I'd have to ask one of their Partners to help resolve the Newt issue of trying to ping the private ip address 100.x. So more flipping expense!! Its all becoming a nightmare really, I only self host systems for my own use and although everything ran perfectly well using a standard ISP Fibre broadband service with just a simple port forward on their provided router to a reverse proxy on my lan with ufw firewall rules to secure things. Since moving to a 5G service with no port forward or bridge mode functionality I can't run a next gen firewall/router option as I planned, nor can I host sites accessible via the web. And now I discover I can't run another system on a VPS like Pangolin. So I guess my best bet is to host my services on the VPS running its own proxy. It is just my hobby and the cost/benefit ratio for me means just paying for more and more services isn't worth it.

<!-- gh-comment-id:2930758037 --> @amberleaf7 commented on GitHub (Jun 2, 2025): > > Thanks for your help, Newt definitely cannot ping the VPS server - here are part of the logs: newt | WARN: 2025/06/02 09:27:32 Ping attempt 10 failed: failed to read ICMP packet: i/o timeout newt | INFO: 2025/06/02 09:27:32 Increasing ping retry delay to 4.5s newt | INFO: 2025/06/02 09:27:37 Ping attempt 11 newt | INFO: 2025/06/02 09:27:37 Pinging 100.89.128.1 newt | INFO: 2025/06/02 09:27:41 Pinging 100.89.128.1 newt | WARN: 2025/06/02 09:27:47 Ping attempt 11 failed: failed to read ICMP packet: i/o timeout newt | INFO: 2025/06/02 09:27:51 Ping attempt 12 newt | INFO: 2025/06/02 09:27:51 Pinging 100.89.128.1 newt | WARN: 2025/06/02 09:28:01 Ping attempt 12 failed: failed to read ICMP packet: i/o timeout On my VPS server the firewall rules allow port 80/tcp port 443/tcp and 51820/udp and my Cloudflare Proxy Status settings for every record is DNS only. I'd applied these settings before I installed Pangolin. The dig command confirms the public ip address of my VPS. I've tried to ping my VPS address and it fails too - I don't know why as I can ping other sites like google.com from my home servers. Is there anything else I can try before I ask my VPS provider why ping requests are not being returned? > > I have contacted the VPS provider and they have changed my server settings so I can now ping the public ip address from my home server via the command line. NB 100.89.128.1 is not the public IP address of my VPS, it is 217.xxx.xx.xxx. However, Newt is still failing to ping this other (internal?) ip address it is using for Pangolin purposes. So the questions I have is why isn't Newt trying to ping the public address of my VPS and using another ip address instead? And if it has to use this 100.xx.xxx.x ip address what rules do I need to apply on the VPS to enable responses etc to be sent back to devices on my home network? > > Under the hood, Pangolin is setting up a Wireguard interface, and Newt is the client that is managing these connections. the 100.X IP range is reserved for [Carrier-Grade NAT](https://en.wikipedia.org/wiki/Reserved_IP_addresses), which is commonly used by solutions such as Tailscale (which _also_ does wireguard under the hood). > > It sounds like your VPS does not give you full/complete root control under the hood, and you still have to work with them for some controls. A quick and easy test is spin up a cheap VPS like DigitalOcean, and you'll only pay for the short amount of time that it is online (or could even use Oracle free tier, I suppose). If you encounter the same behavior with DO, then its a config setting on your side, or maybe a bug. If you do _not_ encounter the behavior, it's your VPS provider's settings preventing the communication. > > I use both Racknerd and DO and haven't had any connectivity issues with Newt & Pangolin Thanks again - your help and advice is very appreciated. It is becoming very apparent my hobby of trying to prove self hosting can be done by anyone using inexpensive standard home equipment & services is becoming very difficult. When I contacted my VPS provider although they resolved things so I could ping the VPS public ip address they told me I'd have to ask one of their Partners to help resolve the Newt issue of trying to ping the private ip address 100.x. So more flipping expense!! Its all becoming a nightmare really, I only self host systems for my own use and although everything ran perfectly well using a standard ISP Fibre broadband service with just a simple port forward on their provided router to a reverse proxy on my lan with ufw firewall rules to secure things. Since moving to a 5G service with no port forward or bridge mode functionality I can't run a next gen firewall/router option as I planned, nor can I host sites accessible via the web. And now I discover I can't run another system on a VPS like Pangolin. So I guess my best bet is to host my services on the VPS running its own proxy. It is just my hobby and the cost/benefit ratio for me means just paying for more and more services isn't worth it.
Author
Owner

@kmanwar89 commented on GitHub (Jun 2, 2025):

It sounds like your frustrations aren't necessarily caused by Pangolin or other reverse proxy solutions, but rather the technical limitations you are uniquely facing. My advice to you is to do the A/B testing I suggested above - you can even use Oracle Free Tier for a no-cost test. This will let you rule out the VPS itself (which it sounds like where your issue might be).

Self hosting is something that requires a LOT of learning, and really diving into just how many steps are involved in the backend to make many SaaS offerings "easy" for an end user. Don't get discouraged, but you may want to decide if its something you can commit the time and effort to.

If it makes you feel any better, I spent 6 hours troubleshooting something that ended up being a bug...so sometimes its a user config side issue, or sometimes its a bug outside of your control. As long as you end up with a working solution at the end of the day, I think it can be considered a win :)

Good luck in your journey.

<!-- gh-comment-id:2931211899 --> @kmanwar89 commented on GitHub (Jun 2, 2025): It sounds like your frustrations aren't necessarily caused by Pangolin or other reverse proxy solutions, but rather the technical limitations you are uniquely facing. My advice to you is to do the A/B testing I suggested above - you can even use Oracle Free Tier for a no-cost test. This will let you rule out the VPS itself (which it sounds like where your issue might be). Self hosting is something that requires a LOT of learning, and really diving into just how many steps are involved in the backend to make many SaaS offerings "easy" for an end user. Don't get discouraged, but you may want to decide if its something you can commit the time and effort to. If it makes you feel any better, I spent 6 hours troubleshooting something that ended up being a bug...so sometimes its a user config side issue, or sometimes its a bug outside of your control. As long as you end up with a working solution at the end of the day, I think it can be considered a win :) Good luck in your journey.
Author
Owner

@amberleaf7 commented on GitHub (Jun 2, 2025):

It sounds like your frustrations aren't necessarily caused by Pangolin or other reverse proxy solutions, but rather the technical limitations you are uniquely facing. My advice to you is to do the A/B testing I suggested above - you can even use Oracle Free Tier for a no-cost test. This will let you rule out the VPS itself (which it sounds like where your issue might be).

Self hosting is something that requires a LOT of learning, and really diving into just how many steps are involved in the backend to make many SaaS offerings "easy" for an end user. Don't get discouraged, but you may want to decide if its something you can commit the time and effort to.

If it makes you feel any better, I spent 6 hours troubleshooting something that ended up being a bug...so sometimes its a user config side issue, or sometimes its a bug outside of your control. As long as you end up with a working solution at the end of the day, I think it can be considered a win :)

Good luck in your journey.

I agree it isn't Pangolin causing me problems. I think my config issue is Unifi Cloud Gateway related. It has instructions on how to setup a Wireguard tunnel on the device itself so I guess I need to research/investigate how to get Newt to work with it. I am frustrated with all of this as it just seems like an unending process of paying for ever more services when buying products or services in general, I just want to pay for something that lets me get on with things instead of being blocked out all the time. Especially when there are so many free open source projects run by good people out there. I too spend hours, weeks and even months sometimes getting things to work (or not) and always tell people not all hobbies are necessarily "fun" all the time!!

<!-- gh-comment-id:2931381611 --> @amberleaf7 commented on GitHub (Jun 2, 2025): > It sounds like your frustrations aren't necessarily caused by Pangolin or other reverse proxy solutions, but rather the technical limitations you are uniquely facing. My advice to you is to do the A/B testing I suggested above - you can even use Oracle Free Tier for a no-cost test. This will let you rule out the VPS itself (which it sounds like where your issue might be). > > Self hosting is something that requires a LOT of learning, and really diving into just how many steps are involved in the backend to make many SaaS offerings "easy" for an end user. Don't get discouraged, but you may want to decide if its something you can commit the time and effort to. > > If it makes you feel any better, I spent 6 hours troubleshooting something that ended up being a bug...so sometimes its a user config side issue, or sometimes its a bug outside of your control. As long as you end up with a working solution at the end of the day, I think it can be considered a win :) > > Good luck in your journey. I agree it isn't Pangolin causing me problems. I think my config issue is Unifi Cloud Gateway related. It has instructions on how to setup a Wireguard tunnel on the device itself so I guess I need to research/investigate how to get Newt to work with it. I am frustrated with all of this as it just seems like an unending process of paying for ever more services when buying products or services in general, I just want to pay for something that lets me get on with things instead of being blocked out all the time. Especially when there are so many free open source projects run by good people out there. I too spend hours, weeks and even months sometimes getting things to work (or not) and always tell people not all hobbies are necessarily "fun" all the time!!
Author
Owner

@kmanwar89 commented on GitHub (Jun 2, 2025):

Newt has nothing to do with your Unifi setup - take that completely out of the picture.

The wireguard setup only occurs between Pangolin (server) and newt (client). You need to have the appropriate ports open in the container, but there shouldn't be anything that stops the wireguard connection from establishing - wireguard is a VPN after all and is made to connect out over the public internet.

I understand your frustrations and I think a lot of people are in the same boat!

<!-- gh-comment-id:2931455511 --> @kmanwar89 commented on GitHub (Jun 2, 2025): Newt has nothing to do with your Unifi setup - take that completely out of the picture. The wireguard setup only occurs between Pangolin (server) and newt (client). You need to have the appropriate ports open in the container, but there shouldn't be anything that stops the wireguard connection from establishing - wireguard is a VPN after all and is made to connect out over the public internet. I understand your frustrations and I think a lot of people are in the same boat!
Author
Owner

@amberleaf7 commented on GitHub (Jun 6, 2025):

Well this is embarassing, the problem was caused by udp port 51820 being locked on the vps. I'd setup ufw rules to unlock the required ports but the vps has its own firewall rules section and although port 80 and 443 were open (by default I guess) udp port 51820 wasn't. Once I opened it in the firewall rules section Newt connected and I was good to go. So the lesson I learnt was get to know your vps setup first!! And the server where Pangolin is installed must be able to be pinged, I tested that by removing the rule temporarily and the pangolin site went offline so had to restore the rule.
Thanks kmanwar89 for your help and patience, it really was appreciated.

<!-- gh-comment-id:2948461547 --> @amberleaf7 commented on GitHub (Jun 6, 2025): Well this is embarassing, the problem was caused by udp port 51820 being locked on the vps. I'd setup ufw rules to unlock the required ports but the vps has its own firewall rules section and although port 80 and 443 were open (by default I guess) udp port 51820 wasn't. Once I opened it in the firewall rules section Newt connected and I was good to go. So the lesson I learnt was get to know your vps setup first!! And the server where Pangolin is installed must be able to be pinged, I tested that by removing the rule temporarily and the pangolin site went offline so had to restore the rule. Thanks kmanwar89 for your help and patience, it really was appreciated.
Author
Owner

@KostyalBalint commented on GitHub (Jun 11, 2025):

To anyone struggling with a similar issue on Oracle's Free tier Ubuntu VPS:

I am currently struggling with a similar issue using Oracle's Free tier VPS. As it turns out, Oracle doesn't like ufw see the “Essential Firewall Rules” section https://docs.oracle.com/en-us/iaas/Content/Compute/References/bestpracticescompute.htm

Also check out the discussion here: https://www.reddit.com/r/oraclecloud/comments/p9a89g/how_to_open_port_on_oracle_cloud_compute_instance/

<!-- gh-comment-id:2962506172 --> @KostyalBalint commented on GitHub (Jun 11, 2025): **To anyone struggling with a similar issue on Oracle's Free tier Ubuntu VPS:** I am currently struggling with a similar issue using Oracle's Free tier VPS. As it turns out, Oracle doesn't like `ufw` see the “Essential Firewall Rules” section https://docs.oracle.com/en-us/iaas/Content/Compute/References/bestpracticescompute.htm Also check out the discussion here: https://www.reddit.com/r/oraclecloud/comments/p9a89g/how_to_open_port_on_oracle_cloud_compute_instance/
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/pangolin#14535