I don't think anyone else has asked this, but please call me el stupido if I've missed it.

We have a vsftpd server that, for a specific client, is not initiating active mode when data needs to be exchanged. When I say specific client I mean a particular system (let's call it X), as I cannot replicate the issue when I use their same login credentials from multiple other systems.

From a network perspective, if I run tcpdump there is no sign of the SYN packet from ftp-data when communicating with system X. For the other connections that do work I see the expected bi-directional flow in to port 21 and out on port 20.

Has anyone ever seen this before? System X is an IBM mainframe, but the client is swearing black and blue "Change freeze!" (it stopped working on 2016-01-05, so Christmas) at suggestions that it's something on their side.
As I say, it was working and then it wasn't. On our server side it's an unchanged system since last year, file deliveries had been fine for weeks.

I'm lost. The session logs look entirely normal, and the setup and send from previous successful transfers appear identical to the now-failing ones. Any suggestions on where to look? Things to try?

Please don't suggest passive mode, as it will be weeks before the client and their big, blue IT outsource provider can make it happen.

Cheers

I would test active FTP from a client behind NAT. If you try from some typical network with 192.168.*.* or 10.*.*.* with all outgoing connections open and no incoming allowed, active FTP is tricky.

It can be solved using a firewall/ftp-proxy between the client and the server. Some firewalls have a setting for this. It can be called "FTP helper" or similar.

I searched, and found this:

http://www.devops-blog.net/iptables/...active-passive

1 members found this post helpful.

In the end I just installed proftpd. Worked right out of the gate, no configuration required other than SELinux booleans. With zero diagnostic assistance available from the outsourced supplier ("We're in change freeze" was the response to any suggestion it might have been their end) and other processes held up by the lack of data, trying to do more trouble-shooting just wasn't happening.

I did ponder the NAT one but the time required to set up a test was more than I cared to spend. The client's system is definitely being NAT'd, but it has been behind NAT the entire time.