🥇Deploying an ASA VPN Load-Balancing Cluster

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.

To help businesses achieve convenient, secure, and scalable VPN access for employees in the shortest possible time, Cisco is licensing the AnyConnect feature-rich SSL VPN client for up to 13 weeks. You can also take ASAv for a test (Virtual ASA for VMWare/Hyper-V/KVM hypervisors and AWS/Azure cloud platforms) from authorized partners or by contacting Cisco representatives working with you.

The procedure for issuing AnyConnect COVID-19 licenses is described here.

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.

Technology details here

The logical topology of the given example:

Primary Deployment:

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.

!
ciscoasa(config)# clock set 19:21:00 Mar 18 2020
ciscoasa(config)# clock timezone MSK 3
ciscoasa(config)# ntp server 192.168.99.136
!
ciscoasa(config)# dns domain-lookup outside
ciscoasa(config)# DNS server-group DefaultDNS
ciscoasa(config-dns-server-group)# name-server 192.168.99.132 
!
! Проверим работу DNS:
!
ciscoasa(config-dns-server-group)# ping ya.ru
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 87.250.250.242, timeout is 2 seconds:
!!!!!
!
! Проверим синхронизацию NTP:
!
ciscoasa(config)# show ntp associations 
  address         ref clock     st  when  poll reach  delay  offset    disp
*~192.168.99.136   91.189.94.4       3    63    64    1    36.7    1.85    17.5
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
!
! Установим конфигурацию нашей ASAv для Smart-Licensing (в соответствии с Вашим профилем, в моем случае 100М для примера)
!
ciscoasa(config)# license smart
ciscoasa(config-smart-lic)# feature tier standard
ciscoasa(config-smart-lic)# throughput level 100M
!
! В случае необходимости можно настроить доступ в Интернет через прокси используйте следующий блок команд:
!call-home
!  http-proxy ip_address port port
!
! Далее мы вставляем скопированный из портала Smart-Account токен (<token>) и регистрируем лицензию
!
ciscoasa(config)# end
ciscoasa# license smart register idtoken <token>

We check that the device has successfully registered a license and encryption options are available:

Set up a basic SSL-VPN on each gateway

Next, configure access via SSH and ASDM:

ciscoasa(config)# ssh ver 2
ciscoasa(config)# aaa authentication ssh console LOCAL
ciscoasa(config)# aaa authentication http console LOCAL
ciscoasa(config)# hostname vpn-demo-1
vpn-demo-1(config)# domain-name ashes.cc
vpn-demo-1(config)# cry key gen rsa general-keys modulus 4096 
vpn-demo-1(config)# ssh 0 0 inside  
vpn-demo-1(config)# http 0 0 inside
!
! Поднимем сервер HTTPS для ASDM на порту 445 чтобы не пересекаться с SSL-VPN порталом
!
vpn-demo-1(config)# http server enable 445 
!

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.

!
vpn-demo-1(config)# ip local pool vpn-pool 192.168.20.10-192.168.20.30 mask 255.255.255.0
!
vpn-demo-1(config)# access-list split-tunnel standard permit 192.168.0.0 255.255.0.0
!
vpn-demo-1(config)# group-policy SSL-VPN-GROUP-POLICY internal
vpn-demo-1(config)# group-policy SSL-VPN-GROUP-POLICY attributes
vpn-demo-1(config-group-policy)# vpn-tunnel-protocol ssl-client 
vpn-demo-1(config-group-policy)# split-tunnel-policy tunnelspecified
vpn-demo-1(config-group-policy)# split-tunnel-network-list value split-tunnel
vpn-demo-1(config-group-policy)# dns-server value 192.168.99.132
vpn-demo-1(config-group-policy)# default-domain value ashes.cc
vpn-demo-1(config)# tunnel-group DefaultWEBVPNGroup general-attributes
vpn-demo-1(config-tunnel-general)#  default-group-policy SSL-VPN-GROUP-POLICY
vpn-demo-1(config-tunnel-general)#  address-pool vpn-pool
!
vpn-demo-1(config)# username dkazakov password cisco
vpn-demo-1(config)# username dkazakov attributes
vpn-demo-1(config-username)# service-type remote-access
!
vpn-demo-1(config)# ssl trust-point SELF
vpn-demo-1(config)# webvpn
vpn-demo-1(config-webvpn)#  enable outside
vpn-demo-1(config-webvpn)#  anyconnect image disk0:/anyconnect-win-4.8.03036-webdeploy-k9.pkg
vpn-demo-1(config-webvpn)#  anyconnect enable
!

(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:

vpn-demo-1(config-aaa-server-group)# dynamic-authorization
vpn-demo-1(config-aaa-server-group)# interim-accounting-update
vpn-demo-1(config-aaa-server-group)# aaa-server RADIUS (outside) host 192.168.99.134
vpn-demo-1(config-aaa-server-host)# key cisco
vpn-demo-1(config-aaa-server-host)# exit
vpn-demo-1(config)# tunnel-group DefaultWEBVPNGroup general-attributes
vpn-demo-1(config-tunnel-general)# authentication-server-group  RADIUS 
!

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

vpn-demo-1(config-network-object)# nat (outside,outside) source dynamic vpn-users interface
vpn-demo-1(config)# nat (inside,outside) source dynamic any interface
vpn-demo-1(config)# same-security-traffic permit intra-interface 
!

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:

!
vpn-demo-1(config)# route-map RMAP-VPN-REDISTRIBUTE permit 1
vpn-demo-1(config-route-map)#  match ip address VPN-REDISTRIBUTE
!
vpn-demo-1(config)# router ospf 1
vpn-demo-1(config-router)#  network 192.168.255.0 255.255.255.0 area 0
vpn-demo-1(config-router)#  log-adj-changes
vpn-demo-1(config-router)#  redistribute static metric 5000 subnets route-map RMAP-VPN-REDISTRIBUTE

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.
```
vpn-demo-1(config)# vpn load-balancing
vpn-demo-1(config-load-balancing)# interface lbpublic outside
vpn-demo-1(config-load-balancing)# interface lbprivate inside
vpn-demo-1(config-load-balancing)# priority 10
vpn-demo-1(config-load-balancing)# cluster ip address 192.168.31.40
vpn-demo-1(config-load-balancing)# cluster port 4000
vpn-demo-1(config-load-balancing)# redirect-fqdn enable
vpn-demo-1(config-load-balancing)# cluster key cisco
vpn-demo-1(config-load-balancing)# cluster encryption
vpn-demo-1(config-load-balancing)# cluster port 9023
vpn-demo-1(config-load-balancing)# participate
vpn-demo-1(config-load-balancing)#
```
- 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.

Source: habr.com

Deploying an ASA VPN Load-Balancing Cluster

Add a comment Отменить ответ