FTP port guide: file transfer on ports 20 and 21

FTP separates commands from file data. The client connects to the server on TCP 21, logs in, and sends commands such as list, retrieve, store, rename, or delete. File listings and transfers then use a separate data connection.

That design made sense in older networks, but it creates problems with NAT, firewalls, and cloud security groups. A port checker can show whether port 21 is reachable, but a successful file transfer also depends on the data channel being allowed.

In active FTP, the client connects to the server's control port, then the server opens a data connection back to the client. That reverse connection often fails through NAT or strict client firewalls.

In passive FTP, the client opens both the control connection and the data connection to the server. Passive mode is more common for internet-facing FTP, but the server must publish a defined passive port range and firewalls must allow that range.

Plain FTP does not encrypt usernames, passwords, commands, or file contents. FTPS adds TLS to FTP, but it still keeps the FTP control and data-channel model. SFTP is different: it runs over SSH, usually on TCP 22, and does not use FTP ports.

For new deployments, SFTP is often simpler to firewall and operate. FTPS may be required for partner compatibility. Plain FTP should be limited to isolated legacy workflows or replaced when possible.

Open FTP only when a legacy partner, device, application, or workflow cannot use SFTP, FTPS, HTTPS upload, object storage, or a managed file-transfer service. Common examples include older EDI feeds, scanners, embedded devices, and vendor integrations.

Avoid public anonymous FTP unless it is intentionally serving public files and has tight upload controls. Writable FTP exposed to the internet is frequently abused for malware staging, data theft, and storage misuse.

Before allowing FTP, decide whether the server will use active mode, passive mode, or both. Define the passive port range, external IP address, user isolation model, chroot or jail behavior, logging, quotas, and whether TLS is required.

A TCP check against port 21 confirms only the control path. Test real uploads and downloads from outside the network because passive range, NAT, TLS inspection, and filesystem permissions can still break transfers.

On Windows Server, IIS FTP can provide FTP or FTPS. Configure user isolation, TLS policy, passive port range, firewall rules, and external IP settings if the server is behind NAT.

On Linux, servers such as vsftpd, ProFTPD, and Pure-FTPd are common. Configure local users or virtual users, chroot behavior, passive port range, TLS certificates if using FTPS, and host firewall rules for TCP 21 plus the data ports.

On cloud servers, allow only the required sources where possible. Open TCP 21 and the passive range in the cloud security group and host firewall. If you cannot define a narrow passive range, FTP will be difficult to secure cleanly.

Start with an external port check for TCP 21. If the control port is open, test with a real FTP client from outside the network. Confirm login, directory listing, upload, download, rename, and delete behavior as appropriate.

If login works but directory listing or transfers hang, inspect passive mode settings, passive port range, external IP advertisement, NAT, cloud security groups, and TLS settings. Many FTP failures are data-channel failures, not port 21 failures.

If port 21 is closed, the FTP service may be stopped, bound to a private interface, blocked by a host firewall, or denied by a cloud security group. If port 21 is open but transfers fail, passive ports or NAT are the first places to check.

If authentication fails, inspect username format, password policy, account lockout, chroot permissions, filesystem ownership, TLS requirement, and server logs. If only some clients fail, compare active vs passive mode and whether the client is behind restrictive NAT.

Avoid plain FTP for credentials or private files. Use FTPS or SFTP when possible, disable anonymous upload, restrict source IPs, isolate users, set quotas, and keep detailed transfer logs.

If FTP must remain public, patch the server, limit passive ports, monitor failed logins and upload volume, scan uploaded files, and remove stale accounts. Treat FTP as a legacy exception with an owner and migration plan.