1

Below are rules for allowing passive FTP that are not working.

/proc/sys/net/netfilter/nf_conntrack_helper is set to 1

The nf_conntrack_ftp module is loaded.

What could be blocking it? Do I really need the counter? Do I really need the tcp dport 1024-65535 line if I already am allowing established related connections with the ct state established,related accept line?

table inet myhelpers {
        ct helper ftp-standard {
                type "ftp" protocol tcp
        }
    chain input {
                type filter hook prerouting priority 0;
                tcp dport 21 ct helper set "ftp-standard"
        }
}
table inet filter {
        chain input {
                type filter hook input priority 0; policy drop;


                ct state established,related accept

                # passive FTP
                tcp dport 21 ct state established,new counter accept
                tcp dport 20 ct state established,related counter accept
                tcp dport 1024-65535 ct state established,related counter accept

        }
}

mauricev
  • 41
  • 2
  • 4
  • Using your rules verbatim, it works here. There are at least two useless things: rules for incoming ftp port 20 are useless for a ftp server (hint: port 20 is not listening and is *outgoing* from port 20 in active mode and not used at all in passive mode) 2: you don't need to set /proc/sys/net/netfilter/nf_conntrack_helper to 1 since you're already using ct helper set. Anyway there's something else. Do you have kernel >= 4.12? do you have other rules? perhaps iptables rules in addition to nftables? or there's an external firewall firewall or NAT router between the client and the server? – A.B Mar 16 '19 at 21:22

1 Answers1

0

Thanks for your answer, A.B. You are right. There is something else. I was testing FTP with TLS and in TLS, the control connection is encrypted, so the firewall can't know what passive port the server is offering up. I have to specify that. Once I did that, it started working.

mauricev
  • 41
  • 2
  • 4