Thank you for reading the article that Attie pointed to. It sounds like you may just need a bit more explanation. I've found OpenBSD's firewall guide, section on "Issues with FTP" to be informative. However, I will try to summarize the issue here.
When software communicates using the Internet Protocols (IPv4 or IPv6), the "IP protocol" (which I am using as a generic term, applying equally to IPv6 and IPv4) includes a destination IP address. When you use some protocols like TCP (which FTP does), UDP (which DNS does), SCTP, you also have a "port number" which is part of the reason we use the term "port forwarding". (Some protocols don't use a "port number". For instance, ICMP uses IP, and has "Message Types", but not "port numbers".)
Most software will provide IP address information to the local computer's TCP/IP networking components, and only provide the remote computer with "payload" (which is whatever other information that the remote computer needs to receive). For instance, with HTTP, your web browser tells your local TCP/IP network stack to open a connection to an IP address, and your web browser tells the remote system what file it wants to receive. Your web browser doesn't announce your IP address. That detail is handled by the TCP/IP networking components.
FTP is different from most software.
FTP actually includes the IP address in its payload. So, in addition to providing the IP address as part of the standard IP packet, part of the FTP conversation mentions what IP address to use. Standard "port forwarding" just modifies the standard location for an IP address, and doesn't modify the FTP conversation.
FTP is a very old protocol, written during the era when universities and major corporations made the network as a research project. Internet defenses like firewalls didn't exist, and weren't needed, at the time. So, the problem that FTP provides was not an issue of poor authorship. The problem is just that FTP was just designed for a different style of network.
This problem is something that can be worked around three different ways:
- You could try using "passive" FTP. This can work with an FTP server that is behind a firewall (but the burden is shifted: the FTP client needs to not be behind a firewall... so often this scenario doesn't work well either). If this fix is possible (which requires that the FTP client software supports this feature), this can be the fastest fix (changing a setting in the FTP client software), but could be easy or difficult depending on what FTP client software is used.
- many routers have support for an option called "ftp proxy" which will modify the FTP conversation, effectively fixing this problem for you. Find and enable such an option (if it exists)
- use a different protocol that doesn't have the same problem
FTP is kind of unique. Most popular protocols today don't have the same problem, and won't, because firewalls do exist now and so people are aware of the problem. (If someone wrote a new protocol and that person was unaware of the problem, they would probably be made aware of the problem before the protocol gets to be very popular.) However, FTP was the best solution at one point in time, and people were reluctant to use other solutions. One key reason for this may be that a lot of people had FTP software, including popular web browsers that supported FTP.
Nowadays, there are available solutions better than FTP. Use the "SSH File Transfer Protocol" (one of the protocols called "SFTP"), or SCP, or HTTPS. Any of these don't require special proxies to run on the firewalls. For solutions that need to be easily available for multiple customers, HTTPS can do the trick. (There may even be other options, like FTPS, but I recommend the prior protocols I just mentioned.)
So, the final bullet point is recommended, but if you feel like you can't do that for some reason, you could try the first or second bullet points (each of which might be a faster, though inferior, fix to the problem you're dealing with).