Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an apache webserver / mailserver (running on Ubuntu) setup like following:

  • Speedport Router with NAT for all required ports
  • DynDNS to get the domain name by using a non-static IP address

The problem I face is, that the website can be accessed ok from outside of the Intranet but not anymore from the inside.

The speedport router does not allow to make any changes regarding to the domain name routing

This is my hosts file:           localhost localhost.localdomain           localhost
# marvin
#          marvin
# marvin

::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

This used to work ok for a year and suddenly stopped working, which puzzles me. It seems like in the Intranet the domainname is not published / routed correctly.

share|improve this question isn't in your hosts file... how did you set it up before? – mgorven Jul 13 '12 at 23:41
up vote 2 down vote accepted

This is a side effect of using NAT with IPv4. Your intranet clients get the "outside" IP address, but that address is only accessible from outside the intranet.

There are two solutions: The first is split-horizon DNS. The second (and probably much better) solution is to deploy IPv6, which does not suffer from this problem.

share|improve this answer
Yeah- somehow even when i try to access the absolute IP address from inside the intranet it does not work. Is this rather router or serve related? – idplanter Jul 19 '12 at 16:17

The quick work-around is to address the server by its internal IP address rather than the internet URL when working from the LAN.

share|improve this answer
Yes - doing that already, but its a nuisance having to do this each time you login into the intranet with a notebook... – idplanter Jul 13 '12 at 14:44
@idplanter: What, you can't create a shortcut to it using the IP address instead of hostname? In any event, this is a classic hairpin NAT problem, and your basic options are the two answers here, enterprise-grade network gear with a good network admin to hack around the problem, separate internal and external sites, or not accessing the site from both inside and outside the network. Pick your poison. – HopelessN00b Jul 15 '12 at 16:13
@HopelessN00b - I could, but thats not very elegant. Also, it had been working flawless in the same configuration for >1 year. Which is why I am still wondering where something went wrong suddenly. – idplanter Jul 19 '12 at 16:15
@idplanter: That's certainly fair enough, but we certainly don't have enough information to tell you why it stopped working. That said, it doesn't change the answer much. The standard way to remove hairpin NAT DNS problems is split-horizon DNS, (or IPv6 if you're lucky enough to be able to migrate to it already) as suggested by Michael Hampton. The standard workaround is the answer suggested here by simplr. If you're really looking for troubleshooting or diagnostic help, that's a very different question than asked here, and requires more info. – HopelessN00b Jul 19 '12 at 16:53

Not sure if this would work for you, but I had the same issue with VMs running with non-routed IP addresses, and forwarding external IPs to them. In my setup, I have a Red Hat server running KVM. The VMs are all IPs. So I have:

extip= (the external VIP address I'm forwarding to one of the VMs)
destip= (the internal non-routed IP of a VM)

So what happens is that if another internal VM, say, tries to talk to, those packets do get forwarded to the target VM ( -- But, since the source IP address is, and is on the same subnet, the target VM sends reply packets back directly to that address, without going through the router IP ( Now those packets don't get recognized by the source VM as part of the same session, so they get dropped. The solution was to add a POSTROUTING SNAT rule to re-write the source IP address, of any packet that comes from the internal VM network -- that forces reply packets to go back out through the gateway IP address. Therefore, my final iptables rules look like this:

# Main DNAT routing rule
iptables -t nat -I PREROUTING -p tcp -d ${extip}/32 -j DNAT --to-destination ${destip}

# SNAT rule to handle internal hosts talking to external IP
iptables -t nat -I POSTROUTING -s -d ${destip}/32 -p tcp -j SNAT --to-source ${extip}

# Final DNAT rule, so the firewall host can also talk to the external IP
iptables -t nat -I OUTPUT -d ${extip}/32 -p tcp -j DNAT --to-destination ${destip}
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.