Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
abc.com isn't in your hosts file... how did you set it up before? –  mgorven Jul 13 '12 at 23:41
add comment

3 Answers 3

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
add comment

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
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 '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
add comment

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}
share|improve this answer
add comment

Your Answer

 
discard

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.