You already have a bunch of NAT-level suggestions, so I wanted to mention there’s an alternative solution: split-horizon DNS, or simply split DNS. Basically, you run a DNS server in your LAN (like pi-hole) which resolves to the private IP, so resolving externally and internally give different results. This way packets don’t hit the router at all. You can also do a wildcard like *.something.lan to avoid having to add a record for every service, and only configure your reverse proxy.
Comment on What path does data take when connecting to a domain at my address?
jws_shadotak@sh.itjust.works 1 day agoI have a reverse proxy set up already. The path from the outside goes:
DNS -> my IP -> reverse proxy -> server
I’m just wondering what happens when my own devices on the same network go to the domain.
floquant@lemmy.dbzer0.com 18 hours ago
Darkassassin07@lemmy.ca 1 day ago en.wikipedia.org/…/Network_address_translation#NA…
TL;DR Your router sees you trying to reach your externap address and routes the connection back to your LAN without leaving the network.
This does still depend on a functional internet connection however, as your client gets your public IP from a public DNS server over the Internet.
If you were to run a DNS server locally (I use pihole for this), you could have that DNS respond with your local IP, allowing clients within your LAN to resolve the name without needing to reach out to public DNS. This means your local connections will still work when your internet is down; it also provides more privacy by keeping those requests local and can let you make local-only names that aren’t publicly listed.
Of the ~28 FQDNs in my setup, only 4 are public. The rest is local/vpn only and not publicly listed due the above. The reverse proxy then drops all connections that don’t use one of those recognised names, before even completing the TLS handshake. (So direct connections from someone port scanning my IP or using a domain name someone else has pointed at my IP are completely ignored/dropped without response. The server doesn’t even send the TLS cert so as to not expose the names defined in it.)
NarrativeBear@lemmy.world 23 hours ago
What you are looking for is something called NAT Reflection/HairPin NAT/NAT loopback.
When you search for a “domain.example.com” your router loops you back at your reverse proxy and all the traffic remains “internal”. Your website will still be externally accessible (the ones you setup to be).
Here’s a example of how to set this up on PfSense router.
folekaule@lemmy.world 1 day ago
Your diagram is almost right, but I think it will help to understand more of the details. It’s important to understand the difference between DNS (domain name lookup) and IP routing.
To break your diagram down more, this is what happens when any computer looks up your website:
- The device does a DNS lookup of “example.com” using their name server, which may forward it to another DNS server (most home routers do this). I won’t go into the multiple levels of DNS lookups and caching here.
- Through looking it up by DNS, the device now has the final IP. DNS is now out of the picture and we’re doing IP routing.
- The device tries to make an HTTP connection to your external IP. HTTP is a protocol that runs over TCP/IP (UDP is used for QUIC/HTTP3). To keep things simple I’ll stick with old fashioned HTTP over TCP without SSL. I am also skipping over NAT.
- For TCP, it performs a handshake, which the reverse proxy will negotiate. Once the connection is established, the browser speaks HTTP to the reverse proxy. It looks something like:
GET / HTTP/1.1 Host: example.com ...lots more headers... <blank line>
- The reverse proxy then takes that request, maps it to an upstream (if any), and makes another request to it via the configured transport. If that part falls down, you will see a 503 error. Otherwise, you will see the response from the upstream, possibly with some modifications made by the reverse proxy (some will rewrite links and cookie paths, for example)
- The reverse proxy sends that response back to the client.
That’s all very simplified, of course.
As others pointed out, things may seem to work differently from the “inside”, if hairpinning is not available or enabled. This is not related to DNS, but to IP routing. The firewall doing NAT can get confused and not know what to do when an internal request goes to an external IP that it itself has. When it turns that around and routes it back to the internal network, that’s called hairpinning.
One “fix” for this, often used in enterprises, is to use so-called split DNS. All that means is that if you’re asking your internal DNS server for an internal name, it will give you the internal address (192.168.1.123 for example), but an external client would get an external IP.
TL;DR: DNS and IP routing are separate concerns and happen at different parts of the TCP/IP stack.
CameronDev@programming.dev 1 day ago
Devices on your domain will typically do a DNS lookup, which gets your public IP. Then they connect to that public IP, which your router recognises and redirects back into your network. The router then forwards that to your reverse proxy.
If your router isnt doing that properly (timing out usually), look up a setting usually called “NAT loopback” or “NAT hairpinning”. Thats the setting that detects your public IP, and redirects it back inward.
lyralycan@sh.itjust.works 1 day ago
Also if you have your own net filter like PiHole or AdGuard Home with DNS rewrites set up, and you use it as a DNS server in WiFi settings, then it works a small bit differently. A public IP and NAT routing is never needed, as the device contacts the DNS server via the router Access Point, and the DNS server translates the service’s FQDN into its internal IP. Aside from that, provided everything is set up correctly, all actual data packets go from device ←→ router ←→ service
CameronDev@programming.dev 23 hours ago
I had issues with that recently, I had a few of my internal services set to resolve internally, but pihole was making a mess of them and returning IPv6 addresses in addition to the IPv4 internal addresses. And then browsers would try use the broken ipv6 address and fail. I just happily rely on hairpinning now, it hardly makes a difference in the scheme of things.