Login works in the office, fails from outside — or worse, the login succeeds outside and then the folder listing hangs. That pattern has one classic cause, and it is not your password.
This is the most reported FTP problem in the world, and it confuses everyone the first time: the same server, the same user, the same password works inside the LAN and fails from the internet. Nothing is wrong with your site or your user. FTP uses two connections, and a home or office router only knows about the first one. Understand the two connections and the fix becomes obvious — but read the honesty note at the end before you leave an FTP server facing the internet at all.
Port 21 is only the control connection — login and commands. Every file and every folder listing travels on a second, separate data connection. In passive mode (the mode FileZilla and browsers use by default), the server replies to PASV with an IP address and a port and says: connect to me here. Inside the LAN that reply is correct. Across a router it usually is not, for two separate reasons — the address and the ports.
By default IIS answers the PASV command with the server's own IP — its private LAN address like 192.168.1.10. A client on the internet receives that reply and tries to reach an address that does not exist on the internet, so the listing times out exactly as in the panel above.
The fix lives in IIS Manager → the server name node → FTP Firewall Support: in the field External IP Address of Firewall, enter the router's public IP address. IIS then writes that public address into PASV replies instead of its LAN address.
Even with the right address, the client now connects to a random port in the server's passive range — and the router drops it, because you only forwarded port 21. FTP needs the whole system in agreement:
50000-50100.net stop ftpsvc then net start ftpsvc.Testing from another PC on the same LAN proves nothing about the router. Test from a phone on mobile data with Wi-Fi off, or from home. In FileZilla, watch the log: a correct setup shows the PASV reply carrying your public IP, and the listing appears. If login works but listing still hangs, one of the three places above is still missing the range — check them in order: IIS range, Windows Firewall, router forward. The passive-mode page in this series has the complete end-to-end checklist.
Now the part most tutorials skip. The moment this fix works, anyone on the internet can reach your FTP login — and plain FTP sends the password in clear text on every connection, readable by any network between the client and you. Attackers scan for open port 21 constantly, and the log page in this series shows what their attempts look like.
The professional options are: put the FTP server behind a VPN so it is never directly public, switch the site to FTPS with a certificate, or move internet file exchange to SFTP. Opening plain FTP to the internet to save ten minutes is a decision admins regularly regret.
The video sets up the whole FTP server on Windows live — including the fast automated route — so you can follow it on your own server, click by click.
▶️ Watch Full VideoBecause the login travels on port 21, which you forwarded, while the listing travels on a passive data port, which you did not. Two connections, two different fates — that split is the signature of this exact problem.
You can, and it works, but you have opened thousands of doors into your server for one service. Fix a small range like 50000-50100 in IIS and forward only that. It is the same effort and a much smaller attack surface.
In active mode the server connects back to the client, so now the client's router and firewall must accept an inbound connection — which most block. That is why passive mode is the standard answer for clients behind NAT.