FTP disconnects after entering passive mode b/c packets are lost

Question

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.

Answer 1

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.

Answer 2

Apparent solution: I've been messing with anything on my router that I thought might be corrupting outgoing packets. I disabled something called "NAT ALG" (Application-level gateway) and the FTP client and server started communicating normally in passive mode again. Apparently this protocol snooping causes problems for a lot of people.

For future readers, my modem/router is a Motorola SBG6580 SurfBoard. Standard issue for my ISP EastLink. It came preconfigured with many such "features" and some seemed be be corrupting outgoing packets at the Ethernet II frame level.

Answer 3

I think this is a known issue with FileZilla version < 3.6.0.2 , do you by any chance use the older version?

Answer 4

I've met the exact same issue on my Windows 7 server. The client couldn't receive the "227 entering passive mode" package. The problem has to be in the server side. I turned off all firewalls but it still got the same result. Finally I found the reason. In the Network and Sharing Center, you can't set your network location to "Public Network". Because windows treat Public Network as untrusted. Any attempts to connect your computer will be regarded as risks and blocked. Just set it to "Work Network" and the server works fine then.