ASA VPN Load Balancing/Clustering with Digital Certificates Deployment Guide

Document

Aug 25, 2009 8:18 AM
Aug 25th, 2009


This document describes the best practice and alternative scenario for deploying ASA-5500 VPN remote access solution in a Load Balancing/Clustering environment using digital certificates authentication.

For more information on VPN Load Balancing/Clustering High Availability services of the ASA appliances please consult the configuraiton guide at http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/vpnsysop.html#wp1048834. Please check cisco.com for new versions of the document.

For more information on configuring Certificates on the  the ASA appliances please consult the configuraiton guide at

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/cert_cfg.html .Please check cisco.com for new versions of the document.

I. Best Practice procedure for deploying with one Unified Client Certificate (UCC)

General Steps:

1) Obtain One UCC with multiple SANs (Subject Alternative Name extensions) with each ASA FQDN/IP included.

Therefore you need one UCC certificate with the CN for the cluster FQDN and/or cluster IP, and SANs for each ASA in hte cluster: ASA-1 FQDN and/or IP, ASA-2 FQDN and/or IP, and so on. Several PKI/Certificate vendors such as Entrust.com support UCC , a.k.a Unified Client Multi-Domain SSL certificates.

Note: The ASA cannot generate a Certificate Signing Request (CSR) with multiple SANS (CSCso70867 is the enhancement asking for this capability ), so you have to have the CA/PKI vendor submit the enrollment for you.


2) On ASA master configure one trustpoint '<name>' pointing to the virtual/cluster.

Example of CLI is below:

crypto ca trustpoint asa-cluster
subject-name CN=asa-cluster.company.com,OU=Department,O=Company,L=City,ST=Massachusetts,C=US
enrollment terminal



Now import the certificate obtained from the CA/PKI vendor:



crypto ca import certificate command.

The adaptive security appliance prompts you to paste the certificate to the terminal in base-64 format.

3)Then export that trustpoint as pkcs12 (certificate and keys will be exported)

crypto ca export asa-cluster pkcs12 <passphrase>


Copy the resulting output and save it to a text file.

4)Then import the pkcs12 to each ASA member of the cluster

crypto ca import asa-cluster pkcs12 <passphrase>

5)Configure all ssl <interface and ssl outside vpnloadbalanced commands pointing to the imported trustpoint '<name>'.

6) Initiate your VPN remote access sessions (IPsec clients, AnyConnect SSL client,Clientless browser-based SSL VPN) to the Load Balanced Virtual IP (VIP) or FQDN.

II. Alternative using Multiple Certificates or Wilcard Certificates

  • A) requires n+1 number of IP addresses and/or DNS-FQDN and n+1 number of certifcates.

The example below deploys a 2 node-cluster, therefore 3 IPs/DNS-FQDNs are needed.

-Three certificates (one for asa-cluster, one for asa1, and one for asa2)  are required

  • B) One wilcard certificate

Wilcard certificates are discouraged in favor of UUC certs. According to one vendor, Entrust,  these are 2 main reasons:

  1. UCC is more secure than wildcard certificates since Entrust UC Certificates specify exactly which hosts and domains are to be protected
  2. UCC is more flexible than wildcard certificates since Entrust UC Certificates aren't limited to a single domain

The procedure for using Multiple Certifcates follows:

Configuration example with  two ASAs operating as a Load-balancing cluster using multiple certificates

VPN cluster IP address:     10.10.1.1
ASA1 outside IP:            10.10.1.2
ASA2 outside IP:            10.10.1.3


DNS Configuration (domain = company.com):

hostname:          IP:
asa-cluster        10.10.1.1
asa1               10.10.1.2
asa2               10.10.1.3


VPN Load Balancing configuration ( on all ASA's in the cluster)

vpn load-balancing
redirect-fqdn enable
cluster ip address 10.10.1.1
participate

Name Resolution: The redirect-fqdn enable setting makes the ASA issue a redirect using hostname as opposed to IP address. This *requires* that the DNS in use has appropriate reverse dns records for hostnames involved in order to function, and that the ASA, not the client, can do this resolution..  This should be configured to avoid certificate hostname mismatch popup warnings.

To test that name resolution is working on the ASA, issue a ping command to the cluster's fqdn, and to each member's fqdn. All ASA cluster members should be able to resolve those names in order for redirect to work.

As a workaround, you can put names on the ASA itself to resolve those addresses, if DNS is not an option

Example:

name 10.10.1.1 asa-cluster.example.com
name 10.10.1.2 asa1.example.com              
name 10.10.1.3 asa2.example.com    

After this, the asa should be able to resolve asa-cluster.example.com, asa1.example.com, and asa2.example.com. You can test this by issuing a ping to all 3 addresses. ICMP may not work, but the asa should be able to give you an IP address for each of the names. If it doesn't, please check name resolution again as redirect-fqdn will not work without it.


Trustpoint configurations

1) asa1 ID certificate trustpoint


crypto ca trustpoint myca
subject-name CN=asa1.company.com,OU=Department,O=Company,L=City,ST=Massachusetts,C=US

Optionally ou could include CN=<asa1 IPAddress> in DN above.

2) asa2 ID certificate trustpoint


crypto ca trustpoint myca
subject-name CN=asa2.company.com,OU=Department,O=Company,L=City,ST=Massachusetts,C=US

Optionally ou could include CN=<asa2 IPAddress> in DN above.

3) load-balancing trustpoint - configured on either ASA and can be imported to all  other ASAs in the cluster


crypto ca trustpoint asa-cluster
subject-name CN=asa-cluster.company.com,OU=Department,O=Company,L=City,ST=Massachusetts,C=US

Optionally ou could include CN=<asa-cluster IPAddress> in DN above.

4) Exporting and Importing Load balancing trustpoint to member ASAs

Once this trustpoint is authenticated and enrolled (both CA and ID certs are present) it can be exported to pkcs12 and imported to all load-balancing cluster member ASAs using the following procedure:


a. Export the trustpoint (certificates and keys)  to a password protected pkcs12.

crypto ca export asa-cluster pkcs12 <passphrase>


Copy the resulting output and save it to a text file.


b. Import the pkcs12 to other ASA's

crypto ca import asa-cluster pkcs12 <passphrase>


Paste pkcs12 data in and enter 'quit' on a line by itself when finished to end the process.

Note: The export/import process only migrates the certificates/keypair from one device to another. Any necessary trustpoint configuration must be manually reconfigured (like revocation-check, CRL options, etc.).

Important note: In versions prior to 8.0(3)6, you were unable to export a trustpoint that only had the ID certificate properly. This created an issue because in ASDM, the ID certificate and the CA certificate were put in 2 different trustpoints. If you run into an issue where you do the import of the cluster certificate on a cluster member, and it says it was successful but the certificate doesn't show up, this is most likely your issue. Go back to the ASA that issued the CSR for the cluster certificate, and authenticate that trustpoint with the issuing certificate and then re-export it. See CSCsl59266 for more details.


At this point the asa-cluster certificates are installed and can be used to correctly identify SSL requests that come into the cluster IP address/hostname .

SSL configuration for using the LB certificate

ssl trust-point myca outside
ssl trust-point asa-cluster outside vpnlb-ip

III. Client Connection Experience for Clientless SSL VPN using a browser


The client connection experience using a browser (Clientless SSL VPN)  is as follows:

a. Client browses to https://asa-cluster.company.com and ASA sends its ID cert to the client.  Note: If client certificate authenticaiton is enabled , client will be prompted to choose a ID certificate fro mthe browser popup.

- The issuer of the ASA certificate should be trusted by the client and therefore shouldn't warn.

- The name that was browsed to (asa-cluster.company.com) is in the ASA cluster certificate so it shouldn't warn of hostname mismatch.


b. Cluster master decides best ASA to redirect to (asa2 in this example) and sends a redirect to client.


c. Client silently initiates new connection to https://asa2.company.com and ASA2 sends its ID cert to the client.

- The issuer of the ASA certificate should be trusted by the client and therefore shouldn't warn.

- The name that was browsed to (asa2.company.com) is in the ASA2 certificate so it shouldn't warn of hostname mismatch.


d. Client experience depends on ASA authentication configuration.

- AAA only - client is prompted to authenticate at login portal and/or choose a group (if tunnel-group-list enable and group-alias is set)

- Certificate authentication  only with group-url or certificate map - client is connected and sees webvpn portal/links, etc.

- Certificate authentication only without group-url or certificate map (group-alias is enabled instead) - client must select a group from portal and click connect. Connection complete.

- AAA + Certificate authentication - with group-url or certificate map - Certificate autheentication  takes place, then client will be prompted for AAA; after entering, connection is complete.

- AAA + Certificate authentication - without group-url  or certificate map (group-alias is enabled instead) - client will be prompted for aaa and group selection (if tunnel-group-list enable is set); after entering, connection is complete.

Average Rating: 5 (2 ratings)

Comments

lanstreamer Tue, 10/27/2009 - 09:13

Thanks for this.  I hadn't considered deploying load balancing for Anyconnect clients using UCCs - will save money on certificates this way hopefully.  I've tried this now but don't want to use redirect-fqdn enable so want to redirect from a load balanced url with a hostname to individual IPs in the cluster.

My cluster:

Load balancing name     entrypoint.domain.com (10.0.0.3)

Load balancing IP          10.0.0.3

ASA 2                          10.0.0.2

ASA 1                          10.0.0.1   

My cert has a subject of entrypoint.domain.com and Sans

X509v3 Subject Alternative Name:
DNS:10.0.0.1, DNS:10.0.0.2, DNS:10.0.0.3

A browser / anyconnect is fine to these URLs with no certificate errors.  Loadbalancing works fine if I point clients to https://10.0.0.3/ 302 redirects to .1 and .2)

https://10.0.0.1/

https://10.0.0.2/

https://10.0.0.3/

However, when the master ASA redirects by issuing a 302 from https://entrypoint.domain.com to https://10.0.0.1 or https://10.0.0.2 the browser and anyconnect pop up a certificate error complaining about the name of the certificate.

Has anyone else tested this scenario redirecting from names to IPs using UCCs?  Any ideas what might be going wrong?

cole.b Mon, 09/27/2010 - 17:48 (reply to lanstreamer)

Unless your certificate has a SAN with the IP address, the browser will complain about it.  The best way to handle this if you have to use IP address (recommend against it) would be to get a UCC with the FQDN and the SANs as all the other IP addresses of the nodes in the cluster.  If this must be a public facing site, you would need to go to globalsign.  Most other CAs will only allow RFC1918 addresses as SAN.

If this is all internal, then have your internal CA issue issue the UCC and you can put whatever you want in the SAN.

kpruett Wed, 08/18/2010 - 08:40

I'm at a point where I need to attempt this method for my organization and noticed the enhancement request as (CSCso70867.) Since this original post was over a year ago, has any progress been made toward resolving this request or do I still need to ask the PKI vendor to generate my enrollment request for me?

cole.b Mon, 09/27/2010 - 17:55 (reply to kpruett)

I haven't had a problem using a 3rd party (GoDaddy) for UCC certs while having the ASA issue the CSR.  Generate the CSR on the ASA with the CN, then at the CA (Godaddy/Entrust/Thawte/Globalsign) add the SANs.  Import on your ASA and assign the trustpoint to the interface and access from your browser to all the SANs (no cert error messages).

kpruett Tue, 09/28/2010 - 06:16 (reply to cole.b)

Good tips, Cole, thanks for the response. I might even switch to GoDaddy if it would make this easier. I got around my initial problem by splitting one of the two FQDN's off to it's own ASA, but my main ASA's will have this issue coming up soon.

stevechapman_2 Thu, 02/17/2011 - 08:11

great post.  Now the problem I have is the cert works fine for IE, but fails when used by firefox any reason why?

thx

Steve Chapman

goulintelstra Tue, 01/10/2012 - 19:36

Hi,

Thanks for the example.  I am trying to set this up, and am encountering an issue whereby the ASAs actually sit behind a firewall which does the NAT translation for the outside address.  Whenever I browse to the NAT cluster IP address, I am being redirected to the real outside IP, not the NAT outside IP.  Is this something that should work with NAT?  See below for config example:

* 3 ASAs - outside IPs of 10.1.1.1, 10.1.1.2, 10.1.1.3, and NATs of 203.1.1.1, 203.1.1.2, 203.1.1.3

* Cluster IP is 10.1.1.4, with NAT of 203.1.1.4

* Config on ASAs:

vpn load-balancing

nat 203.1.1.4

redirect-fqdn enable

interface lbpublic outside

interface lbprivate inside

cluster ip 10.1.1.4

participate

Thanks

goulintelstra Tue, 01/10/2012 - 19:41 (reply to goulintelstra)

I figured this out - I removed the nat configuration, and added name entries for each ASA pointing to the public name of the ASA.

e.g.

name 10.1.1.1 vpn1.company.com

name 10.1.1.2 vpn2.company.com

name 10.1.1.3 vpn3.company.com

Actions

Login or Register to take actions

This Document

Posted August 25, 2009 at 8:18 AM
Stats:
Comments:9 Avg. Rating:5
Views:28762 Contributors:6
Shares:0
Categories: ASA
+

Related Content

Documents Leaderboard

Rank Username Points
1 65
2 56
3 55
4 30
5 24
Rank Username Points
10
5