Maybe you could install nmap on your windows PC and do some port scans.
I assume you have opened the ports in the firewall on your server.
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 second screenshot is of the traffic the workstation sees when the router is running the stock Linksys firmware:
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?
1 Like
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...
2 Likes
Really?
2 Likes
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.
1 Like
Thanks. I'll see if that resolves the problem.
1 Like
Make sure you refresh the package list on LuCI, you should then be able to search for uninstalled packages.
1 Like
Got it. I could have sworn I updated the package list, but I guess not. Anyhow, thanks for the tip, it worked this time.
Cheers,
Ron
If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
1 Like
Hi T.
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.
Cheers,
Ron
fwiw, I've been running an old Tomato router as an FTP server, wired to LAN port of Chaos Calmer and currently LEDE 17.01 routers. Port forward rule for port 21 is defined. It all works fine for past few years.
Today, I replicated the setup from my main LEDE router to a spare router, but configured WAN port with a static IP address. Then connected a FTP client to the WAN port.
FTP client and server works fine through LEDE router.
With LEDE, I had to specifically define the range of dynamic ports on the FTP server and set up corresponding port forwarding rules on the router. kmod-nf-nathelper (or kmod-nf-nathelper-extra) also had to be installed.
I then upgraded it to OpenWrt 18.06.4 (I also tried 18.06.2). After installing kmod-nf-nathelper (or kmod-nf-nathelper-extra), I encounter this error when using Filezilla FTP client from WAN side:
Without kmod-nf-nathelper* installed, I see the following which looks less promising than above error.
It's been suggested to also install kmod-ipt-raw package. Unfortunately, I see the same error message as above with this package installed too.
Looks like I can log into the FTP server, but cannot proceed any further. Looks similar to your wireshark logs?
I'm no expert but the above logs looks like yours and my FTP servers are returning LAN IP address (eg. 192.168.1.205) to the external FTP client, which is why it is failing.
I reverted back to LEDE 17.01.6 and it works fine.
Firewall rules
I also added this rule but it made no improvement.
With LEDE 17.01.6, filezilla client connects successfully (image is from may main router)
Update: I've googled two vsftpd settings which may help 'work around' the issue:
pasv_address
pasv_addr_resolve
If I use the pasv_address to hard code the WAN IP address of the OpenWrt 18 test router, I can successfully access the FTP server from a client on the WAN side. But I then had issues accessing the FTP server from LAN side caused by differing port number - this may be solvable.
I couldn't get pasv_addr_resolve to work when 'briefly' tested which allows use of host names in my 'test' environment, but it does seem to work in live environment with LEDE 17 router.
Repeated above tests using a spare laptop configured with Filezilla FTP server in passive FTP mode with same results as reported above.
Similarly, upgrading the test router to OpenWrt 19.07-snapshot and installing kmod-nf-nathelper and kmod-ipt-raw yielded same results in brief testing.
You’re running into an inherent flaw in the FTP protocol for today’s Internet. FTP goes back to the days that you could get a Class C block with a dial-up account. No NAT, so the control/data-channel worked back then. Passive mode was a later introduced for stateful firewalls and used as a hack for user-managed, single NAT.
That you’ve got the same server on two interfaces that might present different IP addresses to different clients is a core challenge. Two ways you could help that part include:
- Use IPv6 exclusively
- Run one instance of the FTP server bound to each interface explicitly, each with knowledge of what IP gets presented to clients
There might be some packet-inspection hack to rewrite the address in the packet contents, but that obviously won’t work on a encrypted channel.
1 Like