ASA 5510 FTP Issue

Check out the xlate timeout, it's the time-to-live of any translation created by the asa, the default should be 1 hour, maybe someone lowered it to 5 minutes. If this is the case, after 5 minutes tha asa do clear the translation and send a rst to both server and client, this will abort the transfer. Bye, Tosh.

There are a ton of FTP related bugs in 7.0; you might try upgrading the ASA software

I haven't checked out PIX 7 details. In PIX 6, it would not work that way.

The translate timeout applies only after *all* the appropriate connection timeouts have been reached and all of the active connections through the translation are closed. It is not a timeout aimed at controlling connection lengths: it is a timeout aimed at reducing the effort of continually rebuilding translations. For example if you are fetching a document full of HTML links, you don't want to end up having to rebuild the translation just because there happened to be a fraction of a second during which the client paused between fetches.

In turn, the connection timeout (for general TCP) applies only to idle connections: it is reset for any connection when there is I/O on the connection. In PIX 6, a TCP connection that times out due to the 'conn' timeout is not actively sent an RST: the RST waits until the next time there is I/O in that direction. (The need for a RST is not remembered: it is simply generated because the device detects non-SYN traffic that it does not have a connection for.)

The connection timeout for UDP also applies only to idle connections, and of course there is no RST to send for UDP. When additional UDP traffic is detected for which there is no corresponding internal state, it is treated as if it was completely new traffic, generating new flow state if it is permitted by the access rules. This -does- imply that if the UDP port would not normally be open but was opened by way of inspection of earlier traffic (e.g., SIP or RPC or RPC-NETBIOS) then the "came back to life" UDP traffic might be denied by the ACL.

Thanks Merv, I was afraid that might be the case, I have just upgraded from 7.0(2) to 7.0(5) as there was a few FTP related bugs fixed in that version, as well as some security holes closed, but the client does not have any contract for the device, so they are unable to go any higher.

That's what they get if they don't want to spend the money.

-Hurgh-

Hi Tosh,

I have checked this setting and it is set at the default 1 hour. So looks like this is not the issue (though I wish it were, cause then I could fix it).

Thanks for your time.

-Hurgh-

I did it a try and you're right, I was a little confused about ios. Bye, Tosh.