old-style portforward with iptables?

Oh my god. Its been years that I've done this the last time and it seems
that I've forgot some stuff.

We are migrating a service and during migration I need a temporary
portforward from one machine to another. Both machines are standalone in
the internet without additional firewalls and I started with testing by
forwarding port 3222 on sourcemachine to port 22 on targetmachine.

on sourcemachine - where the forwarding is done - I run a 2.4.32-kernel
with iptables and the rules I did are:


echo processing startup
echo 1 > /proc/sys/net/ipv4/ip_forward
echo processing flush
/usr/local/sbin/iptables -F FORWARD
/usr/local/sbin/iptables -F INPUT
/usr/local/sbin/iptables -F OUTPUT
echo processing flush -t nat
/usr/local/sbin/iptables -t nat -F POSTROUTING
/usr/local/sbin/iptables -t nat -F PREROUTING
echo processing policy/ACCEPT
/usr/local/sbin/iptables -P FORWARD ACCEPT
/usr/local/sbin/iptables -P INPUT ACCEPT
/usr/local/sbin/iptables -P OUTPUT ACCEPT

echo processing PREROUTING -t nat
/usr/local/sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 -d
SOURCE_IP --dport 3222 -j DNAT --to DESTINATION_IP:22
echo processing FORWARD
/usr/local/sbin/iptables -A FORWARD -p tcp -i eth0 -d DESTINATION_IP
--dport 22 -j ACCEPT

but things dont work as I remembered them to work. Any help?

thnx,
peter

Hello,

peter pilsl a écrit :
>
> We are migrating a service and during migration I need a temporary
> portforward from one machine to another. Both machines are standalone in
> the internet without additional firewalls and I started with testing by
> forwarding port 3222 on sourcemachine to port 22 on targetmachine.
>
> on sourcemachine - where the forwarding is done - I run a 2.4.32-kernel
> with iptables and the rules I did are:
>
>
> echo processing startup
> echo 1 > /proc/sys/net/ipv4/ip_forward
> echo processing flush
> /usr/local/sbin/iptables -F FORWARD
> /usr/local/sbin/iptables -F INPUT
> /usr/local/sbin/iptables -F OUTPUT
> echo processing flush -t nat
> /usr/local/sbin/iptables -t nat -F POSTROUTING
> /usr/local/sbin/iptables -t nat -F PREROUTING
> echo processing policy/ACCEPT
> /usr/local/sbin/iptables -P FORWARD ACCEPT
> /usr/local/sbin/iptables -P INPUT ACCEPT
> /usr/local/sbin/iptables -P OUTPUT ACCEPT

You may like to set the default policy for the nat chains too.

> echo processing PREROUTING -t nat
> /usr/local/sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 -d
> SOURCE_IP --dport 3222 -j DNAT --to DESTINATION_IP:22

What about the return path from the server to the client ? It must go
through the forwarding box in order for the NAT to work properly.

> echo processing FORWARD
> /usr/local/sbin/iptables -A FORWARD -p tcp -i eth0 -d DESTINATION_IP
> --dport 22 -j ACCEPT

The last rule is useless because the FORWARD chain has the default
policy ACCEPT.

> but things dont work as I remembered them to work. Any help?

What do you mean ? Have you done any trace to check what's going on ?

Don't forget...

echo "1" >>/proc/sys/net/ipv4/ip_forward

on boxes behind the DMZ, and you'll need tmdns and

echo "1" >>/proc/sys/net/ipv4/ip_masq

for the masquerading part.

Peter Lowrie a écrit :
>
> echo "1" >>/proc/sys/net/ipv4/ip_forward

Already done by the OP, if you read carefully.

> on boxes behind the DMZ,

What DMZ ?

> and you'll need tmdns

Why ? This is for mDNS/zeroconf.

> echo "1" >>/proc/sys/net/ipv4/ip_masq

This sysctl does not exist any more in 2.4 kernels and above.

Pascal Hambourg wrote:

>>
>> We are migrating a service and during migration I need a temporary
>> portforward from one machine to another. Both machines are standalone in
>> the internet without additional firewalls and I started with testing by
>> forwarding port 3222 on sourcemachine to port 22 on targetmachine.
>>
>
> You may like to set the default policy for the nat chains too.
>
<skip>

>
>> echo processing PREROUTING -t nat
>> /usr/local/sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 -d
>> SOURCE_IP --dport 3222 -j DNAT --to DESTINATION_IP:22
>
> What about the return path from the server to the client ? It must go
> through the forwarding box in order for the NAT to work properly.
>

Thnx for your assistance.

I set the default-police for both nat-chains too, but no success. But
what do you mean with "return-path" ? I think (which may by complete
nonsense) that the DNAT-target takes care of both ways. All examples and
manuals I found state this single rule as the key-rule for port-forward.

How could I set up the return-path?

I tried

/usr/local/sbin/iptables -t nat -A POSTROUTING -p tcp -o eth0 -s
DESTINATION --sport 22 -j SNAT --to-source SOURCE

but thats just hitting in the air cause I dont really know what it does.
I found it in some howto as part of 1:1-NAT.


>
>> but things dont work as I remembered them to work. Any help?
>
> What do you mean ? Have you done any trace to check what's going on ?

I remember doing lot of port-forwarding many years ago but the details
slipped my mind.

I dont know how to trace/debug this stuff. I tried

tcpdump -i any port 3222

to get any closer to my problem but it seems tcpdump is not the tool of
choice here. I connect from my dynamic client to the first machine which
should forward to the second, but I only see the packages going there
and from tcpdump I would say they are just nuked by my first server
instead of being forwarded

08:44:21.177600 IP xxxxxxxxx.dynamic.xdsl-line.inode.at.17041 >
server1.at.3222: Flags [S], seq 522435283, win 5840, options [mss
1452,sackOK,TS[|tcp]>
08:44:24.187372 IP xxxxxxxxx.dynamic.xdsl-line.inode.at.17041 >
server1.at.3222: Flags [S], seq 522435283, win 5840, options [mss
1452,sackOK,TS[|tcp]>
08:44:30.231874 IP xxxxxxxxx.dynamic.xdsl-line.inode.at.17041 >
server1.at.3222: Flags [S], seq 522435283, win 5840, options [mss
1452,sackOK,TS[|tcp]>

I also included loads of LOG-rules to my setup and watched syslog for
any logs on port 3222, but it didnt reveal more then my tcpdump-output

Apr 26 09:05:25 goldfisch kernel: IN=eth0 OUT=
MAC=00:0e:2e:6c:da:77:00:02:4a:73:70:00:08:00 SRC=xxxx.dynamic.client
DST=server1.at LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=64205 DF PROTO=TCP
SPT=18674 DPT=3222 WINDOW=5840 RES=0x00 SYN URGP=0

So I'm still out of luck


my iptables-framework has extended in the meantime to the following

echo 1 > /proc/sys/net/ipv4/ip_forward
echo processing flush
/usr/local/sbin/iptables -F FORWARD
/usr/local/sbin/iptables -F INPUT
/usr/local/sbin/iptables -F OUTPUT
echo processing flush -t nat
/usr/local/sbin/iptables -t nat -F POSTROUTING
/usr/local/sbin/iptables -t nat -F PREROUTING
echo processing policy/ACCEPT
/usr/local/sbin/iptables -P FORWARD ACCEPT
/usr/local/sbin/iptables -P INPUT ACCEPT
/usr/local/sbin/iptables -P OUTPUT ACCEPT
echo processing policy -t nat/ACCEPT
/usr/local/sbin/iptables -t nat -P POSTROUTING ACCEPT
/usr/local/sbin/iptables -t nat -P PREROUTING ACCEPT
echo processing PREROUTING -t nat
/usr/local/sbin/iptables -t nat -A PREROUTING -j LOG
/usr/local/sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 -d SOURCE
--dport 3222 -j DNAT --to DESTINATION:22
echo processing POSTROUTING -t nat
/usr/local/sbin/iptables -t nat -A POSTROUTING -j LOG
/usr/local/sbin/iptables -t nat -A POSTROUTING -p tcp -o eth0 -s
DESTINATION --sport 22 -j SNAT --to-source SOURCE
echo processing FORWARD
/usr/local/sbin/iptables -A FORWARD -j LOG
/usr/local/sbin/iptables -A FORWARD -p tcp -i eth0 -d DESTINATION
--dport 22 -j ACCEPT
/usr/local/sbin/iptables -A FORWARD -p tcp -o eth0 -s DESTINATION
--sport 22 -j ACCEPT




any help appreatiated !!

thnx
peter

peter pilsl a écrit :
> Pascal Hambourg wrote:
>
>> What about the return path from the server to the client ? It must go
>> through the forwarding box in order for the NAT to work properly.
>
> what do you mean with "return-path" ?

I mean the network path followed by a reply packet from the final server
to the original client. Does this return path include the NAT box ?

> I think (which may by complete
> nonsense) that the DNAT-target takes care of both ways.

Yes, but it requires that reply packets go through the DNAT box. Else it
is obvious that the DNAT box cannot un-DNAT the reply packets. This
"triangle routing" situation is illutrated here :
<http://jengelh.hopto.org/images/dnat-mistake.png>
The local network and its switch can be replaced with the internet and
its routers.

> How could I set up the return-path?

By routing on the final server (e.g. the NAT box is the final servers's
default gateway) or source NAT/masquerade on the DNAT box.
You did not describe your network topology, but I assume the NAT box and
the final server are at random locations and not in a host-gateway
relationship ?

> I tried
>
> /usr/local/sbin/iptables -t nat -A POSTROUTING -p tcp -o eth0 -s
> DESTINATION --sport 22 -j SNAT --to-source SOURCE

Try with --dport instead of --sport.

> tcpdump -i any port 3222
>
> to get any closer to my problem but it seems tcpdump is not the tool of
> choice here. I connect from my dynamic client to the first machine which
> should forward to the second, but I only see the packages going there
> and from tcpdump I would say they are just nuked by my first server
> instead of being forwarded

Did you run tcpdump on the DNAT box and the final server ? Also, you
must also filter on port 22 if you want to capture packets after they
are DNATed.

Pascal Hambourg a écrit :
>
>> I tried
>>
>> /usr/local/sbin/iptables -t nat -A POSTROUTING -p tcp -o eth0 -s
>> DESTINATION --sport 22 -j SNAT --to-source SOURCE
>
> Try with --dport instead of --sport.

And -d instead of -s of course.

thnx a lot for your help !!

Your picture of the "DNAT routing shortcut" and the exchange of d/s in
the postrouting-table did the trick.

Combining both the postrouting-rule suddenly started making sense. Of
course DNAT only changes the destination-part of the package and in
order to get the package back the right way one should modify the
source-part too.


my final and working script now is as follows:

I changed the names to SERVER-A and SERVER-B. Both are
standalone-servers in the internet somewhere and goal is to redirect all
requests from any client to SERVER-A:3222 to SERVER-B:22 without anyone
noticing.


echo 1 > /proc/sys/net/ipv4/ip_forward
echo processing flush
/usr/local/sbin/iptables -F FORWARD
/usr/local/sbin/iptables -F INPUT
/usr/local/sbin/iptables -F OUTPUT
echo processing flush -t nat
/usr/local/sbin/iptables -t nat -F POSTROUTING
/usr/local/sbin/iptables -t nat -F PREROUTING
echo processing policy/ACCEPT
/usr/local/sbin/iptables -P FORWARD ACCEPT
/usr/local/sbin/iptables -P INPUT ACCEPT
/usr/local/sbin/iptables -P OUTPUT ACCEPT
echo processing policy -t nat/ACCEPT
/usr/local/sbin/iptables -t nat -P POSTROUTING ACCEPT
/usr/local/sbin/iptables -t nat -P PREROUTING ACCEPT
echo processing PREROUTING -t nat
/usr/local/sbin/iptables -t nat -A PREROUTING -j LOG
/usr/local/sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 -d SERVER-A
--dport 3222 -j DNAT --to SERVER-B:22
echo processing POSTROUTING -t nat
/usr/local/sbin/iptables -t nat -A POSTROUTING -j LOG
/usr/local/sbin/iptables -t nat -A POSTROUTING -p tcp -o eth0 -d
SERVER-B --dport 22 -j SNAT --to-source SERVER-A
echo processing FORWARD
/usr/local/sbin/iptables -A FORWARD -j LOG
/usr/local/sbin/iptables -A FORWARD -p tcp -i eth0 -d SERVER-B --dport
22 -j ACCEPT
/usr/local/sbin/iptables -A FORWARD -p tcp -o eth0 -s SERVER-B --sport
22 -j ACCEPT


thnx,
peter


Pascal Hambourg wrote:
> Pascal Hambourg a écrit :
>>
>>> I tried
>>>
>>> /usr/local/sbin/iptables -t nat -A POSTROUTING -p tcp -o eth0 -s
>>> DESTINATION --sport 22 -j SNAT --to-source SOURCE
>>
>> Try with --dport instead of --sport.
>
> And -d instead of -s of course.

peter pilsl a écrit :
>
> Combining both the postrouting-rule suddenly started making sense. Of
> course DNAT only changes the destination-part of the package and in
> order to get the package back the right way one should modify the
> source-part too.

Not necessarily. Masquerading is only one method. The main drawback is
that the final server does not see the original source address. This can
make logging, accounting, filtering, etc. more difficult.

Another method which avoids the masquerading is to create a tunnel
between the servers, encapsulating packets belonging to the redirected
connections. It can be a simple IPIP tunnel. The setup is not as simple
as masquerading though.

Note that the masquerading method does not only addresses the routing
shortcut issue but also the potential anti-spoofing policy preventing
the first server from forwarding packets with their original source
addresses. A tunnel addresses this issue too.

> I changed the names to SERVER-A and SERVER-B. Both are
> standalone-servers in the internet somewhere and goal is to redirect all
> requests from any client to SERVER-A:3222 to SERVER-B:22 without anyone
> noticing.

Actually the final server notices : as I wrote, it sees the first server
as the source of all redirected connections.