>> What is it exactly what you want to accomplish? > > Maybe this is contrived and not a good method.. > > I want the above-described kind of option, to pick out and DNAT > connections on a certain port (say, http) directed at the > box, but not > those on the same port but directed elsewhere (like google being > accessed through the box being the gateway). Purpose - to > DNAT-encapsulate some service by the box. Yes, but there is a difference: Here you are talking about packets that come from your client that are sent to Google. These do not have the destination IP of the firewall box but pass through the firewall because you have set your gateway according. Besides, that would be SNAT which is something else. > (It doesn't matter from which direction it came, on which > interface, its contents, etc. - only the destination ip.) If you have a server in your LAN (I actually don't know what your setup is) you want to forward to and perform NAT, you are probably using a private IP (192.168... etc) for that box. A client from the internet can only point to your public IP and there are, in this case, only 2 dependencies that matter: destination IP and destination port. Since you have only 1 public IP, you can specify only 1 destination port, eg 80. Using these 2 you can either decide it's for the local server on the firewall or for the internal server in your LAN. > If i say "-d <ip.of.the.box> --dport 80 -j DNAT ..", that > works, but it introduces the unwanted dependency on the actual > IP value. > > If i say "-i <interface> --dport 80..." for an internal > interface, that catches anything, whether it was meant for > the box or google. Perhaps you're confusing DNAT with SNAT? When packets for Google pass through it's (initial) direction is from your LAN to the internet and packets are SNAT-ed. This is the opposite of what you want above. Gr, Rob
