CCNA online course

File Transfer Protocol (FTP)

Learn how FTP transfers files, how control and data connections use TCP ports, how active and passive modes work, and why SFTP, FTPS, or HTTPS are safer choices.

File Transfer Protocol (FTP) is an application-layer client-server protocol for transferring files across a network. An FTP client connects to an FTP server, authenticates when required, and requests operations such as listing directories, downloading files, or uploading files.

FTP is not the same as ordinary web browsing. A browser commonly retrieves web pages and files using HTTP or HTTPS. FTP provides a broader file-management conversation, including directory navigation, file uploads, permitted deletions, directory creation, and renaming. It is also different from local-network file-sharing protocols, which usually integrate remote files into an operating system through protocols such as SMB or NFS.

FTP is an application-layer protocol, as described in the OSI reference model. It relies on TCP to provide reliable connections.

FTP Client-Server Architecture

The FTP client is the endpoint that initiates the session and requests operations. It may be a command-line program, a graphical file-transfer application, an automation script, or software built into a network-management tool.

The FTP server accepts FTP connections, authenticates users, exposes selected files and directories, and responds to client commands. Server-side permissions determine whether an account can read, write, delete, create directories, or rename files.

FTP separates its communication into two connections:

• Control connection: carries commands, authentication information, and server replies.
• Data connection: carries file contents and directory listings.

This separation is a key reason FTP behaves differently from many simpler request-and-response protocols.

The FTP Control Connection

The control connection normally uses TCP port 21 on the server. The client opens this connection and keeps it open during a typical session. The client sends commands such as login, directory navigation, and transfer requests. The server returns a numeric reply code and a text message.

For example, a client may authenticate over the control connection, request a directory listing, and then receive a separate data connection for that listing. The control connection remains available for the next command.

The FTP Data Connection

File contents and directory listings use a separate data connection. A data connection may be created for one file transfer or one directory listing and then closed when that operation finishes. The exact initiator depends on the selected FTP mode.

Active FTP Mode

In active mode, the client first establishes the control connection to server TCP port 21. After the client requests a data operation, the server initiates the data connection back to the client. The traditional server-side source-port association for this data connection is TCP port 20.

1. The client connects to the server's TCP port 21.
2. The client logs in and requests a listing or transfer.
3. The client tells the server where to establish the data connection.
4. The server opens the data connection toward the client.
5. The listing or file transfer uses that data connection.

Active mode can fail when the client is behind a firewall or NAT device. Such devices commonly block unsolicited inbound connections, and a server-initiated connection may not have a usable path to the client's private address. Stateful FTP inspection can sometimes recognize the control messages and permit the related data flow, but the firewall must be configured appropriately.

Passive FTP Mode

In passive mode, the client establishes both connections. The client connects to TCP port 21 for control and then connects to a temporary, high-numbered port supplied by the server for data.

1. The client connects to server TCP port 21.
2. The client requests passive mode.
3. The server reports a data port and, depending on the protocol exchange, an address.
4. The client opens the data connection to that server address and port.
5. The listing or transfer uses the client-initiated data connection.

Passive mode is generally more compatible with client-side firewalls and NAT because outbound connections from the client are usually permitted. The server-side firewall must allow the configured passive port range, and a server behind NAT must advertise an externally reachable address rather than an unusable private address.

Authentication and Access Control

FTP commonly uses a username and password. Authentication identifies the account, but authentication alone does not decide what the account may do. Authorization and file-system permissions control operations such as:

• Reading or downloading files.
• Writing or uploading files.
• Deleting files.
• Creating, removing, or renaming directories.
• Renaming or deleting existing files.

Anonymous FTP permits a public or limited login without an individually assigned account. It has traditionally been used for public, often read-only, downloads. Anonymous access should be limited to the intended directories and permissions.

ASCII and Binary Transfer Types

ASCII mode, also called text mode, is intended for text representations. An FTP implementation may translate line endings between operating-system conventions. This can be useful for compatible text files but can alter bytes.

Binary mode, also called image mode, transfers file bytes without text-oriented conversion. Use binary mode for images, archives, executables, videos, firmware images, configuration bundles, and other non-text files.

Using ASCII mode for a binary file can corrupt it. Using binary mode for a text file normally preserves its exact bytes, but line endings may not be converted for the destination system. When correctness matters, choose the mode deliberately and compare file sizes or checksums after transfer.

Common FTP Commands and Reply Codes

Command names vary slightly among clients, but the following workflow represents common operations. Credentials are shown only as placeholders; plain FTP credentials should not be used on an untrusted network.

ftp <server-name-or-ip-address>
user <username>
pass <password>
pwd
ls
cd <remote-directory>
binary
get <remote-file>
put <local-file>
quit

FTP replies include a three-digit numeric status code followed by text. Broad categories are:

• 1xx: positive preliminary reply; the server has started an operation and more information or a final reply is expected.
• 2xx: positive completion; the requested operation succeeded.
• 3xx: positive intermediate reply; more information is required, commonly another authentication value.
• 4xx: temporary failure; retrying later or correcting a temporary condition may succeed.
• 5xx: permanent failure; the command or request was rejected until its cause is corrected.

Authentication-related replies are commonly in the 3xx range when the server requests the next credential and in the 5xx range when authentication fails. Exact meanings depend on the individual code and server message.

FTP Security Limitations

Traditional FTP sends usernames, passwords, commands, and transferred data in clear text. Anyone able to observe the traffic on an untrusted network may capture credentials or read and modify transferred files.

Consequences include:

• Credential capture and account compromise.
• Exposure of confidential files.
• Modification or replacement of files during transit.
• Disclosure of commands, paths, and directory contents.

Do not use traditional FTP for sensitive information unless the network is appropriately trusted and an additional protection layer is deliberately provided. Prefer a secured managed-transfer method when confidentiality and authenticated integrity are required.

Firewall and NAT Considerations

FTP can be difficult to filter because its data-channel behavior depends on active or passive mode. A firewall may need an FTP-aware inspection feature that reads control messages and dynamically permits the related data connection. Alternatively, administrators can create carefully scoped rules for known clients, server addresses, and port ranges.

• Permit TCP port 21 from authorized clients to the FTP server.
• For active mode, permit the required server-initiated data flow toward authorized clients.
• For passive mode, configure a defined server passive TCP port range and permit authorized clients to reach that range.
• If the server is behind NAT, configure the externally reachable address that the server advertises.
• Forward and filter the selected passive ports consistently on the NAT device and server firewall.
• Use least-privilege source and destination restrictions rather than exposing broad port ranges unnecessarily.

A passive server that advertises a private address, such as an address from an internal RFC 1918 range, may cause an Internet client to attempt a connection that can never reach the server. A passive port range can fail in the same way if it is not forwarded or permitted.

Practical Examples

Anonymous Public Download

1. Connect the client to the server's TCP port 21.
2. Authenticate with anonymous access if the server permits it.
3. Use a listing command to find the file.
4. Select binary mode before downloading a non-text file.
5. Download the file and compare its size or checksum when a reference is available.
6. End the session with the client's quit command.

This workflow is suitable only for content that does not require confidentiality and for servers intentionally configured to provide public access.

Uploading a Router Software Image

On a controlled internal FTP server, an authenticated account may upload a router software image. The account needs write permission, and the image must be transferred in binary mode. Afterward, verify the remote file size and checksum against the original. Plain FTP is appropriate only when the environment is trusted or another protection layer protects the session; otherwise use a secured alternative.

Active Transfer Fails Behind a Workstation Firewall

A client may log in successfully because the control connection to TCP port 21 works. The directory listing then hangs because the server's reverse data connection is blocked by the workstation firewall or NAT device. Switching the client to passive mode is a common diagnostic and corrective step. If active mode is required, the firewall policy must explicitly support the expected data flow.

Passive Transfer Fails Behind NAT

The server may return a private or otherwise unreachable address, or it may select a passive port that is not forwarded. Inspect the passive-mode response, configure the server to advertise its public reachable address, forward the configured passive port range, and permit that range through the server-side firewall.

Text Transfer and Line Endings

ASCII mode may convert line endings between systems. Binary mode preserves every byte and is therefore required for non-text files. For text files, select ASCII only when the conversion is wanted; otherwise binary mode avoids automatic alteration.

Basic FTP Troubleshooting

First determine whether the failure affects the control connection or the data connection. Successful login proves that the control path and authentication reached a certain point, but it does not prove that listings or transfers can use the data path.

Useful evidence includes FTP status messages, verbose client output, server logs, firewall logs, and packet captures. A capture can show whether TCP port 21 succeeds, whether the server sends a passive port, whether a SYN reaches the data endpoint, and where the handshake stops.

Illustrative Network Policy Requirements

• Allow TCP port 21 only from authorized client networks.
• For active mode, permit the server-initiated data flow required by the deployment.
• For passive mode, choose a defined server port range, permit authorized clients to reach it, and configure the same range in the FTP server, firewall, and NAT device.
• Do not copy an example port range into production without checking the specific FTP server's documentation and security policy.

Many modern FTP clients default to passive mode. Mode settings such as passive and active are conceptual examples; exact command syntax varies by client.

When to Use FTP and When to Choose Another Protocol

Legacy FTP may still appear in controlled internal systems, older network devices, laboratory environments, or public repositories containing non-sensitive downloads. Its continued presence does not remove its security limitations.

• Choose SFTP when SSH-based secure file transfer is available.
• Choose FTPS when FTP behavior is required and TLS can be deployed and validated.
• Choose HTTPS for web-based downloads, uploads, APIs, or managed delivery.
• Choose another secured managed-transfer service when auditing, encryption, integrity checks, and centralized access control are required.

SFTP is not an FTP mode. It is a separate SSH-based protocol. Understanding computer network fundamentals, TCP ports, addressing, and firewall behavior makes FTP troubleshooting much easier.

Exam-Ready Summary

• FTP is an application-layer client-server protocol for file transfer and file management.
• The control connection normally uses TCP port 21 and carries commands, credentials, and replies.
• A separate data connection carries files and directory listings.
• In active mode, the server initiates the data connection; TCP port 20 is traditionally associated with the server side.
• In passive mode, the client initiates the data connection to a temporary high-numbered server port.
• Passive mode usually works better through client-side firewalls and NAT, but the server's passive range and advertised address must be correct.
• Binary mode preserves bytes and is required for images, archives, executables, and firmware.
• Traditional FTP exposes credentials and data in clear text.
• FTPS uses TLS; SFTP uses SSH. They are separate protocols.
• A successful login confirms control-channel progress, not necessarily data-channel connectivity.