Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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'm running ubuntu and I have apache running, however, I can't ping internally to my static IP nor browse http://207.40.XXX.XX the web server using my static IP. I can only ping/browse localhost,, and OR 207.40.XXX.XX only from the outside world.

# cat /etc/hosts       localhost my-server

# hostname

# netstat -tapn
tcp        0      0    *               LISTEN      -                  
tcp        0      0 *               LISTEN      -               
tcp        0      0*               LISTEN      -               
tcp        0      0   *               LISTEN      -               
tcp        0      0*               LISTEN 

Any ideas why this is not working?

share|improve this question
Your question is poorly asked, but this may have your answer.… If you feel this is not the answer please tell us what IP addresses are configured directly on the Ubuntu box. – Zoredache Dec 27 '10 at 23:10
@Zoredache: As the link mentions, NAT Hairpinning might be the problem. – Mike Dec 27 '10 at 23:27
up vote 3 down vote accepted

Your NAT-gateway is not behaving in such a way as to allow it. This is how it is probably working:


  1. You send an ICMP Echo request from to
  2. This routes by way of your router.
  3. Your NAT gateway inside your router rewrites the request to be from (it's static IP address)
  4. Your router replies to the ICMP Echo request
  5. Since your router does not support ICMP state, it never passes the ECHO Reply back to you.


  1. You send a TCP/80 connection request from to
  2. This routes by way of your router
  3. Your NAT gateway rewrites the packet as coming from to
  4. Your NAT gateway notes that there is a port foward in place, so forwards the packet to
  5. The server at replies to the connection attempt from
  6. Your NAT gateway sees the reply and rewrites the To: address on the reply to, but leaves the From: untouched (
  7. Your computer at gets a packet from that it never requested, and drops it on the floor.
  8. Your connection languishes, and never opens.'

Note, it is possible that the reason ping is failing is because of the same reason HTTP is also failing. This is called 'NAT Hairpinning'.

What you need is a NAT gateway smart enough that at step 6 it also rewrites the source address.

share|improve this answer
Ok, I found out that If I disable NAT in my modem/router, I can ping fine, but my Internet connection is gone. Do I actually need to have NAT enabled? – Mike Dec 27 '10 at 23:23
NAT is required if you want any kind of internet connectivity. What you need is a better NAT implementation, which probably means a different router, but could be as easy as changing a config setting on your router. – sysadmin1138 Dec 27 '10 at 23:25
Thanks! I'll try to see if I can change the settings, if not I hope my ISP can provide a new modem. – Mike Dec 27 '10 at 23:31
I suspect you will have difficulty finding a modem. A common work-around is to just setup split DNS. You serve the public address to external clients, and the private address to internal clients. – Zoredache Dec 28 '10 at 0:06

Although 1138's answer is correct, I just wanted to toss in a detailed explanation about what "hairpin NAT" is, how it works, and why it's necessary in this circumstance. If you don't care about the nitty gritty details of IP, NAT and routing, please feel free to ignore the rest of my (rather lengthy) answer.

Without hairpinning, here is what happens during an HTTP connection attempt from a local LAN client ( to the webserver via the external IP address (

  1. sends its SYN packet to, port 80. Since is not on the local network, this packet is sent to the default gateway (i.e. the router).

  2. The router, which is configured to forward to, rewrites the packet's destination address to, and then delivers the packet to the webserver.

  3. The webserver receives the SYN packet, and sends a reply SYN-ACK packet back to the sender's address, which is Since is on the same network, the webserver delivers the packet directly to

  4. The SYN-ACK packet from arrives at, but the host there was not expecting a SYN-ACK from, and so it is dropped/rejected. The host at continues to wait for a reply SYN-ACK from, but of course, that packet will never arrive. The connection attempt will eventually timeout, perhaps after a few retries, and ultimately, the client and the webserver fail to establish a connection.

This problem can be solved by the router at step 2, by applying a "hairpin NAT". In short, the solution is to trick the client and webserver to send their mutual traffic through the router. This is cleverly accomplished by applying a second phase of NAT at step 2, in addition to the one phase normally applied for port forwarding. Here is the sequence again, this time with the added hairpinning NAT:

  1. As before, sends its SYN packet destined for, port 80, to the router.

  2. As before, the router receives the SYN packet, and, as per its configured port-forwarding rule, it rewrites the destination address to This time, however, the router notices that it is about to "hairpin" the packet back out onto the same network from which it was received, so it also rewrites the packet's source address to the router's own LAN address (say: The router then delivers the packet to the webserver at

  3. The webserver receives the SYN packet, and sends its reply SYN-ACK packet back to the sender's address, which, this time, is Thus, the reply goes back to the router.

  4. The router receives the SYN-ACK from the webserver, and recognizes that it is a reply to a packet that it recently NAT-ed (twice). So the router dutifully reverses both NATs, and the reply packet now has source address and destination address Hence, the reply is delivered to, the TCP connection handshake continues, and the client and webserver are able to successfully communicate.

Thus, with hairpinning support in the router, the host at thinks it's talking to a webserver at, while the webserver at thinks it's talking to a client on the router itself ( When hairpinning, all traffic between the two hosts passes through the router, even though both hosts are actually on the same network. This is obviously a suboptimal use of network resources, and is the main reason why setting up a split DNS is usually preferrable to relying on hairpinning.

share|improve this answer

What kind of firewall are you using? It sounds like NAT hairpinning is not turned on.

share|improve this answer
I have an Actiontec PK5000 – Mike Dec 27 '10 at 23:24

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.