Ftp Overview - Learning Module

Loading content...

0/228

FTP Active Mode: The Original Connection Model

When Servers Called Back

In the original FTP design from the early 1970s, the architects made a decision that seemed perfectly reasonable at the time: when a file transfer was needed, the server would initiate the data connection by calling back to the client.

This design, known as Active Mode (or sometimes 'Standard Mode'), reflected the networking reality of the ARPANET era—a relatively small number of well-known hosts, minimal security concerns, and no firewalls or NAT devices to complicate connectivity.

Today, Active Mode remains a fascinating study in protocol evolution. Understanding it reveals not only how FTP works at its deepest level, but also why protocol designs must anticipate future network architectures—a lesson that applies far beyond FTP.

What You Will Learn

By the end of this page, you will understand exactly how Active Mode establishes data connections, the PORT command's format and semantics, the sequence of operations for Active Mode transfers, why Active Mode conflicts with modern network security practices, and how to diagnose Active Mode connection failures.

Active Mode Mechanics: How It Works

In Active Mode, the fundamental principle is clear: the client tells the server where to connect, and the server initiates the data connection back to the client.

Here's the process in detail:

Active Mode Connection Process

•Client opens control connection — The client connects to the server's port 21, establishing the persistent control channel.
•Client selects a local port — The client chooses an available port on its own machine to receive the data connection. This is typically a high-numbered ephemeral port (e.g., 50000-65535).
•Client binds and listens — The client binds a socket to this port and enters listening mode, waiting to accept an incoming connection.
•Client sends PORT command — The client transmits the PORT command on the control connection, informing the server of its IP address and listening port.
•Client requests transfer — The client sends a data transfer command (RETR, STOR, LIST, etc.).
•Server initiates data connection — The server opens an outbound connection from its port 20 to the client's specified IP address and port.
•Data transfers — File content or directory listing flows on the newly established data connection.
•Connection closes — Upon transfer completion, the data connection is closed and both sides return to idle state.

Converting Mermaid diagram...

Key Observation: Notice that the server initiates an outbound connection to the client. The server connects from its port 20 to the client's dynamically chosen port. This is the defining characteristic of Active Mode—and the source of its modern problems.

Why Port 20?

RFC 959 specifies that the server should use port 20 as the source port for data connections. This was intended to allow firewalls to recognize FTP data traffic (destination is dynamic, but source is always 20). In practice, many servers use ephemeral source ports instead, and firewalls rely on stateful inspection rather than port numbers.

The PORT Command: Telling the Server Where to Connect

The PORT command is the client's way of advertising its data connection endpoint. Understanding its format is essential for debugging Active Mode issues and implementing FTP clients.

PORT Command Format

PORT h1,h2,h3,h4,p1,p2\r\n

Where:

h1,h2,h3,h4 — The four octets of the client's IPv4 address
p1,p2 — The port number encoded as two octets

Port Calculation:

Port = p1 × 256 + p2

Example:

PORT 192,168,1,50,195,80

IP Address: 192.168.1.50
Port: 195 × 256 + 80 = 49,920 + 80 = 50,000

PORT Command Examples
PORT Command	IP Address	Port Calculation	Result Port
`PORT 10,0,0,1,4,0`	10.0.0.1	4 × 256 + 0	1024
`PORT 192,168,1,100,20,0`	192.168.1.100	20 × 256 + 0	5120
`PORT 172,16,0,50,195,80`	172.16.0.50	195 × 256 + 80	50000
`PORT 10,20,30,40,255,255`	10.20.30.40	255 × 256 + 255	65535
`PORT 192,168,0,1,0,21`	192.168.0.1	0 × 256 + 21	21

port_command_encoding.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
def encode_port_command(ip_address: str, port: int) -> str:
    """
    Encode an IP address and port into the FTP PORT command format.
    
    Args:
        ip_address: IPv4 address as dotted string (e.g., "192.168.1.50")
        port: Port number (0-65535)
    
    Returns:
        PORT command string ready to send (without CRLF)
    """
    # Split IP address into octets
    octets = ip_address.split('.')
    if len(octets) != 4:
        raise ValueError("Invalid IPv4 address")
    
    # Encode port as two bytes (big-endian)
    p1 = port // 256  # High byte
    p2 = port % 256   # Low byte
    
    # Construct PORT command
    return f"PORT {octets[0]},{octets[1]},{octets[2]},{octets[3]},{p1},{p2}"
 
def decode_port_command(port_string: str) -> tuple:
    """
    Decode an FTP PORT command response into IP address and port.
    
    Args:
        port_string: The comma-separated values from PORT command
    
    Returns:
        Tuple of (ip_address, port)
    """
    parts = port_string.split(',')
    if len(parts) != 6:
        raise ValueError("Invalid PORT format")
    
    ip_address = f"{parts[0]}.{parts[1]}.{parts[2]}.{parts[3]}"
    port = int(parts[4]) * 256 + int(parts[5])
    
    return ip_address, port
 
# Examples
print(encode_port_command("192.168.1.50", 50000))
# Output: PORT 192,168,1,50,195,80
 
ip, port = decode_port_command("192,168,1,50,195,80")
print(f"IP: {ip}, Port: {port}")
# Output: IP: 192.168.1.50, Port: 50000

Security Consideration: The FTP Bounce Attack

The PORT command's design allows a client to specify any IP address—not just its own. This enabled 'FTP bounce attacks' where attackers would use an FTP server to connect to third-party systems, bypassing firewalls that trusted the FTP server. Modern servers should reject PORT commands specifying addresses other than the client's control connection source address.

EPRT: The Extended PORT for IPv6

The PORT command only supports IPv4 addresses. RFC 2428 introduced the EPRT (Extended PORT) command to support both IPv4 and IPv6, using a more flexible and readable format.

EPRT Command Format

EPRT |protocol|address|port|\r\n

Where:

| — Delimiter (any ASCII character > 32, conventionally |)
protocol — Network protocol: 1 for IPv4, 2 for IPv6
address — IP address as standard string (dotted for IPv4, colon-hex for IPv6)
port — Port number as decimal string

Examples:

EPRT |1|192.168.1.50|50000|
   → IPv4 address 192.168.1.50, port 50000

EPRT |2|2001:db8::1|50000|
   → IPv6 address 2001:db8::1, port 50000

EPRT |1|10.0.0.1|21|
   → IPv4 address 10.0.0.1, port 21

PORT vs EPRT Comparison
Aspect	PORT Command	EPRT Command
Specification	RFC 959 (Original FTP)	RFC 2428 (IPv6 Extensions)
IPv4 Support	Yes	Yes (protocol = 1)
IPv6 Support	No	Yes (protocol = 2)
Format	Comma-separated octets	Delimiter-separated strings
Port Encoding	Two-octet encoded (p1×256+p2)	Plain decimal number
Readability	Lower (requires calculation)	Higher (direct reading)
Example	`PORT 192,168,1,50,195,80`	`EPRT \|1\|192.168.1.50\|50000\|`

Client Implementation Strategy

Modern FTP clients should attempt EPRT first (for IPv6 compatibility), falling back to PORT if the server responds with error 500 (command not recognized) or 502 (command not implemented). Most servers support both, but legacy servers may only recognize PORT.

Active Mode Complete Example: Step-by-Step Analysis

Let's trace through a complete Active Mode file download, examining every command and response, and the underlying TCP connections.

Scenario:

Client IP: 192.168.1.50
Server IP: 203.0.113.100
File to download: /pub/docs/manual.pdf (1,048,576 bytes)
Client data port: 49152

active_mode_trace.txt

FTP Trace

=== PHASE 1: CONNECTION ESTABLISHMENT ===
 
[TCP] Client 192.168.1.50:54321 → Server 203.0.113.100:21 [SYN]
[TCP] Server 203.0.113.100:21 → Client 192.168.1.50:54321 [SYN-ACK]
[TCP] Client 192.168.1.50:54321 → Server 203.0.113.100:21 [ACK]
[Control connection established]
 
<-- 220 FTP Server ready.
 
=== PHASE 2: AUTHENTICATION ===
 
--> USER alice
<-- 331 Password required for alice.
 
--> PASS ********
<-- 230 User alice logged in.
 
=== PHASE 3: NAVIGATION ===
 
--> CWD /pub/docs
<-- 250 Directory changed to /pub/docs.
 
--> TYPE I
<-- 200 Type set to I (Binary mode).
 
=== PHASE 4: ACTIVE MODE SETUP ===
 
[Client binds local socket to 192.168.1.50:49152]
[Client starts listening on port 49152]
 
--> PORT 192,168,1,50,192,0
    (Port calculation: 192 × 256 + 0 = 49152)
<-- 200 PORT command successful.
 
=== PHASE 5: TRANSFER REQUEST ===
 
--> RETR manual.pdf
<-- 150 Opening BINARY mode data connection for manual.pdf (1048576 bytes).
 
=== PHASE 6: DATA CONNECTION ===
 
[TCP] Server 203.0.113.100:20 → Client 192.168.1.50:49152 [SYN]
[TCP] Client 192.168.1.50:49152 → Server 203.0.113.100:20 [SYN-ACK]
[TCP] Server 203.0.113.100:20 → Client 192.168.1.50:49152 [ACK]
[Data connection established]
 
[Server transmits 1,048,576 bytes of file content]
 
[TCP] Server 203.0.113.100:20 → Client 192.168.1.50:49152 [FIN]
[TCP] Client 192.168.1.50:49152 → Server 203.0.113.100:20 [ACK]
[TCP] Client 192.168.1.50:49152 → Server 203.0.113.100:20 [FIN]
[TCP] Server 203.0.113.100:20 → Client 192.168.1.50:49152 [ACK]
[Data connection closed]
 
=== PHASE 7: COMPLETION ===
 
<-- 226 Transfer complete.
 
=== PHASE 8: SESSION TERMINATION ===
 
--> QUIT
<-- 221 Goodbye.
 
[TCP connection teardown for control channel]

Critical Observations:

Connection Direction — In Phase 6, notice the server (203.0.113.100:20) initiates the TCP connection to the client (192.168.1.50:49152). This is the signature of Active Mode.
Port 20 Source — The server uses port 20 as its source port. This is the FTP-data well-known port.
Sequential Operations — The PORT command must precede RETR. The client must be listening before RETR is sent.
Closure Signals Completion — The server closes the data connection (FIN) to signal transfer completion. The client's ACK indicates receipt. The 226 response on the control connection confirms successful transfer.
Two Simultaneous Connections — During Phase 6, two TCP connections exist: control (port 21) and data (port 20→49152).

Timing is Critical

The client must be listening on the specified port before sending the RETR command. If the client sends PORT then immediately sends RETR, a race condition can occur where the server connects before the client is ready to accept. Robust implementations wait briefly after PORT to ensure the listener is ready.

The Firewall Problem: Why Active Mode Fails in Modern Networks

Active Mode worked perfectly in the early Internet where firewalls were rare and all hosts had routable IP addresses. Modern network architecture has fundamentally changed this landscape, creating significant obstacles for Active Mode FTP.

Active Mode Challenges

•Client Firewall Blocks Inbound — Most client machines are behind firewalls that block all inbound connections by default. The server's attempt to connect to the client's data port is rejected.
•NAT Breaks Address Advertisement — Clients behind NAT have private IP addresses (10.x.x.x, 192.168.x.x). The PORT command advertises this private address, which is unreachable from the Internet-facing server.
•Stateful Firewalls Don't Understand — Even if inbound traffic is allowed, many firewalls only permit connections that match established outbound sessions. An inbound connection to a random high port appears as unsolicited traffic.
•Security Policies Prohibit — Many organizations' security policies explicitly prohibit inbound connections to client machines, viewing them as potential attack vectors.
•Dynamic Port Range — The dynamically chosen data port could be any of thousands of ports. Opening a firewall range this wide defeats much of the firewall's purpose.

Converting Mermaid diagram...

The Fundamental Conflict:

Active Mode assumes both client and server are equally reachable—a peer-to-peer model where either can initiate connections to the other. Modern network security architecture is explicitly asymmetric:

Servers are expected to accept connections (inbound allowed)
Clients are expected to initiate connections only (inbound blocked)

This security model conflicts directly with Active Mode's design, where the server must connect back to the client.

Partial Solutions:

FTP-aware Firewalls — Some firewalls can inspect FTP control traffic, extract PORT command parameters, and dynamically open corresponding inbound ports. This requires deep packet inspection and doesn't work with encrypted connections (FTPS).
ALG (Application Layer Gateway) — NAT routers with FTP ALG can rewrite PORT commands to use the public IP address and create appropriate port mappings. This is fragile and creates security risks.
Client Firewall Rules — Users can manually open high port ranges, but this creates security vulnerabilities and isn't practical for most users.

The Result: Passive Mode Dominance

These challenges have made Active Mode largely obsolete for client-to-server FTP transfers. Modern FTP clients default to Passive Mode, and many users never encounter Active Mode. However, Active Mode remains important for server-to-server transfers (FXP) and certain legacy integrations where clients can guarantee inbound connectivity.

When Active Mode Works: Valid Use Cases

Despite its challenges, Active Mode remains appropriate—even preferred—in certain scenarios. Understanding these helps select the right mode for specific situations.

Active Mode Valid Scenarios
Scenario	Why Active Mode Works	Considerations
Server-to-Server (FXP)	Both servers have fixed, routable IPs and permissive firewall rules	Security concerns with third-party initiated transfers
Internal Network Transfers	No NAT, controlled firewall policies, known port ranges	May require firewall rule coordination
Client Behind Permissive Firewall	Client can accept inbound connections (DMZ or deliberately opened)	Unusual; typically only for specialized systems
Legacy System Integration	Older systems may only support Active Mode	Consider FTP proxying or modern alternatives
Server as FTP Client	When a server acts as FTP client, it can accept inbound from other servers	Common in automated batch processes

Server-to-Server Transfers (FXP)

FXP (File eXchange Protocol) demonstrates Active Mode's power in specific contexts. When transferring files directly between two FTP servers:

A controlling client connects to both servers
Client sends PASV to Server A (which will receive)
Client sends PORT with Server A's address/port to Server B
Client sends STOR to Server A, RETR to Server B
Server B connects directly to Server A for data transfer

Data flows directly between servers—the client only manages the control connections. This is far more efficient than downloading to the client and re-uploading, especially for large files.

Active Mode for Server-Side FTP Clients:

When automated systems act as FTP clients (e.g., pulling data from partner FTP servers), they often run on servers with stable IP addresses and appropriate firewall rules. In these cases, Active Mode may work perfectly:

The 'client' is actually a server with routable IP
Firewall rules can be configured precisely
No NAT translation issues
May even be preferred for security logging (all data flows inbound)

Decision Principle

Use Active Mode when the FTP 'client' can reliably accept inbound connections. Use Passive Mode when the client is behind NAT, firewalls, or has non-routable addresses—which is true for the vast majority of end-user client connections.

Troubleshooting Active Mode: Diagnosing Connection Failures

When Active Mode fails, the symptoms are often confusing—control commands work perfectly, but data transfers never complete. Here's a systematic approach to diagnosis.

Symptom Analysis

•LOGIN works, LIST fails — Classic Active Mode failure. Control connection (port 21) succeeds, data connection (to client port) is blocked.
•Timeout after PORT command — Server cannot reach client's advertised IP:port. Usually firewall or NAT issue.
•Server responds 425 — 'Can't open data connection'. Server attempted to connect but failed.
•Transfer starts but hangs — Partial connectivity; firewall may block mid-stream or timeout.
•Works locally, fails remotely — Different network paths; local has no NAT, remote does.

active_mode_debug.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
#!/bin/bash
# Active Mode FTP Troubleshooting Script
 
echo "=== Active Mode FTP Diagnostics ==="
 
# Step 1: Check if client can listen on a port
echo -e "\n[1] Testing local port binding..."
python3 -c "
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
try:
    s.bind(('0.0.0.0', 49152))
    s.listen(1)
    print('SUCCESS: Can bind and listen on port 49152')
    s.close()
except Exception as e:
    print(f'FAILURE: Cannot bind - {e}')
"
 
# Step 2: Check external IP visibility
echo -e "\n[2] Checking public IP..."
PUBLIC_IP=$(curl -s https://api.ipify.org 2>/dev/null)
LOCAL_IP=$(hostname -I | awk '{print $1}')
echo "Public IP: $PUBLIC_IP"
echo "Local IP: $LOCAL_IP"
if [ "$PUBLIC_IP" != "$LOCAL_IP" ]; then
    echo "WARNING: Behind NAT - Active Mode likely to fail"
fi
 
# Step 3: Check if firewall allows inbound
echo -e "\n[3] Firewall status..."
if command -v ufw &> /dev/null; then
    sudo ufw status | head -10
elif command -v iptables &> /dev/null; then
    sudo iptables -L INPUT -n | head -10
else
    echo "Check Windows Firewall or other firewall manually"
fi
 
# Step 4: Test with netcat (if server is accessible)
echo -e "\n[4] To test server reachability:"
echo "   On CLIENT: nc -l -p 49152"
echo "   On SERVER: nc <client_ip> 49152"
echo "   If connection succeeds, Active Mode should work"
 
# Step 5: Verbose FTP session (using curl)
echo -e "\n[5] Verbose FTP test (using curl)..."
echo "Run: curl -v --ftp-port - ftp://server/file.txt"
echo "The --ftp-port - flag forces Active Mode"

Diagnostic Checklist:

Verify IP Address — What address is the PORT command advertising? If it's a private IP (192.168.x.x, 10.x.x.x), you're behind NAT.
Test Inbound Connectivity — Can you accept any inbound TCP connection on the advertised port? Use netcat to test.
Check Firewall Logs — Look for dropped packets to/from the data port. The firewall often logs the exact rejection reason.
Compare with Passive Mode — If Passive Mode works and Active doesn't, the issue is almost certainly client-side inbound blocking.
Capture Packets — Use Wireshark or tcpdump to trace the exact failure point. Look for SYN packets without SYN-ACK responses.

Quick Fix

Most Active Mode failures are solved by switching to Passive Mode. If Passive Mode is an option (client supports it, server allows it), it's almost always the right choice for client-server file transfer in modern networks.

Summary: Active Mode in Perspective

We've thoroughly explored FTP Active Mode—from its 1970s origins to its modern challenges. Let's consolidate the essential knowledge:

Key Takeaways

•Server initiates data connection — In Active Mode, the server connects out to the client. This is the defining characteristic that distinguishes it from Passive Mode.
•PORT command advertises client endpoint — The client uses PORT (or EPRT for IPv6) to tell the server its IP address and listening port, encoded in a specific format.
•Server uses port 20 for data — By convention, the server initiates data connections from port 20, though this isn't strictly required.
•Firewalls block Active Mode — Modern client firewalls typically block inbound connections, preventing the server's data connection from reaching the client.
•NAT breaks address advertisement — Clients behind NAT advertise private IP addresses that servers can't reach from the Internet.
•Active Mode still has valid uses — Server-to-server transfers, controlled internal networks, and legacy integrations may still benefit from Active Mode.
•Passive Mode is the modern default — For typical client-server transfers through firewalls and NAT, Passive Mode solves Active Mode's connectivity problems.

What's Next:

Having understood Active Mode and its limitations, we'll now explore Passive Mode—FTP's answer to the firewall and NAT challenges. Passive Mode inverts the connection initiation, having the client connect to the server for data transfer. The next page provides complete coverage of Passive Mode mechanics, the PASV and EPSV commands, and why Passive Mode has become the de facto standard for modern FTP usage.

Page Complete

You now understand FTP Active Mode comprehensively—its mechanics, the PORT command, its incompatibility with modern network security, and when it remains appropriate. This foundation is essential for understanding why Passive Mode was developed and how to choose between modes in practice.

FTP Active Mode: The Original Connection Model

When Servers Called Back

What You Will Learn

Active Mode Mechanics: How It Works

In Active Mode, the fundamental principle is clear: the client tells the server where to connect, and the server initiates the data connection back to the client.

Here's the process in detail:

Active Mode Connection Process

•Client opens control connection — The client connects to the server's port 21, establishing the persistent control channel.
•Client selects a local port — The client chooses an available port on its own machine to receive the data connection. This is typically a high-numbered ephemeral port (e.g., 50000-65535).
•Client binds and listens — The client binds a socket to this port and enters listening mode, waiting to accept an incoming connection.
•Client sends PORT command — The client transmits the PORT command on the control connection, informing the server of its IP address and listening port.
•Client requests transfer — The client sends a data transfer command (RETR, STOR, LIST, etc.).
•Server initiates data connection — The server opens an outbound connection from its port 20 to the client's specified IP address and port.
•Data transfers — File content or directory listing flows on the newly established data connection.
•Connection closes — Upon transfer completion, the data connection is closed and both sides return to idle state.

Converting Mermaid diagram...

Why Port 20?

The PORT Command: Telling the Server Where to Connect

The PORT command is the client's way of advertising its data connection endpoint. Understanding its format is essential for debugging Active Mode issues and implementing FTP clients.

PORT Command Format

PORT h1,h2,h3,h4,p1,p2\r\n

Where:

h1,h2,h3,h4 — The four octets of the client's IPv4 address
p1,p2 — The port number encoded as two octets

Port Calculation:

Port = p1 × 256 + p2

Example:

PORT 192,168,1,50,195,80

IP Address: 192.168.1.50
Port: 195 × 256 + 80 = 49,920 + 80 = 50,000

PORT Command Examples
PORT Command	IP Address	Port Calculation	Result Port
`PORT 10,0,0,1,4,0`	10.0.0.1	4 × 256 + 0	1024
`PORT 192,168,1,100,20,0`	192.168.1.100	20 × 256 + 0	5120
`PORT 172,16,0,50,195,80`	172.16.0.50	195 × 256 + 80	50000
`PORT 10,20,30,40,255,255`	10.20.30.40	255 × 256 + 255	65535
`PORT 192,168,0,1,0,21`	192.168.0.1	0 × 256 + 21	21

port_command_encoding.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
def encode_port_command(ip_address: str, port: int) -> str:
    """
    Encode an IP address and port into the FTP PORT command format.
    
    Args:
        ip_address: IPv4 address as dotted string (e.g., "192.168.1.50")
        port: Port number (0-65535)
    
    Returns:
        PORT command string ready to send (without CRLF)
    """
    # Split IP address into octets
    octets = ip_address.split('.')
    if len(octets) != 4:
        raise ValueError("Invalid IPv4 address")
    
    # Encode port as two bytes (big-endian)
    p1 = port // 256  # High byte
    p2 = port % 256   # Low byte
    
    # Construct PORT command
    return f"PORT {octets[0]},{octets[1]},{octets[2]},{octets[3]},{p1},{p2}"
 
def decode_port_command(port_string: str) -> tuple:
    """
    Decode an FTP PORT command response into IP address and port.
    
    Args:
        port_string: The comma-separated values from PORT command
    
    Returns:
        Tuple of (ip_address, port)
    """
    parts = port_string.split(',')
    if len(parts) != 6:
        raise ValueError("Invalid PORT format")
    
    ip_address = f"{parts[0]}.{parts[1]}.{parts[2]}.{parts[3]}"
    port = int(parts[4]) * 256 + int(parts[5])
    
    return ip_address, port
 
# Examples
print(encode_port_command("192.168.1.50", 50000))
# Output: PORT 192,168,1,50,195,80
 
ip, port = decode_port_command("192,168,1,50,195,80")
print(f"IP: {ip}, Port: {port}")
# Output: IP: 192.168.1.50, Port: 50000

Security Consideration: The FTP Bounce Attack

EPRT: The Extended PORT for IPv6

The PORT command only supports IPv4 addresses. RFC 2428 introduced the EPRT (Extended PORT) command to support both IPv4 and IPv6, using a more flexible and readable format.

EPRT Command Format

EPRT |protocol|address|port|\r\n

Where:

| — Delimiter (any ASCII character > 32, conventionally |)
protocol — Network protocol: 1 for IPv4, 2 for IPv6
address — IP address as standard string (dotted for IPv4, colon-hex for IPv6)
port — Port number as decimal string

Examples:

EPRT |1|192.168.1.50|50000|
   → IPv4 address 192.168.1.50, port 50000

EPRT |2|2001:db8::1|50000|
   → IPv6 address 2001:db8::1, port 50000

EPRT |1|10.0.0.1|21|
   → IPv4 address 10.0.0.1, port 21

PORT vs EPRT Comparison
Aspect	PORT Command	EPRT Command
Specification	RFC 959 (Original FTP)	RFC 2428 (IPv6 Extensions)
IPv4 Support	Yes	Yes (protocol = 1)
IPv6 Support	No	Yes (protocol = 2)
Format	Comma-separated octets	Delimiter-separated strings
Port Encoding	Two-octet encoded (p1×256+p2)	Plain decimal number
Readability	Lower (requires calculation)	Higher (direct reading)
Example	`PORT 192,168,1,50,195,80`	`EPRT \|1\|192.168.1.50\|50000\|`

Client Implementation Strategy

Active Mode Complete Example: Step-by-Step Analysis

Let's trace through a complete Active Mode file download, examining every command and response, and the underlying TCP connections.

Scenario:

Client IP: 192.168.1.50
Server IP: 203.0.113.100
File to download: /pub/docs/manual.pdf (1,048,576 bytes)
Client data port: 49152

active_mode_trace.txt

FTP Trace

=== PHASE 1: CONNECTION ESTABLISHMENT ===
 
[TCP] Client 192.168.1.50:54321 → Server 203.0.113.100:21 [SYN]
[TCP] Server 203.0.113.100:21 → Client 192.168.1.50:54321 [SYN-ACK]
[TCP] Client 192.168.1.50:54321 → Server 203.0.113.100:21 [ACK]
[Control connection established]
 
<-- 220 FTP Server ready.
 
=== PHASE 2: AUTHENTICATION ===
 
--> USER alice
<-- 331 Password required for alice.
 
--> PASS ********
<-- 230 User alice logged in.
 
=== PHASE 3: NAVIGATION ===
 
--> CWD /pub/docs
<-- 250 Directory changed to /pub/docs.
 
--> TYPE I
<-- 200 Type set to I (Binary mode).
 
=== PHASE 4: ACTIVE MODE SETUP ===
 
[Client binds local socket to 192.168.1.50:49152]
[Client starts listening on port 49152]
 
--> PORT 192,168,1,50,192,0
    (Port calculation: 192 × 256 + 0 = 49152)
<-- 200 PORT command successful.
 
=== PHASE 5: TRANSFER REQUEST ===
 
--> RETR manual.pdf
<-- 150 Opening BINARY mode data connection for manual.pdf (1048576 bytes).
 
=== PHASE 6: DATA CONNECTION ===
 
[TCP] Server 203.0.113.100:20 → Client 192.168.1.50:49152 [SYN]
[TCP] Client 192.168.1.50:49152 → Server 203.0.113.100:20 [SYN-ACK]
[TCP] Server 203.0.113.100:20 → Client 192.168.1.50:49152 [ACK]
[Data connection established]
 
[Server transmits 1,048,576 bytes of file content]
 
[TCP] Server 203.0.113.100:20 → Client 192.168.1.50:49152 [FIN]
[TCP] Client 192.168.1.50:49152 → Server 203.0.113.100:20 [ACK]
[TCP] Client 192.168.1.50:49152 → Server 203.0.113.100:20 [FIN]
[TCP] Server 203.0.113.100:20 → Client 192.168.1.50:49152 [ACK]
[Data connection closed]
 
=== PHASE 7: COMPLETION ===
 
<-- 226 Transfer complete.
 
=== PHASE 8: SESSION TERMINATION ===
 
--> QUIT
<-- 221 Goodbye.
 
[TCP connection teardown for control channel]

Critical Observations:

Connection Direction — In Phase 6, notice the server (203.0.113.100:20) initiates the TCP connection to the client (192.168.1.50:49152). This is the signature of Active Mode.
Port 20 Source — The server uses port 20 as its source port. This is the FTP-data well-known port.
Sequential Operations — The PORT command must precede RETR. The client must be listening before RETR is sent.
Closure Signals Completion — The server closes the data connection (FIN) to signal transfer completion. The client's ACK indicates receipt. The 226 response on the control connection confirms successful transfer.
Two Simultaneous Connections — During Phase 6, two TCP connections exist: control (port 21) and data (port 20→49152).

Timing is Critical

The Firewall Problem: Why Active Mode Fails in Modern Networks

Active Mode Challenges

•Client Firewall Blocks Inbound — Most client machines are behind firewalls that block all inbound connections by default. The server's attempt to connect to the client's data port is rejected.
•NAT Breaks Address Advertisement — Clients behind NAT have private IP addresses (10.x.x.x, 192.168.x.x). The PORT command advertises this private address, which is unreachable from the Internet-facing server.
•Stateful Firewalls Don't Understand — Even if inbound traffic is allowed, many firewalls only permit connections that match established outbound sessions. An inbound connection to a random high port appears as unsolicited traffic.
•Security Policies Prohibit — Many organizations' security policies explicitly prohibit inbound connections to client machines, viewing them as potential attack vectors.
•Dynamic Port Range — The dynamically chosen data port could be any of thousands of ports. Opening a firewall range this wide defeats much of the firewall's purpose.

Converting Mermaid diagram...

The Fundamental Conflict:

Servers are expected to accept connections (inbound allowed)
Clients are expected to initiate connections only (inbound blocked)

This security model conflicts directly with Active Mode's design, where the server must connect back to the client.

Partial Solutions:

FTP-aware Firewalls — Some firewalls can inspect FTP control traffic, extract PORT command parameters, and dynamically open corresponding inbound ports. This requires deep packet inspection and doesn't work with encrypted connections (FTPS).
ALG (Application Layer Gateway) — NAT routers with FTP ALG can rewrite PORT commands to use the public IP address and create appropriate port mappings. This is fragile and creates security risks.
Client Firewall Rules — Users can manually open high port ranges, but this creates security vulnerabilities and isn't practical for most users.

The Result: Passive Mode Dominance

When Active Mode Works: Valid Use Cases

Despite its challenges, Active Mode remains appropriate—even preferred—in certain scenarios. Understanding these helps select the right mode for specific situations.

Active Mode Valid Scenarios
Scenario	Why Active Mode Works	Considerations
Server-to-Server (FXP)	Both servers have fixed, routable IPs and permissive firewall rules	Security concerns with third-party initiated transfers
Internal Network Transfers	No NAT, controlled firewall policies, known port ranges	May require firewall rule coordination
Client Behind Permissive Firewall	Client can accept inbound connections (DMZ or deliberately opened)	Unusual; typically only for specialized systems
Legacy System Integration	Older systems may only support Active Mode	Consider FTP proxying or modern alternatives
Server as FTP Client	When a server acts as FTP client, it can accept inbound from other servers	Common in automated batch processes

Server-to-Server Transfers (FXP)

FXP (File eXchange Protocol) demonstrates Active Mode's power in specific contexts. When transferring files directly between two FTP servers:

A controlling client connects to both servers
Client sends PASV to Server A (which will receive)
Client sends PORT with Server A's address/port to Server B
Client sends STOR to Server A, RETR to Server B
Server B connects directly to Server A for data transfer

Data flows directly between servers—the client only manages the control connections. This is far more efficient than downloading to the client and re-uploading, especially for large files.

Active Mode for Server-Side FTP Clients:

The 'client' is actually a server with routable IP
Firewall rules can be configured precisely
No NAT translation issues
May even be preferred for security logging (all data flows inbound)

Decision Principle

Troubleshooting Active Mode: Diagnosing Connection Failures

When Active Mode fails, the symptoms are often confusing—control commands work perfectly, but data transfers never complete. Here's a systematic approach to diagnosis.

Symptom Analysis

•LOGIN works, LIST fails — Classic Active Mode failure. Control connection (port 21) succeeds, data connection (to client port) is blocked.
•Timeout after PORT command — Server cannot reach client's advertised IP:port. Usually firewall or NAT issue.
•Server responds 425 — 'Can't open data connection'. Server attempted to connect but failed.
•Transfer starts but hangs — Partial connectivity; firewall may block mid-stream or timeout.
•Works locally, fails remotely — Different network paths; local has no NAT, remote does.

active_mode_debug.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
#!/bin/bash
# Active Mode FTP Troubleshooting Script
 
echo "=== Active Mode FTP Diagnostics ==="
 
# Step 1: Check if client can listen on a port
echo -e "\n[1] Testing local port binding..."
python3 -c "
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
try:
    s.bind(('0.0.0.0', 49152))
    s.listen(1)
    print('SUCCESS: Can bind and listen on port 49152')
    s.close()
except Exception as e:
    print(f'FAILURE: Cannot bind - {e}')
"
 
# Step 2: Check external IP visibility
echo -e "\n[2] Checking public IP..."
PUBLIC_IP=$(curl -s https://api.ipify.org 2>/dev/null)
LOCAL_IP=$(hostname -I | awk '{print $1}')
echo "Public IP: $PUBLIC_IP"
echo "Local IP: $LOCAL_IP"
if [ "$PUBLIC_IP" != "$LOCAL_IP" ]; then
    echo "WARNING: Behind NAT - Active Mode likely to fail"
fi
 
# Step 3: Check if firewall allows inbound
echo -e "\n[3] Firewall status..."
if command -v ufw &> /dev/null; then
    sudo ufw status | head -10
elif command -v iptables &> /dev/null; then
    sudo iptables -L INPUT -n | head -10
else
    echo "Check Windows Firewall or other firewall manually"
fi
 
# Step 4: Test with netcat (if server is accessible)
echo -e "\n[4] To test server reachability:"
echo "   On CLIENT: nc -l -p 49152"
echo "   On SERVER: nc <client_ip> 49152"
echo "   If connection succeeds, Active Mode should work"
 
# Step 5: Verbose FTP session (using curl)
echo -e "\n[5] Verbose FTP test (using curl)..."
echo "Run: curl -v --ftp-port - ftp://server/file.txt"
echo "The --ftp-port - flag forces Active Mode"

Diagnostic Checklist:

Verify IP Address — What address is the PORT command advertising? If it's a private IP (192.168.x.x, 10.x.x.x), you're behind NAT.
Test Inbound Connectivity — Can you accept any inbound TCP connection on the advertised port? Use netcat to test.
Check Firewall Logs — Look for dropped packets to/from the data port. The firewall often logs the exact rejection reason.
Compare with Passive Mode — If Passive Mode works and Active doesn't, the issue is almost certainly client-side inbound blocking.
Capture Packets — Use Wireshark or tcpdump to trace the exact failure point. Look for SYN packets without SYN-ACK responses.

Quick Fix

Summary: Active Mode in Perspective

We've thoroughly explored FTP Active Mode—from its 1970s origins to its modern challenges. Let's consolidate the essential knowledge:

Key Takeaways

•Server initiates data connection — In Active Mode, the server connects out to the client. This is the defining characteristic that distinguishes it from Passive Mode.
•PORT command advertises client endpoint — The client uses PORT (or EPRT for IPv6) to tell the server its IP address and listening port, encoded in a specific format.
•Server uses port 20 for data — By convention, the server initiates data connections from port 20, though this isn't strictly required.
•Firewalls block Active Mode — Modern client firewalls typically block inbound connections, preventing the server's data connection from reaching the client.
•NAT breaks address advertisement — Clients behind NAT advertise private IP addresses that servers can't reach from the Internet.
•Active Mode still has valid uses — Server-to-server transfers, controlled internal networks, and legacy integrations may still benefit from Active Mode.
•Passive Mode is the modern default — For typical client-server transfers through firewalls and NAT, Passive Mode solves Active Mode's connectivity problems.

What's Next:

Page Complete