Local DNS - Why so HARD?!
-
I have to presume (to much) now.
If the "docker" is device on LAN, then a NAT - actually PAT - rule will do :
In plain text : all incoming TCP connections on the WAN interface that have destination port 443 will get Translated (the T in NAT/PAT) to port TCP 9443, and the IP (was WAN) will get translated to the LAN IP, your 10.10.10.1111)That a vanilla of the mill standard classic 'you host your own web server on your LAN' NAT rule.
Btw : "https://portainer.homelab" is in reality ""https://portainer.homelab:443" as https implies : use destination port 443.
Browsers can't use host names like "portainer.homelab" so it will translate that to an IP first, using DNS. "portainer.homelab" should point to you WAN address.But before going any further, describe your setup. Please don't hide RFC1918.
Thank you so much for the help! I’ll try to describe my setup as best I can. (I understand what RFC1918 means - I’m using 10.10.10.x as RFC1918 - but I’m not sure what you mean by “hiding RFC1918”.) My modem is connected to my pfSense machine (a repurposed mini PC with dual NICs) via the WAN interface. The LAN interface goes to a 24 port managed switch but I’m currently using it as though it’s an unmanaged switch because I haven’t setup any VLANs or subnets yet. I access my pfSense web interface via (my LAN interface is) 10.10.10.1. The machine with the (local/LAN) IP address 10.10.10.111 is an Ubuntu server running several Docker containers. One is Portainer (on port 9443), another is Dokuwiki (on port 7591) another is Ghost (blog - on port 23274), another is Uptime Kuma (port 9937), etc. If I want to access these from outside my home, I use a Cloudflare tunnel (the Docker host at 10.10.10.111 is running cloudflared) with multiple public hostnames such as portainer.mydomain.com, docs.mydomain.com, ghost.mydomain.com, kuma.mydomain.com, etc. In the Cloudflare tunnel configuration, these public hostnames point to 10.10.10.111:9443 (Portainer), 10.10.10.111:7591 (Dokuwiki), 10.10.10.111:23274 (Ghost blog), etc. (and all of that works just fine) but from my main workstation and/or my iPad (a 12.9” iPad Pro from which I do a lot of homelab stuff), I have to (in a browser) type “10.10.10.111:9443” (or:7591 or :9937, etc.) Not only are these IPs and port numbers kinda tedious to type, but I have to either memorize the port numbers or look them up. Also, with multiple containers/services at 10.10.10.111:x, my password manager has to display a list of all the passwords for all the services at 10.10.10.111. If I could access Portainer at “portainer.homelab”, Ghost at “blog.homelab”, Leantime at “projects.homelab”, (note that as far as I’m concerned, if I have to type “portainer.homelab:9443” it kinda defeats the whole purpose) not only would it be easier to remember and easier to type, but my password manager would only show me the appropriate password vault entry. My understanding is that I could setup PiHole to do this and it would work fine. Although that would be the path of least resistance, I’m stubborn. It seems to me there has to be SOME way to do this in pfSense. I understand that HAProxy can do this, too, but I haven’t bee able to make that happen nor find a good tutorial that explains (simply) how.
I hope this clarifies everything adequately.
-
That's because it is an invalid IP address. The ":9443" part is a port number and not part of an IP address.
I do understand that. My point was simply that if I can’t specify a port number, then I need to look for a solution other than host overrides - and I haven’t been able to find one that I can understand well enough to implement (with my obviously limited knowledge).
Your life would be much easier here if you could change the TCP port your docker container is listening on from 9443 to 443 instead.
Yeah, it probably would be, but as I explained to @Gertjan, I have multiple containers running in this host so I need to be able to specify non-standard port numbers to make everything work.
The answer to @Gertjan's question about how things are set up and addressed is key here. If your docker container is just sitting on your LAN and in the same IP subnet as your devices that are trying to reach it,
It is.
then pfSense will be totally out of the picture as no "routing" is required for hosts on the same LAN subnet to communicate. They find each other directly, and just use pfSense as perhaps a DNS server for a host name to IP address lookup.
But isn’t that what local DNS does? (what PiHole does - In addition to blocking advertisements?)
But host overrides and DNS entries can NOT contain TCP port numbers.
If your docker container and the hosts trying to communicate with it are in different IP subnets so that the firewall is required to route that traffic, then you can configure a port-forwarding redirect with a rule that redirects traffic whose destination is "portainer.homelab" with destination port "443" to the container's IP and rewrite the port to "9443".
So if I put the Docker host on a different subnet than my main workstation and iPad, I can use a port redirect?
Here is a link to the documentation describing the port redirect feature: https://docs.netgate.com/pfsense/en/latest/nat/port-forwards.html.
Thank you! I’ll check those out.
-
@erniepantuso said in Local DNS - Why so HARD?!:
So if I put the Docker host on a different subnet than my main workstation and iPad, I can use a port redirect?
Sort of. The Cloudfare tunnel process you have uses a local daemon running in Docker (at least that's my understanding) that behaves much like a web proxy. It is reading the full URL (which includes the domain name and the website name - but note that a website name is not necessarily part of a domain name). It uses the website name portion of the URL (think web page name if that helps you understand it better) to redirect incoming traffic to a particular IP and port.
The problem you will have with the Docker server on the same network as your iPad and other devices is that the firewall is out of the picture. And while I am not a Pi-Hole expert, I could not find any reference to it translating ports. And that makes sense it would not do that because the port number is not part of a hostname.
Port translation/redirection is something a firewall can do when it is routing the traffic. So, if you move your Docker to a different subnet so that internal traffic must be routed by pfSense, then you can use the port translation/redirect rules in pfSense to imitate what the Cloudfare daemon is doing for external traffic. But to pull this off, you will need each container to have its own unique IP address.
Why are you running everything on its own separate port but on the docker host's IP? Why not bridge the networking and give each container instance its own unique IP address on your LAN? So, instead of "10.10.10.111:9443", just make the IP of that docker container say "10.10.10.112", and the next one "10.10.10.113", etc.? Then you could easily use host overrides in DNS Resolver on pfSense to point different hosts names to the corresponding IP address. And put each docker container on the native port for the protocol. So, if you are using
http://, then port 80. Ifhttps://, then port 443. -
@erniepantuso DNS handles name-to-IP, ports are separate. So you’d use myname:9443 in a browser and the override is for myname.
-
I run my own Unbound DNS which runs in a Docker container on my NAS. My pfSense is configured to use this DNS by IP.
I don't specify IP:PORT and the reason for that is that I run Unbound DNS in host based Docker container. Unbound has access to NAS IP. The reason is that Unbound is randomizing outgoing ports.
This config works for me without any issues. The DNS default port is used for inbound queries by all my network devices.
-
@markster said in Local DNS - Why so HARD?!:
I don't specify IP:PORT and the reason for that is that I run Unbound DNS in host based Docker container. Unbound has access to NAS IP. The reason is that Unbound is randomizing outgoing ports.
Not sure I follow what you are trying to say here. The discussion in this thread is about destination (or listening) ports and not ephemeral source ports. Pretty much every application will use random ephemeral ports as the source when communicating with "well-known" destination services. The rare exception being
ntpon Windows which will use 123 for both source and destination. So, yes anunboundinstance will source traffic to say a forwarder using a random ephemeral port (greater than 1000), but the traffic will have a destination port of 53 or 853 depending on whether DNS or DoT is being used. However, when responding to a client that has made a DNS request,unboundwill respond back to that client using the random ephemeral port chosen by the client when it sent the request.What we are talking about in this thread is having multiple docker containers running on the same IP address. In that case, the only way to distinguish them is to configure them to listen on different ports for incoming traffic. The OP does not want to remember the different port numbers for his various servers, so he wondered if DNS could help him. But it only can translate host names to IP addresses. It cannot translate a host name to both IP and port.
-
I’ve come to the conclusion that if I really want to do this in pfSense, I’m going to have to use HAProxy. I tried following this tutorial - “In this post we are going to see how to configure HAProxy and ACME in our pfSense firewall to be able to access services hosted on our servers, for example our Home Assistant interface or our web server.” Seems fairly applicable. If they’re running Home Assistant in a Docker container then they’ll have to get to the Docker host’s IP and the Home Assistant container’s port. The sticking point, though, is that the article is focused on accessing the Home Assistant web interface from somewhere out in the world using an FQDN - rather than from the LAN using a UDN (unqualified domain name). I already have that covered (using a Cloudflare tunnel that goes directly to the proper ip:port without using a reverse proxy) and it’s working well but I was hoping to glean enough information to apply it to my situation. It didn’t work. After following the procedure, when I try going to https://portainer.homelab, it takes me to a web search for Portainer.homelab. I tried switching the 2 WAN rules to LAN rules but it didn’t help. I think maybe I might have HAProxy setup properly but pfSense (DNS Resolver?) isn’t setup properly to send [whatever].homelab to HAProxy.
-
i think you've come to the most complex conclusion - but everyone has to make their own choices.
imho @bmeeks option of bridging your containers, so they have their own separate ip's is the better option
@bmeeks said in Local DNS - Why so HARD?!:
Why not bridge the networking and give each container instance its own unique IP address on your LAN? So, instead of "10.10.10.111:9443", just make the IP of that docker container say "10.10.10.112", and the next one "10.10.10.113", etc.? Then you could easily use host overrides in DNS Resolver on pfSense to point different hosts names to the corresponding IP address. And put each docker container on the native port for the protocol. So, if you are using http://, then port 80. If https://, then port 443.
-
@heper Thank you, again, for your help and guidance.
It’s not my intention to use an overly complex solution. I’d much prefer something simple. I guess I misunderstood (or just don’t understand how to implement) @bmeeks’s suggestion. The containers use the “bridge” network driver in Docker by default. And each one already has its own IP address. My Portainer container, for example, has an IP address (which, interestingly enough, I got from looking at the container’s configuration using Portainer) of 172.23.0.6. But I can’t reach (via LAN) the Portainer web interface using that IP address so it seems like a host override isn’t going to get it done.
Once again, I’m sure my very limited knowledge of TCP/IP networking is a big factor in all of this but I’m guessing that the reason I can’t reach the Portainer web interface at 172.23.0.6 is because it’s gateway is set to 172.23.0.1 (while my workstation and my iPad’s gateway is 10.10.10.1).
When I look at the details of my Portainer container, I see that it’s connected to the Docker network “homelab”. (I did this deliberately because most containers, when launched, use a network called “[container name]_default. I speculated that it might be better if all my homelab containers were on the same network so I created a network called “homelab - details below - and connected all the containers to it.) When I look at in Portainer) the details of the network “homelab”, this is what I see:
Name homelab
Driver bridge
Scope local
Attachable false
Internal false
IPV4 Subnet - 172.23.0.0/16 IPV4 Gateway - 172.23.0.1
IPV4 IP Range IPV4 Excluded IPsShould I try to change the homelab network so that the IPV4 subnet is 10.10.10.32/27 (or something similar - I came up with that subnet using [this subnet calculator](https://www.calculator.net/ip-subnet-calculator.html?cclass=a&csubnet=27&cip=10.10.10.32&ctype=ipv4&printit=0&x=80&y=5 - I don’t think I’ll ever have more than 30 containers, and I’m good with dedicating 10.10.10.33-62 to my containers) but if I do that, will it conflict with pfSense’s routing? (The DHCP pool is already configured for 10.10.10.150-254.) And what about the fact that, in the long run, I’m going to want some of these servers in DMZ VLANs?
Can I/should I leave the IP addresses as they are and use VLANs and/or configure my switch to allow communication between 10.10.10.x and 172.23.0.x? (If that’s even possible?)
-
@erniepantuso you can put your containers directly on your network, vs the "nat' that is normally done.. In this case you could have different IPs for your containers and they could all use say port 443 if you wanted.
This is normally done this way
https://docs.docker.com/network/macvlan/ -
@johnpoz Thank you! I’m off to read that link!
