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.
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.
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.
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.
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:
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.
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.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...