Forwarding non local packets to loopback with iptables?

[Jason Opperisano]

On Tue, 2004-09-07 at 07:49, Mark Ord wrote:
> Setup:
>    NAT + Firewall - Debian, 2.4.18 kernel, iptables v1.2.6a
>    eth0 - 10.0.x.x        - wireless broadband VPN connection
>    eth1 - 192.168.0.1     - Local network
>    ppp0 - server assigned - Internet connection via VPN established via
>                             eth0 - though, fairly irrelivent.
>    eth1:1 - 192.168.0.128 - Local network alias
>    eth1:2 - 192.168.0.129 - Local network alias
>       .. etc ..
> 
> What I want to do is set up a SSH tunnel to another machine, behind
> another firewall, and use the eth1 aliases to access the remote machines from my
> local network (eth1) and the iptables machine. I tried to set this up
> before with iptables, failed, 

can we revisit why that failed, perhaps?

> found discovered rinetd, and have been using
> that since successfully. However, I'd like to use an iptables solution,
> because I think it'll be cleaner (can't easily ifup/ifdown the eth1 aliases
> when using rinetd), plus I'm plain interested in if/how to do an iptables
> solution.

k--see above.

> The main catch here is that I'm not using GatewayPorts for the ssh port
> forwarding. Firstly because binding the forwards to the loopback seems
> slightly more secure, and secondly because the ports I forward to on the
> remote machines are the same - using GatewayPorts binds to all available
> interfaces. Hence I do the ssh port forwards, binding to different
> ports on the loopback on the local end of the ssh tunnel, and then map
> the default service ports on the eth1 aliases to the appropriate port on
> the loopback ie:
> 
> rinetd.conf:
> 
>    192.168.0.128   3389      127.0.0.1       13389 # rdc
>    192.168.0.129   3389      127.0.0.1       23389 # rdc
>    192.168.0.130   3389      127.0.0.1       33389 # rdc
> 
> Connections to 192.168.0.128:3389 redirect to localhost:13389, which connects
> via the ssh tunnel to port 3389 on the remote host.
> 
> Last time I tried to establish this with iptables, I got nowhere. This time
> around I got it working on the iptables machine with:
> 
> $IPTABLES -t nat -I OUTPUT -p tcp -s 192.168.0.128 --dport 3389 \
>         -j DNAT --to 127.0.0.1:13389
>    .. etc .. for each address and port required.
> 
> Connecting to 129.168.0.128 port 3389 takes me where I want - down the
> ssh tunnel, to machine on the remote network.

this isn't exactly a great test scenario, as you're testing locally on
the box itself, which will not cleanly extrapolate to the forwarding
scenario.

> However, no matter what I try, I can't get connections from other machines
> on the 192.168.0.0/24 network to work. I've tried to several combinations
> of using PREROUTING, POSTROUTING and OUTPUT chains, with no luck.
> In particular, I've tried to model it on a rule that works:
> 
>     iptables -t nat -I PREROUTING -p tcp -d 192.168.0.128 --dport 3389 \
>          -j DNAT --to x.x.x.x:3389
>     (where x.x.x.x is a host on the internet.)
> 
> with:
> 
>     iptables -t nat -I PREROUTING -p tcp -d 192.168.0.128 --dport 3389 \
>          -j DNAT --to 127.0.0.1:3389
> 
> which doesn't work, to which I can only conclude that you can't dnat to
> 127.0.0.1.

nope--you sure can't. 

> Is it possible to achieve this with iptables (redirecting traffic coming in
> on eth1 (for eth1:?) to a port on 127.0.0.1), and if so, what rules are
> required?

no.  but since you have dedicated IP addresses per host--why aren't you
just DNAT-ing from the IP on eth1 directly to the host that should
receive the traffic (i believe this is the "previously failed"
scenario)?

-j

-- 
Jason Opperisano <opie at 817west.com>