So I have a duckdns address: ghi.duckdns.org (example name). I used caddy to setup a reverse proxy to access my Immich container outside of my network using the duckdns address. If I use that address inside my local network, the page does not load.
So I've read something about hairpin, but I have no clue how to set this up. I see something on the service page with hairpin, but then I'm lost.
Try disabling SFE/CTF (NAT acceleration) on the Setup page. That "hack" is known to cause all kinds of weird problems. And I seem to recall the breaking of NAT loopback being one of them.
Try disabling SFE/CTF (NAT acceleration) on the Setup page. That "hack" is known to cause all kinds of weird problems. And I seem to recall the breaking of NAT loopback being one of them.
Well you could map the domain name in DNSMasq, so when you're local, the name is resolved locally.
Code:
address=/somedomain.com/192.168.1.100
Of course, that limits you to a single target IP on your port forwards. But if that's all you need, it should work.
You might also consider NOT using port forwarding at all, and instead use something like Cloudflare tunnels. IOW, establish an *outbound* connection from your network to a public reverse proxy, from which you can tunnel back into your various service(s). This makes the issue of NAT loopback moot since you're always making public references to your services, regardless whether you're inside or outside the network hosting those services.
I suppose something like Tailscale or Zerotier could be used as well, but these are not quite as feature-rich as Cloudflare (there are others besides Cloudflare (e.g., Twingate); I'm only using them as an example).
Of course, this introduces a third-party and some additional complexity, but something like Cloudflare also provides additional benefits (managed certs, DDOS protection, MFA, geo-location filtering, etc.).
Well you could map the domain name in DNSMasq, so when you're local, the name is resolved locally.
Code:
address=/somedomain.com/192.168.1.100
Of course, that limits you to a single target IP on your port forwards. But if that's all you need, it should work.
You might also consider NOT using port forwarding at all, and instead use something like Cloudflare tunnels. IOW, establish an *outbound* connection from your network to a public reverse proxy, from which you can tunnel back into your various service(s). This makes the issue of NAT loopback moot since you're always making public references to your services, regardless whether you're inside or outside the network hosting those services.
I suppose something like Tailscale or Zerotier could be used as well, but these are not quite as feature-rich as Cloudflare (there are others besides Cloudflare (e.g., Twingate); I'm only using them as an example).
Of course, this introduces a third-party and some additional complexity, but something like Cloudflare also provides additional benefits (managed certs, DDOS protection, MFA, geo-location filtering, etc.).
IOW, you might want to reconsider your overall approach here rather than remaining "old school" w/ traditional port forwarding and NAT loopback.
I tried something like this, and also address=/ghi.duckdns.org/192.168.1.123, but that did not work.
You can NOT specify a port on a domain name. Domain names only resolve to an IP.
This is why I suggested something like Cloudflare, where you can *hide* your own public IP and the port behind a different FQDN!
That's why I have duckdns. It hides my public ip too. Or is that a wrong assumption?
Not if it's being updated w/ the WAN ip of your router! Which is typically the case. Anyone can easily use the dig or nslookup utilities to resolve your DDNS domain name and identify your public IP. In contrast, something like Cloudflare acts as a reverse proxy w/ its own domain name and public IP, which you can then map to *your* public IP and port(s), thus masking your public IP and port(s) from the end-user.
I see. Just tried the dig utility and gave me my WAN ip indeed. Learned something here. Let's see what Cloudflare can do...
If something like Cloudflare is overkill for your needs, then you might want to consider using FT (FreshTomato) rather than DD-WRT. I know for a fact FT had the same problem w/ CTF and NAT loopback and that a fix has recently been added. I'm very familiar w/ it since I was involved w/ the OP that first reported it (he's even using the same R7000 router) and complained about the implementation (it works, I just don't like the way they did it).
If something like Cloudflare is overkill for your needs, then you might want to consider using FT (FreshTomato) rather than DD-WRT. I know for a fact FT had the same problem w/ CTF and NAT loopback and that a fix has recently been added. I'm very familiar w/ it since I was involved w/ the OP that first reported it (he's even using the same R7000 router) and complained about the implementation (it works, I just don't like the way they did it).
Ok, I'll look into it. I had some stability issues in the past with freshtomato, and DD-WRT has been great. But it's worth a try for my usecase. Is the above 'fix' in the 2024.4 release?
When I tested it, I was using 2024.3, and have no reason to believe it's been removed. You'll quickly know if you enable CTF and dump the mangle table.
Only concern I have w/ 2024.4 is the following (which is unrelated to NAT loopback).
When I tested it, I was using 2024.3, and have no reason to believe it's been removed. You'll quickly know if you enable CTF and dump the mangle table.
Only concern I have w/ 2024.4 is the following (which is unrelated to NAT loopback).
