PASV Client Behind NAT Using SSL = Timeouts?

Before I get into my problem, here's the basic setup that I'm attempting to use:

- Server is Serv-U v5.1, running XP firewall only with a true external IP. Server is configured to accept PASV transfers with implicit SSL. Control connection port is non-standard (25201), and a narrow port range for PASV data port connections has been specified in server & forwarded in XP firewall.

- Client is SmartFTP v1.5.989, running behind (presumed) NAT firewall. Client is configured to PASV mode, using AUTH mode SSL, and all data connection modes are set to Private (Secure). Keep Alive feature is enabled.

Basically, my situation involves some sort of forced connection close that happens in the middle of transfers. The client connects to the server on 25201, negotiates a TLS session successfully, and logs on normally. PASV mode is then initiated, and the client successfully connects securely on a port from the server's specified data port range. A large file transfer (download) is begun, and the data transfers normally until . . . exactly 1 or 2 hours later to the minute, the connection is unexpectedly aborted. Checking my Serv-U logs shows multiple FD_CLOSE messages, initiated seemingly by the client although I suspect they may actually be coming from the NAT.

The only reasoning I can come up with is that the control connection port is being perceived by the NAT as idle since the connection is secure and therefore the NOOP's can't be unencrypted. However, one would expect the NAT to refuse to open the data port at all because it can't unencrypt the PASV data port request coming from the server in the first place, right? Yet somehow it allows the data port connection, at least for those couple of hours.

I haven't tried connecting without the SSL, but I would rather work out a method for maintaining privacy and working successfully with the NAT if possible. I've also tried setting the client option for Control Connection Mode to Clear, but that setting causes a 500 Command Not Understood error from the server and an immediate disconnect.

Sorry about the length of this, but I'm getting a bit desperate, so any suggestions would be very much appreciated. TIA!

Hi,

You seem to not be sure who closes the connection. Maybe you can try with another FTP client program on the same computer. You can also try with SmartFTP and the other client program on another computer (not behind a NAT or at least the same NAT). Then, you will know is this problem is from SmartFTP, the NAT server or maybe your server.

But I think the problem is the NAT server. And as I know, if you can't change the NAT configuration, there is no answer.

Olivier

Thanks for the reply, monaco-o. I'm pretty sure that the NAT is closing the connection, but I'm trying to find a work-around.

I've been doing some twiddling with my server & SmartFTP settings, and thought that I'd solved the problem by having the clients use the global queue exclusively (no direct downloads), and by sending frequent Keep Alive's over the command port, hoping to prevent the NAT from thinking the port was idle & closing it before the data transfer was complete. It seems that with globally queued files, the command port doesn't need to remain open to complete the download (is this true?).

I felt that if this was the case, then I was hopeful that as long as a download on the data connection could be initiated & remained active, then the command port could be stopped (or time out) without cutting off the data port connection. This worked fine when I used SmartFTP to connect to my server from the same computer, but hasn't worked with outside clients.

For whatever reason, when an outside user adds a file to the global queue and then begins the transfer, it cannot connect. The command port connection remains active, but the queue transfer keeps failing/retrying and my server log displays "Unable to establish SSL connection ((null))", which is odd since the command port is also encrypted and it connects with no problem.

I must be missing something obvious. Any suggestions are welcome. TIA