Hi,

I have the following rules established:

[root@li7-87 erikg]# /sbin/iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- localhost.localdomain anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT udp -- anywhere anywhere udp dpt:auth
ACCEPT tcp -- anywhere anywhere tcp dpt:auth
ACCEPT udp -- anywhere anywhere udp dpt:ftp state RELATED,ESTABLISHED
LOG icmp -- anywhere anywhere LOG level warning
DROP icmp -- anywhere anywhere
DROP all -- anywhere anywhere




Now I'm trying to allow FTP but for some reason it doesn't get thru. What am I doing wrong?


Erik

Well, it pretty much isn't that weird
As far as i see in that listing the ftp port (21) is only allowed if
- its udp ... the ftp protocol is on tcp
- the connection is either already established or was innitiated from your part

Now, if you don't have some really really weird marking and pre/postrouting rules in the nat table, then you first need to delete that rule about ftp on udp. Do a listing with line numbers to see the rule's number:

# iptables -L --line-numbers

Then delete the rule by specifieng the rule number:

# iptables -D INPUT <rule's number from above listing>

Be careful what rule you delete . Check again by doing an "iptables -L" to see if you deleted the desired one.

Then add a rule that alows incoming connections on tcp port 21 on all interfaces:

# iptables -A INPUT -p tcp --dport 21 -j ACCEPT

Hope this helped,
Cheers

I made the required changes, but FTP connections are still denied. Help!


Erik

_________________
Acid-Duck@IRC [EFNet]
erik.godin At n0sp4m.sympatico.ca

If you still have the ESTABLISHED RELATED flags set on the ftp line then get rid of them. Obviously the initial ftp connection won't be established and so won't match the rule

_________________
Rgds
Stephen
(Linux user since kernel version 0.11)

Hi,

thanks for your response. Since an FTP session can have multiple connections for one user, I do believe that the related flag isn't needed. Second, the established flag lets the connection come in since my last rule of the INPUT chain is a catch all drop all.

What I was doing wrong was that I had the idea that since the rule ended with -j ACCEPT , the connection would be allowed. I didn't realized that -m state --state controlled the access completely, as opposed to being a kind of "addon".


Erik

_________________
Acid-Duck@IRC [EFNet]

erik.godin At n0sp4m.sympatico.ca

From the man page:

       --state state
              Where state is a comma separated list of  the  con-
              nection  states  to  match.   Possible  states  are
              INVALID meaning that the packet is associated  with
              no  known  connection, ESTABLISHED meaning that the
              packet is associated with a  connection  which  has
              seen  packets  in both directions, NEW meaning that
              the packet has started a new connection, or  other-
              wise  associated  with  a  connection which has not
              seen packets in both directions, and RELATED  mean-
              ing  that  the packet is starting a new connection,
              but is associated with an existing connection, such
              as an FTP data transfer, or an ICMP error.

Note that this means ESTABLISHED will only kick in after the connection has been made (ie after SYNa and SYNb packets have been exchanged). New incoming connections will not match this because there has been no outgoing packet..

_________________
Rgds

Stephen

(Linux user since kernel version 0.11)

i missed your last line with drop all ... obviosuly my "iptables -A INPUT" would append the rule to the end, after the drop one so it would be kindly ignored

you should use something like:

# iptables -I INPUT 4 -p tcp --dport 21 -j ACCEPT

4 = the position to insert the rule (use anything smaller than the drop all rule)

no need for established or related states if you want to accept incoming connections (externally initiated)

I didn't know you could tell where to insert the rule in the chain (well I just never noticed it reading the --help I guess) anyways that's gonna make my life much easier now I won't have to flush my rules and re-add them everytime something is modified/added.

_________________
Acid-Duck@IRC [EFNet]

erik.godin At n0sp4m.sympatico.ca

usually "man <command>" yields more info than "<command> --help"