portfw on iptables 2.4 kernel problem.

portfw on iptables 2.4 kernel problem.

[louie miranda]

I have an internel ftp server w/c i want to access over my linux router(gw)
Its internel IP is 10.0.0.11 and port 21. My externel IP lets say
203.100.100.1.
I followed the docs w/c i found at linuxdoc
http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO/forwarders.html
I type in this iptables rule set,

iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 21 -m state --state
NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A PREROUTING -t nat -p tcp -d $EXTIP --dport 21 -j DNAT --to
10.0.0.11:21

I enabled ip forwarding thru the kernel by typing this command, (this is the
first thing i type then the iptables rule set)

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

svr:/# cat /proc/sys/net/ipv4/ip_forward
1
svr:/#

And still it does not work..

Trying 203.100.100.1...
telnet: Unable to connect to remote host: Connection refused





--
thanks,
louie miranda

Re: portfw on iptables 2.4 kernel problem.

[Raymond Leach]

[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]

On Tue, 2002-12-10 at 10:56, louie miranda wrote:
> I have an internel ftp server w/c i want to access over my linux router(gw)
> Its internel IP is 10.0.0.11 and port 21. My externel IP lets say
> 203.100.100.1.
> I followed the docs w/c i found at linuxdoc
> http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO/forwarders.html
> I type in this iptables rule set,
> 
> iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 21 -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT
> iptables -A PREROUTING -t nat -p tcp -d $EXTIP --dport 21 -j DNAT --to
> 10.0.0.11:21
> 
> I enabled ip forwarding thru the kernel by typing this command, (this is the
> first thing i type then the iptables rule set)
> 
> echo "1" > /proc/sys/net/ipv4/ip_forward
> 
> svr:/# cat /proc/sys/net/ipv4/ip_forward
> 1
> svr:/#
> 
> And still it does not work..
> 
> Trying 203.100.100.1...
> telnet: Unable to connect to remote host: Connection refused
> 
Does this IP (203.100.100.1) belong to the gw?

There are also two diferent type of ftp that work in very different
ways. This only accounts for the control connection.
Also, you don't have forward rules for the return traffic.
> 
> 
> 
> 
> --
> thanks,
> louie miranda
> 
-- 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(  Raymond Leach                       )
 ) Knowledge Factory                  (
(                                      )
 ) Tel: +27 11 445 8100               (
(  Fax: +27 11 445 8101                )
 )                                    (
(  http://www.knowledgefactory.co.za/  )
 ) http://www.saptg.co.za/            (
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   o                                o
    o                              o
        .--.                  .--.
       | o_o|                |o_o |
       | \_:|                |:_/ |
      / /   \\              //   \ \
     ( |     |)            (|     | )
     /`\_   _/'\          /'\_   _/`\
     \___)=(___/          \___)=(___/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: portfw on iptables 2.4 kernel problem.

[Paulo Andre]

On Tue, 2002-12-10 at 10:56, louie miranda wrote:
> I have an internel ftp server w/c i want to access over my linux router(gw)
> Its internel IP is 10.0.0.11 and port 21. My externel IP lets say
> 203.100.100.1.
> I followed the docs w/c i found at linuxdoc
> http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO/forwarders.html
> I type in this iptables rule set,
> 
> iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 21 -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT
> iptables -A PREROUTING -t nat -p tcp -d $EXTIP --dport 21 -j DNAT --to
> 10.0.0.11:21
> 
> I enabled ip forwarding thru the kernel by typing this command, (this is the
> first thing i type then the iptables rule set)
> 
> echo "1" > /proc/sys/net/ipv4/ip_forward
> 
> svr:/# cat /proc/sys/net/ipv4/ip_forward
> 1
> svr:/#
> 
> And still it does not work..
> 
> Trying 203.100.100.1...
> telnet: Unable to connect to remote host: Connection refused
> 
> 
You will have to allow port 20 aswell...FTP uses both port 20 and 21

> 
> 
> 
> --
> thanks,
> louie miranda
> 
> 
> 

Re: portfw on iptables 2.4 kernel problem.

[louie miranda]

> Does this IP (203.100.100.1) belong to the gw?
Yes it does. And that's my gw.

--
louie


On Tue, 2002-12-10 at 10:56, louie miranda wrote:
> I have an internel ftp server w/c i want to access over my linux
router(gw)
> Its internel IP is 10.0.0.11 and port 21. My externel IP lets say
> 203.100.100.1.
> I followed the docs w/c i found at linuxdoc
> http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO/forwarders.html
> I type in this iptables rule set,
>
> iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 21 -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT
> iptables -A PREROUTING -t nat -p tcp -d $EXTIP --dport 21 -j DNAT --to
> 10.0.0.11:21
>
> I enabled ip forwarding thru the kernel by typing this command, (this is
the
> first thing i type then the iptables rule set)
>
> echo "1" > /proc/sys/net/ipv4/ip_forward
>
> svr:/# cat /proc/sys/net/ipv4/ip_forward
> 1
> svr:/#
>
> And still it does not work..
>
> Trying 203.100.100.1...
> telnet: Unable to connect to remote host: Connection refused
>
Does this IP (203.100.100.1) belong to the gw?

There are also two diferent type of ftp that work in very different
ways. This only accounts for the control connection.
Also, you don't have forward rules for the return traffic.
>
>
>
>
> --
> thanks,
> louie miranda
>
--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(  Raymond Leach                       )
 ) Knowledge Factory                  (
(                                      )
 ) Tel: +27 11 445 8100               (
(  Fax: +27 11 445 8101                )
 )                                    (
(  http://www.knowledgefactory.co.za/  )
 ) http://www.saptg.co.za/            (
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   o                                o
    o                              o
        .--.                  .--.
       | o_o|                |o_o |
       | \_:|                |:_/ |
      / /   \\              //   \ \
     ( |     |)            (|     | )
     /`\_   _/'\          /'\_   _/`\
     \___)=(___/          \___)=(___/




--
thanks,
louie miranda
chikka asia, inc.
noc +63-2(7535000-511)

Engineering does not require science. Science helps a lot but people built
perfectly good brick walls long before they knew why cement works.


----- Original Message -----
From: "Raymond Leach" <raymondl@knowledgefactory.co.za>
To: "louie miranda" <lmiranda@chikka.com>
Cc: "Netfilter Mailing List" <netfilter@lists.netfilter.org>
Sent: Tuesday, December 10, 2002 5:01 PM
Subject: Re: portfw on iptables 2.4 kernel problem.

Re: portfw on iptables 2.4 kernel problem.

[louie miranda]

> You will have to allow port 20 aswell...FTP uses both port 20 and 21
Hm, ic. But even when i do netstat -ln i dont see any open sockets on port
21.


--
thanks,
louie miranda


----- Original Message -----
From: "Paulo Andre" <pandre@darkstar.nom.za>
To: "louie miranda" <lmiranda@chikka.com>
Cc: "netfilter" <netfilter@lists.netfilter.org>
Sent: Tuesday, December 10, 2002 5:01 PM
Subject: Re: portfw on iptables 2.4 kernel problem.


> On Tue, 2002-12-10 at 10:56, louie miranda wrote:
> > I have an internel ftp server w/c i want to access over my linux
router(gw)
> > Its internel IP is 10.0.0.11 and port 21. My externel IP lets say
> > 203.100.100.1.
> > I followed the docs w/c i found at linuxdoc
> > http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO/forwarders.html
> > I type in this iptables rule set,
> >
> > iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 21 -m state --state
> > NEW,ESTABLISHED,RELATED -j ACCEPT
> > iptables -A PREROUTING -t nat -p tcp -d $EXTIP --dport 21 -j DNAT --to
> > 10.0.0.11:21
> >
> > I enabled ip forwarding thru the kernel by typing this command, (this is
the
> > first thing i type then the iptables rule set)
> >
> > echo "1" > /proc/sys/net/ipv4/ip_forward
> >
> > svr:/# cat /proc/sys/net/ipv4/ip_forward
> > 1
> > svr:/#
> >
> > And still it does not work..
> >
> > Trying 203.100.100.1...
> > telnet: Unable to connect to remote host: Connection refused
> >
> >
> You will have to allow port 20 aswell...FTP uses both port 20 and 21
>
> >
> >
> >
> > --
> > thanks,
> > louie miranda
> >
> >
> >
>
>
>

RE: portfw on iptables 2.4 kernel problem.

[Rob Sterenborg]

> You will have to allow port 20 aswell...FTP uses both port 20 and 21

Do you ?
I was under the impression that this line would take care of that (which
is already in the iptables config) :

> iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 21 -m state --state
NEW,ESTABLISHED,RELATED -j ACCEPT

However, I'm not sure if it's better to split them up into 2 rules :
iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 21 -m state --state
NEW -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED
-j ACCEPT


Rob

RE: portfw on iptables 2.4 kernel problem.

[Raymond Leach]

[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]

Yes, you do. Port 20 (and/or any other) connections after the control
connection are not 'RELATED, ESTABLISHED' to the control connection.
They are new connections either from the client to the server or vice
versa. You therefore need seperate rules for them.

Remember connection tracking happens at a pakcet level, i.e all states
relate to packets of a connection, not per protocol.

Ray

On Tue, 2002-12-10 at 11:43, Rob Sterenborg wrote:
> > You will have to allow port 20 aswell...FTP uses both port 20 and 21
> 
> Do you ?
> I was under the impression that this line would take care of that (which
> is already in the iptables config) :
> 
> > iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 21 -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT
> 
> However, I'm not sure if it's better to split them up into 2 rules :
> iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 21 -m state --state
> NEW -j ACCEPT
> iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED
> -j ACCEPT
> 
> 
> Rob

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: portfw on iptables 2.4 kernel problem.

[Jozsef Kadlecsik]

On 10 Dec 2002, Raymond Leach wrote:

> Yes, you do. Port 20 (and/or any other) connections after the control
> connection are not 'RELATED, ESTABLISHED' to the control connection.
> They are new connections either from the client to the server or vice
> versa. You therefore need seperate rules for them.

If we are speaking about the data channels of the supported protocols
(FTP, IRC and all the other protocols from p-o-m), then this is absolutely
false.

> Remember connection tracking happens at a pakcet level, i.e all states
> relate to packets of a connection, not per protocol.

In the case of the supported protocols with additional channels, again,
untrue. Please do no spread false info! Why would then the RELATED state
exist?

> > However, I'm not sure if it's better to split them up into 2 rules :
> > iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 21 -m state --state
> > NEW -j ACCEPT
> > iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED
> > -j ACCEPT

Because the destination port of the data channels cannot be port 21,
therefore you must use two rules. And because you specify the
incoming/outgoing interfaces, you need a third rule for the reply packets
as well.

Regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

RE: portfw on iptables 2.4 kernel problem.

[Raymond Leach]

[-- Attachment #1: Type: text/plain, Size: 2449 bytes --]

On Tue, 2002-12-10 at 13:22, Jozsef Kadlecsik wrote:
> On 10 Dec 2002, Raymond Leach wrote:
> 
> > Yes, you do. Port 20 (and/or any other) connections after the control
> > connection are not 'RELATED, ESTABLISHED' to the control connection.
> > They are new connections either from the client to the server or vice
> > versa. You therefore need seperate rules for them.
> 
> If we are speaking about the data channels of the supported protocols
> (FTP, IRC and all the other protocols from p-o-m), then this is absolutely
> false.
OK, then how does connection tracking work for passive ftp?

> 
> > Remember connection tracking happens at a pakcet level, i.e all states
> > relate to packets of a connection, not per protocol.
> 
> In the case of the supported protocols with additional channels, again,
> untrue. Please do no spread false info! Why would then the RELATED state
> exist?
> 
> > > However, I'm not sure if it's better to split them up into 2 rules :
> > > iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 21 -m state --state
> > > NEW -j ACCEPT
> > > iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED
> > > -j ACCEPT
> 
> Because the destination port of the data channels cannot be port 21,
> therefore you must use two rules. And because you specify the
> incoming/outgoing interfaces, you need a third rule for the reply packets
> as well.
> 
> Regards,
> Jozsef
> -
> E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
> PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
> Address : KFKI Research Institute for Particle and Nuclear Physics
>           H-1525 Budapest 114, POB. 49, Hungary
-- 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(  Raymond Leach                       )
 ) Knowledge Factory                  (
(                                      )
 ) Tel: +27 11 445 8100               (
(  Fax: +27 11 445 8101                )
 )                                    (
(  http://www.knowledgefactory.co.za/  )
 ) http://www.saptg.co.za/            (
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   o                                o
    o                              o
        .--.                  .--.
       | o_o|                |o_o |
       | \_:|                |:_/ |
      / /   \\              //   \ \
     ( |     |)            (|     | )
     /`\_   _/'\          /'\_   _/`\
     \___)=(___/          \___)=(___/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: portfw on iptables 2.4 kernel problem.

[Jozsef Kadlecsik]

On 10 Dec 2002, Raymond Leach wrote:

> OK, then how does connection tracking work for passive ftp?

The FTP connection tracking and NAT helper modules support active (PORT,
EPRT) and passive (PASV, EPSV responses) ftp as well. In both cases the
command channel is monitored and the commands/responses are parsed. As the
appropriate patterns detected, the system digs out the announced
port (address) and prepares to accept the data channel.

At iptables level there is no difference whatsoever between active/passive
modes in letting in/NATing them.

Regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

RE: portfw on iptables 2.4 kernel problem.

[Raymond Leach]

[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]

Thank you for clearing that up. I must have not installed/invoked the
ftp connection tracking modules for iptables then...

Ray

On Tue, 2002-12-10 at 13:52, Jozsef Kadlecsik wrote:
> On 10 Dec 2002, Raymond Leach wrote:
> 
> > OK, then how does connection tracking work for passive ftp?
> 
> The FTP connection tracking and NAT helper modules support active (PORT,
> EPRT) and passive (PASV, EPSV responses) ftp as well. In both cases the
> command channel is monitored and the commands/responses are parsed. As the
> appropriate patterns detected, the system digs out the announced
> port (address) and prepares to accept the data channel.
> 
> At iptables level there is no difference whatsoever between active/passive
> modes in letting in/NATing them.
> 
> Regards,
> Jozsef
> -
> E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
> PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
> Address : KFKI Research Institute for Particle and Nuclear Physics
>           H-1525 Budapest 114, POB. 49, Hungary
-- 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(  Raymond Leach                       )
 ) Knowledge Factory                  (
(                                      )
 ) Tel: +27 11 445 8100               (
(  Fax: +27 11 445 8101                )
 )                                    (
(  http://www.knowledgefactory.co.za/  )
 ) http://www.saptg.co.za/            (
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   o                                o
    o                              o
        .--.                  .--.
       | o_o|                |o_o |
       | \_:|                |:_/ |
      / /   \\              //   \ \
     ( |     |)            (|     | )
     /`\_   _/'\          /'\_   _/`\
     \___)=(___/          \___)=(___/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: portfw on iptables 2.4 kernel problem.

[louie miranda]

Hi, thanks for all your replies, etc. But my problem is not yet solved. I
dont know why?!
Can someone give me how did they did it?



--
thanks,
louie miranda


----- Original Message -----
From: "Jozsef Kadlecsik" <kadlec@blackhole.kfki.hu>
To: "Raymond Leach" <raymondl@knowledgefactory.co.za>
Cc: <rsterenborg@xs4all.nl>; "'Paulo Andre'" <pandre@darkstar.nom.za>;
"'louie miranda'" <lmiranda@chikka.com>; "'netfilter'"
<netfilter@lists.netfilter.org>
Sent: Tuesday, December 10, 2002 7:22 PM
Subject: RE: portfw on iptables 2.4 kernel problem.


> On 10 Dec 2002, Raymond Leach wrote:
>
> > Yes, you do. Port 20 (and/or any other) connections after the control
> > connection are not 'RELATED, ESTABLISHED' to the control connection.
> > They are new connections either from the client to the server or vice
> > versa. You therefore need seperate rules for them.
>
> If we are speaking about the data channels of the supported protocols
> (FTP, IRC and all the other protocols from p-o-m), then this is absolutely
> false.
>
> > Remember connection tracking happens at a pakcet level, i.e all states
> > relate to packets of a connection, not per protocol.
>
> In the case of the supported protocols with additional channels, again,
> untrue. Please do no spread false info! Why would then the RELATED state
> exist?
>
> > > However, I'm not sure if it's better to split them up into 2 rules :
> > > iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 21 -m state --state
> > > NEW -j ACCEPT
> > > iptables -A FORWARD -i eth0 -o eth1 -m state --state
ESTABLISHED,RELATED
> > > -j ACCEPT
>
> Because the destination port of the data channels cannot be port 21,
> therefore you must use two rules. And because you specify the
> incoming/outgoing interfaces, you need a third rule for the reply packets
> as well.
>
> Regards,
> Jozsef
> -
> E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
> PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
> Address : KFKI Research Institute for Particle and Nuclear Physics
>           H-1525 Budapest 114, POB. 49, Hungary
>
>
>

Re: portfw on iptables 2.4 kernel problem.

[Raymond Leach]

[-- Attachment #1: Type: text/plain, Size: 4277 bytes --]

Here are the rules I use for ftp outbound from my internal network :

IPTABLES="/usr/sbin/iptables"
NET_INT="10.0.0.0/24"
IFACE_INET="eth0"
IFACE_INT="eth2"
IFACE_DMZ="eth1"
IFACE_LOC="lo"
$ip="10.0.0.67"		# My workstation ip

$IPTABLES -A FORWARD -i $IFACE_INT -p tcp --dport 20:21 -s $ip -m state
--state NEW,ESTABLISHED,RELATED -j ACCEPT
        $IPTABLES -A FORWARD -i $IFACE_INT -p tcp --dport 1024: -s $ip
-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
        $IPTABLES -A FORWARD -i $IFACE_INT -p udp --dport 1024: -s $ip
-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -i $IFACE_INET -p tcp --sport 20:21 -d $ip -m state
--state ESTABLISHED,RELATED -j ACCEPT
        $IPTABLES -A FORWARD -i $IFACE_INET -p tcp --sport 1024: -d $ip
-m state --state ESTABLISHED,RELATED -j ACCEPT
        $IPTABLES -A FORWARD -i $IFACE_INET -p udp --sport 1024: -d $ip
-m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -t nat -A POSTROUTING -o $IFACE_INET -p tcp --dport 20:21 -s
$ip -j SNAT --to-source $IP_INET
        $IPTABLES -t nat -A POSTROUTING -o $IFACE_INET -p tcp --dport
1024: -s $ip -j SNAT --to-source $IP_INET

Enjoy!

Ray

On Wed, 2002-12-11 at 08:08, louie miranda wrote:
> Hi, thanks for all your replies, etc. But my problem is not yet solved. I
> dont know why?!
> Can someone give me how did they did it?
> 
> 
> 
> --
> thanks,
> louie miranda
> 
> 
> ----- Original Message -----
> From: "Jozsef Kadlecsik" <kadlec@blackhole.kfki.hu>
> To: "Raymond Leach" <raymondl@knowledgefactory.co.za>
> Cc: <rsterenborg@xs4all.nl>; "'Paulo Andre'" <pandre@darkstar.nom.za>;
> "'louie miranda'" <lmiranda@chikka.com>; "'netfilter'"
> <netfilter@lists.netfilter.org>
> Sent: Tuesday, December 10, 2002 7:22 PM
> Subject: RE: portfw on iptables 2.4 kernel problem.
> 
> 
> > On 10 Dec 2002, Raymond Leach wrote:
> >
> > > Yes, you do. Port 20 (and/or any other) connections after the control
> > > connection are not 'RELATED, ESTABLISHED' to the control connection.
> > > They are new connections either from the client to the server or vice
> > > versa. You therefore need seperate rules for them.
> >
> > If we are speaking about the data channels of the supported protocols
> > (FTP, IRC and all the other protocols from p-o-m), then this is absolutely
> > false.
> >
> > > Remember connection tracking happens at a pakcet level, i.e all states
> > > relate to packets of a connection, not per protocol.
> >
> > In the case of the supported protocols with additional channels, again,
> > untrue. Please do no spread false info! Why would then the RELATED state
> > exist?
> >
> > > > However, I'm not sure if it's better to split them up into 2 rules :
> > > > iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 21 -m state --state
> > > > NEW -j ACCEPT
> > > > iptables -A FORWARD -i eth0 -o eth1 -m state --state
> ESTABLISHED,RELATED
> > > > -j ACCEPT
> >
> > Because the destination port of the data channels cannot be port 21,
> > therefore you must use two rules. And because you specify the
> > incoming/outgoing interfaces, you need a third rule for the reply packets
> > as well.
> >
> > Regards,
> > Jozsef
> > -
> > E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
> > PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
> > Address : KFKI Research Institute for Particle and Nuclear Physics
> >           H-1525 Budapest 114, POB. 49, Hungary
> >
> >
> >
-- 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(  Raymond Leach                       )
 ) Knowledge Factory                  (
(                                      )
 ) Tel: +27 11 445 8100               (
(  Fax: +27 11 445 8101                )
 )                                    (
(  http://www.knowledgefactory.co.za/  )
 ) http://www.saptg.co.za/            (
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   o                                o
    o                              o
        .--.                  .--.
       | o_o|                |o_o |
       | \_:|                |:_/ |
      / /   \\              //   \ \
     ( |     |)            (|     | )
     /`\_   _/'\          /'\_   _/`\
     \___)=(___/          \___)=(___/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: portfw on iptables 2.4 kernel problem.

[Reckhard, Tobias]

Hi

I'm not entirely sure what you want to do, but here goes.

> I have an internel ftp server w/c i want to access over my 
> linux router(gw)
> Its internel IP is 10.0.0.11 and port 21. My externel IP lets say
> 203.100.100.1.
> I followed the docs w/c i found at linuxdoc
> http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO/forwarders.html
> I type in this iptables rule set,
> 
> iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 21 -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT
> iptables -A PREROUTING -t nat -p tcp -d $EXTIP --dport 21 -j DNAT --to
> 10.0.0.11:21
> 
> I enabled ip forwarding thru the kernel by typing this 
> command, (this is the
> first thing i type then the iptables rule set)
> 
> echo "1" > /proc/sys/net/ipv4/ip_forward
> 
> svr:/# cat /proc/sys/net/ipv4/ip_forward
> 1
> svr:/#
> 
> And still it does not work..
> 
> Trying 203.100.100.1...
> telnet: Unable to connect to remote host: Connection refused

I expect you're trying to access the FTP server on 10.0.0.11 from the
Internet by redirecting connections to the firewall's external IP address
(203.100.100.1) to the FTP server.

I haven't dealt with D/SNATing FTP yet and it's one of the more complicated
protocols to do this for (and it's a horrible protocol anyway, so you should
avoid it entirely if you can), but I believe you need to do the following:

Prerequisites:
1. Load the FTP conntrack and FTP NAT modules (maybe the basic conntrack
module as well), enable IP forwarding.

Take care of the FTP control connection:
2. Permit INPUT on the outside interface of the firewall to TCP port 21 with
states NEW and ESTABLISHED
3. Permit OUTPUT on the outside interface of the firewall from TCP port 21
with state ESTABLISHED
4. In the PREROUTING chain use DNAT to redirect packets "-p tcp -d
203.100.100.1 --dport 21" (see point 2 above) to the internal server at
10.0.0.11.
5. Permit FORWARDing of those same packets with states NEW and ESTABLISHED.
6. Permit FORWARDing of response packets ("-s 10.0.0.11 --sport 21") with
state ESTABLISHED.

The FTP data connection:
a) Active FTP:
7. Permit FORWARDing from the internal server, TCP source port 20, with
states ESTABLISHED and RELATED.
8. Permit FORWARDing to the internal server, TCP destination port 20, with
state ESTABLISHED.
9. Permit OUTPUT from the firewall's outside interface (and source IP
address), TCP source port 20, with states ESTABLISHED and RELATED.
10. Permit INPUT on the firewall's outside interface (and IP), TCP
destination port 20, state ESTABLISHED.

You may also need to SNAT the outbound packets to the firewall's outside IP
address in the POSTROUTING chain.

b) Passive FTP:
11. Permit INPUT on the firewall's outside interface (and IP), TCP
destination port 1024-65535, states ESTABLISHED and RELATED
12. PREROUTING DNAT those packets to the internal server.
13. FORWARD them with states ESTABLISHED and RELATED
14. FORWARD the ESTABLISHED return packets
15. OUTPUT the ESTABLISHED return packets.

Check to see if that works. Add a catch-all logging rule to the end of all
chains you use and see if it gets hit by anything when debugging.

Cheers
Tobias

Re: portfw on iptables 2.4 kernel problem.

[Joel Newkirk]

On Wednesday 11 December 2002 02:32 am, Reckhard, Tobias wrote: 
{heavily snipped by Joel}

> I expect you're trying to access the FTP server on 10.0.0.11 from the
> Internet by redirecting connections to the firewall's external IP
> address (203.100.100.1) to the FTP server.

> Take care of the FTP control connection:
> 2. Permit INPUT on the outside interface of the firewall to TCP port
> 21 with states NEW and ESTABLISHED
> 3. Permit OUTPUT on the outside interface of the firewall from TCP
> port 21 with state ESTABLISHED
> 4. In the PREROUTING chain use DNAT to redirect packets "-p tcp -d
> 203.100.100.1 --dport 21" (see point 2 above) to the internal server
> at 10.0.0.11.
> 5. Permit FORWARDing of those same packets with states NEW and
> ESTABLISHED. 6. Permit FORWARDing of response packets ("-s 10.0.0.11
> --sport 21") with state ESTABLISHED.

This wouldn't work at all.  INPUT shouldn't enter into it at all, unless 
the DNAT fails, and OUTPUT only if a packet is required to leave the 
firewall machine itself, IE if that is where the connection is attempted 
from or to.  Also, for the FTP conntrack helper to work you HAVE to 
allow state RELATED.  FTP will open a control connection to port 21, 
then a request for data will (in passive) cause the server to attempt to 
open a connection BACK to the client's port 20, IE.  This is RELATED, in 
a nutshell.  The FTP helper is required because the control packets will 
embed IP and port data inside the packet itself, rather than its header, 
and without the helper netfilter will only handle the header.

j

RE: portfw on iptables 2.4 kernel problem.

[Reckhard, Tobias]

Munging both replies into one, my answers are inline.

> > I expect you're trying to access the FTP server on 
> 10.0.0.11 from the
> > Internet by redirecting connections to the firewall's external IP
> > address (203.100.100.1) to the FTP server.
> 
> > Take care of the FTP control connection:
> > 2. Permit INPUT on the outside interface of the firewall to TCP port
> > 21 with states NEW and ESTABLISHED
> > 3. Permit OUTPUT on the outside interface of the firewall from TCP
> > port 21 with state ESTABLISHED
> > 4. In the PREROUTING chain use DNAT to redirect packets "-p tcp -d
> > 203.100.100.1 --dport 21" (see point 2 above) to the internal server
> > at 10.0.0.11.
> > 5. Permit FORWARDing of those same packets with states NEW and
> > ESTABLISHED. 6. Permit FORWARDing of response packets ("-s 10.0.0.11
> > --sport 21") with state ESTABLISHED.
> 
> This wouldn't work at all.  INPUT shouldn't enter into it at 
> all, unless 
> the DNAT fails, and OUTPUT only if a packet is required to leave the 
> firewall machine itself, IE if that is where the connection 
> is attempted 
> from or to.

The above takes care of the control connection only. Since the Internet
machine believes it is accessing an FTP server on the firewall itself, the
latter is addressed by its FTP control connection. This means that the
packets cross the firewall's INPUT chain, before they can be DNATed in the
PREROUTING chain. I'm not entirely sure about the outbound packets, but most
things netfilter apart from NAT require symmetric rules, so I suppose you
need an OUTPUT rule to match the INPUT one.

[FTP data]

Thanks for the info, but I know all about FTP data.. What did you think
steps 7 through 15 in my recipe were for?

Tobias

Re: portfw on iptables 2.4 kernel problem.

[Andrea Rossato]

louie miranda wrote:
> I have an internel ftp server w/c i want to access over my linux router(gw)
> Its internel IP is 10.0.0.11 and port 21. My externel IP lets say
> 203.100.100.1.


echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -A FORWARD -d 10.0.0.11 -j ACCEPT
iptables -A FORWARD -s 10.0.0.11 -j ACCEPT

iptables -A PREROUTING -t nat -p tcp -d 203.100.100.1 --dport 21 -j DNAT 
--to 10.0.0.11
ptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 203.100.100.1


tha should work: it's working for me, at least.
Remember that forwarded traffic must be SNATed with the source (public) 
address of the forwarding box.
andrea

Re: portfw on iptables 2.4 kernel problem.

[Joel Newkirk]

On Wednesday 11 December 2002 04:00 am, Reckhard, Tobias wrote:
> Munging both replies into one, my answers are inline.
>
> > > I expect you're trying to access the FTP server on
> > > 10.0.0.11 from the
> > > Internet by redirecting connections to the firewall's external IP
> > > address (203.100.100.1) to the FTP server.
> > >
> > > Take care of the FTP control connection:
> > > 2. Permit INPUT on the outside interface of the firewall to TCP
> > > port 21 with states NEW and ESTABLISHED
> > > 3. Permit OUTPUT on the outside interface of the firewall from TCP
> > > port 21 with state ESTABLISHED
> > > 4. In the PREROUTING chain use DNAT to redirect packets "-p tcp -d
> > > 203.100.100.1 --dport 21" (see point 2 above) to the internal
> > > server at 10.0.0.11.
> > > 5. Permit FORWARDing of those same packets with states NEW and
> > > ESTABLISHED. 6. Permit FORWARDing of response packets ("-s
> > > 10.0.0.11 --sport 21") with state ESTABLISHED.
> >
> > This wouldn't work at all.  INPUT shouldn't enter into it at
> > all, unless
> > the DNAT fails, and OUTPUT only if a packet is required to leave the
> > firewall machine itself, IE if that is where the connection
> > is attempted from or to.
>
> The above takes care of the control connection only. Since the
> Internet machine believes it is accessing an FTP server on the
> firewall itself, the latter is addressed by its FTP control
> connection. This means that the packets cross the firewall's INPUT
> chain, before they can be DNATed in the PREROUTING chain. I'm not
> entirely sure about the outbound packets, but most things netfilter
> apart from NAT require symmetric rules, so I suppose you need an
> OUTPUT rule to match the INPUT one.

I don't see how this would be.  The first chain that a packet entering 
the firewall hits is mangle-PREROUTING, second is nat-PREROUTING.  At 
that point it is DNATted, and then hits a routing decision that 
determines if it is local or not, IE INPUT or FORWARD.  It should never 
'cross' INPUT at all, unless my understanding (and most sources I've 
read, and traversal tests performed) is faulty.

> [FTP data]
>
> Thanks for the info, but I know all about FTP data.. What did you
> think steps 7 through 15 in my recipe were for?

Apologies for this, somehow I lost track of the entire end of your 
message.  I snipped it off to reply about INPUT, and just kept on going 
based on what I still had left, forgetting the remainder.  Someday I'll 
learn to pay more attention when writing 3am replies... (and 3:10 am 
replies to those replies :^)

j

Re: portfw on iptables 2.4 kernel problem.

[louie miranda]

Thanks for those people who replied, But still i can't get it to work.
Ill be posting my rule set here.

=======================================
panic:/# iptables -nL --line-num
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination

Chain FORWARD (policy DROP)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          state
RELATED,ESTABLISHED
2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
3    LOG        all  --  0.0.0.0/0            0.0.0.0/0          LOG flags 0
level 4

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination
panic:/#
=======================================
panic:/# iptables -nL --line-num -t nat
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0          tcp dpt:80
redir ports 3128

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination
panic:/#
=======================================

My rule set is just a simple masq w/ port redirection internally, catching
all port 80 request
and redirect it to my squid on port 3128


I tried the simple rule set that Joel Newkirk, Andrea Rossato and all the
people who have
helped me on my problem but still It does not work, I actually set all the
IPTABLES/NETFILTER
options on my kernel and add "1" on /proc/sys/net/ipv4/ip_forward. I
actually search and
search google.com for my similar problem and tried it all, I had no error's
or such all is working
i think. It just does not connect over to my granted port. Ill try any port
even port 80 or port 139
on my firewall just get this forwarding to work.

Well, thanks again. I hope what i have posted here "my rule set" will give
me such nice answers
to resolved my probem, And ill cont. reading and reading any docs i can find
on the internet.



--
thanks,
louie miranda

RE: portfw on iptables 2.4 kernel problem.

[Reckhard, Tobias]

[snip]
> > The above takes care of the control connection only. Since the
> > Internet machine believes it is accessing an FTP server on the
> > firewall itself, the latter is addressed by its FTP control
> > connection. This means that the packets cross the firewall's INPUT
> > chain, before they can be DNATed in the PREROUTING chain. I'm not
> > entirely sure about the outbound packets, but most things netfilter
> > apart from NAT require symmetric rules, so I suppose you need an
> > OUTPUT rule to match the INPUT one.
> 
> I don't see how this would be.  The first chain that a packet 
> entering 
> the firewall hits is mangle-PREROUTING, second is nat-PREROUTING.  At 
> that point it is DNATted, and then hits a routing decision that 
> determines if it is local or not, IE INPUT or FORWARD.  It 
> should never 
> 'cross' INPUT at all, unless my understanding (and most sources I've 
> read, and traversal tests performed) is faulty.

Then that's where our impression differs. I have thought up to now that
INPUT is hit before PREROUTING before FORWARD before POSTROUTING before
OUTPUT. And that a packet may stop being processed between PREROUTING and
FORWARD as well as between POSTROUTING and OUTPUT.

I may check the one NATing firewall I have running.. later.

Cheers,
Tobias

RE: portfw on iptables 2.4 kernel problem.

[Reckhard, Tobias]

> Thanks for those people who replied, But still i can't get it to work.
> Ill be posting my rule set here.

Have you tried the more complicated rule set that I'd posted (in
pseudo-code)? At a first, casual glance, your NAT rules don't look good to
me.

Cheers,
Tobias

RE: portfw on iptables 2.4 kernel problem.

[Reckhard, Tobias]

Following up to myself...

> Then that's where our impression differs. I have thought up 
> to now that
> INPUT is hit before PREROUTING before FORWARD before 
> POSTROUTING before
> OUTPUT. And that a packet may stop being processed between 
> PREROUTING and
> FORWARD as well as between POSTROUTING and OUTPUT.
> 
> I may check the one NATing firewall I have running.. later.

I just did check that machine and you're right, I was wrong. So INPUT and
OUTPUT rules shouldn't be required in the case we're discussing.

Cheers,
Tobias

RE: portfw on iptables 2.4 kernel problem.

[Rasmus Reinholdt Nielsen]

Hi

I have the same problem here. Using kernel 2.4.19-pre9, where I just can't 
forward port 80. Port 8080 works for instace fine. I have also tried to 
redirect all requests on port 80 to port 8080, but without any luck. When 
connecting to port 80 the browser just hangs. I can see in the apache log 
on the webserver that it gets the request, so I think it is a problem of 
the packets not getting back through the firewall and to the browser.

I just can't see what is wrong. I even tried the following rules to see it 
that would help, but it didn't

iptables -A INPUT -j ACCEPT
iptables -A FORWARD -j ACCEPT
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 80 -j DNAT --to 
<http_ip>:80
echo 1 > /proc/sys/net/ipv4/ip_forward

This is not my usual firewall script, but I can't think of a more open one :)

Anybody knows of this might be a problem with the 2.4.19 kernels, I have a 
2.4.18 firewall as well on which forwarding IS working, with the same ruleset.

thanks

/Rasmus


At 09:09 12-12-2002 +0100, Reckhard, Tobias wrote:
>Following up to myself...
>
> > Then that's where our impression differs. I have thought up
> > to now that
> > INPUT is hit before PREROUTING before FORWARD before
> > POSTROUTING before
> > OUTPUT. And that a packet may stop being processed between
> > PREROUTING and
> > FORWARD as well as between POSTROUTING and OUTPUT.
> >
> > I may check the one NATing firewall I have running.. later.
>
>I just did check that machine and you're right, I was wrong. So INPUT and
>OUTPUT rules shouldn't be required in the case we're discussing.
>
>Cheers,
>Tobias

Re: portfw on iptables 2.4 kernel problem.

[Joel Newkirk]

On Thursday 12 December 2002 03:51 am, Rasmus Reinholdt Nielsen wrote:
> Hi
>
> I have the same problem here. Using kernel 2.4.19-pre9, where I just
> can't forward port 80. Port 8080 works for instace fine. I have also
> tried to redirect all requests on port 80 to port 8080, but without
> any luck. When connecting to port 80 the browser just hangs. I can see
> in the apache log on the webserver that it gets the request, so I
> think it is a problem of the packets not getting back through the
> firewall and to the browser.
>
> I just can't see what is wrong. I even tried the following rules to
> see it that would help, but it didn't
>
> iptables -A INPUT -j ACCEPT
> iptables -A FORWARD -j ACCEPT
> iptables -t nat -A POSTROUTING -j MASQUERADE
> iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 80 -j DNAT --to
> <http_ip>:80
> echo 1 > /proc/sys/net/ipv4/ip_forward
>
> This is not my usual firewall script, but I can't think of a more open
> one :)

Just a few observations.  I assume eth1 is your internet connection, so 
you should probably be using:
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
Otherwise it will constantly be checking the IP of every interface and 
masquerading packets outbound on every interface.
and you also need (did you just not list it?)
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
for the MASQ target to work.

> Anybody knows of this might be a problem with the 2.4.19 kernels, I
> have a 2.4.18 firewall as well on which forwarding IS working, with
> the same ruleset.

Is this just DNAT that fails, or all forwarding?  And just to be sure, 
since you didn't say, are you testing it from outside the LAN, or from a 
local machine (or the firewall box itself)?

j