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
#reboot

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
##exit
#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


Cheers!

0 comments

Recent Posts

See All

Email Security - Breaking Down DKIM & DMARC

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

Email Security - Breaking Down SPF

In the post I want to breakdown & cover SPF in more detail. Especially as I continue to embark on the email security journey/track. before beginning, here is another brief overview of what SPF entai

Understanding FTD Multi-Instance Capability Mode

In this post I want to cover running the multi-instance capability with Firepower Threat Detection (FTD). This capability lets you run containers that use a batch of resources of the security module/