Unable to Access ASDM – “Unable to launch device manager from…”

KB ID 0000915

Problem

A colleague of mine was trying to connect to a firewall via ASDM last week, and was greeted by an error like this.

Cannot Open ASDM

Unable to launch device manager from

Now this is a pretty standard error, and usually means you haven’t been allowed access, or there isn’t a firewall at that address, but in this case I knew that a) he did have access, b) that was the correct IP address, and c) it worked fine on my machine, so it was setup correctly.

As I said above this is a pretty generic error make sure your ASDM is configured correctly. If no one else can access it then run though the article below.

Cannot Access / Open ASDM

Solution 1 (Oct 2018)

This stung me once again today! Windows 10, latest version of Java 8, and ASDM version 7.6(1) and 7.9(2). In the debug I was seeing;

%ASA-7-725014: SSL lib error. Function: SSL3_SEND_SERVER_KEY_EXCHANGE Reason: missing tmp dh key

Fixed by running;

ssl encryption aes256-sha1

Solution 2 (circa 2015)

I saw this very problem again today, while hardening a firewall I had disabled some SSL encryption ciphers, I had left aes256-sha1 active, and removed the others. Took me a while to realise, but if you only have one (or both), of the following ciphers enabled, ASDM won’t load;

  • aes-256-sha1
  • dhe-aes256sha1

If you have any of the following ASDM should load normally;

  • aes128-sha1
  • dhe-aes128-sha1
  • rc4-sha1
  • 3des-sha1

Java 7 Update 51 ASDM

At this point I would consider the problem ‘fixed’ and move on, but the client I’m installing the firewall for wanted some clarification as to why it would not work. “Was it a bug?” So I opened a TAC call, and did some Googling. I came across an excellent article. And found I could replicate it exactly;

Log output

%ASA-6-302013: Built inbound TCP connection 2698 for inside:192.168.100.10/52674 (192.168.100.10/52674) to identity:192.168.100.1/2456 (192.168.100.1/2456) %ASA-6-725001: Starting SSL handshake with client inside:192.168.100.10/52674 for TLS session. %ASA-7-725010: Device supports the following 1 cipher(s). %ASA-7-725011: Cipher[1] : AES256-SHA %ASA-7-725008: SSL client inside:192.168.100.10/52674 proposes the following 14 cipher(s). %ASA-7-725011: Cipher[1] : AES128-SHA256 %ASA-7-725011: Cipher[2] : DHE-RSA-AES128-SHA256 %ASA-7-725011: Cipher[3] : DHE-DSS-AES128-SHA256 %ASA-7-725011: Cipher[4] : AES128-SHA %ASA-7-725011: Cipher[5] : DHE-RSA-AES128-SHA %ASA-7-725011: Cipher[6] : DHE-DSS-AES128-SHA %ASA-7-725011: Cipher[7] : AES128-GCM-SHA256 %ASA-7-725011: Cipher[8] : DHE-RSA-AES128-GCM-SHA256 %ASA-7-725011: Cipher[9] : DHE-DSS-AES128-GCM-SHA256 %ASA-7-725011: Cipher[10] : DES-CBC3-SHA %ASA-7-725011: Cipher[11] : EDH-RSA-DES-CBC3-SHA %ASA-7-725011: Cipher[12] : EDH-DSS-DES-CBC3-SHA %ASA-7-725011: Cipher[13] : RC4-SHA %ASA-7-725011: Cipher[14] : RC4-MD5 %ASA-7-725014: SSL lib error. Function: SSL3_GET_CLIENT_HELLO Reason: no shared cipher %ASA-6-302014: Teardown TCP connection 2695 for inside:192.168.100.10/52671 to identity:192.168.100.1/2456 duration 0:00:00 bytes 7 TCP FINs

Note: the Client (My machine running ASDM) offers 14 cipher sets and theres no match.

By this time I had reply from TAC

————————————–

“The ciphers depends on the client, which in this case is ASDM launcher. ASDM launcher depends on ASDM version installed, latest available launcher is 1.5(73) – ASDM 7.4.1.
I did some tests with the latest software (ciphers741.png) but AES256 was still not proposed by the launcher.

I found a bug opened back in 2012 for exactly same issue, which was closed due to inactivity. Developers mentioned there that launcher is using all the ciphers supported by Java installed on client PC.
https://tools.cisco.com/bugsearch/bug/CSCtx78540/

Please refer to:
https://en.wikipedia.org/wiki/Java_Cryptography_Extension

JCE adds additional ciphers support for a Java client.
I downloaded the JCE for Java 7 

Then I copied local_policy.jar and US_export_policy.jar to the $JAVA_HOME/jre/lib/security (these jars were already there so I had to overwrite them).

After that I tried once again and it worked.

————————————–

OK, that seems fair enough, and Kudos to the TAC engineer who had really gone the extra mile. So I thought I’d try and replicate it on the test bench.

Replace Java Ciphers

Then it worked fine, so I logged the results once again;

%ASA-6-302013: Built inbound TCP connection 2900 for inside:192.168.100.10/63760 (192.168.100.10/63760) to identity:192.168.100.1/2456 (192.168.100.1/2456) %ASA-6-725001: Starting SSL handshake with client inside:192.168.100.10/63760 for TLS session. %ASA-7-725010: Device supports the following 1 cipher(s). %ASA-7-725011: Cipher[1] : AES256-SHA %ASA-7-725008: SSL client inside:192.168.100.10/63760 proposes the following 23 cipher(s). %ASA-7-725011: Cipher[1] : AES256-SHA256 %ASA-7-725011: Cipher[2] : DHE-RSA-AES256-SHA256 %ASA-7-725011: Cipher[3] : DHE-DSS-AES256-SHA256 %ASA-7-725011: Cipher[4] : AES256-SHA %ASA-7-725011: Cipher[5] : DHE-RSA-AES256-SHA %ASA-7-725011: Cipher[6] : DHE-DSS-AES256-SHA %ASA-7-725011: Cipher[7] : AES128-SHA256 %ASA-7-725011: Cipher[8] : DHE-RSA-AES128-SHA256 %ASA-7-725011: Cipher[9] : DHE-DSS-AES128-SHA256 %ASA-7-725011: Cipher[10] : AES128-SHA %ASA-7-725011: Cipher[11] : DHE-RSA-AES128-SHA %ASA-7-725011: Cipher[12] : DHE-DSS-AES128-SHA %ASA-7-725011: Cipher[13] : AES256-GCM-SHA384 %ASA-7-725011: Cipher[14] : DHE-RSA-AES256-GCM-SHA384 %ASA-7-725011: Cipher[15] : DHE-DSS-AES256-GCM-SHA384 %ASA-7-725011: Cipher[16] : AES128-GCM-SHA256 %ASA-7-725011: Cipher[17] : DHE-RSA-AES128-GCM-SHA256 %ASA-7-725011: Cipher[18] : DHE-DSS-AES128-GCM-SHA256 %ASA-7-725011: Cipher[19] : DES-CBC3-SHA %ASA-7-725011: Cipher[20] : EDH-RSA-DES-CBC3-SHA %ASA-7-725011: Cipher[21] : EDH-DSS-DES-CBC3-SHA %ASA-7-725011: Cipher[22] : RC4-SHA %ASA-7-725011: Cipher[23] : RC4-MD5 %ASA-7-725012: Device chooses cipher : AES256-SHA for the SSL session with client inside:192.168.100.10/63760 %ASA-6-725002: Device completed SSL handshake with client inside:192.168.100.10/63760

Note: We now have 23 cipher proposals from the client.

Solution 3

Java 7 Update 51

Java Version 7 update 51 (Released Jan 2014) does not play nice with the Cisco ASDM.

Note: This is NOT the case if the ASDM presents a known, trusted, (not self signed) digital certificate.

Java 7 Update 51 ASDM

Option 1

The easiest option is simply remove Java and downgrade to Java Version 7 Update 45

Java 7 Update 45 ASDM

OR

You can also upgrade your ASDM to version 7.1(5.100) or later, and use the Java Web Start Option.

Java Web Startjava

OR

Create a Java site exception. Note: This DID NOT WORK for me with Java version 7 update 51 to both ASDM Versions 7.1(1) and 7.1(5.100). I only put it here for completeness, because Cisco say it’s a solution.

Java 7 Site Exception

Related Articles, References, Credits, or External Links

Original Article Written 11/02/14

Kudos and thanks to Michal Kunikowski from Cisco TAC for his assistance.

 

Author: Migrated

Share This Post On