On Thursday 26 December 2002 12:36 am, Jun Sun wrote: > I am using both DNAT and SNAT (ip masquerading) on a gateway machine > connecting a private network and internet. The DNAT is used to route > all http traffic to a specific our own web server on the internet. > > Now I am facing an tough problem. Once receving the http request, our > own web server needs to know which machine in our private network > sends this request. Based upon the wording of your question, I presume the server in question isn't physically local? If it is, you can probably handle this by subnetting the server separate from the clients, and NOT SNATting local communications. As long as the server and clients believe that the gateway is the only way to reach each other then traffic will route properly. If there are other routers in the network that both server and clients share then things could be a little more complicated, but still should be doable. Assuming the server lives elsewhere, but you have some control over it, or influence over its configuration, (the rest of your question seems to indicate this is true) look into tunneling. This is the 'proper' way to connect physically non-contiguous networks across a third 'public' network. Create an IPinIP tunnel with the server and the gateway as endpoints, and route traffic from the local network destined for that server through the tunnel instead of NATting. If configured properly it will appear at the server with the local private IP from the client machine, and replies from the server will route back through the tunnel. Check http://lartc.org/howto/lartc.tunnel.html for info and quick'n'dirty examples. Obviously the gateway is running Linux. If the server is as well you should be able to use basic IPinIP tunneling, if the server is Win2k or such look at IPV4 GRE tunnels. It will be important to remember to exclude this traffic from the masquerading SNAT otherwise performed on outbound traffic from the local network. Also, if you are on a dynamic IP (MASQUERADE target instead of SNAT, your phrasing makes this unclear) it becomes necessary to change the tunnel configuration at the server end whenever the gateway's public IP changes, which would complicate things considerably. If both IP's are static, and both machines run Linux, this should all be very simple to implement. Finally, pay attention to MTU, packet size settings, as you may need to reduce them by a couple of dozen bytes to accomodate the added tunnel header without additional fragmentation. Trying to implement your backtrack double-check approach would, I believe, require some custom coding, and I'm quite confident that a tunnel will incur considerably less processing and bandwidth penalty, even if it is necessary to set up userspace code at each end to synchronize to a dynamic IP. j PS - essentially unrelated, between beginning this reply and sending it I decided to set up an IPV6 in IPV4 tunnel, and now I'm on the 6bone. Now I get to play with ip6tables... > Since the web server knows which port on gateway machine is sending > the request, if we know which private IP is mapped to that port, web > server could query the gateway machine and obtain the private IP > address of the requesting machine. > > Does anybody know how to figure out this private IP to gateway > out-going port mapping? > > Assuming this solution works, it does require extra round of traffic > between the server and gateway machine. I wonder if there are any > better solutions. For example, if we can somehow "tag" the http > packets when the gateway re-routes them to our web server and somehow > our server can "read" the tag, things will be solved in a much more > elegant way. > > Thanks for any pointers. Please cc your reply to my email address > as I am not on the mailing list yet. > > Jun
