Keeping traffic from clients to resources on the same network if Pangolin is external

[patchmonkey]

It would be really useful if there was a way to prevent requests from client A through pangolin to resource A from having to be routed out and in through a WAN connection.

Considerer the following:
Client A and Resource A both reside on the same network (Let's call it homenet). Pangolin resides on a VPS run by a common VPS provider, and uses the domain name "homenet.site".

If Client A wants to reach Resource A, there are no optimal paths:

Option 1: Everything through Pangolin

Pros:

• Single url for a resource
• All of the benefits of Pangolin

Cons:

• Internal traffic is routed externally (requires a working WAN link)
• double bandwidth

Option 2: Local through local https domain name

Pros:

• Direct, local network communication

Cons:

• Users must remember a 2nd domain name for same service
• No SSL cert management through pangolin (back to square one with self-signed or firewall port forwarding and manual SSL config)
• No pangolin Authentication/authorization, so that needs to be configured locally if a concern

Option 3: Using local DNS Servers to redirect traffic to the correct resource

Pros:

• Direct, local network communication
• Single URL for resource

Cons:

• No SSL cert management through pangolin
• No pangolin Authentication/authorization, so that needs to be configured locally if a concern
• SSL Cert from the local reverse proxy either needs to be self signed (annoying) or local reverse proxy needs to be set up to grab letsencrypt certs (tricky, and then we have to open the network for port forwarding anyway, rendering the external pangolin a bit moot)

Suggested Solution

Create a "Pangolin local-only" clone or proxy:

A Pangolin "Local Only" clone could sync to the main pangolin installation and retrieve all of the required configuration and certs.

Alternatively, a "Local Only" Proxy could route traffic from client to resource, while offloading certs and authentication/authorization to the main installation.

Pros:

• The main server and the "local only" could communicate through a wireguard tunnel
• The Local Only clone wouldn't have to handle getting letsencrypt certs (it can proxy requests to the main server if the certs are not already present
• Users and administrators need to only remember a single url
• All of the benefits of Pangolin without the major downsides of the above options

[mregni]

Would be very nice to keep local traffic local indeed. At the moment 80% of my traffic is inside my network to a couple of sub domains (managed with traefik) so it would be unnecessary to let the traffic go to the VPS and back to my local network.

I think the local only solution would work great. That way, we don't have to set up a second traefik instance for local calls as well.

[fanaticDavid]

I would love the local-only approach if it were possible. Being able to connect directly to my self-hosted services while at home (even during an internet outage) but still being able to go through the vps while out and about, all with a single url.

At the moment, I'm using Nginx Proxy Manager as a reverse proxy internally for some services that seem to be rather slow through the VPS. Acceptable when I'm outside of the house, but not when I'm on the same network as those services.

[johanngrobe]

How do you handle SSL certificates when using the same domain?

[fanaticDavid]

Pangolin and NPM each retrieve their own Let's Encrypt certificate for the same domain. As I use wildcard certificates, that means it just has to retrieve 2 different certificates anyway. This is probably not the right way to go about it, but it seems to work fine for my use case. At least until there is a better solution, like the one discussed above.

[jhedfors]

Interesting disucssion @patchmonkey, @fanaticDavid, @johanngrobe.

1. I am guessing that this would replace the need for a local reverse proxy, right?
2. Would management be exclusively on the VPS, or could it be managed via the clone?
3. Is this expected to continue to function locally if the VPS where to go offline?

I was using NPM, but recently switched to Zoraxy (which is nice), but as Pangolin serves a similar function, it would be great to have just one interface, and be able to utilize it's access controls/identity providers.

[fanaticDavid]

1. Correct. I did spin up an NPM container for a while but maintaining 2 reverse proxies was far from ideal.
   My main reason for wanting something local is performance: with my ISP limiting my upload speed to 30 Mbps (at best), loading some of my self-hosted services through Pangolin on my VPS can be a little slow. Acceptable when I'm at work, not so much when I'm on the same network as those services.
   A secondary reason is availability: if my home internet goes down while I'm trying to use self-hosted services, I suddenly have to start using local hostnames or ip addresses to access them without a local reverse proxy.
2. I think it would simplify things if we were to appoint the VPS as the primary proxy at all times, so no logic would be required to determine which proxy has the latest settings. Besides, the VPS can be reached from anywhere to make changes, whereas a local clone wouldn't be reachable remotely.
3. Ideally, yes.

All of this is assuming the suggested solution is technically possible. I'm not a dev, just a power user.

[Tredecate]

This almost reminds me of the "Remote Nodes" feature available with Pangolin Cloud, albeit with some obvious differences. It's the idea of deploying some sorta remote agent to a site that acts as a local reverse proxy within that network, but pulls configs/certs from a primary instance.

This type of functionality would probably clear my last big hurdle to fully adopting Pangolin 🙂 It'd be an absolute love-letter to homelab power users.

In the "suggested solution" diagram, you have a local DNS server that routes resource names to the local node. This is what I'd initially imagined, too, but I noticed the "Remote Node" overview mentions the following:

• Delegate the DNS: Your domain and DNS config is still controlled by the Pangolin control plane and the central DNS server routes to the right node when connecting.

If a theoretical implementation of this feature were to build on Pangolin Cloud's existing "Remote Node" feature, I'm curious as to how the DNS setup would work. Relying on the primary VPS node/control plane would still introduce a point of failure if it becomes unavailable for whatever reason. Maybe I'm misunderstanding the docs, though. It could be that the DNS routing wouldn't even be considered for a self-hosted version; I'm not sure how Cloud does it.

Either way, I'm personally partial to just having a local wildcard DNS record pointing to the local node, but still wanted to bring it up for discussion. 🙂

[CartCaved]

I think this is a key area to improve Pangolin. The system does so much right now but this would make it more complete.

My proposed solution would be similar to the local clone option, but essentially opposite - a VPS outpost. I'd like to be able to run Pangolin within my local environment and just have a newt like cloud outpost on a VPS (or Pangolin cloud). Essentially, on each physical site, we'd be running the Pangolin stack allowing all the configuration, certificate management etc, to be managed locally. The VPS/Cloud outpost service would used to coordinate sites and essentially forward traffic to the local sites without requiring opening up ports in the firewall. The local DNS can point directly to the local Pangolin instance.

The benefit compared to the current approach is that internal traffic isn't routed through the internet. The benefit compared to the suggestion proposed above, with a "clone" locally, is that management can be done and kept locally even when WAN or VPS is unavailable.

Of course, automatic certificate renewals require WAN and if there are no holes punched in the firewall, they can't be renewed without the VPS/Cloud. Another option would that the outpost renews and keeps the certificates, with the local Pangolin instance retrieving them. It still requires the VPS running but it's an alternative architecture.

[DarinDev1000]

I was thinking of this feature to replace my local traefik reverse proxy! I'd glad someone else thought of it too.
Currently my homelab looks exactly like Option 3.

Although, "No SSL cert management through pangolin" can be a feature. Just use DNS challenge for ssl certs.

[spaceXrace]

It would indeed be pretty cool if we can set up a second local Pangolin.

It would also be interesting for me to use this second Pangolin server to handle external IPv6 connections, because a direct IPv6 connection has significantly less latency and higher bandwith than the VPS route. At the moment I am also running a second reverse proxy to accomplish this.

[txwgnd]

+1 from my side!

I'am thinking about how to handel this back and forth. From a high level perspective somewhat of a Split-Horizon DNS configuration would be great for this. Pangolin would really benefit from this functionality.

[patchmonkey]

I was able to sort of put into place a system with a similar outcome, although it's not ideal as the design I outlined above. Currently, I have my local caddy AND my pangolin VPS grabbing certificates for my domain using the DNS01 challenge. My local caddy serves LAN and VPN traffic to the resources directly without traversing the WAN using the same URLs; Pangolin via the VPS serves external traffic to my Caddy instance inside the LAN, which then routes the traffic internally.

The main downside is this requires two very distinct configurations; a Caddy config for all of the resources and DNS01 challenge specific plugins and config, and a pangolin configuration to point the resource to the routing/Caddy endpoint inside my lan. Additionally for each of these Pangolin resources, I also have to set the TLS Server name and Custom Host Header to the url of the pangolin resource, so that the Caddy server on the local side routes the request correctly. The result is more or less the same as what I was trying to achieve, but it's a lot of manual config and it's very easy for configurations to diverge.

I thought I'd share if that helps any of you while we hope for more pangolin-based feature-set

[netxer]

Wouldn't you be able to achieve this with just 2 instances of pangolin, 1 local 1 remote and dns routes?

[patchmonkey]

Yup, but there wouldn't be much of a change/improvement over what I have outlined above with Caddy, as I'd still have duplicated configurations and DNS01 challenges. It'd be the same amount of effort if I was setting it up new, but additional effort to swap caddy for pangolin with no net gain in this instance.

[oschwartz10612]

I am not sure if the latest release solves all of this request but the clients and the sites should now attempt to connect locally on the same network instead of relaying: https://pangolin.net/news/1-21-release

[oschwartz10612]

Let me know if you think we can close this.

[patchmonkey]

While this is a great and welcome improvement, it doesn't solve the problem as I've laid it out. There is at least one major constraint that I can see: Every potential consumer of resource needs to have the Pangolin client configured and connected

Instead of relying on a reverse proxy locally to route my traffic, I'd have to rely on my remote pangolin instance and the pangolin client software. That's fine for some of my use cases, but it also makes the amount of things I need to configure/update/monitor for much of my infrastructure much higher.

For some use cases, it's annoying at best and untenable at worst; take the example of a locally hosted Immich installation for photos. If multiple independent users on site are accessing the resource via a number of phones, tablets, and computers, it's a struggle to ensure all of them have installed/updated/connected clients. It's even worse with mobile devices such as android, which can only run one VPN connection at a time; I'd have to have users playing musical VPNs if they needed other VPNs for other purposes. Additionally, Android Auto doesn't function with active VPNs, an annoying limitation which makes VPN flipping/button pressing a necessity, and limits the usefulness of the release in my case.

Additionally, it occurs to me there's potentially another fairly major constraint; if the WAN is down, the connection to the (Remote) pangolin would also be down, and while it's unclear from the docs, I assume that would mean the local resources would be not reachable via the pangolin managed url.