Present Location: News >> Blog >> Cisco AnyConnect and Encryption

Blog

> Cisco AnyConnect and Encryption
Posted by prox, from Charlotte, on November 24, 2012 at 14:38 local (server) time

I've been using the Cisco AnyConnect client for quite awhile as a supported method of extending IPv6 connectivity to my iPad.  It's also come in handy when using unencrypted Wi-Fi networks to prevent snooping.  It's worked flawlessly, except for the last few releases of the AnyConnect client.

Unfortunately, with version 3.1 on Mac OS X and 3.0 on Android, the client just stopped working.  The client tries to connect, then times out after a minute or so.  Previous versions of the client kept working just fine, though.  After digging quite a bit on both the client-side and ASA-side logs, I found absolutely nothing to indicate why the client failed to connect.  For instance, the logs on the server show nothing interesting:

%ASA-6-302013: Built inbound TCP connection 1174 for outside:208.54.87.209/25076 \
(208.54.87.209/25076) to identity:192.0.2.149/443 (192.0.2.149/443)
%ASA-6-725001: Starting SSL handshake with client outside:208.54.87.209/25076 for TLSv1 session.
%ASA-6-725002: Device completed SSL handshake with client outside:208.54.87.209/25076
[... wait a minute or so ...]
%ASA-6-725007: SSL session with client outside:208.54.87.209/64512 terminated.
%ASA-6-302014: Teardown TCP connection 1177 for outside:208.54.87.209/64512 \
to identity:192.0.2.149/443 duration 0:00:26 bytes 130 TCP Reset-I

On the client side (Android, for instance), we have a bunch of generic timeout messages (abridged):

11-24 13:56:36.854 I/vpnandroid(26414): ConnectionActivity: user initiated connection to Example
11-24 13:56:36.870 I/vpnapi  (26414): An SSL VPN connection to vpn.example.com has been requested by the user.
[... removed ...]
11-24 13:56:38.963 D/vpnandroid(26505): CertificateManager: Certificate #0
11-24 13:56:38.963 D/vpnandroid(26505): CertificateManager:     Subject : CN=*.[... removed ...]
11-24 13:56:38.963 D/vpnandroid(26505): CertificateManager:     Issuer  : CN=RapidSSL CA, O="GeoTrust, Inc.", C=US
11-24 13:56:38.963 D/vpnandroid(26505): CertificateManager: Certificate #1
11-24 13:56:38.963 D/vpnandroid(26505): CertificateManager:     Subject : CN=RapidSSL CA, O="GeoTrust, Inc.", C=US
11-24 13:56:38.963 D/vpnandroid(26505): CertificateManager:     Issuer  : CN=GeoTrust Global CA, O=GeoTrust Inc., C=US
11-24 13:56:38.979 I/vpnapi  (26414): Function: VerifyServerCertificate File: AndroidSNAKCert.cpp Line: \
286 client received response with GOOD
[... removed ...]
11-24 13:57:30.924 E/vpnapi  (26414): Function: SendRequest File: CTransportCurlStatic.cpp Line: \
1695 Invoked Function: curl_easy_perform Return Code: -29949906 (0xFE37002E) Description: CTRANSPORT_ERROR_TIMEOUT 28 : Error
11-24 13:57:30.924 E/vpnapi  (26414): Function: sendRequest File: ConnectIfc.cpp Line: 3126 Invoked Function: \
CTransport::SendRequest Return Code: -29949906 (0xFE37002E) Description: CTRANSPORT_ERROR_TIMEOUT
11-24 13:57:30.924 E/vpnapi  (26414): Function: connect File: ConnectIfc.cpp Line: \
468 Invoked Function: ConnectIfc::sendRequest Return Code: -29949906 (0xFE37002E) Description: CTRANSPORT_ERROR_TIMEOUT
11-24 13:57:30.924 E/vpnapi  (26414): Function: TranslateStatusCode File: ConnectIfc.cpp Line: \
2950 Invoked Function: TranslateStatusCode Return Code: -29949906 (0xFE37002E) Description: CTRANSPORT_ERROR_TIMEOUT \
Connection attempt has timed out.  Please verify Internet connectivity.
11-24 13:57:30.924 E/vpnapi  (26414): Function: doConnectIfcConnect File: ConnectMgr.cpp Line: \
2075 Invoked Function: ConnectIfc::connect Return Code: -29949906 (0xFE37002E) Description: CTRANSPORT_ERROR_TIMEOUT
11-24 13:57:30.924 I/vpnapi  (26414): Message type warning sent to the user: Connection attempt has failed.

From the above, there was nothing to conclude.  The ASA didn't respond correctly.  I ran all of the webvpn debugs possible on the ASA and didn't come up with squat.  I then captured amd decoded the SSL traffic, which showed no response to the HTTP POST:

POST / HTTP/1.1
User-Agent: AnyConnect Android 3.0.09073
Host: vpn.example.com
Accept: */*
Accept-Encoding: identity
X-Transcend-Version: 1
X-Transcend-Version: 1
X-AnyConnect-Identifier-ClientVersion: 3.0.09073
X-AnyConnect-Identifier-Platform: android
X-AnyConnect-Identifier-PlatformVersion: 4.1.1
X-AnyConnect-Identifier-DeviceType: Samsung Galaxy Nexus
X-AnyConnect-Identifier-Device-UniqueID: 12DFB4098FFBD9D09952C95C50C3E31017B807E7
X-Aggregate-Auth: 1
Connection: close
Content-Length: 334
Content-Type: application/x-www-form-urlencoded

<?xml version="1.0" encoding="UTF-8"?>
<config-auth client="vpn" type="init">
<device-id platform-version="4.1.1" device-type="Samsung Galaxy Nexus" \
unique-id="12DFB4098FFBD9D09952C95C50C3E31017B807E7">android</device-id>
<version who="vpn">3.0.09073</version>
<group-access>https://vpn.example.com</group-access>
</config-auth>

Oddly enough, the client that still worked, version 2.5 for iOS, showed a GET instead of a POST:

GET / HTTP/1.1
User-Agent: AnyConnect AppleSSLVPN_Darwin_ARM (iPad) 2.5.5130
Host: vpn.example.com
Accept: */*
Accept-Encoding: identity
X-Transcend-Version: 1
X-AnyConnect-Identifier-ClientVersion: 2.5.5130
X-AnyConnect-Identifier-Platform: apple-ios
X-AnyConnect-Identifier-PlatformVersion: 5.1.1
X-AnyConnect-Identifier-DeviceType: iPad3,3
X-AnyConnect-Identifier-Device-UniqueID: fa14141ac8f11d5bcce13a2b2014fe98c786b109
Connection: close

The iOS client above got data back from the server, I just didn't reproduce it here.  Anyway, I couldn't make heads or tails on this, so I upgraded my ASA from 8.4(2) to 8.4(4)5.  This didn't do jack, so I rolled back.  Since I have access to another ASA (running 8.2, I believe), I tested all of the clients against this version.  They all worked!  This indicated that I had a problem in my configuration, somehow.

I tore apart the configuration and went so far as to rebuild the configuration from scratch, testing the clients' connectivity after each step.  They all worked until, and here it is, I added this configuration line:

ssl encryption 3des-sha1 aes128-sha1 aes256-sha1

After that line was added, the newer clients wouldn't connect and did their standard "hang" of death.  Apparently, this was the problem (although I don't see why).  However, by removing the line, I was left with the RC4 stream cipher:

icarus# show run | i ^ssl.enc
icarus# show ssl 
Accept connections using SSLv2, SSLv3 or TLSv1 and negotiate to SSLv3 or TLSv1
Start connections using SSLv3 and negotiate to SSLv3 or TLSv1
Enabled cipher order: rc4-sha1 aes128-sha1 aes256-sha1 3des-sha1
Disabled ciphers: des-sha1 rc4-md5 null-sha1
SSL trust-points:
  inside interface: ASDM_TrustPoint0
  outside interface: ASDM_TrustPoint0
Certificate authentication is not enabled

I then tried a different configuration:

ssl encryption 3des-sha1 aes128-sha1

No dice on this, either.  In fact, I tried a few different combinations and the only ones that worked were ones that had RC4 listed first.  Apparently there is some bug or issue with the encryption types that don't bother affecting the SSL or TLS connection, yet cause the whole WebVPN subsystem to hang!

Anyway, I suppose I'm happy with RC4, for now, since it works.  It's not like I have any super-secret stuff to hide, I'd probably be fine with DES encryption!

Hopefully this will help someone out there fighting with the newer AnyConnect client versions.  I didn't find anything using Google or Bing that related to this type of issue.

> Add Comment

New comments are currently disabled for this entry.