Custom FTP client PASV data connection refused

Question

Going to try and be brief

I've written a custom FTP implementation using c# .net 3.5. The system uses TcpClient (TcpListener for active mode) for managing connections. Been getting strange behavior in a single instance and I would like to ask for possible causes.

The client itself works great in house and a good percentage of our clients are satisfied with it. However, we have one that I can't figure out. I've been sent wireshark traces to poke around in but no real joy. The client machine is behind what I believe (from client description) to be a big network infrastructure. From outside the network, the connection to the same server works like a charm. Here is what I'm seeing.

With my client, operating in passive mode, tcp handshake request goes is sent out for the data connection (server enters passive mode and specifies port), but is never acknowledged. This causes retries and eventual timeout.

With the Filezilla (and windows explorer, and IE...) client, again using passive mode, the connection goes through without issue. Annoyingly, this is causing the client and my boss to point fingers at the code.

Going through the wireshark traces I can't see any differences between TCP frames. All control connections hit port 21 and are acknowledged in both scenarios. Flags are similar. Same applies to the data connection except it is a high numbers port 52000+ (but not the same in the traces i have) in this instance.

I'm no expert in network programming when we start getting into lower level protocol issues and my understanding of larger network caveats is very limited. As the developer I immediately cry "FIREWALL ISSUE" but that doesn't really solve anything for anyone.

To finalise, does anyone know what sort of hardware / firewalling that can cause this sort of behavior? I'm suspecting something blocking traffic on an application level but you never know.

Thanks for reading.

Answer 1

Well shine my shoe. Would you believe it, turns out this is probably user error after all.

The big question hanging over this is 'why does filezilla and windows work but your software does not'. Well I finally got a trace from the server side of things to tell me what is going on.

Seems filezilla and windows fall back to active mode but fail to tell you. Due to port 20 (passive mode, control host port) and 21 (active mode, client data port) being well known, networking hardware may allow it (and often does, regardless of firewall settings).

Our software however, does not fall back automatically to active mode because as a feature it is not recommended by FTP circles. Instead, active mode is a seperate option to pick when setting up the connection. Curiously, it is the outgoing client handshake request that is being zapped by the firewall but stranger things have happened. I'm going to wash my hands of this one and potentially put and automatic fallback into our client.

EDIT: Yeh, the user has a proxy on their network that they didn't tell us about. Sound the pebcak alert!