FTP Login Works but the Directory Listing Hangs: Why

The username works, the password works, and the client says it is connected. Then it waits forever on a folder listing, or on the first file transfer, and nothing in the credentials explains that. FTP opens a second connection for every listing and every file, and that second connection is the one failing. The login only proves the first conversation works.

Work the checks in order. Each one rules out a different layer, so stop at the first that produces an anomaly.

Separate the two connections first

A control connection carries commands and replies on the server's listening port. A data connection carries the directory listing or the file body, and in passive mode the server picks its endpoint and announces it in the PASV or EPSV reply. Permitting port 21 tells you nothing about whether the data port is reachable, which is exactly why a login succeeds while every listing times out. WinSCP's guide to FTP modes lays out the split and its network requirements.

If the client sits behind the VPN, the data path crosses the same tunnel but not necessarily the same policy.

Read the address in the PASV reply

Run a verbose client and read the reply instead of guessing. curl -v ftp://user@host/ prints the PASV line with the address and port the server wants, and that address is where the client connects next. If it is a private address that means nothing on the client's side of the tunnel, the data connection goes nowhere while the control channel stays healthy.

Compare that address with the address the client actually reached. A mismatch is the answer, and it usually comes from NAT or from a server configured with an internal address.

Check the port range and the tunnel policy

Passive servers allocate data ports from a configured range, and that range has to be permitted through the VPN and any firewall in the path. A policy that allows 21 and nothing else is a login-only policy. Confirm the range with whoever runs the server, then test one port from it rather than assuming the whole range behaves the same.

Encrypted control channels make this harder, because a middlebox can no longer rewrite the advertised address in flight.

Know when EPSV or a fallback helps

EPSV returns a port without a separate address, which removes the wrong-address failure when both ends support it. Some clients can also be told to ignore the advertised address and reuse the control connection's destination. Both are legitimate tools aimed at a specific topology, not a blanket fix.

Do not disable TLS just to let a helper inspect the session. That trades a working protocol for a broken threat model.

Confirm with a listing and a transfer

After the address or port policy changes, open a fresh session over the same VPN path and list a directory. Then transfer a small file, because a listing and a transfer can take different code paths on some servers. Check the client log for a data connection to the expected address and port, and confirm the bytes arrived.

Keep FTP, FTPS and SFTP separate in your head while you do this. A passive-port change is not an SFTP setting, and the fix does not carry across protocols.