Hi Gurus!

I've been running iptables on my Linux firewall for several years and have a good basic understanding of its implementation and IP networks in general, however recently I decided to run an ftp server on my firewall to accomodate various anonymous downloads and I am struggling with getting a login prompt when connecting from the Internet. I have narrowed this problem down to a firewall issue, b/c if I unload iptables, I can connect just fine to my vsftpd server on the f/w from both internal and external interfaces. This validates my vsftpd configuration accordingly.

I can also ssh to this f/w box from the Internet just fine.

My config is as follows:

eth0 - internal interface
eth1 - external interface ( ... to DSL 300i using DHCP on external i/f )

Filter Table:
#
# Allow FTP to this firewall from internal addresses only
#
-A INPUT -p tcp -m tcp -i eth0 -s 192.168.1.0/24 --sport 1024: --dport 20:21 -j ACCEPT
-A OUTPUT -p tcp -m tcp -o eth0 --sport 20:21 -d 192.168.1.0/24 --dport 1024: -j ACCEPT

# Allow FTP to firewall from Internet
-A INPUT -p tcp -m tcp -i eth1 --sport 1024: --dport 20:21 -j ACCEPT
-A OUTPUT -p tcp -m tcp -o eth1 --sport 20:21 --dport 1024: -j ACCEPT


-A FORWARD -i eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT


NAT Table:
:POSTROUTING ACCEPT [0:0]

#
# basic masquerading rule
#
-A POSTROUTING -o eth1 -j MASQUERADE


I have the following kernel modules loaded:

Module Size Used by Not tainted
ip_nat_ftp 4112 0 (unused)
ip_conntrack_ftp 5296 1
ipt_LOG 4152 0 (autoclean)
ipt_MASQUERADE 2200 1 (autoclean)
iptable_nat 21720 2 (autoclean) [ip_nat_ftp ipt_MASQUERADE]
ipt_state 1048 5 (autoclean)
ip_conntrack 26976 3 (autoclean) [ip_nat_ftp ip_conntrack_ftp ipt_MASQUERADE iptable_nat ipt_state]
iptable_mangle 2776 0 (autoclean) (unused)
iptable_filter 2412 1 (autoclean)
ip_tables 15096 8 [ipt_LOG ipt_MASQUERADE iptable_nat ipt_state iptable_mangle iptable_filter]


I suspect it has something to do with the state configuration for INPUT and OUTPUT rules on the firewall box. So I did try:
Filter table:
-A OUTPUT -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT

But I suspect its something to do with the NAT table ... ???


Essentially, the Internet ftp client attempts to connect and times out:

$ ftp <firewall hostname>
> ftp: connect :Connection timed out
ftp> quit

On the firewall box hosting this ftp server, running tcpdump on the external interface (eth1):

x.x.x.x: client FTP node IP address
y.y.y.y firewall IP address

tcpdump: listening on eth1
08:48:05.804601 x.x.x.x.53653 > y.y.y.y.21: S 3901527857:3901527857(0) win 65535 <mss 12 60,nop,nop,sackOK> (DF)
08:48:05.804732 y.y.y.y.21 > x.x.x.x.53653: S 38804952:38804952(0) ack 3901527858 win 58 40 <mss 1460,nop,nop,sackOK> (DF)
08:48:09.076808 x.x.x.x.53653 > y.y.y.y.21: S 3901527857:3901527857(0) win 65535 <mss 12 60,nop,nop,sackOK> (DF)
08:48:09.076882 y.y.y.y.21 > x.x.x.x.53653: S 38804952:38804952(0) ack 3901527858 win 58 40 <mss 1460,nop,nop,sackOK> (DF)
08:48:09.744944 y.y.y.y.21 > x.x.x.x.53653: S 38804952:38804952(0) ack 3901527858 win 58 40 <mss 1460,nop,nop,sackOK> (DF)
08:48:15.639463 x.x.x.x.53653 > y.y.y.y.21: S 3901527857:3901527857(0) win 65535 <mss 12 60,nop,nop,sackOK> (DF)
08:48:15.639541 y.y.y.y.21 > x.x.x.x.53653: S 38804952:38804952(0) ack 3901527858 win 58 40 <mss 1460,nop,nop,sackOK> (DF)
08:48:15.744945 y.y.y.y.21 > x.x.x.x.53653: S 38804952:38804952(0) ack 3901527858 win 58 40 <mss 1460,nop,nop,sackOK> (DF)
08:48:24.744950 y.y.y.y.21 > x.x.x.x.53622: S 4263017460:4263017460(0) ack 3884263338 win 58 40 <mss 1460,nop,nop,sackOK> (DF)
08:48:27.744998 y.y.y.y.21 > x.x.x.x.53653: S 38804952:38804952(0) ack 3901527858 win 58 40 <mss 1460,nop,nop,sackOK> (DF)

So, from the trace, you can see the SYN-ACK being logged yet the Internet client never sees the SYN-ACK so it never responds with an ACK back to the firewall to complete the 3-way handshaking.

Now, for the record, this client internet node is my desktop PC within my employers network and it supports internally initiated active and passive FTP sessions. I have also tried it from a box that's sitting on the outside of the firewall altogether and it doesn't see the SYN-ACK as well.

Linux kernel being used is: 2.4.20-8
iptables-1.2.7a-2

Any ideas? Please help! :-)


Also, when loading the ip_conntrack_ftp and ip_nat_ftp modules, do I need to have an explicit rule to account for active sessions using an arbitrarily high port? Or will one of these modules handle that. I thought I read something somewhere that indicated these modules would handle it and its a better approach than putting an explicit rule to allow highport TCP track to/from the box. Please confirm.

Connecting to FTP is quite a complicated matter. Have a look here http://slacksite.com/other/ftp.html. In fact, as you probably know, not only 20 and 21 ports are involved by also other random ports aswell on server or client side depending on type of connection (passive, active).

You need module connection tracking to be on.
# modprobe ip_conntrack_ftp

First open port 21, it is used for active and passive

iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT

Certainly you simply dont want ports >1024 open on server, unless they are related to to previous connection on port 21 so you have to use state RELATED. According to man, RELATED means that the packet is starting a new connection, but is associated with an existing connection. This lines are for active

iptables -A INPUT -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT

these for passive:

iptables -A INPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT

Notice that both server and client operate on ports >1024.

Nope, no luck.

I am totally stumped on this. I can't even get a login prompt. tcpdump on the fw indicates the reception of the SYN pkt from the client ftp station, and the subsequent SYN-ACK yet the client never sees it! How can this be??? If tcpdumps the SYN-ACK on the outside interface, doesn't than unambiguously indicate the packet has passed through the kernel/netfilter/iptables framework?

What's completely bizarre is that if i open my firewall up completely with the following rules right at the beginning of the filter table:

eth0 - internal i/f
eth1 - external i/f

:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

-A INPUT -p tcp -m tcp -i eth0 -j ACCEPT
-A OUTPUT -p tcp -m tcp -o eth0 -j ACCEPT
-A INPUT -p udp -m udp -i eth0 -j ACCEPT
-A OUTPUT -p udp -m udp -o eth0 -j ACCEPT

-A INPUT -p tcp -m tcp -i eth1 -j ACCEPT
-A OUTPUT -p tcp -m tcp -o eth1 -j ACCEPT
-A INPUT -p udp -m udp -i eth1 -j ACCEPT
-A OUTPUT -p udp -m udp -o eth1 -j ACCEPT

This is as wide open as it can get ...

I don't see the SYN-ACK response on the client station and as a result, I can't even get a login prompt all.

Can anyone explain what's going on here?

I am at a total loss here as I should at the very least see a successfull TCP handshake here. Is there some obscure kernel parameter that makes even attempting to connect to an ftp service fail to complete the 3-way connection handshake??? With the rules above, I can easily get a telnet prompt and obviously 3-way handshaking on port 23 succeed. What's going on here? It can't be tcp_wrappers nor PAM at this level.

I've also tried running vsftpd standalone on this f/w box and I get the same behavior.

The ip_conntrack_ftp ip_ nat_ip etc should not prevent the 3-way TCP connection handshaking on port 21 and to prevent the login prompt correct???

Please help ... I've invested so much time into something that should be somewhat trivial!

Kind Regards ... radiowhiz

OK. further update.

If i change /etc/services ftp to use port 29 instead of 21 and use the following rules I can login !!!

eth1 - external
eth0 - internal

-A INPUT -i eth1 -p tcp --dport 29 -j ACCEPT
-A OUTPUT -o eth1 -p tcp --sport 29 -j ACCEPT
-A INPUT -i eth1 -p tcp --dport 20 -j ACCEPT
-A OUTPUT -o eth1 -p tcp --sport 20 -j ACCEPT
-A INPUT -i eth1 -p tcp --dport 29 -m state --state ESTABLISHED -j ACCEPT
-A OUTPUT -o eth1 -p tcp --sport 29 -m state --state NEW,ESTABLISHED -j ACCEPT
-A INPUT -i eth1 -p tcp --dport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -o eth1 -p tcp --sport 20 -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i eth1 -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED -j ACCEPT
-A OUTPUT -o eth1 -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT

and use windoze ftp cmd using open <host> 29

If I change back to port 21 in services as well as the rules above, I return to the same symptoms as before ... no login prompt

Why???? This is completely bizzare. hardcoded constant in one of the netfilter modules????

I can't ls / dir and now .. but its a step in the right direction. In vsftpd, i've got "connect_from_port_20=YES" so I would have thought I would have seen an outbound SYN packet requesting a connection to my ftp client using src port 20 when doing an ls / dir.

ideas?

Where are the Gurus????

I'm no guru, but I'm gonna offer up and observation or two:

You're locking down the source ports at the firewall, but you really don't know that the output traffic is originating from a specific port. For FTP, if you are in active mode, I believe that the server responds on specific ports (21 and 20) but if you are in passive mode, you don' know what ports besides 21 are being used.

Rather than lock down the output, for now I would just use a general OUTPUT statement:

iptables -A OUTPUT -o eth1 -p tcp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

The other observation is that I don't see where you have allowed/disallowed passive mode from the server. If passive mode is used, you need to lock down a port range for passive mode to use in your vsftpd.conf file and then open up that range in your firewall as well. In passive mode I believe that the incoming connection to ports are NEW, so you may have to abandon state matching for the passive port range.

Now the one bit I can't help with is how your box is routing the FTP traffic. I don't use linux as a router so I'm out of my depth, but you do need to be sure that the FTP traffic is getting directed to the right place. So that would include port 21 and and passive port range.

Hi. I'm far from an expert on iptables, but I have found a possible fix for this problem as it is the same problem I was having on my web server. I had the following line way down in the bottom of my iptables rules:

-A INPUT -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j DROP

If I comment it out, I can connect to the server. I found it just looking through the rules trying to make sense of everything. It was the only thing I saw dropping packets that aren't tied to a specific port. From the discussion above I got the impression that ACK is possibly a packet type that is important to the FTP session. The rule looks like it drops ACK packets irrespective of what port they arrive on. Perhaps you have something similar elsewhere in your rules which is dropping packets that you need.

Regards,
- SK