In this article, I would like to provide a step-by-step guide on how to quickly deploy the most scalable scheme available at the moment. Remote-Access VPN based on AnyConnect and Cisco ASA – VPN Load Balancing Cluster.
Introduction: Many companies around the world, due to the current situation with COVID-19, are making efforts to transition their employees to remote work. Due to the mass shift to remote work, there is a critical increase in the load on existing company VPN gateways, and there is a need for rapid scaling. On the other hand, many companies are hurriedly learning to adapt to a concept like remote work from scratch.
To help businesses implement a convenient, secure, and scalable VPN access for employees in the shortest possible time, Cisco offers licenses for the multifunctional SSL-VPN client AnyConnect for up to 13 weeks. .
.
I have prepared a step-by-step guide for a simple deployment option for a VPN Load-Balancing cluster as the most scalable VPN technology.
The example provided below will be quite simple in terms of the authentication and authorization algorithms applied, but it will be a good option for a quick start (which many are currently lacking) with the possibility of in-depth adaptation to meet specific needs during the deployment process.
Brief information: The VPN Load Balancing Cluster technology is neither failover nor clustering in its native understanding; this technology can combine completely different ASA models (with certain limitations) for the purpose of load balancing Remote-Access VPN connections. Session and configuration synchronization between nodes of such a cluster is absent, but automatic load balancing of VPN connections and connection fault tolerance are possible as long as at least one active node remains in the cluster. The load in the cluster is balanced automatically depending on the load of the nodes based on the number of VPN sessions.
To ensure the fault tolerance of specific nodes in the cluster (if required), a file server can be used, allowing the active connection to be handled by the Primary node of the file server. A file server is not a necessary condition for ensuring fault tolerance within a Load-Balancing cluster; the cluster itself will transfer the user session to another live node in case of a node failure, but without maintaining the connection status, which is precisely ensured by the file server. Consequently, these two technologies can be combined if necessary.
A VPN Load-Balancing cluster can contain more than two nodes.
VPN Load-Balancing cluster is supported on ASA 5512-X and higher.
Since each ASA in the VPN Load-Balancing cluster is an independent unit regarding settings, all configuration steps are carried out individually on each device.
Logical topology of the provided example:
Initial deployment:
We deploy instances of ASAv from the necessary templates (ASAv5/10/30/50).
We assign INSIDE/OUTSIDE interfaces to the same VLANs (Outside in its VLAN, INSIDE in its own VLAN, but shared within the cluster, see topology). It is important for interfaces of the same type to be in the same L2 segment.
Licenses:
- At the time of installation, ASAv will not have any licenses and will be limited to a performance of 100 kbps.
- To install the license, you need to generate a token in your Smart Account dashboard: -> Smart Software Licensing
- In the opened window, click the button New Token
- Make sure that there is an active field in the opened window and the checkbox Allow export-controlled functionality… Without this active field, you will not be able to use strong encryption functions and thus VPN. If this field is not active, please contact your account team to request activation.
- After clicking the button Create Token, a token will be generated that we will use to obtain a license for ASAv; we will copy it:
- Repeat steps C, D, E for each deployed ASAv.
- To make it easier to copy the token, we will temporarily allow telnet access. We will configure each ASA (the example below illustrates settings on ASA-1). Telnet with outside does not work, if absolutely necessary, change the security-level to 100 on outside, then change 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, internet access for ASA must be provided. .
In brief, ASA requires:
- HTTPS access to the internet;
- time synchronization (preferably via NTP);
- a configured DNS server;
- We will connect via telnet to our ASAs and configure settings to activate the license through the 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 ! ! Let's check the DNS operation: ! 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: !!!!! ! ! Let's check NTP synchronization: ! 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 ! ! We will set the configuration of our ASAv for Smart-Licensing (according to your profile, in my case 100M for example) ! ciscoasa(config)# license smart ciscoasa(config-smart-lic)# feature tier standard ciscoasa(config-smart-lic)# throughput level 100M ! ! If necessary, internet access can be configured through a proxy using the following command block: !call-home ! http-proxy ip_address port port ! ! Next, we will insert the token copied from the Smart Account portal (<token>) and register the license ! ciscoasa(config)# end ciscoasa# license smart register idtoken <token>- We check that the device has successfully registered the license and encryption options are available:
Configuring the basic SSL-VPN on each gateway
- Next, we 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 ! ! We will enable the HTTPS server for ASDM on port 445 to avoid conflict with the SSL-VPN portal ! vpn-demo-1(config)# http server enable 445 !- To use ASDM, it must first be downloaded from the cisco.com website; in my case, this is the following file:
- To run the AnyConnect client, you need to upload an image for each desktop OS in use (planned for use Linux/Windows/MAC); a file with Headend Deployment Package in the name:
- The downloaded files can be uploaded, for example, to an FTP server and downloaded onto each individual ASA:
- Configure ASDM and Self-Signed Certificate for SSL-VPN (a trusted certificate is recommended in production). The installed FQDN of the virtual cluster address (vpn-demo.ashes.cc), as well as each FQDN associated with the external address of each node in the cluster, must resolve in the external DNS zone to the IP address of the OUTSIDE interface (or to the mapped address if port forwarding on udp/443 (DTLS) and tcp/443(TLS) is used). Detailed information on certificate requirements is provided in the section Certificate Verification of the 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- To verify the operation of ASDM, do not forget to specify the port, for example:
- Let's perform basic tunnel settings:
- We'll make the corporate network accessible through the tunnel and route the internet directly (not the safest method without protection on the connecting host, as it may allow infiltration through an infected host and leakage of corporate data; the option split-tunnel-policy tunnelall will route all host traffic through the tunnel. However, Split-Tunnel allows relieving the VPN gateway and not processing the host's internet traffic)
- We will assign addresses from the subnet 192.168.20.0/24 to the hosts in the tunnel (pool from 10 to 30 addresses for node #1). Each node in the VPN cluster must have its own pool.
- We will perform basic authentication using a locally created user on the ASA (This is not recommended; it is the simplest method); it is better to authenticate through LDAP/RADIUS, and even better to link Multi-Factor Authentication (MFA), for example, 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 example above, we used a local user on the ASA for authenticating remote users, which is not very applicable outside of a lab environment. I will provide an example of how to quickly adapt the configuration for authentication on RADIUS server, using 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 not only allows for quick integration of the authentication procedure with the AD directory service but also distinguishes the connected computer's belonging to AD, understanding whether it is a corporate or personal device and evaluating the status of the connected device.
- Let's configure Transparent NAT so that traffic between the client and corporate network resources is not NATed:
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): To release our clients to the Internet through the ASA (when using tunnelall To configure dynamic NAT using PAT and connect through the same OUTSIDE interface, the following settings are required.
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 !- It is crucial when using a cluster to allow the internal network to know which ASA to route return traffic to users; for this, route redistribution of the /32 addresses issued to clients must be implemented.
Currently, we have not yet configured the cluster, but we already have operational VPN gateways that can be individually connected using FQDN or IP.
We see the connected client in the routing table of the first ASA:
To ensure that our VPN cluster and the entire corporate network 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-REDISTRIBUTENow we have a route to the client from the second ASA-2 gateway, and users connected to different VPN gateways within the cluster can communicate directly through corporate softphones, just as the return traffic from requested resources will arrive at the appropriate VPN gateway.
Next, we proceed to configure the Load-Balancing of the 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 of the cluster will perform a REDIRECT to the less loaded node of the cluster. Don't forget to configure both forward and reverse DNS records for each external address/FQDN of each node in the cluster, as well as for the 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 are checking the operation of the cluster with two connected clients:
- We will make the client experience more convenient with the automatically downloadable AnyConnect profile via ASDM.
We name the profile conveniently and associate our group policy with it:
After the next client connection, this profile will be automatically downloaded and installed in the AnyConnect client, so if needed, it will simply be a matter of selecting it from the list:
Since we created this profile using ASDM only on one ASA, don't forget to repeat the actions on the other ASAs in the cluster.
Output: This way, we quickly deployed a cluster of multiple VPN gateways with automatic load balancing. Adding new nodes to the cluster is straightforward, achieving simple horizontal scaling by deploying new ASAv virtual machines or using hardware ASAs. The multifunctional AnyConnect client can significantly enhance the capabilities of secure remote connectivity with the Posture Assessment, most effectively used in conjunction with the centralized access control and monitoring system, Identity Services Engine..
Source: habr.com
