The Cisco ASA failover configuration requires two identical security appliances connected to each other through a dedicated failover link and, optionally, a stateful failover link. The health of the active interfaces and units is monitored to determine if specific failover conditions are met. If those conditions are met, failover occurs. In case of Active/active configuration both Units carry traffic. For creating active/active Failover, configuring both ASA devices in Multiple context mode is required.

For ASA redundancy scenario the two devices must be the same models, must have the same number and type of interfaces and the same license is required. ASA 5505 and 5510 do not support active/active failover without license upgrade.

For active/active configuration, Failover Contexts and Failover groups need to be created. The Failover group is then applied to Primary or Secondary physical ASA unit. After this, the particular Failover group is applied to a Context. For example, primary unit is active ASA of Failover group1, but Secondary unit is Standby ASA of Failover group1. If primary ASA is out of order, Secondary ASA will become Active of Failover group1.

For explaining Active/Active Failover configuration in details, let’s do the following LAB.

Click on the image above for larger size diagram

Configuration

!Switch both ASA devices to multiple context mode.
asa(config)#mode multiple

!When ASAs are reloaded, connect them to each other with Ge0/2 and Ge0/3 ports. First start with the Primary Unit configuration. Before starting configuration, all interfaces must be in the up state.

!enable LAN Failover.
asa(config)#failover lan enable

!set this unit as primary.
asa(config)#failover lan unit primary

Determine Failover and State interfaces. These two interfaces can be the same physical interface if you don’t need to consume one extra port. In our example here we use two separate physical interfaces.
In this article, the “failover” (interface name for GigabitEthernet0/2) is used as a failover
interface.

!Define Failover Interface
asa(config)#failover lan interface failover Ge0/2

!assign IP address on Failover Interface. MUST be in same Subnet as the standby on the other unit.
asa(config)#failover interface ip failover 192.168.3.1 255.255.255.0 standby 192.168.3.2

In this documentation, the “state” (interface name for GigabitEthernet0/3) is used as a state
interface.

!Define stateful Failover interface
asa(config)#failover link state Ge0/3

!assign IP address on Stateful Failover interface
asa(config)#failover interface ip state 192.168.4.1  255.255.255.0 standby 192.168.4.2

!Create Failover groups, where Failover group1 will be the Primary, i.e. active on Primary Unit and Failover group2 will be the Standby on Primary Unit. Configure also HTTP Replication, after which occurs HTTP Connection state replication between active and Standby ASAs. Also determine Preempt Delay. Preempt Delay means in what time to regain role of Active after Fail Recovery.

asa(config)#failover group 1
asa(config-fover-group)#primary
asa(config-fover-group)#preempt 120
asa(config-fover-group)# replication http

asa(config)#failover group 2
asa(config-fover-group)#secondary
asa(config-fover-group)#preempt 120
asa(config-fover-group)# replication http

Now let’s start creating Contexts and assigning interfaces in each Context.

!Configure the admin context
asa(config)# admin-context admin
asa(config)# context admin
asa(config-ctx)# allocate-interface Management0/0
asa(config-ctx)# config-url disk0:/admin.cfg

!configure the Sub-interfaces
interface GigabitEthernet0/0.10
vlan 10
interface GigabitEthernet0/0.11
vlan 11
interface GigabitEthernet0/1.20
vlan 20
interface GigabitEthernet0/1.21
vlan 21

! Configure the  contexts
asa(config)# context c1
asa(config-ctx)# allocate-interface gigabitethernet0/0.10
asa(config-ctx)# allocate-interface gigabitethernet0/1.20
asa(config-ctx)# config-url disk0:/c1.cfg

asa(config)# context c2
asa(config-ctx)# allocate-interface gigabitethernet0/0.11
asa(config-ctx)# allocate-interface gigabitethernet0/1.21
asa(config-ctx)# config-url disk0:/c2.cfg

!Snap each Context to Failover Groups. If we don’t indicate Contexts to Failover Groups, each context will be in Group1 by default.
asa(config)# context c1
asa(config-ctx)# join-failover-group 1
asa(config)# context c2
asa(config-ctx)# join-failover-group 2

!Configure IP addresses on Context1.
asa#changeto context c1
asa/c1# show running-config interface
!
interface GigabitEthernet0/0.10
nameif outside
security-level 0
ip address 192.168.10.1 255.255.255.0 standby 192.168.10.2
!
interface GigabitEthernet0/1.20
nameif inside
security-level 100
ip address 192.168.20.1 255.255.255.0 standby 192.168.20.2

!Configure IP addresses on Context2.
asa#changeto context c2
asa/c2# show running-config interface
!
interface GigabitEthernet0/0.11
nameif outside
security-level 0
ip address 192.168.11.1 255.255.255.0 standby 192.168.11.2
!
interface GigabitEthernet0/1.21
nameif inside
security-level 100
ip address 192.168.21.1 255.255.255.0 standby 192.168.21.2
!

Now let’s start Secondary Unit configuration.

!Define Failover Interface
asa(config)#failover lan interface failover Ge0/2

!assign IP address on Failover Interface. MUST be in same Subnet as other unit.
asa(config)#failover interface ip failover 192.168.3.1 255.255.255.0 standby 192.168.3.2

!enable LAN Failover.
asa(config)#failover lan enable

!set this unit as secondary
asa(config)#failover lan unit secondary

With the above piece of configuration commands everything is completed and now let’s start checking.

Verification:

!verify Primary UNIT
asa# show failover

Failover On
Failover unit Primary
Failover LAN Interface: failover GigabitEthernet0/2 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 4 of 250 maximum
Version: Ours 8.2(1), Mate 8.2(1)
Group 1 last failover at: 05:12:14 tbilisi Dec 7 2010
Group 2 last failover at: 10:13:04 tbilisi Oct 24 2010

This host:    Primary
Group 1       State:          Active
Active time:    14536379 (sec)
Group 2       State:          Standby Ready
Active time:    0 (sec)

slot 0: ASA5520 hw/sw rev (2.0/8.2(1)) status (Up Sys)
c1 Interface outside (192.168.10.1): Normal
c1 Interface inside (192.168.20.1): Normal
c2 Interface outside (192.168.11.1): Normal
c2 Interface inside (192.168.21.1): Normal
slot 1: empty

Other host:   Secondary
Group 1       State:          Standby Ready
Active time:    1104 (sec)
Group 2       State:          Active
Active time:    14537266 (sec)

slot 0: ASA5520 hw/sw rev (2.0/8.2(1)) status (Up Sys)
c1 Interface outside (192.168.10.2): Normal
c1 Interface inside (192.168.20.2): Normal
c2 Interface outside (192.168.11.2): Normal
c2 Interface inside (192.168.22.2): Normal
slot 1: empty

Stateful Failover Logical Update Statistics
Link : state GigabitEthernet0/3.2 (up)
Stateful Obj    xmit       xerr       rcv        rerr
General         2405585244 0          75798262   188
sys cmd         1938317    0          1938317    0
up time         0          0          0          0
RPC services    0          0          0          0
TCP conn        1241561564 0          43443406   91
UDP conn        1157379296 0          28582971   84
ARP tbl         3799402    0          1833568    13
Xlate_Timeout   0          0          0          0
SIP Session     906665     0          0          0

Logical Update Queue Information
Cur     Max     Total
Recv Q:         0       49      90335543
Xmit Q:         0       7       2405585244

!verify Secondary unit

ASA# show failover

Failover On
Failover unit Secondary
Failover LAN Interface: failover GigabitEthernet0/2
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 4 of 250 maximum
Version: Ours 8.2(1), Mate 8.2(1)
Group 1 last failover at: 05:12:14 tbilisi Dec 7 2010
Group 2 last failover at: 10:13:03 tbilisi Oct 24 2010

This host:    Secondary
Group 1       State:          Standby Ready
Active time:    1104 (sec)
Group 2       State:          Active
Active time:    14537372 (sec)

slot 0: ASA5540 hw/sw rev (2.0/8.2(1)) status (Up Sys)
c1 Interface outside (192.168.10.2): Normal
c1 Interface inside (192.168.20.2): Normal
c2 Interface outside (192.168.11.2): Normal
c2 Interface inside (192.168.21.2): Normal
slot 1: empty

Other host:   Primary
Group 1       State:          Active
Active time:    14536486 (sec)
Group 2       State:          Standby Ready
Active time:    0 (sec)

slot 0: ASA5520 hw/sw rev (2.0/8.2(1)) status (Up Sys)
c1 Interface outside (192.168.10.1): Normal
c1 Interface inside (192.168.20.1): Normal
c2 Interface outside (192.168.11.1): Normal
c2 Interface inside (192.168.21.1): Normal
slot 1: empty

Stateful Failover Logical Update Statistics
Link : state GigabitEthernet0/3.2 (up)
Stateful Obj    xmit       xerr       rcv        rerr
General         111758344  0          1089580597 1046
sys cmd         1938331    0          1938331    0
up time         0          0          0          0
RPC services    0          0          0          0
TCP conn        73801356   0          581933209  113
UDP conn        34185062   0          501003000  886
ARP tbl         1833595    0          3799403    36
Xlate_Timeout   0          0          0          0
SIP Session     0          0          906654     11

Logical Update Queue Information
Cur     Max     Total
Recv Q:         0       7       1104118240
Xmit Q:         0       1       111758344

As we observed from above, active/active Failover is working and everything is as expected.

In this post I will talk about Hub-and-Spoke VPN with one dynamic and two static crypto-maps between Cisco routers. The scenario is as following: There is a central HQ site which will be the Hub of our VPN network and also two branch sites which will be the spokes in our VPN network (see diagram below). The central HQ site will have a dynamic crypto-map while the branch sites will have a static crypto map. By configuring the central site with a dynamic crypto-map it means that the remote branch sites can have a dynamic public IP address. The branch sites will have a static crypto-map because for them the remote site (i.e the central HQ site) will have a static public IP address.

First of all let’s discuss some key points you must have in mind for this scenario which uses both static crypto-map and Dynamic crypto-map.

●     In the case of static crypto-map all peers on the VPN terminator (HUB) must be configured manually with their specific static public IP address. In the case of a dynamic crypto-map we don’t have to configure the peers one-by-one on the VPN terminator (HUB).  There are no changes on the spoke sites, i.e. we leave static crypto-map as it was.

●     In the case of dynamic crypto-map, the initiator of VPN session will be only the spoke site. This means that if traffic doesn’t come from the Spoke in the VPN tunnel, then VPN dynamic tunnel will not be established. When, however, traffic is initiated from the spoke site (branch) then the VPN tunnel will be established and the connection will be bidirectional between branch and HQ.

●    There is a simple configuration on the HUB site. If we add more spokes, configuration will be done only on spoke site and there is no need for changing anything on HUB.

Let’s set our LAB network diagram below.

Equipment used in This lab:

• HQ – 3725 IOS c3725-advsecurityk9-mz.124-1c
• Branches – 2691 IOS c2691-adventerprisek9-mz.123-17a

LAB Scenario:

We’ve got HQ office and two Branches, which are connected via Internet. The Hosts in Branches must have secure access to the servers located in HQ. That is, network subnets 192.168.4.0/24 and 192.168.5.0/24 must have secure access to subnet 192.168.1.0/24. That’s an ordinary scenario, which many organizations implement all over the world. Since this is a Lab scenario, only private IP addresses were used. In a real scenario the WAN IP addresses of HQ and Branches routers will be public IP.

Configuration:

The very first thing you need to do in such a scenario is to verify that all sites have IP connectivity between them. Verify that all WAN interfaces of routers can reach each other over the Internet.

Branches Configuration.

! Create isakmp policy.  If you have multiple policies it is recommended that the most strong policy should be first (i.e have the lowest policy number).
crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
group 2

! Configure crypto isakmp key. The keys between peers must be the same. In our case the branches should specify the static IP address of HQ and have the same key with HQ

crypto isakmp key somestrongkey address 192.168.2.2

! Configure IPsec transform-set.  This specifies what encryption and Hash algorithm should be used for encryption of VPN traffic.

crypto ipsec transform-set ts esp-aes 256 esp-sha-hmac

! Create access list by which we’ll match interesting traffic that will pass through the VPN. In case of Branch 1 will be the following: if source is 192.168.4.0/24 and destination is 192.168.1.0/24 then traffic will be encrypted. Similarly for Branch 2, if source is 192.168.5.0/24 and destination is 192.168.1.0/24 then traffic will be encrypted.
Branch 1 ACL:

ip access-list extended vpn
permit ip 192.168.4.0 0.0.0.255 192.168.1.0 0.0.0.255

Branch 2 ACL:

ip access-list extended vpn
permit ip 192.168.5.0 0.0.0.255 192.168.1.0 0.0.0.255

! Create crypto-map and snap to it the already created transform-set and access list. Also indicate VPN peer and turn on Reverse-route. The purpose of reverse-route is that when VPN tunnel is established, Destination network of access list created for interesting traffic will be added in routing table as static route. In our case this access list is “vpn” and the destination network of this access list is 192.168.1.0/24.

crypto map vpn 10 ipsec-isakmp
set peer 192.168.2.2
set transform-set ts
match address vpn
reverse-route

!Assign crypto-map to external interface. In our case Fa0/0. After this, ISAKMP will turn on.
interface FastEthernet0/0
crypto map vpn

Configuration of Branches is done. Let’s start HQ configuration.

HQ Configuration:
! crypto isakmp policy will not be changed.
crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
group 2

! All peer addresses are assigned with a secret key, i.e. all zeros are assigned, for avoiding writing each branch’s IP address separately.
crypto isakmp key somestrongkey address 0.0.0.0 0.0.0.0

! IPSec Transform-set will not change.
crypto ipsec transform-set ts esp-aes 256 esp-sha-hmac

! Access list, by which interesting traffic is matched, will be changed. Source will be 192.168.1.0/24 and destination will be 192.168.4.0/24 and 192.168.5.0/24.
ip access-list extended vpn
permit ip 192.168.1.0 0.0.0.255 192.168.5.0 0.0.0.255
permit ip 192.168.1.0 0.0.0.255 192.168.4.0 0.0.0.255

! Configure Dynamic crypto-map.  Assign the same parameters, except assigning peers.
crypto dynamic-map vpndynamic 10
set transform-set ts
match address vpn
reverse-route

!Create crypto-map and snap to it already created dynamic crypto-map.
crypto map dynmap 10 ipsec-isakmp dynamic vpndynamic

!Assign crypto-map on external interface. In our case Fa0/0. After this ISAKMP will turn on.

interface FastEthernet0/0
crypto map dynmap

Verification:

Now the configuration is done and let’s start checking if it works. First of all ping SRV from host1. Check the following:  Is VPN tunnel established or not, decaps/encaps increases or not, RRI (reverse-route injection) is added in Branche1 and HQ Routing Tables and also if hit counts in access lists change or not.

!We see, that first few pings are lost, because VPN tunnel takes some time to get established.
host1#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
..!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 40/96/164 ms

host1#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/62/124 ms

!Now check if ISAKMP peers are in state or not.

hq#show crypto isakmp sa
dst             src             state          conn-id slot status
192.168.2.2     192.168.3.2     QM_IDLE              1    0 ACTIVE

branch1#show crypto isakmp sa
dst             src             state          conn-id slot
192.168.2.2     192.168.3.2     QM_IDLE              1    0

!Let’s see again if encaps/decaps increase. If not and they ping each other, this means that traffic is not going through VPN tunnel.

branch1#show crypto ipsec sa
interface: FastEthernet0/0
crypto map tag: vpn, local addr. 192.168.3.2
protected vrf:
local  ident (addr/mask/prot/port): (192.168.4.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
current_peer: 192.168.2.2:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 13, #pkts encrypto: 13, #pkts digest 13
#pkts decaps: 12, #pkts decrypto: 12, #pkts verify 12
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0

hq#show crypto ipsec sa
interface: FastEthernet0/0
crypto map tag: dynmap, local addr 192.168.2.2
protected vrf: (none)
local  ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.4.0/255.255.255.0/0/0)
current_peer 192.168.3.2 port 500
PERMIT, flags={}
#pkts encaps: 12, #pkts encrypto: 12, #pkts digest: 12
#pkts decaps: 13, #pkts decrypto: 13, #pkts verify: 13
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

!Let’s check that RRI is all right and access lists are matched.

hq#show ip route static
S    192.168.4.0/24 [1/0] via 192.168.3.2

branch1#show ip route static
S    192.168.1.0/24 [1/0] via 192.168.2.2

hq#show access-lists vpn
Extended IP access list vpn
10 permit ip 192.168.1.0 0.0.0.255 192.168.5.0 0.0.0.255
20 permit ip 192.168.1.0 0.0.0.255 192.168.4.0 0.0.0.255 (25 matches)

branch1#show access-lists vpn
Extended IP access list vpn
10 permit ip 192.168.4.0 0.0.0.255 192.168.1.0 0.0.0.255 (26 matches)

All the above indicate that everything is all right and VPN is working properly. Also remember that we’ve not assigned peers in HQ configuration and that makes configuration simple (when we have 20 branches there is no need for assigning static peers of Branches on the HQ site). Another great advantage of dynamic crypto map on the HQ site is when a branch site receives dynamic public IP address from the ISP.

In this post I will explain how to configure WEB VPN (or sometimes called SSL VPN) using the Anyconnect VPN client on a Cisco 870 router.

Web Based VPN has three Remote Access modes:

Clientless – You connect to a web page portal from which you can have access to web based applications, File Sharing and Outlook Web Access (OWA) inside the corporate network .

Thin client – This mode allows TCP Port- Forwarding on applications, such as Telnet, SSH, SMTP POP3, Remote Desktop Connection (RDP). It uses a Java applet. This mode may be used only on TCP Based Applications.

Tunnel Mode or AnyConnect VPN client – almost same as an Easy VPN Client (IPSEC VPN client). In this mode you must have Administrator permissions on your remote access laptop/PC and any IP based Application can be used through this mode. A Java client is downloaded to the user’s PC and facilitates the security and encryption from the remote user towards the termination device (router or firewall).

Both ASA and Cisco IOS Routers support web vpn technologies. On ASA an extra license is required if you want to have more than two users for your remote access web vpn. Without purchasing any license it provides support for only two users.

We will be using the following Network diagram in our example:

Requirements for Anyconnect VPN:

• Java runtime 1.4 or later.
• Cisco IOS 12.4(15)T7 (supports ONLY clientless Web Based VPN)
• CISCO IOS 12.4(20)T (supports all web vpn modes, both clientless and anyconnect Client VPN).

Used in Lab for this tutorial:

• Cisco IOS Software, C870 Software (C870-ADVSECURITYK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
• ANY Connect Client: anyconnect-win-2.3.2016-k9.
• FireFox 3.6.8 and IE 8
• Windows XP SP2 and Windows Server Ultimate 32 bit

Configuration.

!Configure Certificate

crypto pki trustpoint local
enrollment selfsigned
revocation-check crl
rsakeypair my_key 1024 1024

!Generate Certificate and turn on HTTPS Service

crypto pki enroll local
ip http secure-server

!Before starting the actual configuration of Web Vpn, first we configure Gateway, on which IP address we shall terminate the Anyconnect VPN, which certificates to use, on which port we shall run the VPN and any redirections necessary ( i.e. if request comes on port 80 port, it will redirect the user to port 443). All these are configured under the webvpn mode.

! enable webvpn gateway configuration mode to configure SSL VPN Gateway. ONLY one Gateway is configured in an SSL VPN Network
webvpn gateway soho

! configure hostname for SSL VPN; in our example hostname is home
hostname home

!configure IP address and port on which SSL VPN will connect.
ip address 99.99.99.160 port 443

!Configure SSL Certificate; in our Example this Certificate is Self-signed
ssl trustpoint local

!configure Redirect. If somebody connects to TCP port 80 it will be redirected to port 443

http-redirect port 80

! Enable WebVPN Gateway
inservice

!turn on AAA and for authentication we use local database
aaa new-model
aaa authentication login webvpn local

!Create Local address pool, from which we’ll assign IP addresses to anyconnect clients.
ip local pool webvpn1 192.168.2.5 192.168.2.10

!Create loopback interface, if we want to announce this network in any dynamic protocol.
interface Loopback2
ip address 192.168.2.1 255.255.255.0

!Create access list, which  later will be used to control what the webvpn client will be allowed to access. This is not access list for Split Tunneling. Split Tunnel is created in context configuration mode.
!
ip access-list extended webvpn-acl
permit tcp 192.168.2.0 0.0.0.255 host 192.168.3.100 eq 3389
!

!After this we need to create a profile context.
!  Create Webvpn context; same as profile on easy vpn
webvpn context networkstraining.com

! change default Title
title “IP Networks Training and Tutorials”

! Verify SSL Certificate.
ssl authenticate verify all

! Change default login message displayed on login page before user login.
login-message “Enter your credentials”

!Configure policy for this group with name networkstraining
policy group  networkstraining

!configure banner to be displayed after successful login
banner “authentication success”

! enable tunnel support for the remote user. If the Cisco AnyConnect VPN Client software package fails to install, the remote user can continue to use clientless mode or thin-client mode.
functions svc-enabled

! Below we configure an SSL VPN tunnel access filter which uses the ACL we have created above. Gives us the opportunity to control which type of traffic must allow or block via access list. In our example we created  webvpn-acl access list, which permits access from network 192.168.2.0/24 to TCP 3389 ( Remote Desktop Protocol )  of host 192.168.3.100 and all the rest are blocked.

filter tunnel webvpn-acl

! Configure IP address pool.  When client is connected via anyconnect client an IP will be assigned from this pool.
svc address-pool webvpn1

! Configures the domain for a policy group.
svc default-domain “http://www.networkstraining.com”

! To install Cisco any connect client on User’s PC.  When this feature is not turned on, when user is disconnected then Cisco anyconnect client will be automatically uninstalled.

svc keep-client-installed

!In case of successful authorization it will show us URL below
svc homepage “http://www.networkstraining.com”

!Configures the tunnel key to be refreshed by initiating a new tunnel connection
svc rekey method new-tunnel

! Below is the split tunnel configuration which specifies the destination network to permit access within the tunnel when the user connects via Cisco anyconnect client.  If we don’t indicate this parameter, then there will be Full Tunnel, meaning that all traffic will pass through the Cisco web VPN Server
svc split include 192.168.3.0 255.255.255.0

!Default group
default-group-policy one

!The name of authentication group. We’ve already created AAA group named webvpn and here this group will be used
aaa authentication list webvpn

!  Bind this context to Gateway created above

gateway soho

! Activate created context.
inservice

After the above we need to install anyconnect client to the flash memory of the router. The version of anyconnect client must support the operating system of the users that will be using the anyconnect service.

webvpn#copy tftp://192.168.3.100/anyconnect-win-2.3.2016-k9.pkg flash
webvpn(config)#webvpn install svc flash:anyconnect-win-2.3.2016-k9.pkg

After this we check if anyconnect cliet installation was successful in our configuration.

!
webvpn install svc flash:/webvpn/svc_1.pkg sequence 1
!