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.