Hi All, I have been on this for some time, looked around a lot, tried a lot. It would be great if you have any ideas why this may be happening. I have a VPS with Debian 8, Apache, MySQL and ISPConfig3 installed on it. It also has pure-FTPD. My VPS has a Firewall. When I try to set up an FTP connection from my PC to my VPS via a FileZilla client, I am able to login, but then get the error message: Response: 227 Entering Passive Mode (xx,xx,xxx,xxx,67,134) Command: MLSD Error: The data connection could not be established: ETIMEDOUT - Connection attempt timed out 1- When I disable the VPS firewall, this error disappears and FTP operation is fine. But I do not want to disable VPS Firewall. 2- I have defined a PassivePortRange for Pure-FTPD via command line. It is 50100 till 51100. I have checked the configuration file /etc/pure-ftpd/PassivePortRange and confirmed that the file now has a record: 50100 51100 3- On te VPS firewall settings, I have added the port range of 50100:51100 to the list of open ports. I was not sure about if I should also add it to ISPConfig3 (is ISPConfic aware of VPS firewall and does it automatically sync the open port numbers?). To be sure, I have created a rule also on ISPConfig3 and added it at the end of the other default ports there. 4- Now when I try to connect from FileZilla client, as you can see above, I am getting 67, 134 in the Passive Mode response. That corresponds to the port 67x256 + 134 = 17286 and it is not in the range I specified in PassivePortRange. Obviously my firewall prevents the FTP connection and even I solve this PassivePortRange problem there could be some other port. BUT, I am stuck on this. Why does pure-ftpd do this? Why does it disregard the port range setting? I appreciate you help on this greately! Thanks in advance...
just to confirm, the ftp login and directory browsing, file uploading/downloading etc all works fine when the vps firewall is disabled? and this is irrespective of the firewall being configured and enabled in ispconfig? what is the vps firewall? is it actually running on the vps? or is it in front of the vps? from what you've said, the PassivePortRange is definitely configured properly for pure-ftpd, when you added those ports to the ispconfig rules, you added them as 50100:51100? what is/are the ip(s) of the interface on the vps? what is the public ip your connecting to for ftp? does /etc/pure-ftpd/conf/ForcePassiveIP exist? if yes, what is the contents of that file?
Thank you for your reply! My apologies for not answering immediately, as I wanted to be sure of the answers. I had listed the remote directory but had not tried any file transfer. And guess what, when I tried I was not even able to list directory even when VPS firewall is off. It took me a lot of time to sort it out. I remembered after a few tries that I had also created a rule via the ISPConfig3. When I deleted it, I was in business. -When firewall is disabled, I am able to list directory contents and perform file transfer remotely from my client Filezilla. -VPS Firewall runs outside my VPS but has access to my VPS' IPtables and uses them. So it does not run in VPS but in front of it. -I have added the ports to PassivePortRange with the following command: echo "50100 51100" > /etc/pure-ftpd/PassivePortRange and then I have restarted the FTP service via: service pure-ftpd-mysql restart I nano the /etc/pure-ftpd/PassivePortRange file and see the row: 50100 51100 Then I checked the /etc/pure-ftpd/conf directory, there is no ForcePassiveIP . IP of the VPS and that of the FTP client trying to reach is the same. As a matter of fact, I can login. It is just that I cannot list directory. It really bugs me, how come Pure-FTPd returns in the 227 message a different passive port range than it is configured for? Best Regards.
so, if I've got this right, the vps firewall is separate, but uses the vps iptables? does it set anything anywhere else other than in the iptables on the vps itself? if so, what else does it set? does it allow you to specify the source / destination ip's? if the rules apply to inbound or outbound traffic? so the ip you're connecting to is a public ip, set on the network interface on the vps itself? that you can connect and transfer files ok with the vps firewall off, suggests that ForcePassiveIP doesn't need to be set, unless when on, it's doing something with NAT, but I can't think of any obvious reason why it would need to. I would suggest just using ufw in ispconfig and setting the ports in the control panel. it applies them using iptables anyway, but i'm reluctant to because i'm not sure if that vps firewall is doing anything else as well. maybe run iptables -L and iptables -L -t nat with the vps firewall on, and then again with it off and check all the rules then, see if it's doing anything strange/unexpected.
It takes me long time to get answers and look for things... First of all I was very wrong when I said "VPS Firewall runs outside my VPS but has access to my VPS' IPtables and uses them". Yes the VPS Firewall does not run inside my VPS Host. But it does NOT use the Iptables rules set for my own VPS Host either. Sorry for the wrong information. VPS Firewall sets the rules for the hypervisor and it is another layer of protection on top of whatever I may have (in this case Iptables) in my own VPS Host. On the hypervisor level, I cannot see what IPtables rules are added based on my settings. On the VPS Host level, when I add the first row via the ISPConfig3 Firewall interface to open the port range 50100:51100 and then run on host command line iptables-save, I see that no rules are added to the NAT table. I see that some rules are added to the filter table (though the only thing i see there for pure-ftpd is a chain failt2ban-failftpd and it has no references, hence I guess it is not used). I still do not understand the behaviour of pure-ftpd trying to use a data port for passive port which is not in the defined range. I somehow feel, the problem in my system does not lie with the firewall, but rather with the pure-ftpd not behaving itself and returning a port which is not in the open port range. And I cannot open that port because it is not predictable - other than taking down the whole firewall!). Because of this reason, I can ftp only after disabling the firewall of te hosting provider ("VPS Firewall" on hypervisor level) and also delete the firewall row on ISPConfig3 (which I guess opens all the ports of my in-VPS firewall iptables).
ok, firstly you've used term vps host to refer to both the hypervisor machine and the vps you're trying to ftp into, it gets a little confusing trying to keep track of what's going on where. i'd suggest using the term 'host' to refer to anything that's actually running/configured/logged on the hypervisor, and the term 'guest' for anything about the vps running ispconfig. what OS is running on the host? what hypervisor are you using on the host? what vps firewall is running on the host? is the guest's public ip configured directly in the guest? or in the host/hypervisor. this is confusing me, this is on the guest vps? you're setting ports in the ispconfig control panel, and running iptables-save? for what purpose? ispconfig can manage and apply the rules, as far as i'm aware, iptables-save will make no difference unless you also install iptables-persistent. have you got any iptables rules being configured on there outside of ispconfig? at the moment, when it can't make a data channel connection and uses one of these ports outside the specified range, i'm just not entirely convinced that it's actually getting that port number from pure-ftpd, i'm not sure if there's some NAT going on somewhere getting in the way and the port number may be coming from that, in which case you may well need to configure ForcePassiveIP, probably to the public ip of the host. answers about the os/hypervisor/firewall questions about will hopefully be enough to work out if one of those relies on nat. I guess for now let's concentrate on the basics, simplest things to check. on the guest, in the ispconfig control panel - system - server config - <guestserver> what firewall option is selected, bastille or ufw? I believe ufw is the preferred option these days, so if it's bastille, it may be worth changing that. make sure the firewall rule exists for this server, and include all the required ports in that rule. once the rule has been applied, and the little job queue icon disappears, from the guest cli run : ufw status you should see output like this: Code: Status: active To Action From -- ------ ---- 20/tcp ALLOW Anywhere 21/tcp ALLOW Anywhere 22/tcp ALLOW Anywhere 25/tcp ALLOW Anywhere 53/tcp ALLOW Anywhere 80/tcp ALLOW Anywhere 110/tcp ALLOW Anywhere 143/tcp ALLOW Anywhere 443/tcp ALLOW Anywhere 587/tcp ALLOW Anywhere 993/tcp ALLOW Anywhere 995/tcp ALLOW Anywhere 2812/tcp ALLOW Anywhere 3306/tcp ALLOW Anywhere 8080/tcp ALLOW Anywhere 8081/tcp ALLOW Anywhere 10000/tcp ALLOW Anywhere 62000:62200/tcp ALLOW Anywhere 11211/tcp ALLOW Anywhere 53/udp ALLOW Anywhere 3306/udp ALLOW Anywhere 20/tcp (v6) ALLOW Anywhere (v6) 21/tcp (v6) ALLOW Anywhere (v6) 22/tcp (v6) ALLOW Anywhere (v6) 25/tcp (v6) ALLOW Anywhere (v6) 53/tcp (v6) ALLOW Anywhere (v6) 80/tcp (v6) ALLOW Anywhere (v6) 110/tcp (v6) ALLOW Anywhere (v6) 143/tcp (v6) ALLOW Anywhere (v6) 443/tcp (v6) ALLOW Anywhere (v6) 587/tcp (v6) ALLOW Anywhere (v6) 993/tcp (v6) ALLOW Anywhere (v6) 995/tcp (v6) ALLOW Anywhere (v6) 2812/tcp (v6) ALLOW Anywhere (v6) 3306/tcp (v6) ALLOW Anywhere (v6) 8080/tcp (v6) ALLOW Anywhere (v6) 8081/tcp (v6) ALLOW Anywhere (v6) 10000/tcp (v6) ALLOW Anywhere (v6) 62000:62200/tcp (v6) ALLOW Anywhere (v6) 11211/tcp (v6) ALLOW Anywhere (v6) 53/udp (v6) ALLOW Anywhere (v6) 3306/udp (v6) ALLOW Anywhere (v6) don't worry if you don't see all those ports numbers, it depends on what services you need running. what's important is you see entries for 21/tcp ALLOW Anywhere 50100:51100/tcp ALLOW Anywhere and if ipv6 is enabled: 21/tcp(v6) ALLOW Anywhere(v6) 50100:51100/tcp(v6) ALLOW Anywhere(v6) if you see these, the guest firewall is working ok and the correct ports are configured. anyway, that's probably enough to go through for now, this post is already way longer than I originally expected.
