ASA 8.0 VPN cluster with WEBVPN and Certificates

Unanswered Question
Sep 25th, 2007

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 vpn.xxxx.org, 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 vpn.xxxx.org and the second being vpn1.xxxx.org or vpn2.xxxx.org 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 vpn1.xxxx.org. ASA 2 is vpn2.xxxx.org. A user browses to vpn.xxxx.org and terminates to ASA1, the current virtual master. ASA1 should present the vpn.xxxx.org certificate. ASA1 determines that it has the lowest load and redirects the user to vpn1.xxxx.org to terminate the WebVPN session. The user should now be presented a certificate that matches vpn1.xxxx.org. ASA2 should also have the certificate for vpn.xxxx.org in case it becomes the cluster master during a failure scenario.

Thanks,

Mark

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
Anonymous (not verified) Mon, 10/01/2007 - 10:54

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 (vpn.xxxx.org, vpn1.xxxx.org, and vpn2.xxxx.org) 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

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.

Mark

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

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 8.0.2.11, but when I upgraded to 8.0.3 this morning the bug is still there.

Here are the details:

Symptom:

========

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.

Condition:

=========

webvpn with load balancing is used

Workaround:

===========

1) downgrade to latest 7.2.2 interim (7.2.2.8 or later)

Warning: configs are not backward compatible.

2) upgrade to 8.0.2 interim (8.0.2.11 or later)

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

Thanks,

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.

Thanks,

Mark

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

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

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.

Mark

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

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.

Mark

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.

Actions

This Discussion