Troubleshooting FTP with pfSense
First off, FTP will only work on the primary WAN at this time, it will not fail over and will not load balance.
Outgoing FTP (LAN -> Internet) *UPDATED PORTS, please check!*
1. Ensure that the FTP helper is not disabled on Interfaces, LAN 2. If you have a restrictive ruleset or are utilizing policy based routing for multiple-wans then ensure that you have permitted traffic to 127.0.0.1 / ports 8000-8030. IE: allow LAN subnet to 127.0.0.1 8000-8030. This rule should be on top of all other LAN rules that utilize policy based routing. 3. If you are running windows try turning off the windows firewall 4. As a test, try with Snort disabled if you have it installed/running. Its preprocessor might be dropping what it believes to be a malformed/invalid command. Updating snort to a more recent version may also help. The proprocessor can drop packets even when snort is not set to block connections.
FTP and 1:1 NAT
Because of the way pf's binat (1:1 NAT) works, the FTP proxy is incompatible with 1:1 NAT for both client and server FTP. For server, you can work around this by configuring your FTP server so you don't need to rewrite the PASV line. See the documentation for your FTP server for information. Not all servers support this, vsftpd is known to work well with this kind of configuration.
For client FTP outbound from 1:1 hosts, the FTP proxy will not function. If your host requires outbound FTP using the FTP proxy, you need to use port forwards + Outbound NAT rather than 1:1 NAT.
This has been fixed in pfSense 2.0 with a PF improvement written by Ermal Luci, one of the pfSense developers.
Incoming FTP using Port Forwards (Internet -> LAN/OPT lan type interface ie. no gateway entered for the OPT interface)
1. Ensure that the FTP helper is enabled on the WAN/OPT interface 2. Delete any existing FTP port forwards or firewall rules that where created perviously for FTP 3. Add a new port forward for destination port 21 with the destination private NAT ip (example: 192.168.1.20) 4. If you are running windows try turning off the windows firewall 5. As a test, try with Snort disabled if you have it installed/running. Its preprocessor might be dropping what it believes to be a malformed/invalid command. Updating snort to a more recent version may also help. The proprocessor can drop packets even when snort is not set to block connections.
Alternatively for incoming FTP you can disable the FTP Helper on Interfaces -> WAN and simply port forward 21 and the data port range used by FTP. Generally this is definable on the FTP server (modern day implementations). You can easily restrict the data port range to a specific range and simply forward that.
Oh no, the above doesn't help. What can I do?
1. Use SCP/SFTP which only needs 1 port to traverse the firewall since its wrapped in SSH (yes a safe AND simple way of traversing a firewall!) 2. Don't use FTP 3. Turn off the FTP helper option in Interfaces -> LAN and Interfaces ->WAN or any optional interfaces in use. 4. Switch to an alternative firewalling system
