I’m trying to setup a reverse proxy using Caddy (great and easy to configure).
Caddy runs a docker on my unraid machine and I want to redirect traffic to some other docker containers. I want the traffic to be able to connect from both outside and inside LAN. I have a server behind NAT, a dynamic IP, duckdns set up and then my own domain pointed using CNAME. Router had ports 80 and 443 forwarded to the appropriate ports assigned to the Caddy docker.
Everything works great from outside my LAN. However from inside my LAN I cannot access my.subdomain/abc or the 2 others. I get redirected to my router setup page instead. If I forward port 1234 to my server, I can access the abc service on my.domain:1234 from both outside and inside LAN. But it seems like the router hijacks all connections from inside the LAN on ports 80 and 443.
I’m looking for 2 possible solutions:
Setup something on my server (some kind of routing software) to let clients from inside the LAN connect to proper services through Caddy.
Change the http and https ports from 80/443 to something else, so that I could access my services from inside and outside the LAN using https://my.domain:444/abc. This is a less desirable solution but acceptable.
Of course I could get rid of the crappy DSL modem/router which doesn’t have a bridge mode (supplied by my telecom company) but this would be a final solution to this problem.
Hoping someone can point me in the right direction.
Hi @Krasnall, as noted by @tobya, this is well outside of Caddy’s scope.
To help you in your search, the problem you’re experiencing happens when two devices behind the same NAT endpoint (the external IP address assigned to your WAN interface) attempt to communicate with each other using the same external IP address.
One of two things usually happens; the router’s port forwarding is only configured on the WAN interface, and LAN traffic is therefore not forwarded (treated as traffic destined for the router itself), OR the router goes to send the packet out to the internet, realises the sender and destination are the same, and the packet is dropped entirely.
Two common solutions exist: split DNS (recommended) and hairpin NAT (avoid if possible).
Split DNS is when you have a DNS server that responds to internal requests for your domain name with the private IP address of the machine serving that domain name. Apart from having to maintain these separate DNS records, this is a straightforward, robust method of giving internal access to a service at a public domain name.
Hairpin NAT (also called loopback or NAT reflection) is a configuration in which the router treats any internal traffic from its LAN interface that is bound for its own WAN interface address as external traffic. This can cause a number of problems for machines not expecting this behaviour (what happens when machine 1 receives a response from machine 2 when it was expecting one from an internet address instead?) and involves double-handling your internal packets through the firewall.
The latter may also not be available on a consumer router, but most support simple recursive DNS servers or you can simply run your own DNS server and configure the router to hand it out for DHCP requests.