Device virtualization is one of the most popular topics in IT industry today and Cisco has been supporting this concept in the majority of its network devices. In this article we will talk about Cisco ASA virtualization, which means multiple virtual firewalls on the same physical ASA chassis. Virtual ASA is also known as “Security Context”.

All firewall models (except ASA 5505) support multiple security contexts (i.e virtual firewalls). By default, all models support 2 security contexts without a license upgrade (except the ASA 5510 which requires the security plus license).

Each Context has it’s own configuration file and security policy, i.e. one context is completely isolated and does not depend on other contexts. The exception is the Admin Context, from which the whole ASA appliance (physical ASA) is managed and also is used to create the other Contexts. For enabling the creation of virtual contexts on the ASA appliance, we must switch to Multiple Context mode. In this mode some features are not available, like Dynamic Routing, IPSEC and SSL VPN, Multicast and Threat Detection. Let’s make a little discussion when multiple context mode is advisable and when it is not.

When would you want to use multiple security contexts?

●       If you want to use the active/active failover feature. Keep in mind that with active/active failover, you should not use more than half of the available bandwidth.
●       If you are an ISP and need to offer a different security context for each customer.
●       If you need to provide different security policies for various departments, users, or vendors and need to create a separate context for each one.
●       If you’d like to reduce hardware requirements by combining the functionality of multiple firewalls into one.

When should you not use multiple security contexts?

●       If you need to provide VPN services such as remote access or site-to-site VPN tunnels.
●       If you need to use dynamic routing protocols. With multiple context mode, you can use only static routes.
●       If you need to use QoS.
●       If you need to support multicast routing.
●       If you need to provide Threat Detection.

Now let’s consider an example of how Contexts are configured. In the scenario in our topology below, we have one ASA appliance and let’s create two contexts for two customers and one admin context for ASA appliance management.

Physical Topology Diagram:

Logical Topology Diagram:

Equipment Used in this LAB

ASA 5520 – Cisco Adaptive Security Appliance Software Version 8.0(3)

Catalyst 2960 – LAN Lite IOS.

Before starting configuration let’s check if it works in Single context mode or multiple context mode. As I’ve already stated, ASA appliance must be in multiple context mode for creating Security contexts.

!Verify ASA Operating mode.

asa # show mode

Security context mode: single

! enable multiple mode, for switching to this Mode, restart is required.

asa(config)#mode multiple

Then the following output is displayed. ASA Appliance converts the current running configuration into two files: a new startup configuration that comprises the system configuration, and “admin.cfg” that comprises the admin context (stored in the root directory of the internal Flash memory). The original running configuration is saved as “old_running.cfg” (in the root directory of the internal Flash memory).

WARNING: This command will change the behavior of the device
WARNING: This command will initiate a Reboot
Proceed with change mode? [confirm]
Convert the system configuration? [confirm]
!
The old running configuration file will be written to flash

The admin context configuration will be written to flash

The new running configuration file was written to flash
Security context mode: multiple

***
*** — SHUTDOWN NOW —
***
*** Message to all terminals:
***
***   change mode

Rebooting….
Booting system, please wait…

!after rebooting verify ASA Operation mode

asa# show mode
Security context mode: multiple

After restarting let’s start configuration of Contexts. First configure the admin 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 for Customer1
interface GigabitEthernet0/1.11
vlan 11
interface GigabitEthernet0/0.21
vlan 21

!configure the Sub-interfaces for Customer2
interface GigabitEthernet0/1.12
vlan 12
interface GigabitEthernet0/0.22
vlan 22

Now we start creating contexts for Customer-1 and Customer-2 and allocate interfaces.

! Configure the Customer1 context shown as C1 in diagram.
asa(config)# context c1
asa(config-ctx)# allocate-interface gigabitethernet0/0.21
asa(config-ctx)# allocate-interface gigabitethernet0/1.11
asa(config-ctx)# config-url disk0:/c1.cfg

! Configure the Customer2 context shown as C2 in diagram.
asa(config)# context c2
asa(config-ctx)# allocate-interface gigabitethernet0/0.22
asa(config-ctx)# allocate-interface gigabitethernet0/1.12
asa(config-ctx)# config-url disk0:/c2.cfg

I will not describe how VLANs on Switches are configured. Let’s consider switching between Contexts. We can switch to any context from admin context, but we can’t switch from Customers context to anywhere.

! Let’s log in to Customer1 context. The syntax of command is the following:
changeto context <context name>

asa#changeto context  c1

! Let’s switch to system configuration mode. Switching to this mode is available only from Admin Context. In system configuration mode Contexts are created and resources are allocated.

asa#changeto system

On my previous post I talked about Cisco ASA Active/Active configuration. In this post I will describe Active/Standby redundancy which is used much more frequently compared with the active/active scenario.

ASA Active/Standby failover/redundancy means connecting two identical ASA firewall units via LAN cable so that when one device or interface fails then the second one will take over the traffic and become the active device. During normal operation, the active ASA will be synchronizing its configuration to the standby unit. The configuration must be changed on active ASA. If we try to change the configuration on standby ASA, then the following warning will be displayed:

ASA# configure terminal
**** WARNING ****
Configuration Replication is NOT performed from Standby unit to Active unit.
Configurations are no longer synchronized.
ASA(config)#

During active/standby failover, the active ASA receives all traffic flows and filters all network traffic while the secondary ASA is in the Ready mode. Therefore you should dimension each ASA device in such a way so that to be able to handle all traffic.

ASA failover works in 2 modes: Stateful Failover and Regular Failover. During regular Failover, when Failover occurs, all active connections will be dropped. During Stateful Failover however, the active unit continually passes per-connection state to standby unit. When failover occurs, both ASA devices will have knowledge about all connections. The active ASA sends the state information of the following protocols/tables to the Standby ASA:

• NAT   Translation Table
• TCP connection Table
• UDP Connection Table
• ARP Table
• Layer2 Bridge Table (if Transparent mode enabled)
• HTTP Connection Table (if HTTP Replication enabled)
• ISAKMP and SA Table
• GTP PDP Connection table

The following are not synchronized:

• HTTP connection Table (unless HTTP Replication Enable)
• Routing Table
• User Authentication (UAUTH) Table
• State Information for Security Service Module.

There are some predefined device requirements for allowing two ASAs to work in Failover mode: both of them must be the same model, both must have the same type and number of  interfaces, the same volume of  RAM and FLASH, the same licenses and  the versions of ASA IOSs of both ASAs must match. If any of these requirements is not satisfied, then they cannot work in failover mode.

Let’s consider an example of active/standby Failover configuration (see diagram below). The Outside interfaces on ASAs are Ge0/0 and LAN interfaces are Ge0/1. For Failover we will use Ge0/2, particularly Ge0/2.1 will be the Failover interface and Ge0/2.2 the state interface (by which the information about protocol States will be exchanged). Note that you don’t have to use two different connections for Failover and State. They can share the same connection/interface.

Configuration

Active Unit Configuration:

Note: Always start with the active ASA first.

!Assign IP address to outside interface. During Failover the primary IP address will be assigned to Standby Unit.
asa(config)# interface g0/0
asa(config-if)# ip address 192.168.1.1 255.255.255.0 standby 192.168.1.2

!Assign IP address to inside interface. During Failover the primary IP address will be assigned to Standby Unit.
asa(config)# interface g0/1
asa(config-if)# ip address 192.168.2.1 255.255.255.0 standby 192.168.2.2

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

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

!Define Failover Interface. In this documentation, the “failover” (interface name for GigabitEthernet0/2.1) is used as a failover interface.
asa(config)#failover lan interface failover Ge0/2.1

!Assign IP address to Failover Interfaces.
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/2.2) is used as a State
interface.

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

!Assign IP addresses to Stateful Failover interfaces
asa(config)#failover interface ip state 192.168.4.1  255.255.255.0 standby 192.168.4.2

!enable Failover
asa(config)#failover

Note: Issue the failover command on the primary device first, and then issue it on the secondary device. After you issue the failover command on the secondary device, the secondary device immediately pulls the configuration from the primary device and sets itself as standby. The primary ASA stays up and passes traffic normally and marks itself as the active device. From that point on, whenever a failure occurs on the active device, the standby device comes up as active.

Standby Unit Configuration:

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

!Define the failover interface
asa(config)#failover lan interface failover Ge0/2.1

!assign IP address to failover interface
asa(config)#failover interface ip failover 192.168.3.1  255.255.255.0 standby 192.168.3.2

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

! Enable failover.
asa(config)#failover

After the above is completed, configuration replication will start with the following message:

“Beginning configuration replication: Sending to mate” ……….
“End Configuration Replication to mate.”

All configuration commands will be done on Primary unit from now on. Connect to the primary unit and issue the command “write memory” to save the configuration. Run also the command “write standby” to save the config to the secondary device.

Verification:

!show failover on Primary  ASA
asa # show failover
Failover On
Last Failover at: 05:12:14 tbilisi Dec 7 2010
This context: Active
Active time: 14228860 (sec)
Interface outside (192.168.1.1): Normal
Interface inside (192.168.2.1): Normal
Peer context: Standby Ready
Active time: 1104 (sec)
Interface outside (192.168.1.2): Normal
Interface inside (192.168.2.2): Normal

Stateful Failover Logical Update Statistics
Status: Configured.
Stateful Obj    xmit       xerr       rcv        rerr
RPC services    0          0          0          0
TCP conn        1217633001 31648      2774       0
UDP conn        1128592801 0          15204      0
ARP tbl         2435313    0          420        10
Xlate_Timeout   0          0          0          0
SIP Session     885790     0          0          0

! show failover on secondary unit.
asa# show failover
Failover On
Last Failover at: 05:12:14 tbilisi Dec 7 2010
This context: Standby Ready
Active time: 1104 (sec)
Interface outside (192.168.1.2): Normal
Interface inside (192.168.2.2): Normal
Peer context: Active
Active time: 14228965 (sec)
Interface outside (192.168.1.1): Normal
Interface inside (192.168.1.2 ): Normal

Stateful Failover Logical Update Statistics
Status: Configured.
Stateful Obj    xmit       xerr       rcv        rerr
RPC services    0          0          0          0
TCP conn        7349       638711328  571031340  112
UDP conn        45152      0          1136400282 886
ARP tbl         430        0          2435305    36
Xlate_Timeout   0          0          0          0
SIP Session     0          0          885779     11