Cisco Virtual Firewalls

With today’s architectural improvements to security appliances, security virtualization and consolidation (think UTM) are at an all time high. Gone are the days of 1 appliance performing 1 function, for 1 network segment. We have just scratched the surface when it comes to security virtualization. In the very near future, security appliances can and will be sliced and diced as much as servers are currently. They too will become the dominant weekly topic in 15 consecutive issues of Network World (one issue they praise VmWare, the next it’s a Hyper-V love fest). None the less, Cisco virtualization is in full swing thanks to Security Contexts.

Virtualization is not for everyone. If you’re a mom an pop store currently happy with your Cisco 505’s performance and not worried about it’s lack of support in the near future, by all means stick with it. But if you are a service provider, NOC, MSS, educational institution, or CSO of a large corporation, virtualization may make economic sense and prove to be a management slam dunk. Gone is the need to buy 10, 20, 50 separate appliances for each of your managed customers, departments, or overlapping network segments. No more looking at that data center diagram to figure out where customer A’s firewall is located in relation to customer B’s. Customer’s A-Z are all located in the same place.

When using multiple Security Contexts, the security appliance is divided into either system execution space, admin context, or individual management contexts.

The system execution space, residing in NVRAM, is used to define the attributes of other security contexts. This is where Security Contexts are created, named, and configured. From the system execution space, resources can be allocated to Security Contexts using configlets (the context’s configuration file). Interfaces are also assigned from the system execution space. Global parameters like boot settings, file management, and failover are also configured here.

The admin context’s primary function is to provide connectivity to network resources. Since Security Contexts are typically deployed in transparent mode (more on that later), the admin context is responsible for providing the management interfaces that allow SSH or HTTPS access. It is also the launch point for other contexts. Administrators can easily jump from one context to another, from the admin context, and not worry about administration requirement of each individual context. The rights of the admin context are inherited when changing from it to any other context.

The admin context must be created before any other contexts and, unlike other contexts, must reside on the local disk. When converting from a stand alone single function appliance (single mode) to a virtual security appliance (multi mode), the network configuration of the single mode appliance is saved as part of the admin context.

The customer context is a virtual firewall containing it’s own configuration for a specific customer. Interfaces are allocated in the system execution space for each customer security context. Administrators of a customer security context (unlike administrators of the admin context) can only access and view the configuration of their assigned customer security context. They cannot copy system images, access the system execution space, or the admin context. One of the major advantages of using multi mode within a single corporation is that it allows for overlapping networks. As an engineer for an MSS (Managed Security Services), I manage many of the biggest Fortune 500 companies around. In order to stay competitive, these industry leading institutions acquire smaller companies that offer a unique nitch to add to their portfolio. Since it is easier to grow via acquisitions than to build from the ground up, they are able to get a foothold into these new arenas immediately. But this “hit the ground running” approach can be a nightmare for the entire IT department. Why? Because most companies use RFC 1918 addresses for their internal networks. Core routers often allocate the entire 10/8, 172.16/12, or 192.168/16 address space and then subnet those addresses for individual network segments. When a company is acquired, it is very likely that their established internal addressing already uses addresses allocated at the new parent company. So now the IT department must re address every single server, host, client, and node on the network to accommodate this acquisition. Multi mode allows for the new acquisition to be assigned it’s own security context, that contains it’s own internal routing, even if that same network exists elsewhere within the same company.

There are some drawbacks to virtualizing a Cisco firewall. For starters, VPNs are not supported in multi mode. If B2B or remote access VPNs are required, you will have to stick to single mode. Multicast is not supported in multi mode as well as QOS.

When considering how many customer contexts can and should be created, two things should be considered. First is licensing. Security Contexts are purchased in licensed bundles starting with 5. The “show version” command from the system execution space will display the number of available Security Contexts (not including the admin context). Next, resource allocation needs to be considered. If physical interfaces are being assigned per context (VLAN tagging can also be used in transparent mode), you will of course have to have the available interfaces. When disk space and RAM is assigned to a Security Context, the amount of available resources is decreased for new contexts.

The packet flow for a Security Context would nearly double the size of this article and will not be discussed. I supposed that if you are at the packet flow stage, you have already decided that this option is appealing to you and should look into Cisco Press’ book, “Cisco ASA: All-in-One Firewall, IPS, and VPN Adaptive Security Appliance” which contains an extensive chapter on Security Contexts. In short I will say that the packet flow is almost exactly that same as single mode if Security Contexts use physical interfaces. But since multi mode is the ideal solution for data centers, physical interfaces are almost never used. In that case, VLAN tagging, the src address, dst address, and ports all play a role in determining whci Security Context will be used.

Cisco defines the steps of setting up Security Contexts as follows:

1. Enable multiple security contexts globally.
2. Set up the system execution space.
3. Specify a configuration URL.
4. Allocate the interfaces.
5. Configure an admin context.
6. Configure a customer context.
7. Manage the security contexts (optional).

See the links below for a configuration example of Multiple Contexts.

Here are a few troubleshooting commands:

sh cpu context all When ran from the system context, this shows cpu for all contexts.

sh resource usage Displays current and peak settings for xlates, nodes, macs, per context.

sh context detail Shows detailed information on all contexts including interface assignments (and VLAN tag), location of config file (which can be on the network –except for the admin context), and context ID.

Show resource acl-partition Displays physical partitions, contexts contained in each partition, and resource limitations (max rules, objects, etc).

Changeto context Changes to another context.

Links:

Configuration example

Cisco overview