For some reason, no matter how many times I try, after a client sends the PASV command (which is correctly received by the server), the server's reply (227 Entering Passive Mode) doesn't get back to the client. I've gone as far as analyzing both client and server traffic with Wireshark to figure that much out. What's especially strange is that that last packet sent by the server has the exact same TCP settings as every other packet it has successfully sent so far. It's all going to the same client, at the same port, and yet for some reason this 227 response never gets through. I am completely floored as to why.
Here are screenshots of the client and server interactions:
Client Capture
As you can see it never recieves ACK for it's PASV command. It tries once more, and then gives up.
Server Capture
As you can see, it receives the PASV command, and sends a response, but it never gets through to the client. It gets the retransmission later and sends the response 3 more times, but again it never gets through. Then it disconnects.
I can't imagine how it's possible that all the other TCP packets get from server to client without issue, but this particular TCP packet does not. The TCP headers are identical for all packets to and from the server respectively, so from my understanding, all routers, firewalls, ISPs, etc. should be treating them equally unless they are packet sniffing.
Best Answer
I've just struggled with the same issue and found this question when googling for a solution. I my case the problem was caused by the firewall (Sonic Wall) that detected the server answer as a possible FTP bounce attack and dropped the connection. The solution was to change the passive setting in the FTP server and enter the internal IP address as the response to a PASV. The firewall then detected it as a legit answer and converted the answer to the external address before transmitting it to the client. It feels very wrong to set up up that way but it works in conjunction with this firewall.