The "Data connection rejected by server" error in FTPS typically stems from a mismatch between the client's active mode request and the server's firewall or NAT configuration. This occurs because FTP uses separate channels for control and data, and secure encryption often interferes with automatic port negotiation. To resolve this, you must ensure your firewall allows the specific passive port range and configure your client to use Passive Mode instead of Active Mode.
Understanding FTPS Connection Architecture
Unlike standard HTTP which uses a single persistent connection, File Transfer Protocol (FTP) operates using two distinct TCP connections: a Control Channel and a Data Channel. The Control Channel remains open throughout the session to send commands like
LIST or
GET. The Data Channel is opened separately to transfer the actual file contents or directory listings. In standard FTP, these ports are negotiated dynamically. However, when SSL/TLS is enabled (FTPS), this negotiation becomes more complex because the data channel must also be encrypted. Many modern firewalls and routers struggle to inspect or allow these encrypted dynamic ports, leading to the rejection error you are experiencing.
The Role of Active vs. Passive Modes
The core of the issue usually lies in how the data connection is initiated. In Active Mode, the client tells the server its IP address and a port number, expecting the server to connect back to it. This is problematic behind most home routers or corporate firewalls because the incoming connection from the server is blocked as unsolicited traffic. In Passive Mode, the server opens a random high-numbered port and tells the client to connect to it. While this solves the inbound firewall issue on the client side, it requires the server-side firewall to explicitly allow that range of ports. If the server does not advertise the correct external IP or if the firewall blocks the specific passive ports, the connection will be rejected.
Troubleshooting Client-Side Configuration
The most immediate fix is to change your FTP client settings. Most default configurations attempt to use Active Mode or auto-negotiate, which fails frequently in secured environments. You should manually switch your client to Passive Mode. For example, in FileZilla, go to Edit > Settings > Connections > FTP and select "Passive" under the Transfer Mode section. This forces the client to initiate the data connection, bypassing the need for the server to punch through your local network barrier. Additionally, ensure that your client is configured to require explicit TLS/SSL rather than implicit, as some servers reject implicit connections on standard ports.
Server-Side Firewall and Port Configuration
If changing the client mode does not resolve the issue, the problem likely resides on the server infrastructure. FTPS servers require a specific range of ports to be open for passive data transfers. Standard FTP uses port 21 for control, but passive data ports can be any high-numbered port (typically 1024-65535). You must configure your server's firewall (such as iptables, Windows Firewall, or cloud security groups) to allow inbound TCP traffic on this specific passive port range. Furthermore, you must configure the FTP daemon itself (like vsftpd or IIS) to define this exact range so it does not pick random ports that might fall outside your allowed list.
NAT and Port Forwarding Considerations
When an FTPS server sits behind a Network Address Translation (NAT) device, such as a typical router, it faces a significant challenge. The server may advertise its internal private IP address (e.g., 192.168.1.10) in the PASV response. The client, located outside the network, receives this private IP and attempts to connect to it, which fails because private IPs are not routable over the internet. You must configure the FTP server software to specify the "External IP" or "MASQUERADE ADDRESS." This ensures that the server advertises its public-facing IP address to clients, allowing them to establish the data connection correctly. Without this setting, the handshake completes, but the data transfer is immediately rejected or times out.
Verifying SSL/TLS Certificate Trust
Sometimes the error message is misleading, indicating a data rejection when the actual cause is a certificate validation failure. If your FTPS server uses a self-signed certificate, many clients will silently drop the connection or fail during the initial handshake without clear errors. Ensure that the root CA certificate of your FTPS server is installed in your client's trusted store. For enterprise environments, using a certificate from a recognized Certificate Authority eliminates trust issues entirely. You can test this by attempting to connect via a web browser or a simple command-line tool that provides verbose SSL output to isolate whether the issue is purely network-based or cryptographic.
Advanced Debugging Steps
If the above steps do not work, engage deep debugging modes in your FTP client. Enable verbose logging to see the raw FTP commands and responses. Look for the
PASV or
EPSV response lines. If the response contains an unexpected IP address or a port number that seems incorrect, it confirms a misconfiguration in the server's passive port settings. You can also use network diagnostic tools like
tcpdump or Wireshark on the server side to see if the SYN packets for the data connection are arriving at the firewall but being dropped. This helps determine if the packet is reaching the host or if it is being blocked earlier in the network path. For more insights on network connectivity diagnostics, you might find
PC: Many Time-Wait Loopback Connections - Open? useful for understanding underlying socket states.
Frequently Asked Questions
Why does FTPS fail while plain FTP works?
Plain FTP sends credentials and port numbers in cleartext, allowing stateful firewalls to easily track and allow the subsequent data connection. FTPS encrypts this metadata, preventing many traditional firewalls from identifying the expected ports, leading to dropped packets. You must configure your firewall to allow the entire passive port range rather than relying on deep packet inspection for individual ports.
What is the difference between Explicit and Implicit FTPS?
Explicit FTPS starts with a plain connection on port 21 and upgrades to TLS using the STARTTLS command, which is widely supported and easier to debug. Implicit FTPS expects an immediate TLS handshake on port 990 and is largely deprecated due to compatibility issues with modern firewalls. Always prefer Explicit FTPS unless your legacy system strictly requires Implicit support.
How do I find the correct passive port range on my server?
The port range is defined in your FTP server's configuration file. For vsftpd, look for
pasv_min_port and
pasv_max_port. For IIS, you configure this in the Advanced Settings of the FTP Firewall Support feature. Ensure these values match exactly what you have opened in your network firewall rules.
Can I use SFTP instead of FTPS to avoid these issues?
Yes, SFTP (SSH File Transfer Protocol) uses a single encrypted channel over port 22, eliminating the complex dual-channel architecture of FTP. It is generally easier to configure through firewalls since only one port needs to be open. If your server supports it, migrating to SFTP is often a more robust long-term solution.
Why do I get "Connection Refused" after the handshake succeeds?
This symptom indicates that the control channel connected successfully, but the server refused the data connection attempt. This is almost always caused by the server advertising an incorrect IP address (internal vs. external) or the client trying to connect to a port that the server's firewall has blocked. Check your server's NAT settings and verify the passive port range is accessible.