0

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 abc.com 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:

127.0.0.1           localhost localhost.localdomain
127.0.0.1           localhost
#192.168.2.110      marvin.localhost.com marvin
#10.8.0.1          marvin marvin.localhost.com
127.0.0.1      mx.localhost.com.cust.b.hostedemail.com
192.168.2.110      DOMAINNAME.com
# 192.168.2.110    marvin.DOMAINNAME.com 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.

1
  • abc.com isn't in your hosts file... how did you set it up before?
    – mgorven
    Jul 13, 2012 at 23:41

3 Answers 3

2

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.

1
  • 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, 2012 at 16:17
1

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

4
  • 1
    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, 2012 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. Jul 15, 2012 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, 2012 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. Jul 19, 2012 at 16:53
0

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 192.168.122.0/24 IPs. So I have:

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

So what happens is that if another internal VM, say 192.168.122.5, tries to talk to 172.1.1.7, those packets do get forwarded to the target VM (192.168.122.7) -- But, since the source IP address is 192.168.122.5, and is on the same subnet, the target VM sends reply packets back directly to that address, without going through the router IP (192.168.122.1). 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 192.168.122.0/24 -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}

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .