Ancient topic, but I ran into similar problems recently and figured my $.02 might help somebody.
In my case, we're running IIS 7.5 behind a slightly older version of ASA, which we're in the process of replacing. We have an existing FTP site and my plan was to simply add FTPS support with the certificate & maybe getting our network admins to open up a few ports. IIS has a similar masquerade setting for each FTP site named "External IP Address of Firewall", which is, itself, misleading.
the TL/DR version: If your FTP server allows you to specify a masquerade IP & a range of ports used for PASV connections, you SHOULD be able to fix this by opening up those ports & disabling ftp inspection.
Due to some some other constraints, I wasn't able to get inspection disabled on our ASA, so I had to make some compromises. Here's what I observed/learned:
- The ASA can only inspect non-encrypted traffic. duh?
- The default behavior of the ASA is to inspect a number of protocols, including FTP.
- the client authenticates on server port 21 and determines the feature set supported by the server.
- The client, if so configured, will send a PASV request to the server
- The server will respond with "227 entering passive mode (a,b,c,d,e,f)" where a.b.c.d is the server address and e*256 + f = port number
- The a.b.c.d address will be the internal IP unless the masquerade address is configured
- the FTP inspection will rewrite the a.b.c.d address to the external IP and open up the specified port for this client.
- If the a.b.c.d address IS the external address, the response packet is discarded. *This might be due to the strict option, which I could not verify.
- CuteFTP will recognize a non-routable IP in the PASV response and attempt to use the server's external address instead.
- the ASA can't read the SSL-encrypted FTPS traffic, so it bypasses the inspection and works.
So in our case, when I set the masquerade IP, I was able to connect just fine via FTPS, but regular FTP would fail. When I removed the masquerade IP, I was still able to connect to both FTP and FTPS using CuteFTP, but our primary client wasn't able to connect to FTPS. (their system wasn't "smart" enough to translate the non-routable IP...)
So my lame workaround was using two separate sites: one that used a masquerade IP and required SSL, the other site that didn't.
TMI, but maybe it helps somebody work through this.
Best Answer
In a nutshell:
sysctl -a | grep ip_local_port_range)Active Mode FTP
Client connects to server over port 21 and establishes a command stream:
client:32198 -> server:21Client must send or receive some data, so it informs the server to connect back to it on some port. To do this, it sends a PORT command similar to this:
PORT 1,2,3,4,5,6This is the client informing the server that the server may connect back to the client (at address 1.2.3.4 on port (5 * 256) + 6 = 1286.
server:20 -> client:1286Typically, this is where you see active mode FTP sessions die; with respect to firewalls and load balancers, the traffic normally flowing from client -> server is expected, but connections initiated by the server to the client are often denied (load balancers are often smart enough to tie associate this data stream with the existing command stream).
Your understanding about needing to open a port range on your firewall to facilitate this behavior is absolutely correct.
Passive Mode FTP
In this scenario, the client establishes a command session as before:
client:56221 -> server:21But when data is communicated, the client sends a
PASVcommand primitive. The server responds with an IP:Port combination that the client should connect back to (in a similar format to thePORTrequest earlier. So the client then connects to the server as follows:client:12347 -> server:4566This bypasses the firewall issues described above for active mode because the connections are established in a traditional and expected manner.
The downside to passive mode is that it consumes more sockets on the server. Issuing frequent
PASVprimitives in a heavily loaded environment could eventually lead to port exhaustion. (Sockets will linger in aTIME_WAITstate for some OS-defined amount of time (~2 minutes I think on Redhat systems).About your problem
Unless you really are suffering from port exhaustion issues, it is highly unusual that passive mode would fail and active mode would more often succeed. Usually is is the other way around. If you are able to post more about the errors you occasionally receive, we can debug it further.
I would recommend using passive mode wherever possible, and so I would recommend looking into the passive-mode specific failures to find the root cause of your issue before conceding to using active mode FTP.