[ale] port forwarding for iptables.

[JK]

Atlanta Geek wrote:
> One last note.  Right now the Client (doing the telnet), the proxy
> server( running iptables) and the server (final destination of
> traffic) is all on the same network.


So what we're expecting is that client C telnets to proxy:port R:p,
and the proxy does its magic and mirrors that connection out to server
S.

The thing about that is, if S and C are on the same subnet, S is
not going to bother sending its replies via R. It's just gonna
say, "Oh, I have to reply to host C, he's on my subnet, so I'll
send him this packet directly at his physical address."  This
will almost certainly confuse C and make it drop the reply
packets on the floor: requests go to R, but replies come from S,
and appear totally unrelated to anything C has got going on.

One way to get around this would be to put S and R on a different
logical subnet from C. That will involve giving R's Ethernet
interface multiple IPs.  If your existing subnet is 192.168.1.0.24,
then something like this should do it:

   # on R, add a second IP to eth0:

   ip addr add dev eth0 192.168.99.1/24

   # on S, change the IP to be on the .99. net and add a route
   # to get to the .1. net:

   ip addr del dev eth0 <existing IP of eth0>
   ip addr add dev eth0 192.168.99.2/24
   ip route add 192.168.1.0/24 via 192.168.99.1

That will make S believe it's on the 192.168.99.0 subnet, and that
it has to talk to R to get any traffic thru to C.

Another way to get around this is with an SNAT rule on R, so
that all port-forwarded traffic appears to come from R, and
replies will therefore also go to R. The way to do that would
be something like:

   iptables -t nat -I POSTROUTING -p tcp -d S -dport p -j SNAT --to-source R

(replacing S, p, and R with the appropriate IPs/ports.) In this
case you don't need to change any IP addresses or routes, which
is nice.  It strikes me as a bit more of a hackfest than the
"add-a-subnet" trick, since that SNAT wouldn't be necessary
at all if C and R were on separate subnets with valid routes
between them, which seems like the more usual case.  Also
some protocols just don't work right in the presence of
SNAT (ftp is a shining example).

Note that all this is just to get the logical network topology
into a state where DNAT makes sense -- it doesn't have anything
to do with actually getting R to forward the traffic you care
about.  I'm going to reply to your other message in a minute.

-- JK