Cisco ASA VPN Load Balancing is a mechanism used to distribute Remote Access VPN connections equal amongst the ASA devices in the virtual cluster. One ASA device in the cluster is defined as the “master”, which redirects connection requests to the other devices. All other ASA devices in the virtual cluster are “backup” nodes and can take over the “master” role if the master fails.
When a Remote Access VPN user connects, the initial request is sent to the Load Balancer FQDN. The “master” uses the load balancing algorithm to determine the least loaded ASA and the client is redirected.
Key Information
- A Load Balancing cluster consists of two or more ASA devices.
- One device is defined as the master, the remaining devices are backups.
- Load Balancing is currently only supported on ASA software, not FTD
- Load Balancing is not supported in multi-context mode
- Supports up to 10 nodes in a Load Balancing cluster
- All devices must be on the same inside and outside IP network
- Supports IKEv2/IPSec and SSL VPN (Client and Clientless)
- Configuration is not replicated between the devices
- VPN IP Address Pool must be unique per ASA
Load Balancing Algorithm
- All nodes begin with 0% load, and all percentages are rounded to the nearest half-percent.
- The master device only takes a connection if all the members have a load that is one percent higher than the master device.
- If the master device does not take the connection, the session is taken by the backup device that currently has the smallest load
- If all the members have the same load percentage, then the backup device with the least amount of sessions takes the session.
- If all the members have the same load percentage and the same number of sessions, then the backup device with the least amount of IP addresses takes the session.
Master Election Process
The VPN load balancing Master Election process is performed on the cluster outside network. There are two types of data exchanged on the outside network:
- Address Resolution Protocol (ARP) packets for the cluster IP address that are used for master discovery are exchanged. The maximum number of ARP packets that are sent for the cluster IP address in order to discover the master is: (10 – priority) + 1
- UDP packets on port 9023 (unless changed from default) for the Hello request/response messages are exchanged on the inside interface.
As an example, if the priority is five for a load-balancing device, it attempts to send up to six ARP packets (10 – 5 + 1 = 6) in order to see if any master device owns the cluster IP address. If a master device is detected, the ASA does not send any more ARP messages and waits 15 seconds before it sends the UDP Hello request. The master device then responds with an UDP Hello response.
Cisco reference guide to ASA VPN Load Balancing Master Election Process
Certificates
Certificates are used with Remote Access VPN’s in order for the client to perform server authentication and establish encrypted communication. It is recommended to use a public signed certificate from a trusted third-part Certificate Authority (Verisign, QuoVadis, GoDaddy etc) to ensure the user does not inadvertently trust a certificate from a rogue server.
When establishing a connection to an ASA VPN Load Balancer, the client must trust the VPN Load Balancer FQDN certificate for the initial connection and once redirected, each of the ASA’s load balanced.
- User establishes a VPN connection to the load balancer FQDN certificate. E.g. vpn-lb.companyname.com
- The connection is redirected to the least loaded ASA, connecting to the ASA’s identity certificate e.g. companyname.com or asa2.companyname.com
When using certificates with VPN Load Balancing it is recommended to use a Multi Domain Certificate, this certificate will specific the load balancing FQDN as the DN and the FQDN of each ASA as a separate Subject Alternative Name (SAN). This same certificate is imported to all load balanced ASAs.
Figure 1- Example: Multi-Domain (SAN) Certificate
- ASA does not support creation of Certificate Signing Request (CSR) with multiple SAN field, in this scenario openssl can be used to create the CSR.
Configuration
This post will describe how to configure Two ASAv version 9.12(3) firewalls with VPN Load Balancing.
Certificate Configuration
As the ASA does not support the creation of a CSR with SAN fields, we will use openssl on Ubuntu linux.
- Login to linux, on the CLI create a san configuration
- Enter the command sudo vi san.conf
- Copy and paste the configuration below, changing the relevant information
[ req ] default_bits = 4096 prompt = no encrypt_key = no default_md = sha256 distinguished_name = dn req_extensions = req_ext [ dn ] CN = vpn-lb.lab.local emailAddress = admin@lab.local O = LAB OU = IT Services L = London ST = London C = GB [ req_ext ] subjectAltName = DNS: vpn-lb.lab.local, DNS: asa1.lab.local, DNS: asa2.lab.local, DNS: asa3.lab.local
- Save the file using the command :w!
- Quit vi using the command :q!
- Create a Private Key and CSR using the san.conf using the command below
openssl req -new -config san.conf -keyout vpn-lb.key -out vpn-lb.csr
- View the output of CSR using the command below
openssl req -text -noout -verify -in vpn-lb.csr
Confirm the output includes the Subject Alternative Name as defined in the san.conf file.
admin@ubuntu:~$ openssl req -text -noout -verify -in vpn-lb.csr verify OK Certificate Request: Data: Version: 1 (0x0) Subject: CN = vpn-lb.lab.local, emailAddress = admin@lab.local, O = LAB, OU = IT Services, L = London, ST = London, C = GB Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (4096 bit) Modulus: 00:bd:c7:a5:76:a6:01:17:47:aa:1f:58:d6:1c:c2: d6:a9:69:94:7e:01:8e:b4:5a:8e:f9:fb:28:2f:fe: 81:0b:3b:f1:98:f7:7e:66:de:b6:9c:54:43:41:a7: 19:b1:99:bf:0b:7d:3f:f7:bd:d5:83:97:60:58:da: 68:74:1d:d2:15:38:99:b8:c1:f2:e1:e4:34:14:19: c0:75:43:d7:1b:4e:2d:f0:e4:a0:06:12:f7:af:14: 56:7b:f7:2b:fe:1d:40:b9:15:e3:be:75:a9:2a:78: 47:7c:e6:28:a7:d7:1f:10:bd:88:d0:b3:e3:a2:a5: 39:47:05 Exponent: 65537 (0x10001) Attributes: Requested Extensions: X509v3 Subject Alternative Name: DNS:vpn-lb.lab.local, DNS:asa1.lab.local, DNS:asa2.lab.local, DNS:asa3.lab.local
- Send the CSR file vpn-lb.csr to the Public Certificate Authority to be signed
- Once the certificate has been signed and returned from the CA, rename the identity certificate as vpn-lb.cer
- Merge the Issuing Certificate and Root Certificates into one file called cer
- Copy the the file vpn-lb.cer and cer certificates on to the linux server or which computer is running openssl
- Create a PKCS12 file called vpn-lb.pfx containing the Private Key, Signed Certificate and Root Certificates, using the command below.
openssl pkcs12 -export -out vpn-lb.pfx -inkey vpn-lb.key -in vpn-lb.cer -certfile RootCert.cer
admin@ubuntu:~$ openssl pkcs12 -export -out vpn-lb.pfx -inkey vpn-lb.key -in vpn-lb.cer -certfile RootCert.cer Enter pass phrase for vpn-lb.key: ******** Enter Export Password: ********* Verifying - Enter Export Password: *********
- The ASA expects to import the server certificate in pkcs(.p12) format encoded with base64, the .pfx file can be encoded in base64 with the following command.
openssl base64 -in vpn-lb.pfx > vpn-lb-b64.pfx
- Copy the vpn-lb-b64.pfx file off the linux server, this will be imported on to each ASA in later steps.
ASA Configuration
This post will only cover VPN Load Balancing specific configuration and assumes that a basic AnyConnect SSL-VPN configuration has been configured on each ASA. The links below covers AnyConnect Remote Access VPNs in more detail:
The following configuration must be configured on each ASA node.
RSA Keypair and Certificate Trustpoint
Create an RSA Key and the Certificate Trustpoint
crypto key generate rsa label VPN_LB_KEY modulus 2048 crypto ca trustpoint VPN_LB enrollment terminal keypair VPN_LB_KEY
Import the certificate
crypto ca import VPN_LB pkcs12 <passphrase> ASA-1(config)# crypto ca import VPN_LB pkcs12 Cisco1234 Enter the base 64 encoded pkcs12. End with the word "quit" on a line by itself: MIIYKQIBAzCCF+8GCSqGSIb3DQEHAaCCF+AEghfcMIIX2DCCDgcGCSqGSIb3DQEH BqCCDfgwgg30AgEAMIIN7QYJKoZIhvcNAQcBMBwGCiqGSIb3DQEMAQYwDgQImitU qw1thacCAggAgIINwOMGbErdLvFBSyrTNEOeq9kIefnkVp8Ha8WczR58EeSiDrD2 SfoZsyF+CBiCvSew8NLy/KpjR/wk1IU4jBuCwBhy9wWpN3NHcmFAxpaFz2tL8wCj xdb6bNykyhJQ6uSewK/QjyXVvcmXUPDuYMz862Xdrk55p6mrYpIWsOfvU6WjnNGK quit
NOTE – the same certificate is imported to each ASA node.
Certificate Trustpoint
Configure the VPN_LB Trustpoint on the outside interface for the primary certificate and the load balancing certificate.
ssl trust-point VPN_LB OUTSIDE ssl trust-point VPN_LB OUTSIDE vpnlb-ip
VPN Pool
Define a unique VPN Pool on each ASA device.
ASA1
ip local pool VPN_POOL 192.168.14.10-192.168.14.254 mask 255.255.255.0
ASA2
ip local pool VPN_POOL 192.168.15.10-192.168.15.254 mask 255.255.255.0
VPN Load Balancing
The configuration steps are identical on each ASA node, except the priority must be unique on each node. “1” would define the master.
ASA 1
vpn load-balancing redirect-fqdn enable priority 1 interface lbpublic OUTSIDE interface lbprivate INSIDE cluster key ***** cluster ip address 11.11.11.1 participate
ASA 2
vpn load-balancing redirect-fqdn enable priority 2 interface lbpublic OUTSIDE interface lbprivate INSIDE cluster key ***** cluster ip address 11.11.11.1 participate
Name Resolution
When using the redirect-fqdn enable setting, the ASA will issue a redirect using the hostname instead of the IP address – this should be configured to avoid certificate errors on the client (unless the IP address has been defined in the SAN fields). The ASA itself performs the DNS resolution when redirecting. Each ASA VPN Load Balancing cluster member should be able to resolve the FQDN’s.
name 11.11.11.1 vpn-lb.lab.local name 11.11.11.2 asa1.lab.local name 11.11.11.3 asa2.lab.local
Testing/Verification
Establish a Remote Access VPN connection to the Load Balancer FQDN, if successful no certificate errors should be displayed. The first connection should be sent to a “backup” node. Establish a second VPN connection, if the load of the “backup” node(s) is more than 1% higher than the “master” then the “master” will take the connection.
In the output of the command show vpn load-balancing we can determine that the 2 connections have been distributed over the 2 ASAs.
Figure 3 – “show vpn load-balancing” command output
Enable debugging using the command debug vpnlb 128
From the output below on the “backup” we can see the initial discovery of the “master” node, topology received and subsequent hello packets.
Figure 3 – Load Balancing Backup/Slave node discovering master
The output on the “master” confirms the initial hello request from the “backup” node, this connection is via the outside interface – NOTE, the ASA has resolved the outside interface IP address to the FQDN asa2.lab.local (as defined using the name command).
Figure 4 – Load Balancing Master node communication with backup/slave
Full Configuration
hostname ASA-1 ! names name 192.168.0.89 vpn-lb.lab.local name 192.168.0.90 asa1.lab.local name 192.168.0.91 asa2.lab.local ! ip local pool VPN_POOL 192.168.14.10-192.168.14.254 mask 255.255.255.0 ! interface GigabitEthernet0/1 nameif OUTSIDE security-level 0 ip address asa1.lab.local 255.255.255.0 ! interface GigabitEthernet0/2 nameif INSIDE security-level 100 ip address 192.168.101.3 255.255.255.0 ! same-security-traffic permit intra-interface object network RAVPN subnet 192.168.14.0 255.255.255.0 object network LAN subnet 192.168.8.0 255.255.252.0 ! nat (INSIDE,WAN) source static LAN LAN destination static RAVPN RAVPN nat (INSIDE,OUTSIDE) source static LAN LAN destination static RAVPN RAVPN ! object network RAVPN nat (OUTSIDE,OUTSIDE) dynamic interface ! prefix-list RAVPN seq 5 permit 192.168.14.0/24 ! route-map RAVPN permit 5 match ip address prefix-list RAVPN ! router bgp 7500 bgp log-neighbor-changes bgp router-id 192.168.101.3 address-family ipv4 unicast neighbor 192.168.101.2 remote-as 7500 neighbor 192.168.101.2 activate redistribute static route-map RAVPN no auto-summary no synchronization exit-address-family ! route OUTSIDE 0.0.0.0 0.0.0.0 192.168.0.1 1 route WAN 2.2.2.0 255.255.255.0 1.1.1.254 1 route WAN 3.3.3.0 255.255.255.0 1.1.1.254 1 route Null0 192.168.14.0 255.255.255.0 1 ! aaa-server ISE protocol radius authorize-only interim-accounting-update periodic 24 dynamic-authorization aaa-server ISE (INSIDE) host 192.168.10.10 key ***** authentication-port 1812 accounting-port 1813 radius-common-pw ***** aaa-server ISE (INSIDE) host 192.168.10.11 key ***** authentication-port 1812 accounting-port 1813 radius-common-pw ***** ! crypto ipsec security-association pmtu-aging infinite crypto ca trustpoint VPN_LB keypair VPN_LB crl configure ! vpn load-balancing redirect-fqdn enable priority 1 interface lbpublic OUTSIDE interface lbprivate INSIDE cluster key ***** cluster ip address vpn-lb.lab.local participate webvpn enable OUTSIDE hsts enable max-age 31536000 include-sub-domains no preload anyconnect image disk0:/anyconnect-win-4.8.01090-webdeploy-k9.pkg 1 anyconnect enable tunnel-group-list enable cache disable error-recovery disable group-policy GP-1 internal group-policy GP-1 attributes dns-server value 192.168.10.5 vpn-tunnel-protocol ssl-client address-pools value VPN_POOL dynamic-access-policy-record DfltAccessPolicy ! tunnel-group TG-1 type remote-access tunnel-group TG-1 general-attributes authentication-server-group ISE default-group-policy GP-1 tunnel-group TG-1 webvpn-attributes group-alias TG-1 enable !