SWAG reverse proxy for internal use

At the moment I’m using swag as a reverse proxy for external services. I would like a few of them also made available via an internal URL.

As an example:
The external URL is dns.itv369.net.
I would like to use dns.itv360.lan or dns.itv.lan for internal use.

Is there a way to do that within the same config file as the external url? And how could that look like?

With warm regards - Will

For swag to do reverse proxy, it needs to be a valid domain. It’s not going to be able to provide certs for .Lan etc.

You can just use your same domain internally with splitdns.

1 Like

I don’t understand this split domain concept.

I have added the 2 domains within Pihole pointing it to the Host where the SWAG container is residing: itv360.lan and itv.lan are both pointing to 192.168.139.235. Here SWAG is listening to port 80 and 443.

How do I proceed from here?
Knowing that with internal URL’s there will be no valid certificate (which is fine - just as long data is encrypted).

Reason for looking into this is that users don’t need to rember the TCP ports of the services. Another reason is that services can run on 127.0.0.1 in cases where SWAG is running the same host as the services.

No swag won’t get a certificate at all for those domain.

Reason I suggested split dns is so you can use your domain internally. Setup apps as normal but then don’t have external DNS entries for the apps you want to keep internal.

Thats fine - I will find another wa of having certificates.

Split DNS seems to leave me with some open ends:

  • Users need to rember the TCP ports of these services. Which is not the case when a reverse proxy (like SWAG) kicks in.
  • Another advantage is that services can run with 127.0.0.1 in cases where SWAG is running on the same host as the services.

What is your view here?

First point, no you’d still be routing everything through swag.
Second point: you’d just setup the proxy conf correctly for swag to connect to those services.

As mentioned by @j0nnymoe you can’t get a certificate that’s signed by Letsencrypt or another certificate authority for a .lan domain.
Not having a valid certificate also defeats the purpose of having certificates, unless you deploy your own CA but this gets complicated.

The easiest and most secure approach is arguably to use a wildcard certificate. You can do this in SWAG by setting up a DNS challenge.
Then, you could have all internal services under that verified domain (buy a domain name for LAN use only); or a subdomain such as something like lan.itv369.net.
You will setup dns records such as lan.itv369.net and myservice.lan.itv369.net in pihole only, instead of doing it with you domain provider - that’s what’s called a split DNS.
You should also block non-lan traffic in SWAG for those specific internal domains, or better yet have them in a separate instance that’s not forwarded.

Those are common setups scenarios you will see in enterprise and it’s not difficult to put in place.

Longs story short: using .lan or .local is considered bad practice. So is using invalid certificates. Instead, a more secure and easier approach is to use a wildcard certificate with a domain/subdomain that does not have public DNS records (split DNS).

1 Like

At the moment I have such a lan-only approach as described. It is based on the official domain itv360.net.

The downside of this setup is that it requires an Internet connection to work. I was looking for a way to use these applications even if there is no internet connection.

The idea of forwarding them via swag is so that users don’t have to remember TCP ports. For example, they would just use npm.itv.lan (versus icarus.tech.lan:8090) to access the device monitoring. This allows us to be flexible with hosts and containers when migrating everything to Kubernetes (versus the current standalone docker hosts and containers).

Perhaps you have answered this without me noticing this - but how would your suggestions fit into this?

Exactly how we explained it but just would use your domain you have setup with swag rather than .Lan.