ASA VPN HTTP 401 When automatic certificate selection is enabled

[powelca]

We're in the process of laying the groundwork for using AAA+Cert auth for VPN connectivity but we've hit a bit of a SNAFU. In the AnyConnect config on the ASA we've specified Certificate Store Override and Automatic Certificate Selection in preparation but now machines are suddenly having issues connecting despite the fact that we haven't enabled cert auth yet. 

The message that is received by the end user is: "The secure gateway has rejected the connection attempt. A new connection attempt to the same or another secure gateway is needed, which requires re-authentication. The following message was received from the secure gateway: Other error.

If I look closer in the logs it looks like the error is being generated by this: "The HTTP response code from the secure gateway is 401, Other error HTTP/1.1 401 Unauthorized

To add to my own confusion here are some other things that I can't explain.

If I manually uncheck "Automatic Certificate Selection", I can connect again. I'm not prompted to select a cert as I would expect because certificate auth is not required anywhere.

If I connect directly to a VPN appliance instead of using the load balanced name, this works. Maybe this is a load balancer issue but from the logs it seems like the client is reaching out to an appliance at the point that the failure occurs so I'm not sure what else to try... I'll probably open a TAC case but I figured I'd see if anyone else has some suggestions.

[sbrunell]

Hi,

I have the same issue. Did you finally find the answer to your problem ?

Thanks a lot in advance

Sylvie

[powelca]

Appears to be this:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvt81585

For the time being we had to disable load balancing and are operating with a single appliance with the secondary configured as a failover.

[CMD0968]

Did you ever get any kind of resolution from TAC on this other than to disable LB?

[powelca]

We were provided with a hotfixed version of AnyConnect that seems to resolve the issue but since we've already worked around the problem we opted to wait for the next GA release. Rumor has it this will be sometime in June.

[powelca · Accepted solution]

In case anyone stumbles upon this in the future, this bug is marked as fixed in AnyConnect 4.9.00086. In my testing I have not been able to reproduce the issue. :)

[CMD0968]

Thanks, @powelca for the followup.  When you migrated to 4.9, did you have any issues with the update to the algorithms?

---

---

• For SSL VPN, AnyConnect no longer supports the following cipher suites from both TLS and DTLS: DHE-RSA-AES256-SHA and DES-CBC3-SHA

• For IKEv2/IPsec, AnyConnect no longer supports the following algorithms:

  • Encryption algorithms: DES and 3DES

  • Pseudo Random Function (PRF) algorithm: MD5

  • Integrity algorithm: MD5

  • Diffie-Hellman (DH) groups: 2, 5, 14, 24

[Marvin Rhoads]

Those are old algorithms deprecated in AC 4.9. As long as you are running a relatively modern ASA (i..e. running software released in the last 5 years) you should have no problem supporting the newer algorithms, especially for SSL VPN.

If you are using IKEv2 for your remote access VPN (uncommon) and have hard-coded the only the older DH groups or hash algorithm then you could potentially have issues (easily resolved but still issues).

You can always test by upgrading one client using the offline installer and then connecting to your VPN.