NAT, firewalls, and failed transfers

If login works, the control connection works. If LIST, RETR, or STOR hangs, focus on the separate data connection.

In active mode, check whether the server can reach the client endpoint. In passive mode, check the server’s passive port range, public address advertisement, NAT mapping, and firewall rules.

Capture the FTP replies and identify whether the failure happens before 150, during transfer, or before final 226. “FTP is down” is not a useful diagnosis until you identify the channel.

Use a layered trace:

1. DNS and TCP reach the control service
2. 220 greeting arrives
3. authentication reaches 230
4. PASV or EPSV returns an endpoint
5. the data TCP connection opens
6. 150 starts the operation
7. bytes and EOF cross the data channel
8. 226 completes the command

If step 4 advertises 10.0.0.8 to an Internet client, fix server NAT configuration. If step 5 times out, inspect passive-range mappings and firewalls. If bytes stop after 150, inspect network resets, storage, and timeouts. If 426 replaces 226, the transfer was aborted.

FTPS adds another layer: firewalls cannot inspect encrypted control commands to open ports dynamically. Configure and permit an explicit passive range instead of relying on an FTP-aware helper.

Reproduce one failure with verbose client logs and server logs. Stop at the first missing step in the list and change only that layer.