ASA 5520 - ftp tls negotiation not working

[jlmickens]

Howdy all.

One of our users has been trying to connect to an outside FTP server utilzing FTPES (explicit TLS).  I've tested this on a machine connected to the internet via a cable modem, and it works fine, but if we try from inside the corporate network, the TLS negotiation times out.  I've been trying to find answers on google for a couple of hours now but not making much headway, other than finding a few references to not being able to do TLS over an ASA. A few other solutions I've seen include turning off the firewall, which  isn't going to happen.  Not inspecting FTP isn't much of an option  either (I've only got the default inspection maps).  Most of these are a few years old and I haven't been able to find anything similar to our situation.

Our ASA is currently running 8.0 (4) 39.  Is anyone aware of how I can get the FTPES connections working?  I've got the access rule currently set to be wide open to this FTP server, just in case the connection was trying to use another port, but that doesn't appear to be the issue.

Thanks in advance for your suggestions.

[Maykol Rojas]

Hi,

Please refer to the following:

Q. Is FTP with TLS/SSL supported through the Security Appliance?

A. No. In a typical FTP connection, either the client or the  server must tell the other what port to use for data transfer. The PIX  is able to inspect this conversation and open that port. However, with  FTP with TLS/SSL, this conversation is encrypted and the PIX is unable  to determine what ports to open. Thus, the FTP with TLS/SSL connection  ultimately fails.

One possible workaround in this situation is to use an FTP client  that supports the use of a "clear command channel" while still using  TLS/SSL to encrypt the data channel. With this option enabled, the PIX  should be able to determine what port needs to be opened.

Document

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_qanda_item09186a00805b87d8.shtml

Another thing to reference is the following explanation that I created when people ask this same question, these are the scenarios where SSL/TLS FTP can work across the ASA.

FTP server working on Active mode, located on the inside and the clients on the outside. In this scenario, the host on the outside would make a connection on port 990 to the inside, if the FTP server has an static one to one, everything is going to work fine, if the server has a port forwarding, you need to make sure that is the same IP address that it uses to make outbound connection to the internet, here is why:

Once the control channel has been established (990), the server on active mode is going to set the data channel (normally on port 20). Besides telling the client that the port is 20, he will send a SYN packet to the client on that port. If the SYN on port 20 gets to the client with a different IP, the connection is never going to be completed, what you are going to see is only SYN requests and the ftp session will hang.

Bottom line, make sure that the IP that ftp server uses is the same for outbound and inbound ftp connections.

Scenario 2

Client on the inside and server on the outside, Server on Passive mode.

Same thing, client initiates the connection on port 990, the server agrees and waits for the client to set the port command. Client initiates the connection to the outside world in that n+1 port to the server and everything is going to work fine.

This may sound a little bit complicated, what you need to understand is that the firewall cannot open the Data channel because the Control channel is encrypted. Make sure that the data channel is seeing by the firewall as a regular connection.

Hope it helps.

Mike

[jlmickens]

But if I've got the rule set to be wide open, would it matter?  The client should be able to go out whatever port it wants.  We're talking about Scenario 2 here.  Client is initiating connection on port 21 (FTP), gets a response from the server, etc.  I get to the following packet:

7    0.104442    50.97.182.123    172.16.30.200    FTP    103    Response: 234 AUTH command ok. Expecting TLS Negotiation.

Client sends back a 165 byte response that appears to be encrypted, also on port 21.  On my internet connected machine, the server then sends back a large encrypted packet on the same port, but through the ASA there isn't one.

8.   0.105876  172.16.30.200  50.97.182.123 FTP  165 Request: \026\003\003(etc, etc)

[Maykol Rojas]

And what are you able to see on the syslogs of the ASA? So basically, is just the data that is encrypted ?

Mike

[jlmickens]

Sorry - got sidetracked by larger issues.  Syslogs aren't showing me anything.  I'm not really familiar with FTPES, but it appears to me that the data is encrypted, yes.

[Maykol Rojas]

Hi Jim,

No worries. Here is the main reason behind me asking this info. You know that if the FTP connection uses 2 ports. One to control the session (mainly commands, usernames passwords and so on) and the other one for sending the actual data.

How the ASA works is that it sees everything that happens (on layer 7) on the FTP connection. That way, he know what secondary port will be used for data and that way, the ASA opens the port dynamically, without having to open all IP. 

If the ASA is not able to see the port 21 in plain text, it will not be able to open the data channel dynamically.

On regular FTPs, it uses port 990 instead of 21 and that is why the ASA cannot open the data port and hence, the connection does not work.

If you try to use passive FTP from the client on the inside. the connection should work fine.

Mike

[jlmickens]

I did set the client to use passive, and it still does not work. I have no idea what the server is set to, as it is not ours.

I'm still confused as to why I'm not seeing the large packet come back from the server on port 21 through the ASA like I do on the machine using the cable modem.

[Maykol Rojas]

I dont think that is something to be concerned about. Does regular FTP connections work ok?

Mike

[jlmickens]

Yes, regular FTP connections work fine.