In this article, I would like to provide step-by-step instructions on how you can quickly deploy the most scalable scheme at the moment. Remote Access VPN access based AnyConnect and Cisco ASA - VPN Load Balancing Cluster.
Introduction Many companies around the world, in view of the current situation with COVID-19, are making efforts to transfer their employees to remote work. Due to the mass transition to remote work, the load on the existing VPN gateways of companies is critically increasing and a very fast ability to scale them is required. On the other hand, many companies are forced to hastily master the concept of remote work from scratch.
I have prepared a step-by-step guide for a simple deployment of VPN Load-Balancing Cluster as the most scalable VPN technology.
The example below will be quite simple in terms of the authentication and authorization algorithms used, but will be a good option for a quick start (which is currently not enough for many) with the possibility of in-depth adaptation to your needs during the deployment process.
Brief information: VPN Load Balancing Cluster technology is not a failover and not a clustering function in its native sense, this technology can combine completely different ASA models (with certain restrictions) in order to load balance Remote-Access VPN connections. There is no synchronization of sessions and configurations between the nodes of such a cluster, but it is possible to automatically load balance VPN connections and ensure fault tolerance of VPN connections until at least one active node remains in the cluster. The load in the cluster is automatically balanced depending on the workload of the nodes by the number of VPN sessions.
For failover of specific nodes of the cluster (if required), a filer can be used, so the active connection will be handled by the Primary node of the filer. The fileover is not a necessary condition for ensuring fault tolerance within the Load-Balancing cluster, the cluster itself, in the event of a node failure, will transfer the user session to another live node, but without saving the connection status, which is precisely provided by the filer. Accordingly, it is possible, if necessary, to combine these two technologies.
A VPN Load-Balancing cluster can contain more than two nodes.
VPN Load-Balancing Cluster is supported on ASA 5512-X and above.
Since each ASA within the VPN Load-Balancing cluster is an independent unit in terms of settings, we carry out all configuration steps individually on each individual device.
We deploy ASAv instances of the templates we need (ASAv5/10/30/50) from the image.
We assign the INSIDE / OUTSIDE interfaces to the same VLANs (Outside in its own VLAN, INSIDE in its own, but generally within the cluster, see the topology), it is important that interfaces of the same type are in the same L2 segment.
Licenses:
At the moment the ASAv installation will not have any licenses and will be limited to 100kbps.
To install a license, you need to generate a token in your Smart-Account: https://software.cisco.com/ -> Smart Software Licensing
In the window that opens, click the button new token
Make sure that in the window that opens there is an active field and a checkmark is checked Allow export-controlled functionality⦠Without this field active, you will not be able to use the functions of strong encryption and, accordingly, VPN. If this field is not active, please contact your account team with an activation request.
After pressing the Create Token, a token will be created that we will use to obtain a license for ASAv, copy it:
Repeat steps C,D,E for each deployed ASAv.
To make it easier to copy the token, let's temporarily allow telnet. Let's configure each ASA (the example below illustrates the settings on ASA-1). telnet does not work with outside, if you really need it, change security-level to 100 to outside, then return it back.
!
ciscoasa(config)# int gi0/0
ciscoasa(config)# nameif outside
ciscoasa(config)# ip address 192.168.31.30 255.255.255.0
ciscoasa(config)# no shut
!
ciscoasa(config)# int gi0/1
ciscoasa(config)# nameif inside
ciscoasa(config)# ip address 192.168.255.2 255.255.255.0
ciscoasa(config)# no shut
!
ciscoasa(config)# telnet 0 0 inside
ciscoasa(config)# username admin password cisco priv 15
ciscoasa(config)# ena password cisco
ciscoasa(config)# aaa authentication telnet console LOCAL
!
ciscoasa(config)# route outside 0 0 192.168.31.1
!
ciscoasa(config)# wr
!
To register a token in the Smart-Account cloud, you must provide Internet access for ASA, details here.
In short, ASA is needed:
access via HTTPS to the Internet;
time synchronization (more correctly, via NTP);
registered DNS server;
We telnet to our ASA and make settings to activate the license through Smart-Account.
For ASDM to work, you must first download it from the cisco.com website, in my case it is the following file:
For the AnyConnect client to work, you need to upload an image to each ASA for each used client desktop OS (planned to use Linux / Windows / MAC), you will need a file with Headend Deployment Package In the title:
The downloaded files can be uploaded, for example, to an FTP server and uploaded to each individual ASA:
We configure ASDM and Self-Signed certificate for SSL-VPN (it is recommended to use a trusted certificate in production). The set FQDN of the Virtual Cluster Address (vpn-demo.ashes.cc), as well as each FQDN associated with the external address of each cluster node, must resolve in the external DNS zone to the IP address of the OUTSIDE interface (or to the mapped address if port forwarding udp/443 is used (DTLS) and tcp/443(TLS)). Detailed information on the requirements for the certificate is specified in the section Certificate Verification documentation.
!
vpn-demo-1(config)# crypto ca trustpoint SELF
vpn-demo-1(config-ca-trustpoint)# enrollment self
vpn-demo-1(config-ca-trustpoint)# fqdn vpn-demo.ashes.cc
vpn-demo-1(config-ca-trustpoint)# subject-name cn=*.ashes.cc, ou=ashes-lab, o=ashes, c=ru
vpn-demo-1(config-ca-trustpoint)# serial-number
vpn-demo-1(config-ca-trustpoint)# crl configure
vpn-demo-1(config-ca-crl)# cry ca enroll SELF
% The fully-qualified domain name in the certificate will be: vpn-demo.ashes.cc
Generate Self-Signed Certificate? [yes/no]: yes
vpn-demo-1(config)#
!
vpn-demo-1(config)# sh cry ca certificates
Certificate
Status: Available
Certificate Serial Number: 4d43725e
Certificate Usage: General Purpose
Public Key Type: RSA (4096 bits)
Signature Algorithm: SHA256 with RSA Encryption
Issuer Name:
serialNumber=9A439T02F95
hostname=vpn-demo.ashes.cc
cn=*.ashes.cc
ou=ashes-lab
o=ashes
c=ru
Subject Name:
serialNumber=9A439T02F95
hostname=vpn-demo.ashes.cc
cn=*.ashes.cc
ou=ashes-lab
o=ashes
c=ru
Validity Date:
start date: 00:16:17 MSK Mar 19 2020
end date: 00:16:17 MSK Mar 17 2030
Storage: config
Associated Trustpoints: SELF
CA Certificate
Status: Available
Certificate Serial Number: 0509
Certificate Usage: General Purpose
Public Key Type: RSA (4096 bits)
Signature Algorithm: SHA1 with RSA Encryption
Issuer Name:
cn=QuoVadis Root CA 2
o=QuoVadis Limited
c=BM
Subject Name:
cn=QuoVadis Root CA 2
o=QuoVadis Limited
c=BM
Validity Date:
start date: 21:27:00 MSK Nov 24 2006
end date: 21:23:33 MSK Nov 24 2031
Storage: config
Associated Trustpoints: _SmartCallHome_ServerCA
Don't forget to specify the port to check ASDM is working, for example:
Let's carry out the basic settings of the tunnel:
Let's make the corporate network available through the tunnel, and let the Internet go directly (not the safest method if there are no protections on the connecting host, it is possible to penetrate through an infected host and display corporate data, option split-tunnel-policy tunnelall will let all host traffic into the tunnel. Nevertheless split-tunnel makes it possible to offload the VPN gateway and not process host Internet traffic)
Let's issue addresses from the 192.168.20.0/24 subnet to hosts in the tunnel (pool from 10 to 30 addresses (for node #1)). Each node of the VPN cluster must have its own pool.
We will carry out basic authentication with a locally created user on the ASA (This is not recommended, this is the easiest method), it is better to do authentication through LDAP/RADIUS, or better yet, tie Multi-Factor Authentication (MFA)Eg Cisco DUO.
(OPTIONAL): In the above example, we used a local user on the ITU to authenticate remote users, which of course, except in the laboratory, is poorly applicable. I will give an example of how to quickly adapt the setting for authentication to RADIUS server, for example used Cisco Identity Services Engine:
This integration made it possible not only to quickly integrate the authentication procedure with the AD directory service, but also to distinguish whether the connected computer belongs to AD, to understand whether this device is corporate or personal, and to assess the status of the connected device.
Let's configure Transparent NAT so that the traffic between the client and the resources of the corporate network network is not scribbled:
vpn-demo-1(config-network-object)# subnet 192.168.20.0 255.255.255.0
!
vpn-demo-1(config)# nat (inside,outside) source static any any destination static vpn-users vpn-users no-proxy-arp
(OPTIONAL): In order to expose our clients to the Internet through the ASA (when using tunnelall options) using PAT, as well as exit through the same OUTSIDE interface from which they are connected, you need to make the following settings
When using a cluster, it is extremely important to enable the internal network to understand which ASA to route return traffic to users, for this you need to redistribute routes / 32 addresses issued to clients.
At the moment, we have not yet configured the cluster, but we already have working VPN gateways that can be individually connected via FQDN or IP.
We see the connected client in the routing table of the first ASA:
In order for our entire VPN cluster and the entire corporate network to know the route to our client, we will redistribute the client prefix into a dynamic routing protocol, for example OSPF:
Now we have a route to the client from the second ASA-2 gateway and users connected to different VPN gateways within the cluster can, for example, communicate directly through a corporate softphone, as well as return traffic from the resources requested by the user will come to the desired VPN gateway:
Let's move on to configuring the Load-Balancing cluster.
The address 192.168.31.40 will be used as a Virtual IP (VIP - all VPN clients will initially connect to it), from this address the Master cluster will make a REDIRECT to a less loaded cluster node. Don't forget to write forward and reverse DNS record both for each external address / FQDN of each node of the cluster, and for VIP.
We check the operation of the cluster with two connected clients:
Let's make the customer experience more convenient with the automatically loaded AnyConnect profile via ASDM.
We name the profile in a convenient way and associate our group policy with it:
After the next connection of the client, this profile will be automatically downloaded and installed in the AnyConnect client, so if you need to connect, just select it from the list:
Since we created this profile on only one ASA using ASDM, don't forget to repeat the steps on the other ASAs in the cluster.
Conclusion: Thus, we quickly deployed a cluster of several VPN gateways with automatic load balancing. Adding new nodes to the cluster is easy, with simple horizontal scaling by deploying new ASAv virtual machines or using hardware ASAs. The feature-rich AnyConnect client can greatly enhance secure remote connection by using the Posture (state estimates), most effectively used in conjunction with the system of centralized control and access accounting Identity Services Engine.