As suggested by @meuh in a comment, I had a look at the documentation hosted at https://home.regit.org/netfilter-en/secure-use-of-helpers/.
The paragraph "Using the CT target to refine security" explains:
One classic problem with helpers is the fact that helpers listen on predefined ports. If a service does not run on standard port, it is necessary to declare it. Before 2.6.34, the only method to do so was to use a module option. This was resulting in having a systematic parsing of the added port by the chosen helper. This was clearly suboptimal and the CT target has been introduced in 2.6.34. It allows to specify what helper to use for a specific flow. For example, let’s say we have a FTP server on IP address 22.214.171.124 running on port 2121.
To declare it, we can simply do
iptables -A PREROUTING -t raw -p tcp --dport 2121 \\ -d 126.96.36.199 -j CT --helper ftp
It's not my case (since I'm using a regular port 21 for it) but still it seems to work if one wants to enable the ftp helper for inbound connections.
iptables -A PREROUTING -p tcp -m tcp --dport 21 -j CT --helper ftp
My (working) configuration is now:
# Generated by iptables-save v1.4.21 on Sat Aug 12 17:39:53 2017 *raw :PREROUTING ACCEPT [445:37346] :OUTPUT ACCEPT [375:44051] -A PREROUTING -p tcp -m tcp --dport 21 -j CT --helper ftp COMMIT # Completed on Sat Aug 12 17:39:53 2017 # Generated by iptables-save v1.4.21 on Sat Aug 12 17:39:53 2017 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [169:17775] -A INPUT -p tcp -m tcp --dport 21 -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -j DROP COMMIT # Completed on Sat Aug 12 17:39:53 2017
It is probably interesting to notice how the document suggests to be wary of this kind of configuration, since the behaviour of the firewall depends on the user input.
I'm wondering if there are risks by facing a FTP server on the Open Internet in this way. In general FTP is known not to be the best protocol in terms of security, anyway…