I have had the opportunity to configure and deploy about four ASA’s within the last two weeks, six if you count my personal ones in my home lab. I have really learned my around the CLI within the ASA OS, and no it’s not IOS, there are enough differences to drive you nuts. I love ASDM to access the ASA. I use it heavily for troubleshooting and VPN. Packet Tracer within ASDM is a lot more nice and polished then the CLI method. The ASDM tool, like others that run on Java come with their challenges, the major one being the version of Java. Thankfully the ASDM application has become better about supporting the latest and greatest version of Java. I remember the days of having to run a certain version of Java or else ASDM wouldn’t work.
There are plenty of blogs and instructions out there on how to configure the ASA for SSH and HTTP access, but after searching and following many of them I found they were all missing something that prevented access via ASDM to ASA. After all the initial configurations of the ASA, things like HTTP enable, creating users, and allowing access from a host or subnet, I found myself still unable to access the ASA via ASDM.
I ran across two things, one Java related and one ASA related. First the Java related fix was to add the URL/IP address of the ASA webpage to the secure list within the Java security settings. I don’t remember having to do this in versions of Java 7, but maybe I am wrong and just don’t remember. The other fix was the command:
ssl encryption rc4-sha1 aes128-sha1 aes256-sha1 3des-sha1
This missing command cost me three hours of my life!
The default configuration of the SSL encryption is “des-sha1” which most modern browsers will reject this type of SSL connection. The “des-sha1” command essentially breaks the SSL communication between ASDM and the ASA because it disables the more secure SSL ciphers that are required for the ASDM communication. So now my question to Cisco is why are newer versions of hardware and code shipping like this out of the box? Why would a company like Cisco ship a product with essentially weak security configured on their firewalls?
Whatever their reasons are, they have stumped more than a fair share of us engineers out there with this configuration. I personally wiped the configuration my ASA more than twice thinking it was a bum config file and hoped a factory restore would fix the issue. I hope someone else can find this tip prior to wasting away unrecoverable hours that could be spent configuring the rest of the ASA.
