Can't ping static IP from internal network, only from outside

Question

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, 127.0.0.1, and 192.168.0.120 OR 207.40.XXX.XX only from the outside world.

# cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       my-server.myhost.com my-server

# hostname
my-server

# netstat -tapn
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -                  
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:29754         0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN 

Any ideas why this is not working?

Solution 1

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

Ping

1. You send an ICMP Echo request from 192.168.0.5 to 207.40.123.45
2. This routes by way of your router.
3. Your NAT gateway inside your router rewrites the request to be from 207.40.123.45 (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.

HTTP

1. You send a TCP/80 connection request from 192.168.0.5 to 207.40.123.45
2. This routes by way of your router
3. Your NAT gateway rewrites the packet as coming from 207.40.123.45:41345 to 207.40.123.45:80
4. Your NAT gateway notes that there is a port foward in place, so forwards the packet to 192.168.0.120:80
5. The server at 192.168.0.120 replies to the connection attempt from 207.40.123.45:41345
6. Your NAT gateway sees the reply and rewrites the To: address on the reply to 192.168.0.5:36311, but leaves the From: untouched (192.168.0.120:80)
7. Your computer at 192.168.0.5 gets a packet from 192.168.0.120 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.

Solution 2

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 (192.168.0.5) to the webserver via the external IP address (207.40.123.45):

1. 192.168.0.5 sends its SYN packet to 207.40.123.45, port 80. Since 207.40.123.45 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 207.40.123.45:80 to 192.168.0.120:80, rewrites the packet's destination address to 192.168.0.120, 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 192.168.0.5. Since 192.168.0.5 is on the same network, the webserver delivers the packet directly to 192.168.0.5.

4. The SYN-ACK packet from 192.168.0.120 arrives at 192.168.0.5, but the host there was not expecting a SYN-ACK from 192.168.0.120, and so it is dropped/rejected. The host at 192.168.0.5 continues to wait for a reply SYN-ACK from 207.40.123.45, 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, 192.168.0.5 sends its SYN packet destined for 207.40.123.45, 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 192.168.0.120. 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: 192.168.0.1). The router then delivers the packet to the webserver at 192.168.0.120.

3. The webserver receives the SYN packet, and sends its reply SYN-ACK packet back to the sender's address, which, this time, is 192.168.0.1. 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 207.40.123.45 and destination address 192.168.0.5. Hence, the reply is delivered to 192.168.0.5, 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 192.168.0.5 thinks it's talking to a webserver at 207.40.123.45, while the webserver at 192.168.0.120 thinks it's talking to a client on the router itself (192.168.0.1). 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.

Comments

[Zoredache]

Your question is poorly asked, but this may have your answer. serverfault.com/questions/167601/… If you feel this is not the answer please tell us what IP addresses are configured directly on the Ubuntu box.

[Mike]

@Zoredache: As the link mentions, NAT Hairpinning might be the problem.

[Mike]

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]

I have an Actiontec PK5000

[Deb]

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.

[Mike]

Thanks! I'll try to see if I can change the settings, if not I hope my ISP can provide a new modem.