FTP login works but directory listing fails: fix the data channel

Why does FTP log in fine but fail when I open the folder?

Because FTP runs two TCP connections, not one. TCP port 21 carries the login and every command. A second data connection carries each directory listing and each file. A firewall that passes only port 21 delivers a successful login and a failed folder, in that order.

The FTP specification, RFC 959, splits every session this way. The control connection stays open for login, navigation and transfer commands. A fresh data connection opens for each listing and each file. Opening a folder forces a listing, so it forces the second connection. That is why the failure waits until after login. Which side opens that connection depends on the mode:

Match your symptom to its cause before touching anything:

• Login accepted, then the first listing hangs or fails: the data channel is blocked between client and server.
• Login refused outright: credentials or the panel's FTP service, a different problem entirely.
• A port test on TCP port 21 that fails: even the control path is filtered, and that rule comes first.
• Reply 425 after a transfer command: the server could not open the data connection.
• No reply to a ping: routing or subnet trouble below FTP, and no FTP test means anything until an address answers.

What does FTP reply 425 mean?

Reply 425 is the server telling you it could not open the data connection. That is the FTP signature of a blocked channel: the control session on TCP port 21 is alive, the login succeeded, and the server tried to open or accept the second connection and failed.

The reply text usually reads 425 Can't open data connection. It arrives right after the command that needed data, typically a directory listing. A graphical client may hide the number behind a generic message that the file cannot be accessed; the Windows Explorer view of an FTP address behaves this way. Running the same login from the command line shows the numeric reply, and a vague popup becomes a diagnosis.

Which ports does FTP actually need open?

Port 21 for control plus the data channel for the mode you run. Active mode has the panel open a data connection back to your PC, classically from TCP port 20. Passive mode has your PC connect to a port the panel announces, so the rule set differs.

TCP port 21 is reserved for commands in both modes; the FTP specification fixes it there. Active mode sends data from TCP port 20 on the panel back to the port your client announced with its PORT command. Passive mode has no fixed data port: the panel names a port inside its own configured range and your client connects to it. That range is a server setting, and the panel's manual or network configuration names it. Fixing the range to a small block is what makes a clean, auditable rule possible. Leaving it wide forces the firewall to open hundreds of ports for one panel.

How do I test from the PC which channel is blocked?

Run three tests in order: a ping to the panel address, Test-NetConnection against port 21, then a real login and directory listing from the command line. The step that fails names the channel.

1. ping <panel-ip-address>. A reply clears routing and subnet. No reply is network trouble below FTP.
2. Test-NetConnection <panel-ip-address> -Port 21. A True result means the login path is open. A False means the control port is filtered, and that rule needs fixing before anything else.
3. Log in with ftp <panel-ip-address> and run dir. Login success followed by a long pause and 425 Can't open data connection is the signature of this fault: control open, data blocked.
4. Repeat the listing with a graphical FTP client set to passive, then to active. One mode lists the folder and the other fails, and you have found the direction your filter blocks. The command-line client that ships with Windows runs active mode, so passive testing needs a graphical client.
5. Move the PC onto the panel's own switch, with no firewall in the path, and list again. A listing there clears the panel and puts the block in the network.

The same shape, a ping that answers and a transaction that fails, appears one layer up in HMI pings the PLC but reads fail: check the protocol driver, where the driver turns out to be the missing piece.

How do I fix the firewall for passive mode?

Set the server's passive port range to a small fixed block. Open TCP port 21 plus that block from PC to panel in one rule scoped to the two addresses. Set every client to passive mode, which keeps all data connections leaving the PC.

1. Set the panel's passive port range in its network or FTP configuration. The manual names the setting.
2. Add one firewall rule: source the PC address, destination the panel address, protocol TCP, port 21 plus the passive range.
3. Set every client to passive mode, so the data connections leave the PC.
4. If the panel sits behind a NAT router, check the address it announces in passive mode. A server that advertises its private address sends clients on other networks to an address they cannot reach. That mismatch returns 425 with every port correctly open. The cure is the server's external or passive address setting.
5. Active mode remains available where passive cannot run. It needs a rule allowing the connection the panel opens from TCP port 20 to the PC, plus a matching rule in the PC's own firewall. Passive stays simpler, because most networks already allow connections leaving the PC.

For a production emergency, connect the PC directly to the panel on an isolated subnet, copy the file, and put the network back the way it was. Never leave a firewall switched off on a plant-connected PC. Keep every rule scoped to two addresses and named ports; a range opened to any address invites more than FTP.

Recommendation: run FTP in passive mode with the server's range fixed to a block of about 100 ports, open TCP port 21 plus that block in one rule scoped to the PC and panel addresses, and use a direct PC-to-panel connection on an isolated subnet only for one-off transfers when the firewall cannot be changed.

Example: loading a 1 MB page to the panel

In this example a PC at 192.168.1.20 needs to load one HTML page of about 1 MB to a panel at 192.168.1.50. The listing fails until TCP port 21 plus a 100-port passive block, TCP ports 50000 to 50099, is open between them. The whole job, tests and rule change and upload, takes about 10 minutes. The addresses are chosen for the walk-through; substitute your own.

1. Test-NetConnection 192.168.1.50 -Port 21 returns True. The control path is open.
2. ftp 192.168.1.50 accepts the login, and dir pauses before the server returns 425 Can't open data connection. Control fine, data channel blocked.
3. The panel manual names its passive range setting. Set the start port to 50000 and the count to 100 ports. The last port is 50000 + 100 - 1 = 50099, so the range is TCP ports 50000 to 50099.
4. One firewall rule covers it: source 192.168.1.20, destination 192.168.1.50, protocol TCP, ports 21 and 50000 to 50099. That is 1 control port plus 100 data ports, 101 ports in total.
5. The client switches to passive mode. dir returns the listing, the 1 MB HTML page uploads in a few seconds on a 100 Mbit/s link, and the listing shows the file with its size.

Two addresses and 101 ports, and the folder that failed all morning opens on the first try.

What if the block sits in a firewall I do not manage?

Stop and send the network owner a rule request that names both addresses, TCP port 21, and the passive range. A managed plant firewall is not yours to route around and not yours to weaken.

Put everything the owner needs into the request: source address, destination address, protocol TCP, port 21, the passive range, the business reason, and how long the rule should stay live. While it waits, move the PC onto the panel's subnet for the transfer, but only if that subnet is isolated from the plant network. Testing one hop at a time is the same discipline that clears HMI remote access port forwarding failures: name the hop, name the port, test, move to the next.

How do I confirm the file actually made it onto the panel?

The listing is the confirmation. The folder opens, your file appears with the byte size you sent, and a download back to a scratch folder matches the original. That clears the whole path from PC to panel storage.

Three checks close the job:

• The folder opens in the client and your file shows in the listing with the size you sent.
• The file downloads back to a scratch folder and matches the original.
• The panel serves the page: open its web address in a browser and confirm the new content renders.

If the folder still refuses to open on a direct connection with no firewall between PC and panel, the fault has moved into the panel itself. Take it to the panel vendor's support channel with the model, the firmware version, the exact reply text, the client, and the mode in use.

Questions