ASA 8.0 VPN cluster with WEBVPN and Certificates

Unanswered Question
Sep 25th, 2007
User Badges:

I'm looking for advice from anyone who has implemented or tested ASA 8.0 in a VPN cluster using WebVPN and the AnyConnect client. I have a stand alone ASA configured with a public certificate for SSL as, which works fine.

According to the config docs for 8.0, you can use a FQDN redirect for the cluster so that certificates match when a user is sent to another ASA.

Has anyone done this? It looks like each box will need 2 certificates, the first being and the second being or depending on whether this is ASA1 or ASA2. I also need DNS forward and reverse entries, which is no problem.

I'm assuming the client gets presented the appropriate certificate based on the http GET.

Has anyone experienced any issues with this? Things to look out for migrating to a cluster? Any issues with replicating the configuration and certificate to a second ASA?

Example: Assuming ASA1 is the current virtual cluster master and is also ASA 2 is A user browses to and terminates to ASA1, the current virtual master. ASA1 should present the certificate. ASA1 determines that it has the lowest load and redirects the user to to terminate the WebVPN session. The user should now be presented a certificate that matches ASA2 should also have the certificate for in case it becomes the cluster master during a failure scenario.



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Anonymous (not verified) Mon, 10/01/2007 - 10:54
User Badges:

Make sure trust points are correct. For Load balancing to work You would have a VPN LB cluster with these two devices, assuming they share the same IP-networks.

I just had a case open asking these same questions. To over simplify what I just went through, you need three certificates (,, and You install the vpn and vpn1 certificates on ASA1 and vpn and vpn2 on ASA2. Assuming your outside interface is named "Outside" and you certificates are named Thawte and Thawte1 issue the following commands:

ssl trust-point Thawte1 Outside

ssl trust-point Thawte Outside vpnlb-ip

Like I said above I just worked through all of this with a TAC case. The examples given here are what I recieved from the tech I worked with.

cairnsm Thu, 11/01/2007 - 07:18
User Badges:

I have been delayed on finishing this due to other clients and the fact that it works on the single ASA right now.

I didn't see the vpnlb-ip option in the command document that I looked at for 8.0.

I was wondering how this would be set up since I already have a trustpoint associated with the interface and didn't see the option of associating a trustpoint to the load balance IP. It might have been crytal clear if it was documented. I'll have to go back and download the latest command reference PDF.

Thanks for the feedback.


kellerja1 Sun, 11/18/2007 - 05:24
User Badges:

I'm going through the same issue now with a pair of ASA 5540s. I added a vpnlb-ip trust point, but I'm still getting only the physical interface certificate presented to connecting clients when the vpn load-balance IP is used.

There is a bug associated with this issue: CSCsj38269. Apparently it is fixed in the iterim release, but when I upgraded to 8.0.3 this morning the bug is still there.

Here are the details:



ASA 8.0 load balancing cluster with WEBVPN.

When connecting using a web browser to the load balancing ip address or FQDN,

the certifcate send to the browser is NOT the certificate from the trustpoint

assigned for the load balancing using the

"ssl trust-point vpnlb-ip" command.

Instead its using the ssl trust-point certificate assigned to the interface.

This will generate a certificate warning on the browser as the URL entered

on the browser does not match the CN (common name) in the certificate.

Other than the warning, there is no functional impact if the end user

continues by accepting to proceed to the warning message.



webvpn with load balancing is used



1) downgrade to latest 7.2.2 interim ( or later)

Warning: configs are not backward compatible.

2) upgrade to 8.0.2 interim ( or later)

cairnsm Thu, 12/20/2007 - 06:35
User Badges:


I configured this the other day and experienced the issue with 8.0.3. I was going to open a case tomorrow when on-site. Sounds like the answer is to drop back to the interim release. I'll give it a shot in the morning. Otherwise, things seem to work.

I had bumped this firewall set from 8.0.2 to 8.0.3 before configuring the load balancing piece.



kellerja1 Thu, 12/20/2007 - 06:49
User Badges:

If the certificates where generated before the update, it appears to be affected. TAC resolved this for me by deleting the trust points and certs and then we regenerated them. After re-assigning the new certs to the interfaces in the GUI, and then using the command line to set the vpn-lb cert this worked as expected.

cairnsm Thu, 12/20/2007 - 06:58
User Badges:

Are you using certs from an internal CA? I have public certs that were requested from within 8.0.2. I don't mind removing everything and reinstalling the certs if I have to, but I'll try to downgrade from 8.0.3 to the interim release and see what happens.


cairnsm Wed, 12/26/2007 - 07:18
User Badges:

I finished configuring this setup with 8.0(3). I confirmed with TAC that the fix for the bug mentioned earlier in this thread does exist in this code.

I did not have to do anything with the public certs that were requested and installed with 8.0(2) code via Thawte.

One thing I noticed when working in command line, was changing trustpoints. It looks like the 'ssl encryption" command gets removed if you remove your trustpoints and add them back in with the appropriate physical and vip interface options, while the ASDM will apply the command as part of the trustpoint change. When making the change via command line, I started getting a self signed cert even though all of the trustpoints were associated. When going into "Configuration>Remote Access VPN>Advanced>SSL Settings" via ASDM, the encryption algorithms needed to be applied again.

This appears to be a common thing with the ASA where removing underlying config will delete something else, like removing and redefining an ACL will delete the command that associated the access-group with an interface.

Thanks for everyone's input. Feel free to contact me offline (via my profile) for specific details if needed.


My ASA's (8.0.3) are now straightened out. The bug fix in in 8.0.3 code, but a straight upgrade will not solve the problem. After the upgrade I needed to issue the commands

redirect-fqdn disable

redirect-fqdn enable

Under the VPN load-balancing configuration. For soe reason rebooting and having the ASA either participate in the load balanced culsert does not force the certificate for the load balanced address to be handed out.


This Discussion