When attempting to set up an FTP server for passive mode, I’m running into a really weird problem: The control connection is successfully established, but the data transfer is choking.
As for the setup of SuSEfirewall2, the following conditions are met:
FW_DEV_EXT=“eth0”
FW_SERVICES_EXT_TCP=“ftp”
FW_SERVICES_ACCEPT_RELATED_EXT=“0.0.0.0/0,tcp,40000:40100 ::/0,tcp,40000:40100”
FW_LOAD_MODULES=“nf_conntrack_ftp”
nf_conntrack_ftp is loaded (that’s what I have double-checked first), and PASV is enabled in vsftpd. Connecting to the FTP server correctly establishes the FTP session, but when attempting to do any data transfer, the data connection is blocked by the firewall (verified with nmap while the FTP control connection was still up - the port was shown to be closed).
As another test, I moved the entire thing to the variable FW_SERVICES_ACCEPT_EXT, and with the ephemeral ports unconditionally opened, the passive data transfer worked (active transfer isn’t viable, because that would require some major tinkering with the entire local infrastructure).
Now, all this leads me to wonder if something is wrong with nf_conntrack_ftp, because the exact same setup has worked just fine on a 3.x kernel.
My current specs server-side:
kernel-default-4.11.8-2.2
xen-4.9.0_08-3.1
vsftpd-3.0.3-10.2
[FONT=arial]SuSEfirewall2-3.6.360-1.1
I can only offer limited advice here (my experience with ftp is limited to using it as a client). If you remove the port ranges does the connection then work as expected?
For a better picture, can you also please provide the pasv_max_port, pasv_min_port settings from vsftp.conf (ie ensure they are consistent with the port range you posted)?
… “looks like with kernel 4.7 you need “net.netfilter.nf_conntrack_helper =
1” in sysctl.conf to continue things like PASV FTP or Hylafax (which uses FTP as
procotocol) working like before” …
AK
–
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)
> https://bugzilla.redhat.com/show_bug.cgi?id=1369489
>
>
> … “looks like with kernel 4.7 you need “net.netfilter.nf_conntrack_helper =
> 1” in sysctl.conf to continue things like PASV FTP or Hylafax (which uses FTP
> as procotocol) working like before” …
>
> AK
>
*[FONT=arial]pasv_min_port=40000
pasv_max_port=40100
*
Made a mistake when reproducing FW_SERVICES_ACCEPT_RELATED_EXT, because in contrast to FW_SERVICES_ACCEPT_EXT it uses inverse logic concerning the ports, but correcting that gave the same result.
[/FONT]When setting up firewall rules, I adjust them to the service that I wish to provide so both definitions are matching here.
Plus when checking with iptables -n -L | grep RELATED, the rule in question (IPv4) is displayed as
ACCEPT tcp – 0.0.0.0/0 0.0.0.0/0 tcp dpts:40000:40100 ctstate **RELATED
**
So this isn’t a problem, either. However, the rule just doesn’t seem to be hit, causing the data transfer to fail.
Although I also may have some custom rules set, commenting those out didn’t help, either.
Another interesting thing, though, when attempting to access the FTP server with a CLI client is that it complains that the destination address were already in use - something that is definitely not true since the access attempt shows up in the firewall logs.
The most interesting part, however, is this error message provided by the FTP client:
229 Entering Extended Passive Mode (|||40051|)
ftp: Can't connect to `81.169.175.87:40051': Connection refused
500 Illegal PORT command.
ftp: Can't bind for data connection: Address already in use
The corresponding entry in the firewall log is this one:
In case you wish to double-check things, just try to connect to ftp.robidu.de and do an anon login - then try to do anything. I’d be curious about the results…
I can’t seem to get a passive connection… am I missing something?
~> ftp -p ftp.robidu.de
Trying 81.169.175.87:21 ...
Connected to ftp.robidu.de.
220 "robidu.de FTP service"
Name (ftp.robidu.de:dean):
530 This FTP server is anonymous only.
ftp: Login failed
ftp> dir
530 Please login with USER and PASS.
Passive mode refused.
ftp> exit
221 Goodbye.
~> ftp ftp.robidu.de
Trying 81.169.175.87:21 ...
Connected to ftp.robidu.de.
220 "robidu.de FTP service"
Name (ftp.robidu.de:dean):
530 This FTP server is anonymous only.
ftp: Login failed
ftp> passive
Passive mode: off; fallback to active mode: off.
ftp> exit
221 Goodbye.
Made a mistake when reproducing FW_SERVICES_ACCEPT_RELATED_EXT, because in contrast to FW_SERVICES_ACCEPT_EXT it uses inverse logic concerning the ports, but correcting that gave the same result.
When setting up firewall rules, I adjust them to the service that I wish to provide so both definitions are matching here.
Plus when checking with iptables -n -L | grep RELATED, the rule in question (IPv4) is displayed as
ACCEPT tcp – 0.0.0.0/0 0.0.0.0/0 tcp dpts:40000:40100 ctstate RELATED
So this isn’t a problem, either. However, the rule just doesn’t seem to be hit, causing the data transfer to fail.
Although I also may have some custom rules set, commenting those out didn’t help, either.
~> ftp ftp.robidu.de
Trying 81.169.175.87:21 ...
Connected to ftp.robidu.de.
220 "robidu.de FTP service"
Name (ftp.robidu.de:dean): ftp
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> dir
229 Entering Extended Passive Mode (|||40056|)
ftp: Can't connect to `81.169.175.87:40056': Connection refused
200 EPRT command successful. Consider using EPSV.
150 Here comes the directory listing.
drwxr-xr-x 7 ftp ftp 4096 Aug 09 2015 pub
226 Directory send OK.
ftp> close
221 Goodbye.
ftp> quit
The box that you have tried that from, does it have a firewall enabled or not?
I have done some additional tests on a box that is linked directly to the Internet and protected by a firewall, and although that gave me a slightly different result, it still was a failure:
229 Entering Extended Passive Mode (|||40078|)
ftp: Can't connect to `81.169.175.87:40078': Connection refused
200 EPRT command successful. Consider using EPSV.
425 Failed to establish connection.
However, when I disabled SuSEfirewall2 at the client side, everything suddenly started working. boggle
On the client side I’m not even doing NAT or the likes…
It looks as if the firewall on the client side is actually interfering.