Traefik for two domains, one internal and one external
Traefik for two domains, one internal and one external
So, at the moment I'm using Nginx Proxy Manager, but lately I started seeing it moving slower and slower and even though I tried traefik some time ago, I didn't manage to make it work.
Anyway, I want to start using traefik again, but I want to use it like this:
- I want to access all my services/containers in my LAN through http (port 80) on something like sub.mylan.home
- I want to access some of my services over the internet through https (port 443) on sub.mydomain.com
I know this is possible, but I don't get the hang of the configuration. Somone care to share some tips?
First of all, have you stacking the public and private subdomains on the same base domain? It's what I do at the moment, I have external services on
*.mydomain.comand internal services on*.home.mydomain.com.You can get one wildcard cert for
*.mydomain.comand one for*.local.mydomain.comso all your services are protected by TLS, both inside and outside your LAN. You also get to manage all of them identically in the same place (Traefik in your case).You do NOT have to define any of these domains in DNS in order to pass the Let's Encrypt DNS challenge. LE doesn't care what you'll put in DNS, just wants to verify the domain is yours. So just giving it an API token with access to mydomain.com is enough. (If your DNS provider doesn't offer API check out this list of providers.)
It's important to understand that the reverse proxy doesn't actually care about DNS and whether those domains resolve, it just looks for the domain in the HTTP headers. So you can define those domains anywhere you want. You have several options:
- For the public subdomains you need to define them in your public DNS, so you can resolve them from anywhere on the Internet. Let's say your server IP is 1.2.3.4. You define an A record pointing mydomain.com to 1.2.3.4, and a wildcard CNAME that points *.mydomain.com to mydomain.com. Now all the subdomains directly under mydomain.com resolve to that IP.
- For the private subdomains you have several options:
- Best approach is to do the same as above for
*.home.mydomain.com, but do in on the private DNS used on your LAN, and point to the LAN IP of your server instead of your public IP. - If for whatever reason your LAN DNS can't do this (or you can't control it) you can put the entries in the public DNS. It's a bit unorthodox putting private LAN stuff in a public DNS but it works.
- You can even define sub.home.mydomain.net names in the local hosts file on your PC, if you only need to access them from the PC. You only need to trick your browser into resolving them so it will put them in the HTTP headers, the reverse proxy doesn't care.
- Best approach is to do the same as above for
An important note about security, because someone has already mentioned this in another comment. There are malware bots that keep scanning domains and IPs and ports looking for apps, and then they try exploits to try to break in. Having services exposed publicly without an extra authentication in front can make you vulnerable to these bots. It's not a question of if they'll find your app, it's a question of when. You can mitigate the risk by blacklisting IPs in your router, for example you can blacklist anything that's not coming from your country, but that only reduces the surface, does not completely eliminate the threat.
The bots also scan issued Let's Encrypt certificates (which are a matter of public record) which is why it's important to only get wildcard (*.mydomain.com) certificates, never explicit subdomains (sub.mydomain.com). It's also important to never link to your services from web pages or share them with others.
Assuming you keep the subdomains for yourself, and you get a wildcard cert, and you use a reverse proxy, and you make the domain not easy to guess (don't use something like "calendar.mydomain.com") then you can very effectively prevent bots from getting to your services. That's because the reverse proxy won't honor requests if it doesn't recognize the full domain name. So the subdomain can act as a sort of access key if you make it long enough (63 chars limit per subdomain, 255 max limit on the entire domain). That's a pretty respectable key length... as long as you don't publish it anywhere (only define it on the reverse proxy and your phone for example).
Thanks for the great explanation.
So, currently, as I said, I'm using nginx proxy manager and do this:
- reverse proxy to all my services inside the internal network on http: *arr stuff, rss reader, jellyfin and some other minor things. All of them use name.local.home notation. I'm using a local DNS for this, of course.
- reverse proxy to just two services externally on https under wildcard certificates - both are non-standard names and the names are not related to the services themselves. For both these services I use Authelia with 2FA, so even if an attacker guesses the subdomain name, they'll have to bypass that. As far as I can see in my logs, there are no attempts to breach my services. This is what I want to replicate and I'm planning on testing it.
On the other hand, You gave me a good idea about using *.lab.domain.com getting resolved by the local DNS and the main *.domain.com by my public DNS. I'll give this a try too in the near future. Another plan for me is to start using Authentik, as I saw it's a bit better than Authelia in some areas, even though it may be overkill for a little project - I'll have to see.
Since your reverse proxy is nginx you can also look at vouch-proxy. It's smaller and more light-weight than either Authelia or Authentik, but of course it doesn't have all their features, basically just login with an external service.
Caveat emptor, split DNS can cause issues down the line that are a proper nightmare to debug.
Don’t do it unless you a) understand what is happening on your network when you config it this way b) have the tools and ability to verify it is working like you think it should and troubleshoot when things eventually break and c) can exercise enough control over your network to make sure all DNS resolution in your LAN happens the way you think it should.
Perhaps I'm misunderstanding the term but I don't think what I described is split DNS. Split DNS is when the same DNS server resolves a name differently depending on the IP address of the client.
In the scenario I described the DNS servers involved do not discriminate, they always resolve the same names the same way.
The ability to discriminate at the client (to search specific DNS servers for specific domains) is not split DNS (although it's often incorrectly called that).
If this is what you meant then yes, it can be a bit of a headache. For example if you need to resolve local LAN names (.lan or .local), Tailscale names, and Docker names at the same time inside a container it can get a bit hairy.
Yes you can. Just set your routers accordingly.
Also: it’s probably not what you want. Trivial misconfigs would have disastrous effects.
it’s probably not what you want
What do you mean?
Not OP, but generally, you want to separate internal and external services as much as possible. Some even suggest running external services on a cloud server and internal servers on your LAN.
If you run internal and external services on the same host, you need to be careful to not make any configuration mistakes. Take extra time to also test what should NOT be possible.
It can happen that your internal services are still reachable from externally, by calling the external IP and setting the Host header manually to sub.mylan.home, even if that were pointing to an internal address. Traefik would only compare the Host header. To secure this you might also add an IP filter for the internal host, but I‘m not sure whether that’d be secure enough.
You’ll be putting yourself in a situation where a typo, or a wrong docker compose copy/paste, or a default config you forgot to override, will expose stuff to the Internet.
I'm using Nginx Proxy Manager, but lately I started seeing it moving slower and slower
I guarantee you that nginx performs adequately for self hosting. If something is running slower I'd look elsewhere first.
It's not slow as in slow to respond. it's slow when restarting... sometimes it takes 3-4 minutes until it's up and I don't have time for that ;-) Also, it's a good "reason" for me to learn traefik.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
Fewer Letters More Letters DNS Domain Name Service/System HTTP Hypertext Transfer Protocol, the Web IP Internet Protocol SSL Secure Sockets Layer, for transparent encryption TLS Transport Layer Security, supersedes SSL VPN Virtual Private Network nginx Popular HTTP server
6 acronyms in this thread; the most compressed thread commented on today has 6 acronyms.
[Thread #647 for this sub, first seen 1st Apr 2024, 13:05] [FAQ] [Full list] [Contact] [Source code]
I would recommend using a VPN to access your services instead of exposing them to the Internet.