1

I've been trying to get a server up and running to deploy my cloud service. Most of my operations are client ip based. When I was using godaddy, the script that returned the client's ip worked fine (php, $_SERVER variable). Now on my server, it's returning 192.168.1.1 (my router/gateway). Why is this? I'm running Apache, PHP5, Ubuntu Server 12.04 LTS. I appreciate it the help in advance.

Osmium USA
  • 153
  • 1
  • 8
  • How did you set it up? – Michael Hampton Feb 24 '13 at 23:13
  • I haven't played with the config files. The domain name uses a zone record to my IP. My router then port forwards from 1007 to 80 on my server. I think the port forwarding is doing it, but that really doesn't make any sense, that shouldn't touch the source ip portion of the request. – Osmium USA Feb 24 '13 at 23:20
  • 1
    Can you diagram the network layout and example IPS? Something akin to `1.2.3.4 -Internet-> 192.168.1.1 -Private-> 192.168.1.5` ? – R. S. Feb 25 '13 at 01:35
  • Is this problem occurring when *you* test your server or when other people actually *use* it? – David Schwartz Feb 25 '13 at 07:52
  • I'd start looking at the settings on the router/gateway; it sounds as though it's masquerading all inbound addresses. – Jenny D Feb 25 '13 at 10:12
  • Is this server you are setting up currently on your local network? Are you accessing the server via the external (WAN) address of your local router which you have NAT rules setup on to map through to the local IP of your server? – Matt Feb 25 '13 at 10:28
  • I can get the real client IP when its connected to from an outside source (confirmed with my phone on 4G). I am connecting to my IP address from inside that IP address. So, now that this problem is solved, could explain why this happens? Thank you. – Osmium USA Feb 25 '13 at 13:49

2 Answers2

1

You're using hairpin NAT, which must rewrite the source IP address. If you're going to connect to an outside IP address from the inside, the source IP address will always have to be the gateway's IP address. Otherwise, the return packets would never get back to the source machine.

My advice to you is simply not to do this. If you want to connect to a local machine, use its local IP address.

This answer explains the same issue.

Here what would happen if you didn't use SNAT:

  1. The request originates on a machine with only a private IP address, so it has a private source IP address.

  2. The destination is not local, so the request is sent to the gateway.

  3. The gateway rewrites only the destination (this is wrong!) and sends the packet to the server.

  4. The server sees a query from a local IP address, so its sends the reply to a local IP address.

  5. The local machine sees a reply from a local IP address to a packet sent to a remote IP address and ignores the reply.

Hairpin NAT is a form of dual NAT, using both SNAT and DNAT. It cannot work without SNAT. The replies must also be NATted, which means the source has to be NATted to get the replies to the gateway.

Community
  • 1
David Schwartz
  • 31,449
  • 2
  • 55
  • 84
  • That is plain wrong. – Hauke Laging Feb 25 '13 at 01:20
  • What part do you think is wrong? My statement that he's using hairpin NAT, my explanation of why hairpin NAT requires SNAT, or both? – David Schwartz Feb 25 '13 at 07:55
  • It's wrong that this must be the explanation (even if this configuration is used); cannot edit the comment any more to make that clear. At least if the WAN IP is not an interface on the local router you can access the WAN IP from internal clients without DNAT/SNAT on the local router, even gaining a bit performance. You can configure the server as nexthop for the WAN IP and do DNAT from WAN IP to local IP on the server. The server sends its reply packets directly to the client but with the expected source address, saving the router from this load. Possible but improbable indeed. – Hauke Laging Feb 25 '13 at 11:11
  • @HaukeLaging: I never said this "must be" the explanation, only that it *is* the explanation. It is also the most likely explanation. – David Schwartz Feb 27 '13 at 22:48
-1

Check with tcpdump what the packets look like that reach the server. Maybe SNAT has been activated on the gateway.

Edit 1

This refers to the case that the access is from outside the local net so that SNAT is possible but not necessary.

Hauke Laging
  • 5,285
  • 2
  • 24
  • 40
  • Here's what one line of the tcpdump of port 40 (-n) looks like: `18:03:51.124438 IP 192.168.1.1.63981 > 192.168.1.131.80: Flags [.], ack 2156, win 4238, length 0` Obviously it's getting all of the traffic from the router. Where do I find the SNAT setting? Is it different from NAT (I need this enabled to get to the internet from my other computers attached to this router.) – Osmium USA Feb 25 '13 at 00:04
  • NAT is the general term. DNAT, SNAT (source/destination) and MASQUERADING (kind of SNAT) are NAT options. Have a look at `iptables -t nat -L -nv`. You need NAT to the Internet. This is NAT to the LAN. The same technology but both configurations are not related. It should be no problem to deactivate SNAT to the LAN without affecting your Internet connectivity. – Hauke Laging Feb 25 '13 at 00:14
  • @HaukeLaging: SNAT is, and must be, activated on the gateway. Without SNAT, hairpin cannot possibly work. (How would the replies get back?) – David Schwartz Feb 25 '13 at 01:01
  • @DavidSchwartz Interesting question, how the replies would get back if the **gateway** sends DNATed packets to the webserver. Let me guess, what would a system do with its reply packets to an address outside the link network? Oh, yeah, send it to its gateway. Which is exactly what's needed. No need at all for SNAT. If that cannot possibly work, why did I just successfully test right that? So if you are so convinced that you don't believe me: I am sure you have the opportunity to test for yourself. – Hauke Laging Feb 25 '13 at 01:19
  • @HaukeLaging: You're confused. The replies are only to an address outside of the link network if SNAT is used. If SNAT is not used, the replies are to the original source address, which is inside the private network since the request originated on a machine that only has a private IP address. – David Schwartz Feb 25 '13 at 01:22
  • @DavidSchwartz "since the request originated on a machine that only has a private IP address" Where does this information come from? All the OP mentioned is the gateway IP. That makes sense only if he does port forwarding from the WAN IP. Client 1.2.3.4 makes a connection to his WAN IP 4.3.2.1. The gateway does DNAT and SNAT, resulting in a packet from 192.168.1.1 to 192.168.1.131. Without SNAT the result would be a packet from 1.2.3.4 to 192.168.1.131 which would not result in any problems. If the client was in the local net it would not use the gateway. – Hauke Laging Feb 25 '13 at 01:34
  • @HaukeLaging: Sorry, you're completely and utterly confused. I'm not sure how I can explain it any more clearly than I already have. He's not testing over the Internet. He's testing with an inside machine accessing his server's public IP address. This *requires* SNAT to work. Otherwise one half of the connection will be NATted and the other won't, which can't work. – David Schwartz Feb 25 '13 at 01:54
  • @DavidSchwartz You are very good at claiming I was confused and very bad at answering the simple and important question what your claim ("inside machine accessing his server's public IP address") is based on. In the case you assume SNAT is necessary, that's right. In the case I assume it's not (possible though, explaining the described effect). Which assumption is right cannot be decided from the information he gave. I am surely not "confused" just because because we make different **assumptions** about the scenario. – Hauke Laging Feb 25 '13 at 02:19
  • @HaukeLaging: This is like arguing that if someone says they can't access the Internet, it's reasonable to answer, "You need a computer to access the Internet". SNAT being enabled where not needed is extraordinarily improbable. Many routers won't even let you do it and automatically use SNAT when, and only when, it's needed. – David Schwartz Feb 25 '13 at 07:57