CCNA Security 33

When it comes to virtualization in an ASA, we have a phenomenon known as Security Contexts. The reason why we use Security Contexts is that it allows us to split a single ASA firewall into multiple virtual firewalls. This does not mean that every interface needs to belong to only one Security Context. An interface can be partitioned to support multiple Security Contexts. This is only true if you're using Routed mode. L2 firewalls require unique interfaces for each context.
When you enable multi-context mode, you automatically have an Administrator context. Users logged into the Administrator context can make changes to the system and can also have access to all other contexts.

Context information is stored in a database file in flash. The ASA has a base startup-configuration stored in flash, and each context has a separate configuration file which can reside in the flash or be downloaded during start-up from a remote system. The context configuration files have the extension of .cfg.

Now the question is that, as packets come into the ASA, how does the device actually know what context the packet belongs to? Now, this brings us into the topic of Packet Classification.

Each context has a separate IP address and a unique MAC address. Every packet that comes inbound to the ASA must be classified by something unique. This attribute can come in the form of a MAC address, Destination IP address, or almost any attribute that can be extracted from a packet. The most common attribute used in routed mode is the MAC address and is the Cisco recommended method. Here's how we visualize this:


Once the ASA is converted into multi-context mode, two files are saved in flash:
Admin.cfg
old_running.cfg

The Admin.cfg will be responsible for saving Admin context configuration, and old_running will be taken from the current running-config. The Administrator context does not have any traffic-passing interfaces. The Administrator context is mainly used to fetch configurations for other contexts, change system configurations and create new contexts. We can even turn regular contexts into the Administrator Context (you can only have one at one time).

To switch to multi-context mode, you need to type:
mode multiple

Now we'll create two new context using:
context ONE
allocate-interface e0 OUTSIDEONE
allocate-interface e1 INSIDEONE
config-url ONE.cfg
context TWO
allocate-interface e0 OUTSIDETWO
allocate-interface e1 INSIDETWO
config-url TWO.cfg

You can actually configure each context by going into them using:
changeto context ONE
conf t
in OUTSIDEONE
nameif OUTSIDE
sec 0
ip add 1.1.1.10 255.255.255.0
mac 0000.0000.1111
in INSIDEONE
nameif INSIDE
sec 100
ip add 2.2.2.10 255.255.255.0
mac 0000.0000.1112

Configuration for TWO would then be:
changeto context TWO
conf t
in OUTSIDETWO
nameif OUTSIDE
sec 0
ip add 1.1.1.11 255.255.255.0
mac 0000.0000.2221
in INSIDETWO
nameif INSIDE
sec 100
ip add 2.2.2.11 255.255.255.0
mac 0000.0000.2222

What I've done above is to allow a basic feel of the contexts system. This is not configured into a truly practical system. Its true application will be discussed in a different article in the future.