We use Filezilla to manage our website hosting. The webhosting uses FTP over TLS. (see attachement)
I can't get FTP over TLS working on our internal network. I have the following allow rule in our network ( see attachement.
Does it mean I have to setup FTP proxy, as described here: https://forum.opnsense.org/index.php?topic=3868.0 (https://forum.opnsense.org/index.php?topic=3868.0)
Can you try in passive mode? Also try a packet capture on the firewall or the client to confirm that the transfer is using the ports that you think it should be using.
Bart...
Bartjsmit how do you start a pacture capture on the firewall? I am using "Firewall"->"Log files" -> "Live View", but I don't get any blocked packages.
Interfaces, Diagnostics, Packet Capture. You can save the file and comb through it with Wireshark (other packet trace analysers are available).
Bart...
FTPS will probably never work (unless the FTP proxy can intercept like squid) because the port is transferred encrypted so OPNsense cannot add the DNAT rule dynamically.
Fabian, thanks for your response.
So, what is then the most convenient way to let SFTP trough the firewall?
sftp is over SSH, which is easy: TCP/22. The problem is FTPS ("normal" FTP over TLS) which is using a variant of start TLS which is not supported by the standard FTP proxy. Maybe there is another proxy out there, which does support it but this must be compatible with FreeBSD.
Active FTP: Client connects to the server, decides on a port to use for the data channel (your log is showing the command-side channel) and connects.
Passive FTP: Client connects to the server, server tells it "my public IP is XYZ, use port ABC", your client connects to this for its data channel. This is where everything falls apart in your setup, see below.
That being said: The only way to "easily" punch through a NAT is setting up the FTP server for explicit FTP over TLS (there isn't any other way to use FTP, I don't care what the RFCs say) with a limited port range for the data channel (EDIT:) in passive mode. Your server will need to answer with its "true" public IP, and a limited port range that is port forwarded to it. Accessing it from the internal network is a matter of correctly doing the translation (handled by OPNSense,shouldn't be an issue, at least wasn't in my tests).