I’ve got Immich working great on Unraid, but if I’m on my network I can’t really use it. Just fails to resolve the dns. I looked it up and it’s that my router doesn’t support hairpin or something. It’s a Aginet hb810. I found a workaround in the Immich client where you can add a second entry that’s network specific, but it doesn’t seem to work very reliably.
What are my options?
Opinionated wall of text incoming:
Hairpin is an annoying hack. It happens and is necessary when you are getting a public IP from DNS but the service is not actually listening on that address itself, because the router owns that address, and that address is actually on the other side of the router, the public-facing side, not the side you’re on, so now you have to go out to the public side of the router, turn around (the hairpin turn) and come back in as if you were a public user in order to get to a service that was literally sitting right next to you (on the private side) the whole time.
What you should do instead: You should have your own internal DNS for your own personal network that resolves the DNS properly within the context of that network. This avoids needing to use hairpin at all, because your traffic is never trying to go out to the public internet in the first place. If you get the correct, context-specific best path IP to your services at all times, you don’t have to use the naive, public IP for immich that doesn’t even actually exist on your local network.
The terminology around all this is confusing and sometimes stupid because private networks behind NAT never really existed when DNS was invented, and a lot of people deal with it in stupid and overcomplicated ways. If this same DNS server were then also going to be shared and used publicly to host your own domain names to other people, you would need a thing called “split zones” or “split DNS” but you don’t need to do that and you should avoid that too. Keep private DNS private, and leave public DNS out in public. Separate them intentionally and deliberately.
If you are getting the public IP for your Immich, then you are using its public DNS. I will try and make it simple for you, the way I think everyone should do it:
Your LAN/VPN environment is private. It should have its own dedicated authoritative private DNS server whose purpose is limited to completely and comprehensively servicing all the DNS IP lookup needs of that LAN/VPN environment and being the sole source of truth within that network. Often, the local network’s DNS is already correctly configured and provided by your router to handle all public IPs, and this is usually completely fine for self-hosting. What matters is that you should be able to add custom IP addresses to it, and it should be private to your network. Nobody else should have access to this DNS configuration, not because it’s really important for security but just because it is irrelevant outside the context of your local network, which is usually exactly what your router DNS provides. Your internal network DNS is responsible for two things within that environment:
You just have to implement and maintain the first part, usually in your router’s configuration. If you want more control or consistency over the DNS your local network is using it can also be self-hosted with something small like dnsmasq, or even big old granddaddy bind/named (not as complex as it seems and very standardized). Either way, that’s your responsibility, and once you’re providing correct local IPs for Immich on your local DNS (outside your network, you and the public will still use public DNS and get the public IP) everything will just work.
Hairpin may feel convenient. It’s not, it’s a workaround for a misconfiguration. Having private DNS that is separate and distinct from public DNS may feel like duplication of effort, but it’s not, it’s fundamental to even having a local network and puts you in the drivers seat for the layout of that network. Take responsibility for it instead of letting hairpin fix your mess.
Got it, roll my own dns server and disable it on the aginet device
I agree it’s a stupid hack, but there are good reasons to use public addresses in your local environment too: for example you’ll need it for any roaming device like a laptop or a phone. It also vastly simplifies certificate management where you can just use sour existing publicly valid certs to access your services.
The only proper solution would probably be ipv6, but that’s not trivial either.
You can do all those things with proper routing and there is no difference from mobile devices (as long as they use DHCP and what mobile device wouldn’t?). What I’m suggesting does not change anything on the public side. You still authenticate publicly to renew your certificates. You still give the same certificates to both public and local networks. They’re still valid. Nothing changes.
The only difference is that when you’re local, your DNS gives you the correct local IP address where that service is hosted, say, 192.168.12.34 instead of using public DNS, getting an external IP that’s on the wrong side of the router, and having to go outside your own network and come back in. Hairpin is like that simpsons episode where Abe goes in the revolving door, takes off his hat, puts his hat back on, and goes back out the same revolving door in the span of 2 seconds. It’s pointless, why are you doing that? If you didn’t want to be on the outside of the network, why are you going to the outside of the network first? Just stay inside the network. Get the right IP. No hairpin routing needed. No certificate madness needed. Everything just works the way its supposed to (because this is in fact the way it’s supposed to work)
Ahh okay. Well then the issue becomes actually having this DNS server with all the records you need, and serving it to the correct clients - for example you’ll need a different set of records for your LAN and for your VPN.
Although come to think of it since my DNS records are already kinds scripted I could probably fairly easily just script different URLs based on the DNS server I want to serve them from… Maybe worth a try.