We are having a problem with the AnyConnect client when connecting to our VPN. We are running the following:
(2 each) ASA v8.2(1) -- active/standby failover
AnyConnect Essentials Licensing
NOTE: We are not using certificates for authentication.
Primary clients: Windows XP and Windows 7
We have purchased an Entrust certificate for our ASA failover cluster called "vpn.company.com" and the it is attached to the outside interface on the ASA.
Steps to Reproduce
The issue is we have a valid certificate that should be used for the connection. However, when looking at the connections made by the AC client with Fiddler, it would appear that the AC client is trying to connect directly to the ASA's IP address, and not the name. This is a nuisance for XP users, and a show-stopper for Win7 users as they do not have admin privileges.
I have not been able to find any documentation on Cisco.com relating to this issue. In short, how do I get the AC client to use "vpn.company.com" so there is no Cert mismatch?
Try to setup the XML file so that the only server in the list is your "vpn.company.com", and see if that resolves the issue. It could be a bad order-of-operations behavior the client is exhibiting where it looks up the host and the launches the tunnel connection using the IP without regard for the dns hostname.
LMK if that helps at all.
I will read through the article more thoroughly; I've already been through parts of it -- won't hurt to go through again. I did initially have the IP address in my XML file, and immediately removed it when I noticed that it was using the IP address in the FIddler dump. It hasn't had any effect unfortunately -- even with uninstalling and re-installing the AC client locally.
The only other article/post I've come across on Cisco's site that comes close is here:
which seems to suggest that I will need a UCC certificate (which seems ridiculous) to do some of what I need to do. However the issue with that post is that it still wouldn't fix the issue where the AC client is using the IP address.
I will let you know if I find any smoking guns in the doco link you sent. Any other thoughts appreciated. I can't believe Cisco made the setup of the AC client this convoluted.
Unfortunately, no. I've not yet found what the issue could be. Of course, not having test gear hasn't helped much either.
One thing I have started looking into is the possibility of enabling the VPN Load Balancing. I'm not currently using it (we don't need the load balancing, just the failover). Under VPN load-balancing, there is an option "redirect-fqdn" -- which should send the client the FQDN, instead of the IP address. It has no effect in just active/standby failover mode alone, and I've not yet had a chance to try and rig up a test.
What's your configuration? Are you using VPN Load Balancing?
Were you able to resolve this issue? I am having this issue with AC 2.5, upgraded to AC 3 and still having the issue. SSL cert works fine, anyconnect connects fine when logging in through the asa, however when using the client I am getting a certificate error.
I also configured the PTR record to match the A-record to no avail.
I'm glad you posted as we were able to get it working, but I'd forgotten I posted here.
We ended up moving our equipment from one rack to another -- when the firewalls came back on-line, everything was working fine -- and the certificate issue was gone. Due to the issue going away, we never got to filing a TAC case.
So, I would try rebooting your ASA. If that doesn't work -- would be very interested at the 'official' solution from Cisco if you're able to file a TAC case.
I have reloaded the firewall since to no avail, I opened a TAC case however the engineer assigned kept repeating that he cannot replicate the issue however I can replicate the issue on all computers that connect to my VPN.
Ugh, just great.
There does definitely seem to be some bug in the ASA code that is the cause. I've even had our Cisco SE onsite to look at it, along with some other colleagues that are ASA experts as well -- they're all stumped.
If TAC can't replicate, perhaps they'd be willing to RMA the device -- so they can have a look at yours when it gets back?