Do you have FTP conntrack helper enabled in /ip firewall service-port? If you do, it should recognize data connections as related and it should be enough for unencrypted FTP. But it will fail with encrypted connections, you would have to manually allow ports and properly configure clients to use them (that would be for active mode; for passive mode, you would have to allow all outgoing >1024).
Unfortunately, FTP is not firewall-friendly protocol at all, because in addition to primary (control) connection, it uses additional data connections for transfers (inluding directory listings) with completely random ports. It’s always either server connecting to client (active mode) or client connecting to server (passive mode) and depending on how strict filtering is on one side or other, there are always some opportunities for problems. As long as control connection is unencrypted and uses default port 21, things work fine in most cases, thanks to the helper scanning control connections for addresses and ports and doing all the magic. But add SSL (and you do want it, because plain transfers readable for anyone on the way are not very good) and the helper is out and you must add all exceptions manually.
Thank you for so “opened” answer. I was waiting for some magic ) for FTP, but, as you said, that magic is available only for unencrypted way.
Also, I think about a way, when
1 - client goes to 21 port
2 - MIK adds his IP to “list” in firewall for some time
3 - MIK accepts forwarding of “list” of IP’s
4 - after some time, MIK cleares IP “list”
Rule 1 will allow all communication to the ftp-remote address list from ether5. The second rule will catch the initial TCP port 21 connection, and add the dst address list to the ftp-remote address list for the specified timeout, 2 hours in this case.
One possible downfall to think about though is all it would take is someone port scanning an IP for port 21 to allow all communication to that IP address list for the timeout with or without an established connection. You could narrow down the 2nd rule to require an established connection, but that would have to be above your established/related rules.
You could narrow down the 2nd rule to require an established connection, but that would have to be above your established/related rules
established/related state of connection does not work with disabled FTP conntrack helper in /ip firewall service-port. I will test it tommorow, with enabled FTP helper.
You shouldn’t need the helper, you are just looking for an already established connection to port 21 for the first rule to match, meaning it’s completed the 3 way handshake. The helper is looking inside of that connection to see if there are any related connections to the first. It just needs to be above the “accept established” rules, and it should work. If it is not above that rule in order, then the packet will never be processed by that rule.
Is there NAT involved as well? If so, and if there’s also encryption, then active mode will never work because the FTP protocol sends the IP address and port number for the client’s data connection in-band in the control connection - if the control connection is encrypted, then the protocol helper cannot help. Normally, it inspects the contents of the control session, and when it sees the server send its private IP address for the data socket, the protocol helper modifies this in-band message. The src/dst addresses of the IP header aren’t used. Encrypted connections hide this information from the protocol helper so it cannot fix these messages.
Use sftp (ssh-based) instead of ftps… it only uses a single port.
Of course if this is just an anonymous ftp server and there is no sensitive data being transferred, then good old-fashioned FTP should be fine.
(I think FTP has existed for longer than TCP/IP, actually)
I know customers may want to do different things, but if your NAT configuration only allows certain things to work, then it’s unfortunate but what you want and what they want are incompatible.
Like Scotty said, “I canna change the laws of physics.”
