Troubleshooting FTP Passive Mode Failures with Packet Capture Analysis

While troubleshooting an FTP transfer failure, we observed that a client could successfully transfer files to the
DEVFTP server but failed when connecting to PRODFTP. Both servers were configured
to support passive FTP, so deeper analysis of the FTP control and data channels was required.

This post walks through how FTP passive mode works, how packet capture analysis helped isolate the issue, and the
steps used to resolve it.

How FTP Passive Mode Works

FTP uses two separate TCP connections:

Control Connection – used for commands and responses
Data Connection – used for file transfers or directory listings

Control Connection

The client first establishes a connection to the FTP server on TCP port 21.

Over this connection the client sends commands such as:

LIST
RETR
STOR
PASV

Passive Mode (PASV)

When operating in passive mode, the client sends a PASV command to request that the
server open a data port. The server responds with a 227 message containing the IP and port for the data
connection.

227 Entering Passive Mode (172,16,40,222,90,160)

How the Port is Calculated

(p1 * 256) + p2

227 Entering Passive Mode (172,16,40,222,90,160)

IP Address: 172.16.40.222
Port: (90 * 256) + 160 = 23200

The client then opens a second TCP connection to:

172.16.40.222:23200

Observed Symptoms

PRODFTP – Transfer Fails

Server response: 227 Entering Passive Mode
Data port advertised: 23200
Filtering for this port shows no data traffic
The client eventually sends FIN, ACK, closing the session

DEVFTP – Transfer Works

Server response: 227 Entering Passive Mode
Data port advertised: 23256
Traffic on this port shows a successful data connection
File transfer completes normally

Packet Capture Analysis

Wireshark filter to identify passive responses:

ftp.response.code == 227

DEVFTP Response

227 Entering Passive Mode (10,100,20,222,90,200)

IP Address: 10.100.20.222
Port: 23256

tcp.port == 23256

PRODFTP Response

227 Entering Passive Mode (172,16,40,222,90,160)

IP Address: 172.16.40.222
Port: 23200

tcp.port == 23200

Key Observation

The critical difference is the IP address returned in the PASV response.

Server	PASV IP	Result
DEVFTP	10.100.20.222	Transfer succeeds
PRODFTP	172.16.40.222	Transfer fails

Common Causes of Passive FTP Failures

Firewall Blocking

Firewalls may block the passive data ports. If the server selects a port that is not permitted, the data session fails.

Incorrect NAT Configuration

If the FTP server is behind NAT, it may advertise an internal IP in the 227 response, which external clients can’t reach.

Unreachable Network

The client may not have routing access to the subnet returned in the passive response.

Troubleshooting Steps

Verify Reachability

ping 172.16.40.222
telnet 172.16.40.222 23200

Inspect Firewall Rules

Ensure the server’s configured passive port range is permitted (commonly restricted to a defined range for security).

Verify Server Configuration

Ensure the server advertises a routable IP in its passive responses, especially when behind NAT.

Root Cause

PRODFTP returned an unreachable IP (172.16.40.222) in the passive response, so the client could not establish the data connection.

Resolution

Configure PRODFTP to advertise a reachable IP in the 227 response
Allow the server’s passive port range through relevant firewalls
Validate NAT rules if the server is behind NAT

Conclusion

To troubleshoot passive FTP: extract the 227 IP/port, compute the port, then verify reachability and firewall/NAT behavior.
Packet captures make the failure mode obvious quickly.