CoreFTP SSL Connection Problem

Sorry for the delay.  I was ill most of last week.  Here is the SLL portion of my running configuration:

ssh xxx.xxx.xxx.xxx 255.255.255.224 outside
ssh xxx.xxx.xxx.xxx 255.255.255.255 outside
ssh 192.xxx.xxx.xxx 255.255.255.255 inside
ssh 192.xxx.xxx.xxx 255.255.255.255 inside
ssh timeout 60
ssh version 2
console timeout 20

Does this cover the "PIX Firewall allows the configuration to allow/deny secure FTP traffic through it" part?

If there are any other lines you are looking for, please specify what you believe the beginning of those lines should look like.  And how would an access list that is not specific to the outside host look if I am to open specific ports on my firewall?  The entity that I need to connect to also maintains tight security and so they may be redirecting behind their firewall as well.  Back on access lists, I am a beginner at PIX stuff and am only used to seeing those types of specifics when configuring NAT.

Thanks in advance for your assistance.

Here is a Wireshark depiction of the attempt.  It is seen that the initial SSL/TLS session is established, but the certificate transaction is getting blocked.  I just can't figure out where the block is coming from.  This works great outside of our business fiewall (like my house), but not from work (where it's supposed to and needs to work from).  I have looked at our PIX and asked our IPS provider, and I'm not saying that I have covered all the bases there, but I'm getting a zero; I just need to figure out where the breakdown/block is coming from.  Can anyone decode the lingo in this capture?  Thanks in advance.

your wireshark capture indicates it is opening ftp connection over port 21  -ftp, not secure ftp

you are confusing ssh (secure shell) with secure ftp. ssh is an encryption protocol used with certain secure ftp servers, but the above commmands you have are not associating traffic with the ftp server

 Secure FTP initiates a connection on TCP port 990 then expects return data on a TCP high port, usually  port 10021 or 10121. If port 990 isn't open or if the server isn't listening on the correct return port, it will fail
verify  which type of secure FTP  you are y using - Secure FTP is often confused with "FTP over SSL".

first, coreFTP operates with ssh on port 22 :
http://www.coreftp.com/server/


second, make sure you are using static NAT if you have a seperate public ip for this server:

static(inside, outside) [public address of ftp server] [inside lan address of server] netmask 255.255.255.255 0 0

the have the appropriate inbound access-lists for allowing ssh traffic for this server:

access-list outside_inside permit tcp any host [public ip of server] eq 22
apply the access list to the outside interface:

access-group outside_in   in interface outside

If you still have traffic getting blocked, then open up access lists for ports 989 and 990 using the access-list syntax above

then test the connection, and take wireshark capture and you will see the encrypted traffic

also, forgot to add that unless you are using ssh to run the CLI from the internet, it creates more of a security risk for the firewall. You really should only run ssh from a vpn connection, rather than just open the ports to the outside world.

to enable ssh for CLI sessions:

crypto key generate rsa modula 2048
sh xxx.xxx.xxx.xxx 255.255.255.224 outside
ssh version 2

again, this is for management of the asa - this is not for enabling ssh inbound for the core ftp  so use my commands for that

Thanks for the correction.  However, there is absolutely NO outside access to the routers or firewall, and all inside access is via SSH; no telnet or http whatsoever.  Sorry for pasting SSH information that is not relevant to my question at all.  

Here is an updated screenshot.  It shows the whole of the SSL connection attempt from a PC on my private network (192.x.x.x) to the server on the remote network (134.x.x.x).  I cannot identify anything in the configuration that would be blocking the establishment of a certificated session.  

Again, here's what I believe is happening.  A secure TLS session is established for the purposes of authentication, or in this instance, the issuing of a certificate.  However, the seond half of this process is breaking down.  I cannot figure out what is blocking it.

Reading back over your last post, I am not totally clear on what the provider is doing insofar as SecureFTP versus FTP over SSL, but it appears to me that they are setting-up a TLS session for the purposes of FTP, so that looks like FTP over SSL (the "new" SSL).  I am not sure on how to allow access to the network through the firewall for port 989-990 when it apprears to me that it's already allowed.  Can you clarify?

Enough for now.  And thanks so much again!

I have obtained more information from the host service.  

"FTP/SSL -- This method is sometimes referred to as FTP over SSL or FTPS.  Conventional port number used for this protocol is 990.  However, 'host' has a proxy server as a front-end to its mainframe, allowing clients to connect to it.  Clients are expected to use port 21 and ephemeral ports 1xxxx through 1x1xx as transitory data ports."

I am not clear on what I may be overlooking insofar as the higher-numbered port range.  I really don't know how to open those ports as it appears as if I can only assign those to a NATted address/device.  I mean, I can't just "open them up" for all to use.  Although there is only one outside host address to be concerned with, we have several people internally that will be using this service, so I cannot create a NAT entry for 'them'; or more correctly, several NAT entries, one for each of them.

Thanks again for all of your assistance!