I'm having a problem with ftp getting through the firewall from a Windows based system.
My server is a HP DL380 running CentOS 7 and vsftpd. vsftpd is set to run passive mode by default and is set to use ports 10100 to 10199 as the random port range. The router is a Linksys E4200V2. I've opened ports 20, 21, 10100 to 10199 (along with a bunch of others - mail, ssh, http/s, etc.) All the other ports work fine, but I can't get ftp to work - it doesn't appear that any ftp traffic is getting through to the server and the client fails with a "no response from server" error.
I had seen another message that indicated installing kmod-nf-nathelper would work, but that package doesn't appear in either the list of available or installed packages.
Another message indicated that nf-conntrack-ftp used to be installed but was no longer included in the most recent kernel versions.
I want to forward packets to various machines behind the router depending on the port number, but the majority (including the ftp traffic) would be going to the DL380 which has its own firewall running. Is it possible to set the specified ports to route to the appropriate machine and then as the last rule forward all packets to the DL380 and let that machine's firewall take care of the rest? Would this solve my ftp problem, and would it open me up to other security risks (other than the ones inherent in having the DL380 exposed to the world)?
Your FTP Server is inside your LAN zone, or outside?
For Outside, you should install kmod-ipt-raw together with kmod-nf-nathelper (update your package list, to find it).
When you want to share your internal ftp-server to the internet, it is the best way, when you define fixed passv ports on your ftp and forward them from external to your internal ftp server + port 20-21.
Or at least, when your ftp is on top of your router, is should be not such a big problem. Also follow the same rule for fixed passv ports and open the ports on your router.
Hi Thomas! Thanks for the reply. The FTP server is running inside the LAN but (and I can't believe I didn't mention this in the original host) is running on a KVM guest machine running CentOS 7 on a CentOS 6.9 host. Of course, this complicates things somewhat. I've got wireshark running on the Windows box and I can see the appropriate FTP commands going out. I'm trying to set up Wireshark on the VM to see if the VM sees the traffic incoming. I suspect I'll also need to set up Wireshark on the host as well, but haven't got there yet. I'll post more as I get closer to a solution.
Cheers,
R.
Hi tunk. Ports are opened as required, but see my reply to ThomasCr for more important details. I'm still working on the problem and will post more as I get closer to a solution.
Thanks and cheers,
R.
Hi all,
Further to my earlier post, I've determined that the problem lies within OpenWrt. I've installed Wireshark on both the server and the workstation, and the workstation capture illustrates the problem. I've included two screenshots of the relevant Wireshark captures. The first screenshot (below) is of the traffic the workstation sees when the router is running OpenWrt 18.06.4:
The relevant IP addresses are:
24.143.186.10 - the public IP address of the ftp server
192.168.2.4 - the internal IP address of the ftp server
24.143.186.11 - the public IP address of the workstation
192.168.2.43 - the private IP address of the workstation
Just to note: even though the private IP addresses nominally belong to the same /24 address range, they're on completely separate networks, behind physically distinct routers that are themselves attached to the ISP router that supplies the public facing IP addresses (which are 1 bit different).
This test setup is testing a passive ftp transfer with ports 10100 to 10199 set up as the random high number port range that vsftpd is allocated.
The thing to note here is that OpenWrt doesn't do the NAT on the IP address that's sent back as part of the 227 reply to the PASV command. Instead it returns the private local address of the server.
Contrast this with the Linksys firmware which does do the NAT on the 227 reply's IP address. It correctly returns the public facing IP in the reply message.
I'm pretty sure this should be considered a bug in OpenWrt, but I'm open to counter-arguments. I also don't know how to file a bug report with OpenWrt, so if anyone could point me in the right direction on that score I'd be grateful.
Cheers,
R.
Hi V.
The fact that OpenWrt can't do passive ftp "out of the box" when the appropriate port forwarding is applied via the LuCl interface strikes me as a bug, and a pretty serious one at that. You're quite correct that I could dive into /etc/config/firewall, but maybe some others aren't quite that knowledgeable just yet. On the other hand, I could just use the stock Linksys firmware...
The FTP protocol on the modern internet is virtually obsolete, you shouldn't expect it to waste free space in the default OpenWrt build.
If you understand the tcpdump output, there should be no problem reading the iptables dump and the firewall service documentation.
What is the current status of your issue?
Hi V.
It's still unresolved at the moment. I've had to shift gears to resolve a completely unrelated client issue, and that will take a while. I'll get back to it in a couple of days.
Cheers,
R.
Hi Bill,
Did the same thing - opened ports 10100-10199 in OpenWrt and in vsftpd, but OpenWrt can't NAT the address that's part of the reply to the PASV command.
Cheers,
R.
BTW, why would you think that drop_invalid would have anything at all to do with the issue I described? It's a NAT issue. No packets need to be dropped. The packets that are incorrect (the server's replies to the PASV commands that indicate the appropriate port the server is listening on) simply need to be NATted correctly. Also, I don't see anything relating to kmod-nf-nathelper in downloads.openwrt.org. Unless you have a more specific location in mind...
Ahhh. Thank you. I was looking at the packages listed in the LuCI interface under Software, and didn't think to check the openwrt.org site itself. My bad. Thanks for the pointer.
It's not solved yet, but I've put it on the back burner for the moment - other unrelated issues are sucking up most of the oxygen in the room. I've reverted to a backup router running the stock Linksys firmware that handles ftp traffic well. For what it's worth, installing the ftp-helper package didn't make a difference. I'll post more when I get a chance to get back to this issue.
