Configuring & Verifying ASA Contexts

"The What?" - In this post I want to go over configuring & verifying multicontext mode on Cisco ASA. To understand what security contexts are see: ASA Security Contexts Tidbit

"The Why?" - Using multicontext mode on Cisco ASA provides some valuable benefits. This mode allows us to partition the ASA into multiple "virtual" firewalls which could allow you to utilize one firewall for multiple customers. This mode also allows you to deploy different security policies perhaps for separate departments, or users. Lastly, this mode aides in possibly saving money instead of the need to buy multiple pieces of hardware. Note that there are licensing costs & this decision is ultimately based on your requirements.

"The How?" - I want to start with the main configuration components. Security contexts can be broken down into a few steps which are:

  • Enable multiple contexts globally

  • Set up system execution space

  • Specify Config URL

  • Allocate interfaces

  • Configure Admin context

  • Configure a customer context

  • Manage the contexts

First thing first, in order to enable multiple contexts we need to initiate multiple-mode globally. As the admin when doing so you will be prompted to convert current run config into system execution space and the admin context. Once finished the device will reboot to change modes. An important note is that the device saves the old single mode run config as old_running.cfg in flash. Lastly, it is important to know that the ASA stores the system execution space in NVRAM & the admin context in flash (admin.cfg).

To enable the ASA via CLI:

#mode multiple

To verify mode via CLI:

#show mode

Note that if you ever need to revert back to single mode you can copy the old_running.cfg from flash into start, set mode to single, & reboot the ASA. This process is done like this:

#copy disk0:/old_running.cfg start
#mode single

Secondly, the system execution space is created when you enable multiple mode. So after reboot we can access the system execution space via the following:

#changeto system

Remember that the system execution context allows us to define the admin and customer contexts.

Thirdly, you need to declare a configuration URL for each respective context as this is required for the contexts to become active. There are several options which include local disk, http/s, tftp, ftp. Once we configure a configuration URL the ASA attempts to pull config, if it does not exist, then the cfg file gets created with default settings. Configuring a config URL looks like this:

#context admin
##config-url disk0:/admin.cfg

Fourthly, interfaces must be allocated to the contexts. Both physical or sub-interfaces are capable of being assigned to contexts. Something to consider is whether or not you wish to allow context admins to view interface IDs, which are displayed by default. Some important command definitions:

  • map_name = use when you want to display the name of interface instead of ID

  • invisible = ASA hides the interface ID in configuration and show int command; will only show mapped name

  • visible = ASA shows interface ID

Example of allocating interfaces:

#context ExampleA
##allocate-interface G0/0 A_Inside visible
##allocate-interface g0/1 A_Outside visible

In the example above we chose to allow context ExampleA admin to view interface ID, while assigning G0/0 as its inside interface, and G0/1 as its outside interface.

Next (5th), it is important that you configure an admin context. The ASA will automatically create an admin context. It is important to know that this context gets treated like other contexts on the appliance. In order to switch to your admin context perform the following:

#changeto context admin

If you wish to use another context as the admin context perform the following:

#context ExampleA
##config-url disk0:/ExA.cfg
#admin-context ExampleA

To see what context is configured as admin context use the following:

#show run | i admin-context
#show admin-context

Combining the last two configuration steps, 6 & 7, it is important to configure & deploy customer contexts to meet your requirements. Per Cisco any context that is not the admin context is referred to as a customer context. In these steps you can configure the respective contexts with all supported firewall-related options. In order to switch between contexts:

#changeto context <name>

There you have it. I just covered the main configuration blocks for configuring/deploying & verifying security contexts. Lastly, to understand how the ASA classifies packets to ensure they are sent to the correct context see: ASA MultiContext Mode Packet Classification Tidbit



Recent Posts

See All

"The What?" - In this blog I want to share some valuable Digital Network Architecture Center (DNAC) tips & tricks that I have collected that are quite useful when needing to troubleshoot/perform some

In this post I want to cover the ESA Email pipeline. The email pipeline represents how emails are processed through the system from start to finish. The pipeline consists of 3 main phases: Receipt:

I recently started pursuing email security studies. Other posts have mentioned this, and a recent post shared a deeper look at SPF. In this blog I want to cover DKIM & DMARC. Starting with DKIM, it