FTP Connection problems.

FTP Connection problems.

[Vincent Blondel]

Hi all,

I a trying to initiate ftp connections to some of my servers but it
doesn't work. You can find below a schema representing my three
machines, client, firewall and ftp server. There is no NAT at the moment
and the script I use on my firewall.

---

 ftp server                   eth1 fw eth0                 client 
192.168.125.1      192.168.125.240    192.168.124.240    192.168.124.1

---

#!/bin/sh
#

fw="/sbin/iptables"
nat="$fw -t nat"
mangle="$fw -t mangle"

CONN_TRACK="1" 				# Connection Tracking
UNPRIVPORTS="1024:65535" 		# unprivileged port range

# Remove any existing rules from all chains
$fw --flush
$nat --flush
$mangle --flush

# Unlimited traffic on the loopback interface
$fw -A INPUT  -i lo -j ACCEPT
$fw -A OUTPUT -o lo -j ACCEPT

# Set the default policy to drop
$fw --policy INPUT   DROP
$fw --policy OUTPUT  DROP
$fw --policy FORWARD DROP

$nat --policy PREROUTING  DROP
$nat --policy OUTPUT      DROP
$nat --policy POSTROUTING DROP

$mangle --policy PREROUTING  DROP
$mangle --policy OUTPUT      DROP

# Remove any pre-existing user-defined chains
$fw --delete-chain
$nat --delete-chain
$mangle --delete-chain

if [ "$CONN_TRACK" = "1" ]; then
	$fw -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
	$fw -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
	$fw -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
fi

# Incoming FTP requests
iptables -A FORWARD -i eth0 -o eth1 -p tcp -s 192.168.124.1 --sport
$UNPRIVPORTS -d 192.168.125.1 --dport 21 -m state --state NEW -j ACCEPT

# Port Mode Data Channel Responses
iptables -A FORWARD -i eth1 -o eth0 -p tcp -d 192.168.124.1 --sport 20
--dport $UNPRIVPORTS -m state --state NEW -j ACCEPT

Thanks to help me ...
Vincent

Re: FTP Connection problems.

[a.ledvinka]

modprobe ip_nat_ftp             - if passive works but active writes error 
after PORT command or hangs.
modprobe ip_conntrack_ftp       - if forwarding rule filtering based on 
state. remember to accept RELATED tcp connections.

see
modinfo ip_conntrack_ftp
...
parm:        ports int array (min = 1, max = 8)

if you want to access ftp servers unusual ports. then you would have to 
add some entry to /etc/modules.conf with options line or in script you use 
add ports parameter.

RE: FTP Connection problems.

[Jason Opperisano]

> Hi all,
>
> I a trying to initiate ftp connections to some of my servers but it
> doesn't work. You can find below a schema representing my three
> machines, client, firewall and ftp server. There is no NAT at the moment
> and the script I use on my firewall.
>
> ---
>
>  ftp server                   eth1 fw eth0                 client
> 192.168.125.1      192.168.125.240    192.168.124.240    192.168.124.1
>
> ---
>
> #!/bin/sh
> #
>
> fw="/sbin/iptables"
> nat="$fw -t nat"
> mangle="$fw -t mangle"
>
> CONN_TRACK="1"                                # Connection Tracking
> UNPRIVPORTS="1024:65535"              # unprivileged port range
>
> # Remove any existing rules from all chains
> $fw --flush
> $nat --flush
> $mangle --flush
>
> # Unlimited traffic on the loopback interface
> $fw -A INPUT  -i lo -j ACCEPT
> $fw -A OUTPUT -o lo -j ACCEPT
>
> # Set the default policy to drop
> $fw --policy INPUT   DROP
> $fw --policy OUTPUT  DROP
> $fw --policy FORWARD DROP
>
> $nat --policy PREROUTING  DROP
> $nat --policy OUTPUT      DROP
> $nat --policy POSTROUTING DROP
>
> $mangle --policy PREROUTING  DROP
> $mangle --policy OUTPUT      DROP
>
> # Remove any pre-existing user-defined chains
> $fw --delete-chain
> $nat --delete-chain
> $mangle --delete-chain
>
> if [ "$CONN_TRACK" = "1" ]; then
>       $fw -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>       $fw -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>       $fw -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> fi
>
> # Incoming FTP requests
> iptables -A FORWARD -i eth0 -o eth1 -p tcp -s 192.168.124.1 --sport
> $UNPRIVPORTS -d 192.168.125.1 --dport 21 -m state --state NEW -j ACCEPT
>
> # Port Mode Data Channel Responses
> iptables -A FORWARD -i eth1 -o eth0 -p tcp -d 192.168.124.1 --sport 20
> --dport $UNPRIVPORTS -m state --state NEW -j ACCEPT
>
> Thanks to help me ...
> Vincent

if the client is running a passive FTP client--you need to have the FTP connection tracking module loaded for those connections to be considered RELATED:

  # modprobe ip_conntrack_ftp

-j

RE: FTP Connection problems.

[Jason Opperisano]

> I compiled a kernel without any modules ( all these are in vmlinuz ) an
> I use the very basic ftp client from coreutils ( so normally this does
> not initiate passive connections ).
>
> So what do I have to do ???

go look in your config file that you used to compile your kernel.  did you set CONFIG_IP_NF_CONNTRACK (i assume you did) and CONFIG_IP_NF_FTP (this is connection tracking for FTP)?  if not...i see a make config && make dep clean bzImage install in your future...

use an FTP client that allows you to switch between active and passive mode on the fly so you can determine what is and is not working.  i use ncftp, which supports 'set passive on|off'...  the basic "ftp" command that ships with FC1 supports switching back and forth with the 'passive' command.  the way your rules are set up, *active* FTP should be working.

also--please rethink this:

> $nat --policy PREROUTING  DROP
> $nat --policy OUTPUT      DROP
> $nat --policy POSTROUTING DROP
>
> $mangle --policy PREROUTING  DROP
> $mangle --policy OUTPUT      DROP

you'll never get anything working with those set to DROP (relatively speaking)...

-j

Re: FTP Connection problems.

[Aleksandar Milivojevic]

Vincent Blondel wrote:
> Hi all,
> 
> I a trying to initiate ftp connections to some of my servers but it
> doesn't work. You can find below a schema representing my three
> machines, client, firewall and ftp server. There is no NAT at the moment
> and the script I use on my firewall.

OK, let's go through it line by line...

> # Set the default policy to drop
> $fw --policy INPUT   DROP
> $fw --policy OUTPUT  DROP
> $fw --policy FORWARD DROP

These are OK, and recommended setting for firewall.

> $nat --policy PREROUTING  DROP
> $nat --policy OUTPUT      DROP
> $nat --policy POSTROUTING DROP
> 
> $mangle --policy PREROUTING  DROP
> $mangle --policy OUTPUT      DROP

With the above policies, you were dropping packets in PREROUTING chain 
before they ever had a chance to reach INPUT or FORWARD chains (same 
thing for POSTROUTING, packets are going there after (and if) they pass 
FORWARD or OUTPUT chains).  Also, make a note that packets will go 
through only one of INPUT (just before packet is delivered to local 
process), OUTPUT (as soon as packet is generated by local process), or 
FORWARD chains (packets that are not generated or to be delivered 
locally).  They will never go through two or all three of them.

Filter table is intended for general packet filtering, so that is the 
only table where (generally) you would set default policy to DROP.  (as 
a sidenote, you could use nat table for filtering if you don't care if 
origin and/or destination of packet is remote or local, but that isn't 
something you would generally do).

Nat table is intended for implementig NATed networks, and mangle is for 
general purpuse packet mangling (strange things you might want to do to 
packets).  They are not intended for packet filtering (although you can 
do it there too).  So you would leave those two with ACCEPT policy, and 
not implement any DROP rules there either.

There's a logic behind why all chains do not exist in all tables, and 
why you can't use all targets in all tables.  And basically the logic is 
based on for what the table was intended to be used.

> if [ "$CONN_TRACK" = "1" ]; then
> 	$fw -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> 	$fw -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> 	$fw -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> fi

I'd probably be more restrictive here, and allow only ESTABLISHED.  Than 
I would add separate generic rules for related ICMP packets (and you 
really want to add those if you remove RELATED from above lines), and 
then I would have rules for incoming related connections with helper 
module match for each one of them.  The ICMP thing would be something 
like (for INPUT, add similar for OUTPUT and FORWARD):

$fw -A INPUT -p icmp -m state --state RELATED -j ACCEPT

> # Incoming FTP requests
> iptables -A FORWARD -i eth0 -o eth1 -p tcp -s 192.168.124.1 --sport
> $UNPRIVPORTS -d 192.168.125.1 --dport 21 -m state --state NEW -j ACCEPT

This is OK.

> # Port Mode Data Channel Responses
> iptables -A FORWARD -i eth1 -o eth0 -p tcp -d 192.168.124.1 --sport 20
> --dport $UNPRIVPORTS -m state --state NEW -j ACCEPT

This is wrong.  The first packet of this connection will be in RELATED 
state, and the rest will be in ESTABLISHED state (if you load ftp helper 
module, as you should).  However, your generic rules for 
ESTABLISHED,RELATED will catch and accept this connection regardless of 
this line (read below why they are not working).  If you go with my 
advice of removing generic RELATED rule, than you would write it 
something like this (you'd need two lines):

# This will handle active FTP data transfers
iptables -A FORWARD -i eth1 -o eth0 \
    -p tcp -s 192.168.125.1 -d 192.168.124.1 \
    --sport 20 --dport $UNPRIVPORTS \
    -m helper --helper ftp \
    -m state --state RELATED -j ACCEPT

# This will handle passive FTP data transfers
iptables -A FORWARD -i eth0 -o eth1
    -p tcp -s 192.168.124.1 -d 192.168.125.1 \
    --sport $UNPRIVPORTS --dport $UNPRIVPORTS \
    -m helper --helper ftp \
    -m state --state RELATED -j ACCEPT

If you are going to have your generic RELATED,ESTABLISHED match, than 
you don't need any of those rules (you only need rule for allowing 
connection to FTP port 21).  Also, you can ommit specifying helper 
module, it's just that this way you are matching which helper marked the 
packet as related (security is paranoid by its nature ;-).

Also, for the related match, you will need to load FTP helper module (it 
doesn't get loaded automatically).  Without it, it isn't going to work. 
  The one you need is ip_conntrack_ftp.  You might also load ip_nat_ftp 
(which will in turn load ip_conntrack_ftp automatically, since it 
depends on it).  Add a line like this to your firewall script (anywhere 
in the script):

    modprobe ip_nat_ftp

You can even type it manually on command line (before or after you load 
the rules, doesn't matter).

After that, when you do lsmod | grep '^ip' you should see ip_nat_ftp and 
ip_conntrack_ftp loaded.

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: FTP Connection problems.

[Vincent Blondel]

On Tue, 2004-08-24 at 18:10, Aleksandar Milivojevic wrote:
> Vincent Blondel wrote:
> > Hi all,
> > 
> > I a trying to initiate ftp connections to some of my servers but it
> > doesn't work. You can find below a schema representing my three
> > machines, client, firewall and ftp server. There is no NAT at the moment
> > and the script I use on my firewall.
> 
> OK, let's go through it line by line...
> 
> > # Set the default policy to drop
> > $fw --policy INPUT   DROP
> > $fw --policy OUTPUT  DROP
> > $fw --policy FORWARD DROP
> 
> These are OK, and recommended setting for firewall.
> 
> > $nat --policy PREROUTING  DROP
> > $nat --policy OUTPUT      DROP
> > $nat --policy POSTROUTING DROP
> > 
> > $mangle --policy PREROUTING  DROP
> > $mangle --policy OUTPUT      DROP
> 
> With the above policies, you were dropping packets in PREROUTING chain 
> before they ever had a chance to reach INPUT or FORWARD chains (same 
> thing for POSTROUTING, packets are going there after (and if) they pass 
> FORWARD or OUTPUT chains).  Also, make a note that packets will go 
> through only one of INPUT (just before packet is delivered to local 
> process), OUTPUT (as soon as packet is generated by local process), or 
> FORWARD chains (packets that are not generated or to be delivered 
> locally).  They will never go through two or all three of them.
> 
> Filter table is intended for general packet filtering, so that is the 
> only table where (generally) you would set default policy to DROP.  (as 
> a sidenote, you could use nat table for filtering if you don't care if 
> origin and/or destination of packet is remote or local, but that isn't 
> something you would generally do).
> 
> Nat table is intended for implementig NATed networks, and mangle is for 
> general purpuse packet mangling (strange things you might want to do to 
> packets).  They are not intended for packet filtering (although you can 
> do it there too).  So you would leave those two with ACCEPT policy, and 
> not implement any DROP rules there either.
> 
> There's a logic behind why all chains do not exist in all tables, and 
> why you can't use all targets in all tables.  And basically the logic is 
> based on for what the table was intended to be used.
> 
> > if [ "$CONN_TRACK" = "1" ]; then
> > 	$fw -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> > 	$fw -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> > 	$fw -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> > fi
> 
> I'd probably be more restrictive here, and allow only ESTABLISHED.  Than 
> I would add separate generic rules for related ICMP packets (and you 
> really want to add those if you remove RELATED from above lines), and 
> then I would have rules for incoming related connections with helper 
> module match for each one of them.  The ICMP thing would be something 
> like (for INPUT, add similar for OUTPUT and FORWARD):
> 
> $fw -A INPUT -p icmp -m state --state RELATED -j ACCEPT
> 
> > # Incoming FTP requests
> > iptables -A FORWARD -i eth0 -o eth1 -p tcp -s 192.168.124.1 --sport
> > $UNPRIVPORTS -d 192.168.125.1 --dport 21 -m state --state NEW -j ACCEPT
> 
> This is OK.
> 
> > # Port Mode Data Channel Responses
> > iptables -A FORWARD -i eth1 -o eth0 -p tcp -d 192.168.124.1 --sport 20
> > --dport $UNPRIVPORTS -m state --state NEW -j ACCEPT
> 
> This is wrong.  The first packet of this connection will be in RELATED 
> state, and the rest will be in ESTABLISHED state (if you load ftp helper 
> module, as you should).  However, your generic rules for 
> ESTABLISHED,RELATED will catch and accept this connection regardless of 
> this line (read below why they are not working).  If you go with my 
> advice of removing generic RELATED rule, than you would write it 
> something like this (you'd need two lines):
> 
> # This will handle active FTP data transfers
> iptables -A FORWARD -i eth1 -o eth0 \
>     -p tcp -s 192.168.125.1 -d 192.168.124.1 \
>     --sport 20 --dport $UNPRIVPORTS \
>     -m helper --helper ftp \
>     -m state --state RELATED -j ACCEPT
> 
> # This will handle passive FTP data transfers
> iptables -A FORWARD -i eth0 -o eth1
>     -p tcp -s 192.168.124.1 -d 192.168.125.1 \
>     --sport $UNPRIVPORTS --dport $UNPRIVPORTS \
>     -m helper --helper ftp \
>     -m state --state RELATED -j ACCEPT
> 
> If you are going to have your generic RELATED,ESTABLISHED match, than 
> you don't need any of those rules (you only need rule for allowing 
> connection to FTP port 21).  Also, you can ommit specifying helper 
> module, it's just that this way you are matching which helper marked the 
> packet as related (security is paranoid by its nature ;-).
> 
> Also, for the related match, you will need to load FTP helper module (it 
> doesn't get loaded automatically).  Without it, it isn't going to work. 
>   The one you need is ip_conntrack_ftp.  You might also load ip_nat_ftp 
> (which will in turn load ip_conntrack_ftp automatically, since it 
> depends on it).  Add a line like this to your firewall script (anywhere 
> in the script):
> 
>     modprobe ip_nat_ftp
> 
> You can even type it manually on command line (before or after you load 
> the rules, doesn't matter).
> 
> After that, when you do lsmod | grep '^ip' you should see ip_nat_ftp and 
> ip_conntrack_ftp loaded.

Thanks a lot for all the details but I still get some problems. As I
said it all the netfilter source code is compiled in a custom kernel
without any modules. 

Concerning the little iptables script I have written, I updated it with
your comments and now I get the next script 

#!/bin/sh
#

fw="/sbin/iptables"
nat="$fw -t nat"
mangle="$fw -t mangle"

CONN_TRACK="1"                          # Connection Tracking
UNPRIVPORTS="1024:65535"                # unprivileged port range

# Remove any existing rules from all chains
$fw --flush
$nat --flush
$mangle --flush

# Unlimited traffic on the loopback interface
$fw -A INPUT  -i lo -j ACCEPT
$fw -A OUTPUT -o lo -j ACCEPT

# Set the default policy to drop
$fw --policy INPUT   DROP
$fw --policy OUTPUT  DROP
$fw --policy FORWARD DROP

$nat --policy PREROUTING  ACCEPT
$nat --policy OUTPUT      ACCEPT
$nat --policy POSTROUTING ACCEPT

$mangle --policy PREROUTING  ACCEPT
$mangle --policy OUTPUT      ACCEPT

# Remove any pre-existing user-defined chains
$fw --delete-chain
$nat --delete-chain
$mangle --delete-chain

if [ "$CONN_TRACK" = "1" ]; then
        $fw -A INPUT -m state --state ESTABLISHED -j ACCEPT
        $fw -A OUTPUT -m state --state ESTABLISHE -j ACCEPT
        $fw -A FORWARD -m state --state ESTABLISHED -j ACCEPT
        $fw -A INPUT -p icmp -m state --state RELATED -j ACCEPT
fi

# Incoming FTP requests
iptables -A FORWARD -i eth0 -o eth1 -p tcp -s 192.168.124.1 --sport
$UNPRIVPORTS -d 192.168.125.1 --dport 21 -m state --state NEW -j ACCEPT

# This will handle active FTP data transfers
iptables -A FORWARD -i eth1 -o eth0 \
    -p tcp -s 192.168.125.1 -d 192.168.124.1 \
    --sport 20 --dport $UNPRIVPORTS \
    -m helper --helper ftp \
    -m state --state RELATED -j ACCEPT

# This will handle passive FTP data transfers 
iptables -A FORWARD -i eth0 -o eth1
    -p tcp -s 192.168.124.1 -d 192.168.125.1 \
    --sport $UNPRIVPORTS --dport $UNPRIVPORTS \
    -m helper --helper ftp \
    -m state --state RELATED -j ACCEPT

... but the connection takes a long time to terminate. If I disable all
the rules, ftp connection goes directly but with iptables enabled it
takes such 8 seconds to accomplish the annonymomus connection ( with
data port and passive models ).

What is this all about ???

Regards
Vincent

Re: FTP Connection problems.

[a.ledvinka]

could be many reasons.

either side wants to do ident lookup and timeouts or
either side wants to do reverse and forward dns lookup somwhere around 
accepting connection before anything happens and timeouts on nonworking 
dns or
you use some inteligent ftp client that would rever to passive ftp if 
active is not working or else.

best to choose command line ftp client and test it with explicit passive 
mode on and off to see if it is realy able to open both types of 
connections.
next check dns from both ends of connection and see how fast (and if it is 
correct - not serverfail/nxdomain/... type of response) you get answer 
from dns service for both revers and forward lookups for other side.
then allow or reject (don't simply drop) traffic for ident service or 
modify ftp server setting

btw: not directly related to your problem but you might also want to: $fw 
-A FORWARD -p icmp -m state --state RELATED -j ACCEPT (and maybe OUTPUT 
too)

Re: FTP Connection problems.

[Vincent Blondel]

On Wed, 2004-08-25 at 13:11, a.ledvinka@promon.cz wrote:
> could be many reasons.
> 
> either side wants to do ident lookup and timeouts or
> either side wants to do reverse and forward dns lookup somwhere around 
> accepting connection before anything happens and timeouts on nonworking 
> dns or
> you use some inteligent ftp client that would rever to passive ftp if 
> active is not working or else.
> 
> best to choose command line ftp client and test it with explicit passive 
> mode on and off to see if it is realy able to open both types of 
> connections.
> next check dns from both ends of connection and see how fast (and if it is 
> correct - not serverfail/nxdomain/... type of response) you get answer 
> from dns service for both revers and forward lookups for other side.
> then allow or reject (don't simply drop) traffic for ident service or 
> modify ftp server setting
> 
> btw: not directly related to your problem but you might also want to: $fw 
> -A FORWARD -p icmp -m state --state RELATED -j ACCEPT (and maybe OUTPUT 
> too)

To test my iptables configuration, I am doing the very basic connection
tests :

wget --passive 192.168.125.1://pub/test.iso

ftp 192.168.125.1
<this takes here already 8 seconds>
anonymous
password
cd test
get test.iso

So this could not be a dns problem. This could also not be a traffic
congestion problem because I am trying this config with three stations
(connected directly by a ethernet cable) located on my desk.

Regards
Vincent

RE: FTP Connection problems.

[Jason Opperisano]

> ... but the connection takes a long time to terminate. If I disable all
> the rules, ftp connection goes directly but with iptables enabled it
> takes such 8 seconds to accomplish the annonymomus connection ( with
> data port and passive models ).
>
> What is this all about ???
>
> Regards
> Vincent

your server is trying to do a reverse DNS lookup on the IP address of the connecting client.  either disable reverse lookups on your FTP server, or allow it to resolve DNS through your firewall.

-j

RE: FTP Connection problems.

[Vincent Blondel]

On Wed, 2004-08-25 at 13:48, Jason Opperisano wrote:
> > ... but the connection takes a long time to terminate. If I disable all
> > the rules, ftp connection goes directly but with iptables enabled it
> > takes such 8 seconds to accomplish the annonymomus connection ( with
> > data port and passive models ).
> >
> > What is this all about ???
> >
> > Regards
> > Vincent
> 
> your server is trying to do a reverse DNS lookup on the IP address of the connecting client.  either disable reverse lookups on your FTP server, or allow it to resolve DNS through your firewall.
> 
> -j

Here the logfile generated by tcpdump on my firewall when I ...

ftp 192.168.125.1 (from 192.168.124.1)

14:31:19.818595 IP 192.168.124.1.32790 > 192.168.125.1.ftp: S
2452334504:2452334504(0) win 5840 <mss 1460,sackOK,timestamp
10914109[|tcp]>
14:31:19.819085 IP 192.168.125.1.ftp > 192.168.124.1.32790: S
2932060858:2932060858(0) ack 2452334505 win 5792 <mss
1460,sackOK,timestamp 1164327[|tcp]>
14:31:19.819448 IP 192.168.124.1.32790 > 192.168.125.1.ftp: . ack 1 win
5840 <nop,nop,timestamp 10914109 1164327>
14:31:29.830558 IP 192.168.125.1.ftp > 192.168.124.1.32790: P 1:66(65)
ack 1 win 5792 <nop,nop,timestamp 1165329 10914109>
14:31:29.830970 IP 192.168.124.1.32790 > 192.168.125.1.ftp: . ack 66 win
5840 <nop,nop,timestamp 10924124 1165329>

Furthermore, as you suggested it I added in my proftpd server
configuration 

UseReverseDNS                   off

... But this does not change anything.

I hope these information will be useful for you.

Regards
Vincent

RE: FTP Connection problems.

[Jason Opperisano]

> Here the logfile generated by tcpdump on my firewall when I ...
>
> ftp 192.168.125.1 (from 192.168.124.1)
>
> 14:31:19.818595 IP 192.168.124.1.32790 > 192.168.125.1.ftp: S
> 2452334504:2452334504(0) win 5840 <mss 1460,sackOK,timestamp
> 10914109[|tcp]>

SYN

> 14:31:19.819085 IP 192.168.125.1.ftp > 192.168.124.1.32790: S
> 2932060858:2932060858(0) ack 2452334505 win 5792 <mss
> 1460,sackOK,timestamp 1164327[|tcp]>

SYN-ACK

> 14:31:19.819448 IP 192.168.124.1.32790 > 192.168.125.1.ftp: . ack 1 win
> 5840 <nop,nop,timestamp 10914109 1164327>

ACK

> 14:31:29.830558 IP 192.168.125.1.ftp > 192.168.124.1.32790: P 1:66(65)
> ack 1 win 5792 <nop,nop,timestamp 1165329 10914109>

10 second delay...  either that FTP is sending packets elsewhere that aren't getting captured, or has some problem/configuration that keeps it from responding any faster than that.

can you perform the tcpdump on the FTP server itself?

> 14:31:29.830970 IP 192.168.124.1.32790 > 192.168.125.1.ftp: . ack 66 win
> 5840 <nop,nop,timestamp 10924124 1165329>
>
> Furthermore, as you suggested it I added in my proftpd server
> configuration
>
> UseReverseDNS                   off
>
> ... But this does not change anything.

you *did* restart the daemon after that, right?  ;-)

-j

RE: FTP Connection problems.

[Vincent Blondel]

On Wed, 2004-08-25 at 14:49, Jason Opperisano wrote:
> > Here the logfile generated by tcpdump on my firewall when I ...
> >
> > ftp 192.168.125.1 (from 192.168.124.1)
> >
> > 14:31:19.818595 IP 192.168.124.1.32790 > 192.168.125.1.ftp: S
> > 2452334504:2452334504(0) win 5840 <mss 1460,sackOK,timestamp
> > 10914109[|tcp]>
> 
> SYN
> 
> > 14:31:19.819085 IP 192.168.125.1.ftp > 192.168.124.1.32790: S
> > 2932060858:2932060858(0) ack 2452334505 win 5792 <mss
> > 1460,sackOK,timestamp 1164327[|tcp]>
> 
> SYN-ACK
> 
> > 14:31:19.819448 IP 192.168.124.1.32790 > 192.168.125.1.ftp: . ack 1 win
> > 5840 <nop,nop,timestamp 10914109 1164327>
> 
> ACK
> 
> > 14:31:29.830558 IP 192.168.125.1.ftp > 192.168.124.1.32790: P 1:66(65)
> > ack 1 win 5792 <nop,nop,timestamp 1165329 10914109>
> 
> 10 second delay...  either that FTP is sending packets elsewhere that aren't getting captured, or has some problem/configuration that keeps it from responding any faster than that.
> 
> can you perform the tcpdump on the FTP server itself?

Here you are ...

tcpdump.firewall.log

15:59:24.071217 IP 192.168.124.1.32796 > 192.168.125.1.ftp: S
3496999441:3496999441(0) win 5840 <mss 1460,sackOK,timestamp
16200055[|tcp]>
15:59:24.072144 arp who-has 192.168.124.1 tell pix1
15:59:24.072464 arp reply 192.168.124.1 is-at 00:50:ba:e2:a9:ed
15:59:24.072499 IP 192.168.125.1.ftp > 192.168.124.1.32796: S
4161421847:4161421847(0) ack 3496999442 win 5792 <mss
1460,sackOK,timestamp 1692753[|tcp]>
15:59:24.072847 IP 192.168.124.1.32796 > 192.168.125.1.ftp: . ack 1 win
5840 <nop,nop,timestamp 16200057 1692753>
15:59:34.085569 IP 192.168.125.1.ftp > 192.168.124.1.32796: P 1:66(65)
ack 1 win 5792 <nop,nop,timestamp 1693755 16200057>
15:59:34.085984 IP 192.168.124.1.32796 > 192.168.125.1.ftp: . ack 66 win
5840 <nop,nop,timestamp 16210073 1693755>

tcpdump.ftp.log

15:52:48.574738 192.168.124.1.32796 > iptables.ftp: S
3496999441:3496999441(0) win 5840 <mss 1460,sackOK,timestamp 16200055
0,nop,wscale 0>
15:52:48.574908 arp who-has 192.168.125.240 tell iptables
15:52:48.575204 arp reply 192.168.125.240 is-at 0:30:4f:5:74:39
15:52:48.575226 iptables.ftp > 192.168.124.1.32796: S
4161421847:4161421847(0) ack 3496999442 win 5792 <mss
1460,sackOK,timestamp 1692753 16200055,nop,wscale 0> (DF)
15:52:48.576318 192.168.124.1.32796 > iptables.ftp: . ack 1 win 5840
<nop,nop,timestamp 16200057 1692753>
15:52:48.597025 iptables.33254 > 192.168.124.1.auth: S
4154447273:4154447273(0) win 5840 <mss 1460,sackOK,timestamp 1692755
0,nop,wscale 0> (DF)
15:52:51.587881 iptables.33254 > 192.168.124.1.auth: S
4154447273:4154447273(0) win 5840 <mss 1460,sackOK,timestamp 1693055
0,nop,wscale 0> (DF)
15:52:53.575270 arp who-has iptables tell 192.168.125.240
15:52:53.575318 arp reply iptables is-at 0:50:22:0:3:46
15:52:57.587870 iptables.33254 > 192.168.124.1.auth: S
4154447273:4154447273(0) win 5840 <mss 1460,sackOK,timestamp 1693655
0,nop,wscale 0> (DF)
15:52:58.588596 iptables.ftp > 192.168.124.1.32796: P 1:66(65) ack 1 win
5792 <nop,nop,timestamp 1693755 16200057> (DF)
15:52:58.589458 192.168.124.1.32796 > iptables.ftp: . ack 66 win 5840
<nop,nop,timestamp 16210073 1693755> [tos 0x10] 

> 
> > 14:31:29.830970 IP 192.168.124.1.32790 > 192.168.125.1.ftp: . ack 66 win
> > 5840 <nop,nop,timestamp 10924124 1165329>
> >
> > Furthermore, as you suggested it I added in my proftpd server
> > configuration
> >
> > UseReverseDNS                   off
> >
> > ... But this does not change anything.
> 
> you *did* restart the daemon after that, right?  ;-)

yes sure :)

> 
> -j

I am back :)

Re: FTP Connection problems.

[Aleksandar Milivojevic]

Vincent Blondel wrote:
> Thanks a lot for all the details but I still get some problems. As I
> said it all the netfilter source code is compiled in a custom kernel
> without any modules. 
> 
> Concerning the little iptables script I have written, I updated it with
> your comments and now I get the next script 

[snip]

> if [ "$CONN_TRACK" = "1" ]; then
>         $fw -A INPUT -m state --state ESTABLISHED -j ACCEPT
>         $fw -A OUTPUT -m state --state ESTABLISHE -j ACCEPT
>         $fw -A FORWARD -m state --state ESTABLISHED -j ACCEPT
>         $fw -A INPUT -p icmp -m state --state RELATED -j ACCEPT
> fi

Add these too:

$fw -A OUTPUT -p icmp -m state --state RELATED -j ACCEPT
$fw -A FORWARD -p icmp -m state --state RELATED -j ACCEPT

> ... but the connection takes a long time to terminate. If I disable all
> the rules, ftp connection goes directly but with iptables enabled it
> takes such 8 seconds to accomplish the annonymomus connection ( with
> data port and passive models ).
> 
> What is this all about ???

You could use a bit of logging.  Add these as last rules (at the very 
end of your script):

iptables -A INPUT -j LOG --log-prefix "INPUT "
iptables -A OUTPUT -j LOG --log-prefix "OUTPUT "
iptables -A FORWARD -j LOG --log-prefix "FORWARD "

Logs will go wherever your kernel logs go.  Usually /var/log/messages.

Since these will be at the end of your rules, they will log all packets 
dropped by policy just before they are dropped.  My guess is that you 
will either find TCP SYN packets to port 113 (ident) or UDP packets to 
port 53 (DNS).

To silently disable ident (incoming and outgoing) on FTP server, you 
could do something like this (you can add line for FORWARDED packets, if 
you wish):

iptables -A INPUT -p tcp --sport 1024: --dport 113 \
    -j REJECT --reject-with tcp-reset
iptables -A OUTPUT -p tcp --sport 1024: --dport 113 \
    -j REJECT --reject-with tcp-reset
iptables -A OUTPUT -p tcp --sport 113 --dport 1024: \
    -m state --state RELATED -j ACCEPT

If you want your FTP server to be able to resolve names and reverse 
lookup IP addresses:

iptables -A OUTPUT -p udp --sport 1024: --dport 53 \
    -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp --sport 1024: --dport 53 \
    -m state --state NEW -j ACCEPT

(you can add IP address(es) of your DNS server(s) there)

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

RE: FTP Connection problems.

[Jason Opperisano]

> Here you are ...
>
> tcpdump.firewall.log
>
> 15:59:24.071217 IP 192.168.124.1.32796 > 192.168.125.1.ftp: S
> 3496999441:3496999441(0) win 5840 <mss 1460,sackOK,timestamp
> 16200055[|tcp]>
> 15:59:24.072144 arp who-has 192.168.124.1 tell pix1
> 15:59:24.072464 arp reply 192.168.124.1 is-at 00:50:ba:e2:a9:ed
> 15:59:24.072499 IP 192.168.125.1.ftp > 192.168.124.1.32796: S
> 4161421847:4161421847(0) ack 3496999442 win 5792 <mss
> 1460,sackOK,timestamp 1692753[|tcp]>
> 15:59:24.072847 IP 192.168.124.1.32796 > 192.168.125.1.ftp: . ack 1 win
> 5840 <nop,nop,timestamp 16200057 1692753>
> 15:59:34.085569 IP 192.168.125.1.ftp > 192.168.124.1.32796: P 1:66(65)
> ack 1 win 5792 <nop,nop,timestamp 1693755 16200057>
> 15:59:34.085984 IP 192.168.124.1.32796 > 192.168.125.1.ftp: . ack 66 win
> 5840 <nop,nop,timestamp 16210073 1693755>
>
> tcpdump.ftp.log
>
> 15:52:48.574738 192.168.124.1.32796 > iptables.ftp: S
> 3496999441:3496999441(0) win 5840 <mss 1460,sackOK,timestamp 16200055
> 0,nop,wscale 0>
> 15:52:48.574908 arp who-has 192.168.125.240 tell iptables
> 15:52:48.575204 arp reply 192.168.125.240 is-at 0:30:4f:5:74:39
> 15:52:48.575226 iptables.ftp > 192.168.124.1.32796: S
> 4161421847:4161421847(0) ack 3496999442 win 5792 <mss
> 1460,sackOK,timestamp 1692753 16200055,nop,wscale 0> (DF)
> 15:52:48.576318 192.168.124.1.32796 > iptables.ftp: . ack 1 win 5840
> <nop,nop,timestamp 16200057 1692753>
> 15:52:48.597025 iptables.33254 > 192.168.124.1.auth: S
> 4154447273:4154447273(0) win 5840 <mss 1460,sackOK,timestamp 1692755
> 0,nop,wscale 0> (DF)
> 15:52:51.587881 iptables.33254 > 192.168.124.1.auth: S
> 4154447273:4154447273(0) win 5840 <mss 1460,sackOK,timestamp 1693055
> 0,nop,wscale 0> (DF)

IDENT request...bingo...

iptables -I FORWARD -p tcp --syn --dport 113 -j REJECT --reject-with tcp-reset

-j

Re: FTP Connection problems.

[Aleksandar Milivojevic]

Vincent Blondel wrote:

> 15:52:48.597025 iptables.33254 > 192.168.124.1.auth: S
> 4154447273:4154447273(0) win 5840 <mss 1460,sackOK,timestamp 1692755
> 0,nop,wscale 0> (DF)

There you go.  Ident lookup (auth is tcp/113, which is ident service). 
It was blocked by your firewall rules, so you had that delay before it 
timed out.

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: FTP Connection problems.

[Vincent Blondel]

On Wed, 2004-08-25 at 16:13, Aleksandar Milivojevic wrote:
> Vincent Blondel wrote:
> > Thanks a lot for all the details but I still get some problems. As I
> > said it all the netfilter source code is compiled in a custom kernel
> > without any modules. 
> > 
> > Concerning the little iptables script I have written, I updated it with
> > your comments and now I get the next script 
> 
> [snip]
> 
> > if [ "$CONN_TRACK" = "1" ]; then
> >         $fw -A INPUT -m state --state ESTABLISHED -j ACCEPT
> >         $fw -A OUTPUT -m state --state ESTABLISHE -j ACCEPT
> >         $fw -A FORWARD -m state --state ESTABLISHED -j ACCEPT
> >         $fw -A INPUT -p icmp -m state --state RELATED -j ACCEPT
> > fi
> 
> Add these too:
> 
> $fw -A OUTPUT -p icmp -m state --state RELATED -j ACCEPT
> $fw -A FORWARD -p icmp -m state --state RELATED -j ACCEPT
> 
> > ... but the connection takes a long time to terminate. If I disable all
> > the rules, ftp connection goes directly but with iptables enabled it
> > takes such 8 seconds to accomplish the annonymomus connection ( with
> > data port and passive models ).
> > 
> > What is this all about ???
> 
> You could use a bit of logging.  Add these as last rules (at the very 
> end of your script):
> 
> iptables -A INPUT -j LOG --log-prefix "INPUT "
> iptables -A OUTPUT -j LOG --log-prefix "OUTPUT "
> iptables -A FORWARD -j LOG --log-prefix "FORWARD "
> 
> Logs will go wherever your kernel logs go.  Usually /var/log/messages.
> 
> Since these will be at the end of your rules, they will log all packets 
> dropped by policy just before they are dropped.  My guess is that you 
> will either find TCP SYN packets to port 113 (ident) or UDP packets to 
> port 53 (DNS).
> 
> To silently disable ident (incoming and outgoing) on FTP server, you 
> could do something like this (you can add line for FORWARDED packets, if 
> you wish):
> 
> iptables -A INPUT -p tcp --sport 1024: --dport 113 \
>     -j REJECT --reject-with tcp-reset
> iptables -A OUTPUT -p tcp --sport 1024: --dport 113 \
>     -j REJECT --reject-with tcp-reset
> iptables -A OUTPUT -p tcp --sport 113 --dport 1024: \
>     -m state --state RELATED -j ACCEPT
> 
> If you want your FTP server to be able to resolve names and reverse 
> lookup IP addresses:
> 
> iptables -A OUTPUT -p udp --sport 1024: --dport 53 \
>     -m state --state NEW -j ACCEPT
> iptables -A OUTPUT -p tcp --sport 1024: --dport 53 \
>     -m state --state NEW -j ACCEPT
> 
> (you can add IP address(es) of your DNS server(s) there)

this is the result from /var/log/sys.log on my firewall with logging
enabled without anything else changed.

Aug 25 16:56:20 lfs kernel: device eth0 entered promiscuous mode
Aug 25 16:56:23 lfs kernel: FORWARD IN=eth1 OUT=eth0 SRC=192.168.125.1
DST=192.168.124.1 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=10297 DF PROTO=TCP
SPT=33306 DPT=113 WINDOW=5840 RES=0x00 SYN URGP=0 
Aug 25 16:56:26 lfs kernel: FORWARD IN=eth1 OUT=eth0 SRC=192.168.125.1
DST=192.168.124.1 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=10298 DF PROTO=TCP
SPT=33306 DPT=113 WINDOW=5840 RES=0x00 SYN URGP=0 
Aug 25 16:56:32 lfs kernel: FORWARD IN=eth1 OUT=eth0 SRC=192.168.125.1
DST=192.168.124.1 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=10299 DF PROTO=TCP
SPT=33306 DPT=113 WINDOW=5840 RES=0x00 SYN URGP=0 
Aug 25 16:56:37 lfs kernel: device eth0 left promiscuous mode

Re: FTP Connection problems.

[Vincent Blondel]

On Wed, 2004-08-25 at 16:13, Aleksandar Milivojevic wrote:
> Vincent Blondel wrote:
> > Thanks a lot for all the details but I still get some problems. As I
> > said it all the netfilter source code is compiled in a custom kernel
> > without any modules. 
> > 
> > Concerning the little iptables script I have written, I updated it with
> > your comments and now I get the next script 
> 
> [snip]
> 
> > if [ "$CONN_TRACK" = "1" ]; then
> >         $fw -A INPUT -m state --state ESTABLISHED -j ACCEPT
> >         $fw -A OUTPUT -m state --state ESTABLISHE -j ACCEPT
> >         $fw -A FORWARD -m state --state ESTABLISHED -j ACCEPT
> >         $fw -A INPUT -p icmp -m state --state RELATED -j ACCEPT
> > fi
> 
> Add these too:
> 
> $fw -A OUTPUT -p icmp -m state --state RELATED -j ACCEPT
> $fw -A FORWARD -p icmp -m state --state RELATED -j ACCEPT
> 
> > ... but the connection takes a long time to terminate. If I disable all
> > the rules, ftp connection goes directly but with iptables enabled it
> > takes such 8 seconds to accomplish the annonymomus connection ( with
> > data port and passive models ).
> > 
> > What is this all about ???
> 
> You could use a bit of logging.  Add these as last rules (at the very 
> end of your script):
> 
> iptables -A INPUT -j LOG --log-prefix "INPUT "
> iptables -A OUTPUT -j LOG --log-prefix "OUTPUT "
> iptables -A FORWARD -j LOG --log-prefix "FORWARD "
> 
> Logs will go wherever your kernel logs go.  Usually /var/log/messages.
> 
> Since these will be at the end of your rules, they will log all packets 
> dropped by policy just before they are dropped.  My guess is that you 
> will either find TCP SYN packets to port 113 (ident) or UDP packets to 
> port 53 (DNS).
> 
> To silently disable ident (incoming and outgoing) on FTP server, you 
> could do something like this (you can add line for FORWARDED packets, if 
> you wish):
> 
> iptables -A INPUT -p tcp --sport 1024: --dport 113 \
>     -j REJECT --reject-with tcp-reset
> iptables -A OUTPUT -p tcp --sport 1024: --dport 113 \
>     -j REJECT --reject-with tcp-reset
> iptables -A OUTPUT -p tcp --sport 113 --dport 1024: \
>     -m state --state RELATED -j ACCEPT
> 
> If you want your FTP server to be able to resolve names and reverse 
> lookup IP addresses:
> 
> iptables -A OUTPUT -p udp --sport 1024: --dport 53 \
>     -m state --state NEW -j ACCEPT
> iptables -A OUTPUT -p tcp --sport 1024: --dport 53 \
>     -m state --state NEW -j ACCEPT
> 
> (you can add IP address(es) of your DNS server(s) there)

ok great ... It works now. I just added a rule 

iptables -A FORWARD -i eth1 -o eth0 \
    -p tcp -s 192.168.125.1 -d 192.168.124.1 \
    --sport $UNPRIVPORTS --dport 131 \
    -j REJECT --reject-with tcp-reset

Thanks a lot to all of you for helping me to solve this problem. I will
now investigate on the net what is this IDENT protocol about and I can
now go further with my iptables configuration.

:)
Vincent