It is important to understand the basics of the FTP protocol in order to configure FileZilla/FileZilla Pro, firewalls and routers. Setting up the network components for FTP outside a local area network (LAN) might be non trivial.
Read below to learn more.
What distinguishes FTP from most other protocols is the use of secondary connections for file transfers.
When you connect to an FTP server, you are actually making two connections.
First, the control connection is established, over which FTP commands and their replies are transferred.
Then, in order to transfer a file or a directory listing, the client sends a particular command over the control connection to establish the data connection.
The data connection can be established in two different ways, using active mode or passive mode.
In passive mode, which is the recommended, FileZilla/FileZilla Pro sends the PASV command to the server, and the server responds with an address. FileZilla Pro then issues a command to transfer a file or to get a directory listing, and establishes a secondary connection to the address returned by the server.
In active mode, FileZilla/FileZilla Pro opens a socket on the local machine and tells its address to the server using the PORT command. Once FileZilla Pro issues a command to transfer a file or listing, the server will connect to the provided address. In both cases, the required file or listing gets transferred over the data connection.
Generally, establishing outgoing connections requires little or no configuration of the involved routers/firewalls compared to allowing incoming connections.
In passive mode, the connection is outgoing on the client side and incoming on the server side.
In active mode this is reversed. Note that the only difference is how the connection gets established.
Once established, the connection can be used both for uploads or downloads.
A common network setup might look like this:
In passive mode, the involved routers and firewalls on the server side need to be configured to accept and forward incoming connections. On the client side, however, only outgoing connections need to be allowed (which will be the case most of the times).
Analogously, in active mode, the router and firewall on the client side need to be configured to accept and forward incoming connections. Only outgoing connections have to be allowed on the server side.
Since in most cases one server provides a service for many users, it is much easier to use the passive mode and configure the router and firewall only once than use the active mode and configure the client’s router/firewall for each individual client. Therefore, passive mode is recommended in most cases.
Most broadband users will have a NAT (Network Address Translation) router between their computer and the internet. This may be a standalone router device (perhaps a wireless router), or be built into a DSL or cable modem.
In a NAT environment, all systems behind the NAT router form a Local Area Network (LAN), and each system in the LAN has a local IP address (recognizable as four small numbers separated by dots).
The NAT router itself has a local IP address as well.
In addition, the NAT router also has an external IP address by which it is known to the Internet.
For example a system might look like this:
The internal IP addresses are only valid inside the LAN. Think about a server behind a NAT router.
Imagine what might happen if a client requests passive mode, but the server doesn’t know the external IP address of the NAT router.
If the server sends its internal address to the client, two things could happen:
- If the client is not behind a NAT, the client would abort since the address is invalid.
- If the client is behind a NAT, the address given by the server might be the same as a system in the client’s own LAN.
In both cases passive mode would be impossible.
So if a server is behind a NAT router, it needs to know the external IP address of the router in passive mode.
In this case, the server sends the router’s external address to the client.
The client then establishes a connection to the NAT router, which in turn routes the connection to the server.
Some routers and firewalls analyze connections and, if they think they detect FTP, they silently change the data exchanged between client and server. If the user has not explicitly enabled this feature, this behavior can cause various problems.
For an example, imagine a client behind a NAT router trying to connect to the server. Let’s further assume that this client does not know it is behind a NAT and wants to use active mode. So it sends the PORT command with the user’s local, un-routable IP address to the server:
This command tells the server to connect to the address 10.0.0.1 on port 12*256+34 =3106
The NAT router sees this and silently changes the command to include the external IP address.
At the same time, the NAT router will also create a temporary port forwarding for the FTP session, possibly on a different port even:
The above command tells the server to connect to the address 220.127.116.11 on port 24*256+55 = 6199
With this behavior, a NAT router allows an improperly configured client to use active mode.
So why is this behavior bad? Essentially, it can cause a number of problems if it is enabled by default, without explicit user consent. The FTP connections in their most basic form appear to work, but as soon as there’s some deviation from the basic case, everything will fail:
- The NAT router blindly assumes some connection uses FTP based on criteria like target ports or the initial server response:
- The used protocol is detected as FTP, yet there is no guarantee that this is true (a false positive). Though unlikely, it is conceivable that a future revision of the FTP protocol might change the syntax of the PORT command. A NAT router modifying the PORT command would then silently change things it does not support and thus break the connection.
- The router’s protocol detection can fail to recognize an FTP connection (a false negative). Say the router only looks at the target port, and if it is 21, it detects it as FTP. As such, active mode connections with an improperly configured client to servers running on port 21 will work, but connections to other servers on non-standard ports will fail.
- Obviously, a NAT router can no longer tamper with the connection as soon as an encrypted FTP session is used, again leaving the user clueless why it works for normal FTP but not for encrypted FTP.
- Say a client behind a NAT router sends
PORT 10,0,0,1,12,34. How does the NAT router know the client is improperly configured? It is also possible that the client is properly configured, yet merely wants to initiate an FXP (server-to-server) transfer between the server it is connected to and another machine in the server’s own local network.
Therefore, having protocol specific features enabled in a NAT router by default can create significant problems. The solution to all this, then, is to know your router’s settings, and to know the configuration abilities of a router before you set it up. A good NAT router should always be fully protocol-agnostic. The exception is if you as the user have explicitly enabled this feature, knowing all its consequences.
While this section only discussed the combination of a NAT router on the client side with active mode, the same applies to a server behind a NAT router and the reply to the PASV command.
It is recommended to use the network configuration wizard. It can be reached at the Edit menu. The wizard will guide you through the necessary steps and can test your configuration.
If you want to connect to any server, you need to tell your firewall that FileZilla Pro should
be allowed to open connections to other servers. Most normal FTP servers use port 21, SFTP servers use port 22 and FTPS (implicit mode) use port 990 by default.
These ports are not mandatory, however, so it’s best to allow outgoing connections to arbitrary remote ports.
Since many servers on the internet don’t support both transfer modes, it’s recommended that you configure both transfer modes on your end.
In passive mode, FileZilla Pro has no control over what port the server chooses for the
data connection. Therefore, in order to use passive mode, you’ll have to allow outgoing
connections to all ports in your firewall.
In active mode, FileZilla Pro opens a socket and waits for the server to establish the transfer connection.
By default, FileZilla Pro asks the operating system for the machine’s IP address and for the number of a free port. This configuration can only work if you are connected to the internet directly without any NAT router, and if you have set your firewall to allow incoming connections on all ports greater than 1024.
If you have a NAT router, you need to tell FileZilla Pro your external IP address in order for active mode connections to work with servers outside your local network:
- If you have a fixed external IP address, you can enter it in Edit Settings, FTP, Active
Mode, Use the following IP address box.
- If you have a dynamic IP address, you can authorize FileZilla Pro to obtain your external
IP address from a special website. This will occur automatically each time FileZilla Pro is started.
No information will be submitted to the website (regardless of FileZilla Pro version).
If in doubt, use the second option.
If you do not want to allow incoming connections on all ports, or if you have a NAT router, you need to tell FileZilla Pro to use a specific range of ports for active mode connections.
Configure the range in Edit > Settings, FTP, Active Mode, enable Limit local ports used by FileZilla and fill the boxes with the minimum and maximum port numbers. You will have to open these ports in your firewall. If you have a NAT router, you need to forward these ports to the local machine on which the FileZilla Pro is installed on. Depending on your router model, you can either forward a range of ports or you need to forward all ports individually.
Valid ports can be from 1 to 65535; however, ports less than 1024 are reserved for other protocols. It is best to choose ports greater than or equal to 50000 for active mode FTP.
Due to the nature of TCP (the underlying transport protocol), a port cannot be reused immediately after each connection. Therefore, the range of ports should not be too small to prevent the failure of transfers of multiple small files. A range of 50 ports should be sufficient in most cases.