Site not accessible through public IP from intranet

Question

I'm hosting some sites/services like Jenkins on a server I've got at home. I'd like to have them accessible from the Internet as well as intranet through a public domain name. For this I've registered a noip domain name pointing to my (dynamic) public ipv4. The router has port forwards configured to NAT a port onto my server.

All this was working fine, until I've changed network provider and thus my router last weekend.

Now I can't connect to my sites from the intranet using the public domain name which is being resolved to my public ip.

What I've tested:

• Pinging the public domain name from intranet resolves the correct public ip -> no DNS issue
• Sites are accessible from the internet when using the public domain name (or ip) and correct port
• Sites are NOT accessible from the intranet when using the public domain name (or ip) and correct port. In this case the browser shows a network connection timeout error (ERR_CONNECTION_TIMED_OUT)
• Sites are accessible from the intranet when using the internal ip and correct port (as specified in the port forwarding rule for destination)

What network config on the router has to be changed for it to route this correctly from the intranet?

Router manual: https://www.sunrise.ch/content/dam/sunrise/residential/hilfe/internet/Sunrise_Home_User_Manual_Sunrise_Internet_Box_new_firmware_e.pdf

Router configuration: Firewall is currently disabled to make sure it is not causing issues:

This is a duplication of my post here: https://networkengineering.stackexchange.com/posts/59290

Answer 1

This is mostly a guess-based answer based on the most common problem of this type. To be completely sure, however, you'd need to actually investigate what the server sees (Wireshark/tcpdump are good tools).

---

DNAT (port-forwarding) within the same subnet is very problematic, as the return path from the server to client usually bypasses the router, and there is no chance to un-NAT this return traffic.

To work around this, some (but not all) routers have a "NAT loopback" or "NAT hairpin" option. As far as I understand, this option additionally performs SNAT for all connections, rewriting the client IP address and making the server think all connections come from the router itself.

Without loopback/hairpin, your clients can reach the server, but do not recognize replies that have arrived from the server (as the IP address no longer matches), so a connection can never be established.

• If your router does not have this option, but has manual advanced NAT configuration, you could build a similar NAT rule yourself – tell the router to 'masquerade' all connections coming from the LAN and going back to the same LAN.

  (This of course still has the same downside of hiding clients' IP addresses from the server.)

• However, IMHO, the best option (untested personally, but I have no reason to believe it should not work) is to put the server on a different subnet from the rest of your devices. As long as the server's return traffic to clients goes through the gateway, the problem should be avoided – even if there is no VLAN separation and if both subnets live on the same ethernet.

  The above could also possibly be implemented by changing the subnet mask or adding custom routes to the server.