mirror of
https://github.com/fosrl/pangolin.git
synced 2026-07-16 14:47:04 -05:00
[GH-ISSUE #977] Unable to add Synology NAS as resource (Gateway Timeout) #1710
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/pangolin#1710
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @youenl-dev on GitHub (Jun 27, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/977
Hi,
I have a working instance of Pangolin on a VPS where I've been able to add various services (Pihole, Proxmox, Plex, etc) as resources without any issue.
Pangolin has been fantastic and very stable over the last few months, but I can't manage to add my Synology NAS as a resource at all. Using http and port 5000, or https and port 5001, I always end up with a Gateway Timeout error.
Local and remote access with Quickconnect or Netbird works fine, so I'm not sure if the issue comes from DSM or Pangolin.
Any help or idea would be much appreciated. Many thanks!
@adrianeastles commented on GitHub (Jun 27, 2025):
Hi,
With exposing your Synology NAS and Proxmox directly to the public internet; it's not recommended for security reasons.
Regarding your issue with adding the Synology NAS as a resource in Pangolin and encountering a "Gateway Timeout" error, here's what I recommend checking:
Newt Container Mode on NAS:
Pangolin Resource Configuration:
HTTPS{Your Synology NAS's Local IP Address}(e.g.,192.168.1.X or 10.0.0.X).5001(This is the default HTTPS port for DSM. If you've changed it on your Synology NAS, use your custom port.)If you're still experiencing issues after verifying these settings, it might be worth checking:
pingortelnet {NAS IP} 5001from your VPS to your Synology NAS's IP address to confirm basic network reachability on that specific port.Let me know how it goes!
@robtec commented on GitHub (Jun 28, 2025):
Curious on this point. As Pangolin manages access and security to resources, is it still dangerous to expose certain services to the www via Protected Pangolin? Is there a chance pangolin won't protect services under different circumstances?
@youenl-dev commented on GitHub (Jun 29, 2025):
Thank you for your reply, you definitely pointed me in the right direction.
My Newt container is running on a lxc container on
192.168.10.16and cannot ping my NAS on192.168.20.11, while being perfectly able to ping other services running on192.168.20.x, including VMs running on the NAS itself.This would point to a network config issue in DSM directly, and I believe has nothing to do with Pangolin.
I think I'll also take your advice of not exposing my NAS to the internet, but would be interested to know as well if Pangolin is as secure as Tailscale or NetBird when used for remote access.
Many thanks,
Y.
@adrianeastles commented on GitHub (Jun 29, 2025):
Sorry about not responding before, never got the notification sent to me.
You're correct that Pangolin is designed to manage access and add a layer of security to your resources. It acts as a reverse proxy and authentication/authorization layer, which is a significant improvement over directly exposing services. However, the primary concern with exposing services like your Synology NAS or Proxmox, even through Pangolin, is that these services themselves are complex applications that can have their own security vulnerabilities (software bugs, misconfigurations, unpatched exploits, etc.). If a vulnerability exists in DSM (Synology's operating system) or Proxmox, an attacker might still be able to exploit it, even if they first have to bypass Pangolin's access controls.
Pangolin is secure for what it is designed to do: act as a robust, authenticated reverse proxy for exposing services to the public internet in a controlled manner. It's a fantastic self-hosted Cloudflare Tunnel alternative. However, the biggest difference with using Tailscale/NetBird's is your Synology NAS or Proxmox never directly listens for incoming connections from the public internet. Instead, your devices (laptop, phone, NAS, server) connect outbound to a control server (Tailscale's cloud, or your self-hosted Headscale/NetBird server) to discover each other and exchange WireGuard keys. Thus, because your services aren't listening for public connections, they are effectively "invisible" to general internet scans. This drastically reduces the attack surface compared to a public-facing proxy.
Disclaimer: Please note that these are my own insights and observations based on my experience as a software engineer. I'm not speaking on behalf of the Pangolin team or any other product mentioned in this post.
@youenl-dev commented on GitHub (Jun 29, 2025):
This makes perfect sense, thank you very much for the detailed explanation. Much appreciated!
@oschwartz10612 commented on GitHub (Jun 30, 2025):
Sounds resolved but feel free to reopen if needed. Thanks for the great write up @adrianeastles !
@ghost commented on GitHub (Dec 9, 2025):
Curious, why all containers I do have working with Newt by the name, but only this one needs to be pointed directly on to the IP of Synology?
Stumbled across this post while searching what I'm missing and still do not understand.
(https is clear to me, as otherwise nginx of Synology log-in portal complain "The plain HTTP request was sent to HTTPS port")
Didn't anyhow set this by myself.
It working, basically inserted the Docker config from Site configuration from Pangolin, just the ports added.
Is this anyhow unsafe?
@eppjo commented on GitHub (Mar 2, 2026):
I had the same problem. Paperless and Portainer worked fine via Pangolin on a VPS and Newt on the Synology, but Synology itself was not accessible. After a long search on the web, I found the solution: Leave the field for the custom domain blank in the login portal settings.
In Pangolin I added the resource via http, hostname and port 5000.