Section 4-1. Using Security Contexts to Make Virtual Firewalls

4-1. Using Security Contexts to Make Virtual Firewalls

Beginning with PIX 7.0 and Firewall Services Module (FWSM) 2.2(1), you can configure one physical firewall chassis to act as multiple virtual firewalls. Each virtual firewall is called a context because it is one partition or instance of a fully functional firewall.

Even though all the configured contexts are emulated by a single firewall CPU, the traffic inspection and security policies of each are kept separate, as if they were being handled by a dedicated physical firewall. Therefore, each context can be configured and managed by different administrators, or they can all be managed by one administrator who has access to them.

Traditionally, one physical firewall would be added to a network every time a new firewall function was needed. The cost of adding firewalls in this way is incremental. The ability to run multiple security contexts on a single firewall provides a way to limit the cost of firewall hardware. Firewall contexts can be added according to license limits. This capability does come with a trade-off, however, because all contexts must share the resources available on the hardware platform.

Security contexts can be useful in both service provider and enterprise environments. A service provider can partition one physical firewall into multiple security contexts that can be assigned to customers for a recurring cost. Each customer can configure and manage his or her respective context.

In an enterprise setting, multiple contexts could be assigned to individual departments or organizations where there is no overlap in security policies. Each department would operate its own firewall context independently of others. On the "public" side of each firewall, each context could connect to a shared or common Internet feed.

Security Context Organization

A Cisco firewall that can support security contexts can operate in only one of the following modes:

Single-context mode One context is configured on one physical firewall platform. This is the traditional or default mode of operation.
Multiple-context mode Two or more contexts can be configured on one physical firewall.

In multiple-context mode, a firewall is organized into the following functions, each having its own user interface:

System execution space A special area where individual contexts are defined and physical firewall resources are mapped to them. Because the system execution space doesn't use security policies and can't provide network connectivity, it can't really function as a true firewall context.
Administrative context A fully functional virtual firewall that is used mainly to manage the physical firewall. You can configure security policies, network addressing and routing, and any other firewall function needed for administrative use. This context operates independently of any other context.
User contexts Fully functional virtual firewalls that can be configured and handed over to a third party if needed. Each user context can have its own security policies, network addressing, access control, and so on. Almost anything that can be configured on a single-firewall platform can be configured on a user context.

Figure 4-1 shows how a single physical firewall can be organized to provide multiple security contexts. Each context has its own set of virtual firewall interfaces that are mapped from the physical or VLAN firewall interfaces.

Figure 4-1. Single- and Multiple-Context Security Modes

In practice, the physical firewall platform might not have enough interfaces to be able to map them one-to-one with context interfaces. In Figure 4-1, the firewall would need two unique physical interfaces for each context! Even if there were enough interfaces to go around, you might not want to use all of them in the first place when only a few could provide the necessary connectivity.

Sharing Context Interfaces

Multiple-context mode allows some flexibility in mapping interfaces. You can map one physical interface to one context interface when isolation from other firewalls is required.

You can also map one physical interface to several context interfaces so that the contexts share a single connection. This might be practical in an enterprise setting, where each context is designated for a different department. Most likely, an enterprise would have a single path toward the public Internet. Every department would share that path, provided by one physical firewall interface. As that interface is mapped to each context, the resulting logical or mapped interface would become the context's outside interface. Figure 4-2 illustrates this concept.

Figure 4-2. Mapping Common Interfaces to Contexts

Physical interfaces can be shared in any configuration. For example, if two firewall contexts need to provide access to some authentication servers that they share, one physical interface could be mapped to those two contexts and no others.

Finally, consider that all contexts are really emulated by one firewall platform. As packets enter a physical firewall interface, the firewall CPU must determine which context is the true destination.

If one physical interface is mapped to one context interface, the firewall CPU simply takes packets arriving on that interface and puts them in the queue for that context interface. The mapped context must be the virtual firewall that will inspect and handle the inbound traffic.

Suppose one physical interface is mapped to interfaces in several contexts. Now when packets arrive on that interface, the firewall CPU must decide which of the mapped contexts is the correct destination firewall.

A firewall running in multiple-context mode uses a classifier function to sort out which context should actually process each inbound packet. In effect, a classifier is positioned at each firewall interface to decide which context should receive packets as they arrive. Figure 4-3 illustrates this concept.

Figure 4-3. Using a Packet Classifier to Match Inbound Traffic to a Security Context

The classifier is simple; if it can find a unique source interface or destination address, it has enough information to hand off a packet to a context. The classifiers shown at the bottom of Figure 4-3 have an easy job because their source interfaces are mapped to a single unique context. Packets arriving on the inside interfaces are passed directly to the respective context inside interfaces to begin the normal firewall stateful inspection process.

However, if firewall interfaces are shared between contexts, as in the topmost interface shown in Figure 4-3, the problem becomes a bit more difficult. The classifier at the top of the figure is faced with the task of finding a unique destination context for each inbound packet.

A classifier does this by attempting to find the packet destination address defined in one of the connected contexts. The destination address must be uniquely identified in one of the following ways:

A global address defined in a static NAT entry
A global address used in an xlate entry
A firewall interface address (used when packets are destined for the firewall itself)

A classifier also works in only one direction. Each packet that arrives on a shared interface is examined so that it can be sent to a specific context. Because of this, you should work through scenarios with a connection originating on each side of the firewall to make sure that the classifier process will work properly. The classifier must find the destination address as a global address entry in one (and only one) of the security contexts.

For example, Figure 4-4 shows a simple arrangement in which two security contexts are configured to share their outside interfaces toward the public network. The left side of the figure shows what happens when a connection is initiated from inside host 192.168.1.100 to outside host 198.133.219.25. Because the inside context interfaces are not shared, the classifier nearest to the inside host can simply send the packets to Context A, where the host is connected. At Context A, the inside address is translated to global address 207.246.96.47, because of a static NAT configuration.

Figure 4-4. Example of Sharing Outside Context Interfaces

For the return traffic from the outside host, the classifier examines arriving packets on the shared outside interfaces. The destination address is 207.246.96.47, which is found as a global address in the xlate table on Context A. Therefore, traffic originating on the inside network can make the round trip successfully.

On the right side of Figure 4-4, a connection originates from the outside host, located on the shared interfaces. Here, the destination address 207.246.96.47 is again found as a global address in a static NAT xlate entry on Context A. This traffic too can make the round trip.

What if a dynamic NAT or PAT were used instead of a static NAT? In that case, the dynamic NAT would be configured to use one or more global addresses during translation. In Figure 4-4, the global address is 207.246.96.46, which could be found in xlate entries for connections passing through Context A. The classifiers on either side of the firewall would have no problem finding the global address on Context A.

Issues with Sharing Context Interfaces

If you decide to share the inside context interfaces, you should be aware of a classifier limitation. Consider the arrangement shown in Figure 4-5, where Contexts A and B share their inside interfaces.

Figure 4-5. Example of Sharing Inside Context Interfaces

The classifier must examine packets entering from the inside networks to decide which context should receive them. A search is made to find the packet destination addresses in the context xlate tables. In particular, the classifier can find only global addresses in the tables. This means that there must already be a static NAT entry in place for the outside address to appear as a global address.

In practice, this is seldom successful. The outside context interface usually points toward a public network such as the Internet, where most or all of the addresses exist but are not configured into the context. Usually, a default route points the way toward the public network where a context can find every other host that isn't explicitly configured. However, the classifier must use actual global addresses, not routes, so it can't determine which context to use to reach outside hosts.

To remedy this situation, you would have to configure static NAT entries for each of the outside host addresses that might be involved in connections from the inside hosts! That might result in two extremes:

The list of outside hosts would be too small to be practical for the inside users.
The number of outside hosts would be much too great to try to configure.

In most cases, the inside context interfaces are not shared because inside networks tend to be isolated and protected from every other network. However, another scenario deserves consideration. With multiple security contexts at your disposal, you might consider nesting or cascading contexts to provide layers or shells of security in an enterprise network.

Consider Figure 4-6, in which the left portion represents such a hierarchy of security contexts. The topmost context might be used at the boundary with the Internet to provide common security policies for the entire enterprise. Then other contexts might be nested below that to serve individual departments or buildings within the enterprise.

Figure 4-6. Example of Nesting Security Contexts

To test this scenario, the structure has been reduced on the right portion of the figure to show a cascade of just two security contexts. This turns out to be very similar to the previous example, in which the inside context interfaces were shared. However, it might not be obvious that the middle classifier is positioned where two context interfaces are shared. The Context A inside interface is shared with the Context B outside interface to build the cascading structure.

Again, when packets originating from the inside hosts reach this classifier, chances are that no static NAT or global address will be configured or found for outside Internet hosts. Therefore, that classifier can't decide whether to send the packets to Context A or back to Context B.

As a result, you should plan on nesting or cascading security contexts only if you can provide static NAT entries for each outside host that inside hosts will be allowed to contact. Otherwise, you can build a nested arrangement from separate physical security appliance platforms, where classifiers aren't needed between firewalls or contexts.

Configuration Files and Security Contexts

The firewall's Flash memory file system is accessible only from the system execution space. This is because Flash is considered a controlled resource, available only to the physical firewall's administrators. If an individual user context is given over to be managed by a third party, it wouldn't make sense to allow that third party to make changes to or allocate all of the firewall Flash for his or her own use.

Where, then, are the firewall image and configuration files stored for a user context? None of the contexts runs its own firewall operating system image. Only one image is run in multiple-context mode, and that image is managed only by the system execution space. All other contexts appear to run the same image, as shown by the output generated by the show version command.

Configuration files, however, are used and maintained by each context. They have the following characteristics:

The system execution space has both startup and running configuration files that are stored in the Flash memory. The startup configuration file can be read, written, and copied, but it is kept in a hidden Flash file system.
Admin and user contexts have both startup and running configuration files. The startup configuration files can be stored in the Flash file system or on an external TFTP, FTP, or HTTP server. When an external server is used, the user context administrators can have complete autonomy over the configuration and use of their firewall context.
The system execution space configuration defines where each context's startup configuration file will be located.

Guidelines for Multiple-Context Configuration

You can configure and use several different types of contexts on a physical firewall or security appliance:

The system execution space Although this isn't a true context itself, it is the foundation for all other contexts.
The admin context A fully functional virtual firewall that can be used to administer the physical firewall platform.
One or more arbitrarily named user contexts Each context operates as an independent virtual firewall.

Each has a specific role within the firewall platform, making configuration somewhat confusing.

The system execution space handles context definition, overall firewall modes of operation, and the physical firewall resources. Therefore, it should be configured before resources and features become available to other contexts.

You can configure the following types of features in the system execution space:

Physical firewall interfaces (speed, duplex, negotiation, descriptions, VLAN associations, and operational status)
System images (firewall operating system and PIX Device Manager/Adaptive Security Device Manager [PDM/ASDM] management application)
Firewall startup configuration file
Context mode (single or multiple)
Firewall mode (routing or transparent)
Context definitions (configuration files, interface allocation, or mapping)
Firewall failover
Saving crash information
Firewall system clock

You must enter firewall license activation keys from the system execution space. In addition, the system execution space provides all access to the firewall's Flash file system.

However, the system execution space has no networking capability of its own. To access external network resources, such as a TFTP server containing the firewall image, the system execution space must work in conjunction with the admin context, where normal IP addressing and address translation are configured.

You should consider each nonsystem context to be a fully functional standalone firewall. Therefore, you can configure the admin and user contexts with all the firewall features presented in this book.

Initiating Multiple-Context Mode

Follow these steps to prepare a firewall for multiple-security context support:

1.	Verify multiple-context licensing: Firewall# show activation-key A firewall can run in multiple-context mode only if it has been licensed to do so. As well, the maximum number of security contexts is set by the license. You can display the number of contexts supported by the current license, as shown in the following output: Firewall# show activation-key Serial Number: 401262144 Running Activation Key: 0xcc05f166 0xd4c17b68 0x98501048 0x818cf190 0x4133d195 License Features for this Platform: Maximum Physical Interfaces : 10 Maximum VLANs : 100 Inside Hosts : Unlimited Failover : Active/Active VPN-DES : Enabled VPN-3DES-AES : Enabled Cut-through Proxy : Enabled Guards : Enabled URL-filtering : Enabled Security Contexts : 5 GTP/GPRS : Enabled VPN Peers : Unlimited This machine has an Unrestricted (UR) license. The flash activation key is the SAME as the running key.
2.	(Optional) Install a new license activation key: Firewall# activation-key key You might need to install a new activation key if multiple-context mode is disabled or if you need to increase the number of supported contexts. The key given here is a string of five groups of characters, each consisting of four pairs of hexadecimal digits. You can add a 0x prefix to each group of hex digits to denote the hex format, but this isn't necessary. For example, you could use the following command: Firewall# activation-key 59381b44 a46717cc a43114a8 8ce11438 862113ba Refer to Chapter 2, "Configuration Fundamentals," section 2-2, "Firewall Features and Licenses," for more information about configuring license activation keys.
3.	Verify the security context mode: Firewall# show mode By default, a firewall operates in single-context mode. You can display the current mode with this command. If the firewall is currently running in single-context mode, you see the following output: Firewall# show mode Running Firewall mode: single Firewall# If the firewall is already running in multiple-context mode, you see the following output: Firewall# show mode Running Firewall mode: multiple Firewall#
4.	Initiate multiple-context mode: Firewall(config)# mode [noconfirm] multiple In single-context mode, all the firewall's configuration commands are contained in the startup configuration. Multiple-context mode changes this concept, because the initial startup configuration must contain commands that define the individual contexts. Each context has its own startup configuration file that configures features used only by that context. If single-context mode already has some configuration when this command is used, an admin context is automatically created, and the appropriate commands are imported into it. Any interfaces that were configured and enabled are automatically mapped into the admin context, too. Otherwise, the admin context begins with no mapped interfaces. The end result is that the firewall automatically generates the startup configuration for the system execution space, which is stored in a hidden Flash file system. A startup configuration for the admin context is automatically generated and stored as the flash:/admin.cfg file. Initiating multiple-context mode triggers the display of several prompts for you to confirm each action before it is carried out. You can use the noconfirm keyword to force the firewall to initiate multiple-context mode without any confirmation prompts. NOTE After it is entered, the mode command does not appear in any firewall configuration. This is because it changes the firewall's behavior. The firewall still can remember which mode to use after booting up. For example, a firewall running in single-context mode is configured to begin running in multiple-context mode. The mode multiple command produces the following output: Firewall(config)# mode multiple 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 * * --- SHUTDOWN NOW --- * * Message to all terminals: * * change mode to flash Flash Firewall mode: multiple [output omitted] Creating context 'system'... Done. (0) Creating context 'null'... Done. (257) Creating context 'admin'... Done. (1) INFO: Context admin was created with URL flash:/admin.cfg INFO: Admin context will take some time to come up .... please wait. *** Output from config line 32, " config-url flash:/admi..." [output omitted] Firewall# show mode Running Firewall mode: multiple Firewall# Notice that several contexts are automatically created during this process: The system context is actually the system execution space, the null context serves as a placeholder or a system resource, and the admin context becomes the configuration for the administrative side of the firewall. The number in parentheses after each context, such as (0), indicates the context number or index. The null context is always defined with the topmost index. After you initiate multiple-context mode, the firewall also leaves hooks for a backout plan should you ever need to revert to single-context mode. The previous running configuration is automatically saved as the flash:/old_running.cfg file. If the mode single command is used in the future, the firewall attempts to use that file to re-create a single-context mode configuration. Therefore, you should consider leaving that file intact in the Flash file system for future use.

Navigating Multiple Security Contexts

In multiple-context mode, it is possible to open an administrative session (console, Telnet, or Secure Shell [SSH]) to the firewall and then move around between security contexts. This allows you to configure and monitor any of the contexts as necessary without opening sessions to the individual virtual firewalls.

You can navigate between contexts only if you successfully connect and authenticate to the admin context or the system execution space first. At that point, you are considered an administrator of the physical firewall platform and any contexts that are configured.

If you connect to a user context first, the firewall limits your administrative session to only that context. This restricts the administrators of a user context from gaining access to any other context on the firewall. Each context is then independently managed from within that context.

Context Prompts

Moving between contexts can get confusing. During one administrative session, you might have to keep track of which physical firewall platform and which context (virtual firewall) you are connected to. Fortunately, the firewall gives you a landmark each time you move your session.

The firewall always updates its prompt to indicate which context you are currently accessing. The traditional prompt, Firewall#, represents the system context; Firewall represents the firewall's host name. Any other context is indicated by a prompt such as Firewall/context#, where context is the name of the context.

TIP

As you move into various contexts, keep in mind that each context has its own startup and running configuration. Therefore, the running configuration must be saved on each context independently.

Think of each context as an independent firewall. The admin context represents the firewall that is used by the platform administrators. The system execution space, although not a true context, provides the functions necessary to extend the physical firewall resources (interfaces, Flash memory, context definitions, and so on) to any admin and user contexts.

Changing a Session to a Different Context

You can move your terminal session from one context to another, as long as you have the administrative rights to do so, by entering the following command:

 Firewall# changeto {system | context name}

For example, suppose your firewall has the host name MyPix. It also has a system execution space (always created by default), an admin context, and a user context called CustomerA. You can use the following commands to navigate between contexts:

 MyPix# MyPix# changeto context admin MyPix/admin# MyPix/admin# changeto context CustomerA MyPix/CustomerA# MyPix/CustomerA# changeto system MyPix#

Notice how the session prompt automatically changes to indicate the firewall and context name each time the session is moved. Keep in mind that the system execution space is always called system and not context system. Therefore, it doesn't really have a context name to be displayed in the prompt.

Configuring a New Context

All contexts must be defined from a firewall's system execution space. Make sure you position your session in the system space with the following command before continuing:

 Firewall# changeto system

The firewall also needs an admin context to be able to communicate beyond itself. The admin context is usually built automatically when the firewall is configured for multiple-context mode. As well, each time the firewall boots up, you should see console messages indicating that the admin context has been rebuilt.

To see a list of the contexts that have been configured, you can use the following command:

 Firewall# show context

In the following example, only the admin context has been built:

 Firewall# show context Context Name      Interfaces                    URL *admin                                          flash:/admin.cfg Total active Security Contexts: 1 Firewall#

To configure a new context, follow these steps:

Name the context:

 Firewall(config)# context name

Every context must have a name that is unique on the physical firewall platform. This name is used in the context definition, in commands used to change sessions over to the context, in the user interface prompt, and in some forms of logging messages.

TIP

You must add an admin context to every firewall so that it can communicate with the outside world. Therefore, the first context you should create is the admin context.

By default, the admin context is named "admin" and is created by using the context admin command. If you decide to give it some other arbitrary name, you will identify it as the admin context in a later configuration step.

(Optional) Label the context:

 Firewall(config-ctx)# description text

You can define an arbitrary string of descriptive text (up to 200 characters) if you need to label a context with more information than just its name. For example, you might want to add a responsible person's name and contact information, or some specific information about the purpose of the context, such as the following:

 Firewall(config)# context BuildingC_DataCenter Firewall(config-ctx)# description Contact John Doe, jdoe@mycompany.com,   (859)555-1234; schedule any context downtime one week ahead of time.

Map existing firewall interfaces into the context.

Firewall interfaces (physical or logical) are always created and tuned from within the system execution space. All user contexts (including the admin context) begin with no interfaces when they are first defined. As well, no interfaces can be created from a user context.

Instead, you must map specific interfaces from the system execution space into a user context. After an interface has been mapped, it can be configured with a name, a security level, and an IP address from that context's configuration mode.

(PIX 7.x only) Map a physical interface:
```
 Firewall(config-ctx)# allocate-interface physical-interface [map-name]   [visible | invisible] 
```
The physical firewall interface named physical-interface ("GigabitEthernet0," for example) is mapped into the current context.
By default, the mapped interface appears with the same physical-interface hardware name in the context. If you would rather keep the interface hardware name hidden from the context users, you can specify an arbitrary interface name such as map-name. The context users then use that name to configure the interface.
By default, mapped interface hardware names are also kept invisible to context users who use the show interface command. This is identical to including the invisible keyword. If you want to provide a clue as to the context interface's position in the firewall platform, use the visible keyword. When a mapped interface is made visible, context users can see its "system name" in the show interface output, as in the following example:
```
 Firewall(config)# context NewContext Firewall(config-ctx)# allocate-interface ethernet1 test visible Firewall(config-ctx)# exit Firewall# changeto context NewContext Firewall/NewContext# show interface test Interface test "", is down, line protocol is down         System name Ethernet1         Available but not configured via nameif Firewall/NewContext# 
```
TIP

When you map an interface into a user context, you are actually creating a "hardware" name for that interface. You still have to configure the user context so that the new interface has a name, using the nameif interface configuration command. In the preceding example, context NewContext considers the new mapped interface name "test" to be the hardware device. Interface "test" doesn't have a name and a security level for firewall use until it is configured further. You could use the following commands to complete the interface configuration:
```
 Firewall/NewContext# show running-config interface test ! interface test  no nameif  no security-level  no ip address Firewall/NewContext# configure terminal Firewall/NewContext(config)# interface test Firewall/NewContext(config-if)# nameif outside INFO: Security level for "outside" set to 0 by default. Firewall/NewContext(config-if)# no shutdown 
```
Now the show interface command shows the mapped interface "hardware" name (test), the logical name (outside), and the system platform name (Ethernet1), as shown in the following output:
```
 Firewall/NewContext# show interface outside Interface test "outside", is down, line protocol is down         System name Ethernet1         MAC address 00a0.c901.0201, MTU 1500         IP address unassigned                 Received 0 packets, 0 bytes                 Transmitted 0 packets, 0 bytes                 Dropped 0 packets Firewall/NewContext# 
```

Map a physical subinterface or VLAN interface.

In PIX 7.x, a physical interface can operate as a trunk, transporting traffic over multiple VLANs, where each VLAN is mapped to a unique subinterface number. For example, in the system execution space, interface gigabitethernet1 operates as a trunk. VLAN 5 might be mapped to subinterface gigabitethernet1.5, and VLAN 7 might be mapped to gigabit-ethernet1.7. (The subinterface numbers are arbitrary and do not have to match the VLAN number.)

On an FWSM platform, only VLAN interfaces are supported as if they are physical interfaces.

You can map a subinterface or a VLAN interface from the system execution space to a user context, as if it were a physical interface. Use the following command to define a single mapping:

FWSM 2.x	`Firewall(config-ctx)#` `allocate-interface vlannumber` `[map_name]`
PIX 7.x	`Firewall(config-ctx)#` `allocate-interface` `physical-interface.subinterface` `[map_name] [visible` \| `invisible]`

The physical subinterface named physical-interface.subinterface (PIX 7.x) or the VLAN interface (FWSM) is mapped to the current context as an interface by the same name. You can include an arbitrary logical map_name if you want to keep the actual interface name hidden from the context users. In that case, the context users use map_name to further configure the interface.

You can also map a range of subinterfaces or VLAN interfaces, as long as their subinterface or VLAN numbers are contiguous. Use the following command to accomplish this mapping:

FWSM 2.x	`Firewall(config-ctx)#` `allocate-interface vlannumber-vlannumber` `[map_name-map_name]`
PIX 7.x	`Firewall(config-ctx)#` `allocate-interface` `physical-interface.subinterface-physical.interface.subinterface` `[map_name-map_name] [visible` \| `invisible]`

Specify the range of interfaces with the starting subinterface and the ending subinterface, separated by a hyphen. The physical interface name (physical-interface) must be identical in the range definition, with only the subinterface numbers changing. For example, the following command maps subinterface numbers 1 through 5:

 Firewall(config-ctx)# allocate-interface   gigabitethernet0.1-gigabitethernet0.5

For the FWSM platform, the range is given with the starting and ending VLAN interfaces, each beginning with the keyword vlan followed by the VLAN number. For example, the following command maps interfaces for VLANs 1 through 5:

 Firewall(config-ctx)# allocate-interface vlan1-vlan5

Naturally, you can also map a range of subinterfaces or VLAN interfaces to a range of logical interface names. To do so, specify the range of map names from starting to ending, separated by a hyphen. The map_name is an arbitrary name ending with a number. Both the starting and ending map_name must be identical, except for the number. The starting and ending number must define a range of the same size as the physical or VLAN interface range.

For example, you can allocate a range of five physical subinterfaces to a range of five logical names with the following PIX 7.0 command:

 Firewall(config-ctx)# allocate-interface   gigabitethernet0.1-gigabitethernet0.5 Int1-Int5

Similarly, you could use the following command on an FWSM platform:

 Firewall(config-ctx)# allocate-interface vlan1-vlan5 Int1-Int5

NOTE

Although an interface can be mapped to other contexts, each context maintains its own interface state. For example, suppose physical interface GigabitEthernet0 has been mapped to interface0 in context admin. Context admin can shut down its interface0 while the physical interface GigabitEthernet0 is still up and functioning in the system execution space.

Naturally, the reverse is not true; the system execution space controls the interface state for all other contexts. If the system space has a physical interface administratively shut down (with the shutdown command), all other contexts with that interface mapped show it as simply "down" and not "administratively down."

Also notice that, in the system space, interfaces are strictly physical and do not have logical names or security levels. You can see this in the following example:

 Firewall# show interface Interface GigabitEthernet0 "", is up, line protocol is up   Hardware is i82543 rev02, BW 1000 Mbps, Full-duplex         Description: Outside public network (non-trunk)         Available for allocation to a context         MAC address 0003.479a.b395, MTU not set         IP address unassigned [output omitted] Interface GigabitEthernet0.2 "", is up, line protocol is up         VLAN identifier 2         Description: VLAN 2 - inside private network         Available for allocation to a context Interface GigabitEthernet0.3 "", is up, line protocol is up         VLAN identifier 3         Description: VLAN 3 - stateful failover         Available for allocation to a context

Define the context startup configuration location:

 Firewall(config-ctx)# config-url url

The startup configuration can be located at a URL defined by url at any of the locations listed in Table 4-1.

Table 4-1. Context Startup Configuration Locations
Location	url Syntax
Flash memory (PIX)	`flash:/[path/]filename`
Flash memory (FWSM)	`disk:/[path/]filename`
TFTP server	`tftp://[user[:password]@]server[:port]/[path/]filename[;int=if_name]`
FTP server	`ftp://`[user[:password]@]server[:port]/[path/]filename[;type=xy] where x denotes ASCII mode (a) or binary mode (i) and y denotes passive mode (p) or normal mode (n)
HTTP server	`http[s]://[user[:password]@]server[:port]/[path/]filename`

CAUTION

As soon as you enter the config-url command, the system execution space attempts to load that configuration file immediately. This is done so that the new context can be built with a working configuration. If the URL points to a location external to the fire-wall, the IP connectivity configured on the admin context is used to reach the URL server.

However, be aware that if you re-enter the config-url command to point to a new configuration file location, the configuration commands in that file are immediately merged with the context's running configuration. This could result in an undesirable configuration.

Within the new context, the URL pointing to the configuration file is used in place of a startup configuration file in Flash memory. If the configuration file doesn't yet exist, the firewall creates the file with a minimal or blank context configuration.

Any commands that involve the startup configuration use the URL instead. For example, the copy running-config startup-config and write memory commands copy the current running configuration to a file defined by the URL.

In this fashion, the startup configuration can be uploaded to or downloaded from the URL location. The only exception is a URL that points to an HTTP or HTTPS server; then the file can only be downloaded to the firewall context.

For example, the following commands configure the CustomerA context to download its startup configuration from a TFTP server:

 Firewall(config)# context CustomerA Firewall(config-ctx)# config-url tftp://192.168.200.10/pixconfigs/   CustomerA.cfg

TIP

You can name the configuration file with any arbitrary name, with or without a dotted suffix. Usually, it's a good idea to develop some sort of naming standard. For example, the filename might indicate the context name, and a suffix of .cfg could be added to indicate that the file is a context configuration.

(Optional) Designate the admin context:

 Firewall(config)# admin-context name

By default, the admin context is named "admin," and the following command is automatically added to the system execution space configuration:

 Firewall(config)# admin-context admin

If you would rather use the context you have just created as the admin context, you can use the preceding command to assign its new role. The previous admin context still exists in the system execution space configuration and as a working context.

TIP

You must store the admin context startup configuration file in the internal Flash memory so that it is always accessible. Make sure you have defined the configuration file location as such:

 Firewall(config-ctx)# admin-context admin Firewall(config-ctx)# config-url flash:/admin.cfg

If a context other than one called "admin" is configured as the admin context, the commands might appear as follows:

 Firewall(config-ctx)# admin-context Main Firewall(config-ctx)# config-url flash:/Main.cfg

Context Definition Example

Consider a physical firewall that is configured with three separate contexts for the enterprise:

One for firewall administration
One for Department A
One for Department B

Figure 4-7 shows a network diagram of the multiple-context arrangement.

Figure 4-7. Network Diagram of the Multiple-Context Example

For the purposes of this example, each context is defined and configured with only basic interface parameters. The idea is to become familiar with context creation and configuration and interface allocation. You perform the configuration steps by connecting to the physical firewall console to gain access to the system execution space.

First, get a sampling of the physical interfaces that are available on the system execution space. These interfaces are available to be mapped into user contexts. The following command and output are used:

 Firewall# show running-config : Saved : ASA Version 7.0(1) <system> ! interface GigabitEthernet0/0  description Public interface ! interface GigabitEthernet0/1  description Trunk for private context interfaces ! interface GigabitEthernet0/1.2  vlan 2 ! interface GigabitEthernet0/1.3  vlan 3 ! interface GigabitEthernet0/1.4  vlan 4 [output omitted]

Next, the admin context is used for firewall management, so it must be defined in the system execution space configuration. The admin startup configuration is stored in Flash as the file admin.cfg. Two firewall interfaces are allocated to the context. Because it is the admin context, the interface names cannot be mapped to other arbitrary names. Use the following commands to configure the admin context:

 Firewall# configure terminal Firewall(config)# context admin Firewall(config-ctx)# config-url flash:/admin.cfg Cryptochecksum(unchanged): 352c788c 39cd2793 66c6ef98 c6bc632e INFO: Context admin was created with URL flash:/admin.cfg INFO: Admin context will take some time to come up .... please wait. Firewall(config-ctx)# Firewall(config-ctx)# allocate-interface GigabitEthernet0/0 Firewall(config-ctx)# allocate-interface GigabitEthernet0/1.2 Firewall(config-ctx)# exit Firewall(config-ctx)# admin-context admin Firewall(config)#

Now you can define a user context called DepartmentA. This is also done from the system execution space. Two firewall interfaces are allocated to the context, and the names are mapped to the generic values intf0 and intf1. For the present time, the context startup configuration is stored as a file named DepartmentA.cfg in Flash memory. You can manage this file from the system execution space only, but context users can read or write to it using the startup-config command keyword. Later, the context users can arrange to store the file on an external server. When that happens, the following config-url command needs to be updated:

 Firewall(config)# context DepartmentA Firewall(config-ctx)# config-url flash:/DepartmentA.cfg WARNING: Could not fetch the URL flash:/DepartmentA.cfg INFO: Creating context with default config Firewall(config-ctx)# description Virtual Firewall for Department A Firewall(config-ctx)# allocate-interface GigabitEthernet0/0 intf0 Firewall(config-ctx)# allocate-interface GigabitEthernet0/1.3 intf1 Firewall(config-ctx)# exit

Define the user context DepartmentB with the following commands on the system execution space. This context is structured similarly to the DepartmentA context. The startup configuration also is stored on the firewall Flash until it is moved later.

 Firewall(config)# context DepartmentB Firewall(config-ctx)# description Virtual firewall for Department B Firewall(config-ctx)# config-url flash:/DepartmentB.cfg WARNING: Could not fetch the URL flash:/DepartmentB.cfg INFO: Creating context with default config Firewall(config-ctx)# allocate-interface GigabitEthernet0/0 intf0 Firewall(config-ctx)# allocate-interface GigabitEthernet0/1.4 intf1 Firewall(config-ctx)# exit Firewall(config)# exit Firewall#

After all the contexts are defined, don't forget to save the system execution space configuration to Flash memory using the following command:

 Firewall# copy running-config startup-config

At this point, the firewall Flash memory contains the startup configuration files for every user context. (The system execution space startup configuration file is always stored in a hidden Flash file system.) The firewall Flash memory looks something like this:

 Firewall# dir flash:/ Directory of flash:/ 3      -rw-  4958208     06:41:52 Nov 30 2004  image.bin 4      -rw-  8596996     10:12:38 Nov 12 2004  asdm.bin 10     -rw-  1591        16:45:18 Dec 03 2004  old_running.cfg 12     -rw-  1853        09:47:02 Dec 30 2004  admin.cfg 14     -rw-  2119        14:16:56 Dec 07 2004  CustomerA.cfg 16     -rw-  2002        14:19:44 Dec 07 2004  CustomerB.cfg 16128000 bytes total (2565231 bytes free) Firewall#

NOTE

Notice that the system execution space contains an Adaptive Security Device Manager (ASDM) image file (asdm.bin). Users in other contexts cannot directly access the Flash file system, so those contexts can't use the image file. However, users in each context can run ASDM sessions to manage the context. The firewall coordinates all this from the system execution space from a single ASDM image. As expected, context users can see and manage only their own context.

Now, each user context can be configured as an independent firewall. Each one starts with an empty configuration, except for the mapped interface definitions, so the initial session must be opened from the system execution space. As soon as a context is configured with enough information to have network connectivity, users can connect through any other means (Telnet, SSH, ASDM, and so on).

First, change the session to the admin context and have a look at the available interfaces. Notice that each one is present but has no usable configuration.

 Firewall# changeto context admin Firewall/admin# show running-config : PIX Version 7.0(1) <context> names ! interface GigabitEthernet0/0  no nameif  no security-level  no ip address ! interface GigabitEthernet0/1.2  no nameif  no security-level  no ip address [output omitted]

At a minimum, name the inside and outside interfaces, and configure them with IP addresses and security levels. You can do this with the following configuration commands (described in more detail in Chapter 3, "Building Connectivity"):

 Firewall/admin# configure terminal Firewall/admin(config)# interface GigabitEthernet0/0 Firewall/admin(config-if)# nameif outside Firewall/admin(config-if)# security-level 0 Firewall/admin(config-if)# ip address 192.168.1.10 255.255.255.0 Firewall/admin(config-if)# no shutdown Firewall/admin(config)# interface GigabitEthernet0/1.2 Firewall/admin(config-if)# nameif inside Firewall/admin(config-if)# security-level 100 Firewall/admin(config-if)# ip address 192.168.2.1 255.255.255.0 Firewall/admin(config-if)# no shutdown

You can configure the DepartmentA and DepartmentB user contexts in a similar manner. Use the changeto context DepartmentA and changeto context DepartmentB commands to move the session to each context.

In this example, firewall interfaces are allocated to the user contexts with the mapped names intf0 and intf1. After you connect to a user context session, the only clue you have about a mapped interface is its generic or mapped name. After all, the idea behind mapping interfaces is to present context users with arbitrary interface names that don't represent physical hardware.

Therefore, you might have to return to the system execution space configuration to remember which physical firewall interface is mapped to which context interface and which context interface should be configured as inside and outside.

To continue the example, the DepartmentA user context is configured next. Notice the initial interface definitions:

 Firewall/admin# changeto context DepartmentA Firewall/DepartmentA# show running-config : Saved : PIX Version 7.0(1) <context> names ! interface intf0  no nameif  no security-level  no ip address ! interface intf1  no nameif  no security-level  no ip address [output omitted]

Now you can configure the context interfaces with the following commands:

 Firewall/DepartmentA# configure terminal Firewall/DepartmentA(config)# interface intf0 Firewall/DepartmentA(config-if)# nameif outside Firewall/DepartmentA(config-if)# security-level 0 Firewall/DepartmentA(config-if)# ip address 192.168.1.11 255.255.255.0 Firewall/DepartmentA(config-if)# no shutdown Firewall/DepartmentA(config)# interface intf1 Firewall/DepartmentA(config-if)# nameif inside Firewall/DepartmentA(config-if)# security-level 100 Firewall/DepartmentA(config-if)# ip address 192.168.3.1 255.255.255.0 Firewall/DepartmentA(config-if)# no shutdown

TIP

After you move your session to a different user context, it might be tempting to use the exit command to return to the previously visited context or the system execution space. Entering exit only terminates your session with the current context, requiring you to authenticate with it again so that you can use the changeto command.

Think of each context as having its own virtual console connection. By using the changeto command, you move the console connection from one context to another.

Allocating Firewall Resources to Contexts

When a firewall platform is running in single-context security mode, you can configure and use only one operational firewall. Therefore, that firewall can use any or all of the available traffic inspection and session resources on that hardware platform. In other words, if the firewall uses most of its own resources while it does its job, its own performance isn't affected.

In multiple-context security mode, however, all the configured contexts must share the available resources on their physical firewall platform. If one context becomes heavily loaded or highly utilized, it can use a majority of the traffic inspection resources. This can affect the other contexts by leaving them starved for the same resources.

Multiple-context mode can support resource allocation by imposing limits on how specific resources are used. You can configure resource limits in classes according to the resource type and assign memberships in the classes to contexts. Resource allocation has the following characteristics:

Resource allocation is available on the FWSM, starting with release 2.2(1). This feature currently is unavailable in PIX 7.0, although it is planned for a future release.
Firewall resources that can be limited fall into several categories:
- Stateful inspection The number of hosts, connections, address translations, and application inspections

- MAC addresses The number of MAC addresses learned in transparent firewall mode

- Syslog message generation rate The number of logging messages sent per second to Syslog servers

- Administrative sessions The number of Telnet, SSH, and IPSec connections to the firewall
The default class permits unlimited use of most resources for all contexts by default. You can configure the default class and adjust specific resource limits in it, if needed.
You can define and configure new classes with resource limits tailored for a certain level of service.
You can impose specific limits on a context by assigning it membership in a class. Otherwise, every context that is not a class member belongs to the default class.
Limits are set per class, not per context. Therefore, all contexts that are assigned to a class share various resources up to the limits of that class. To configure limits on a per-context basis, define one class per context and assign each context to its respective class.
To exercise thorough control over system resources, you should define classes with specific limits. Then make sure every context is assigned to a class. After that's done, no context can inherit the unlimited resources of the default class.

You can use the following steps to define and apply classes of resource limits to security contexts:

Define a class of service.

Identify the class:
```
 Firewall(config)# class name 
```
The class is named name (an arbitrary string up to 20 characters).
TIP

You can adjust the resource limits that are defined in the default class by using the class name default in this configuration step. The command syntax then becomes class default. By default, all the default class limits are set to unlimited (0), except for the following:
- Telnet sessions (the default is 5)
- SSH sessions (the default is 5)
- IPSec sessions (the default is 5)
- MAC addresses (the default is 65,535 entries)
(Optional) Define a limit for all resources:
```
 Firewall(config-class)# limit-resource all number% 
```
All resource types are limited to number (1 to 100) percent of the maximum available on the physical firewall platform. This limit overrides any resource types that are set in the "default" class. If number is set to 0, all resources are allowed to be unlimited. The value number must be followed by a percent character.
For example, to limit all resources to 50 percent of their possible values, you would use the following command:
```
 Firewall(config-class)# limit-resource all 50% 
```

(Optional) Define a limit for a single resource:

 Firewall(config-class)# limit-resource [rate] resource_name number[%]

You can limit a specific firewall resource within the class. If you set a limit with this command, it overrides any limit set by the limit-resource all command or by the "default" class.

You can limit the resource named resource_name to an actual value as number or to a percentage of the maximum possible value as number%. You can also add the rate keyword to indicate that number should be interpreted in units per second.

Use Table 4-2 to find resource names and their maximum values.

Table 4-2. Resource Names and Maximum Values
resource_name	Resource Type	Platform Maximum^[1]
hosts	Number of concurrent hosts having connections	256,000
conns	Total UDP and TCP connections between any hosts	999,900 concurrent 102,400 per second
xlates	Address translations	256,000 concurrent
fixups	Application inspections	10,000 per second
mac-addresses	Transparent firewall MAC address table	65,000 concurrent
syslogs	Syslog messages generated	30,000 per second^[2]

^[1] Platform maximum values shown are for the FWSM. Currently, the resource allocation feature is unavailable for the PIX or ASA platforms in PIX 7.0.

^[2] The FWSM can generate a sustained rate of 30,000 logging messages per second to a terminal session or the internal logging buffer. Sending messages to a Syslog server imposes additional packet overhead, reducing the actual rate to 25,000 messages per second.

Firewalls also support resource limits on various types of sessions that terminate on the firewall. Use Table 4-3 to find those resource names and maximum values.

Table 4-3. Resource Names and Maximum Values for Terminating Session Types
resource_name	Resource Type	Platform Maximum
telnet	Concurrent Telnet sessions	100^[1]
ssh	Concurrent SSH sessions	100^[1]
ipsec	Concurrent IPSec connections	10^[2]

^[1] The FWSM can support up to 100 concurrent Telnet and SSH sessions over all contexts. It imposes a limit of five concurrent Telnet and five concurrent SSH sessions per context.

^[2] The FWSM can support up to 10 concurrent IPSec connections over all contexts, or up to five concurrent connections per context.

You can repeat the limit-resource command to define other resource limits for the class. For example, a class called Silver is configured to limit all firewall resources to 25% of the maximum available resources. In addition, the number of xlates is limited to 50,000, and the number of conns is limited to 100,000. The number of Syslog messages is limited to 4000 per second. You can use the following commands to define these limits:

 Firewall(config)# class Silver Firewall(config-class)# limit-resource all 25% Firewall(config-class)# limit-resource xlates 50000 Firewall(config-class)# limit-resource conns 100000 Firewall(config-class)# limit-resource rate syslogs 4000

Exit the resource class submode:
```
 Firewall(config-class)# exit 
```

Assign a context to a class.

Select a context:
```
 Firewall(config)# context name 
```
The context name should already be defined in the system execution space configuration.
Assign it to a resource class:
```
 Firewall(config-ctx)# member class 
```
The context becomes a member of the resource allocation class named "class," as defined in Step 1. You can assign membership in only one user-defined class per context. Keep in mind that every context also belongs to the default class. Any resource limit that isn't defined in "class" is then inherited from the default class.

Monitor resource allocation.

Display class membership:
```
 Firewall# show class 
```
Each of the configured classes is shown with its member contexts. In the following example, all contexts are members of the "default" class, and only context 1 is a member of the "silver" class:
```
 Firewall# show class Class Name           Members    ID   Flags default                All       1    0001 silver                   1       2    0000 Firewall# 
```

Review resource allocation:

 Firewall# show resource allocation [detail]

You can use this command to display the current breakdown of resource limits as percentages of the total available. Add the detail keyword to see a more detailed breakdown by resource and context, as in the following example:

 Firewall# show resource allocation Resource                    Total          % of Avail  Conns [rate]               85000              50.00%  Fixups [rate]              50000              50.00%  Syslogs [rate]             15000              50.00%  Conns                     500000              50.05%  Hosts                     131072              50.00%  IPSec                          5              50.00%  Mac-addresses              32767              49.99%  SSH                           50              50.00%  Telnet                        50              50.00%  Xlates                    131072              50.00% Firewall# show resource allocation detail Resource Origin:         A       Value was derived from the resource 'all'         C       Value set in the definition of this class         D       Value set in default class Resource         Class         Mmbrs  Origin      Limit    Total   Total % Conns [rate]     default         all      CA  unlimited                  silver            1      CA      85000    85000    50.00%                  All Contexts:     1                       85000    50.00% Fixups [rate]    default         all      CA  unlimited                  silver            1      CA      50000    50000    50.00%                  All Contexts:     1                       50000    50.00% Syslogs [rate]   default         all      CA  unlimited                  silver            1      CA      15000    15000    50.00%                  All Contexts:     1                       15000    50.00% Conns            default         all      CA  unlimited                  silver            1      CA     500000    500000   50.05%                  All Contexts:     1                       500000   50.05% [output truncated]

Display the current resource usage:

 Firewall# show resource usage [context context_name | top n | all |   summary | system] [resource {[rate] resource_name | all} | detail]   [counter counter_name [count_threshold]]

You can use this command to display the actual resources being used, as described in Table 4-4.

Table 4-4. Options for Displaying Resources Being Used
Keyword	Description
context context_name	Resources in use by the context named context_name
top n resource resource_name	Displays the n greatest users of a specific resource
all	Displays all resource usage information
summary	Displays a summary by resource type
system	Resources in use by the system execution space

You can also display the results for a specific resource by giving the resource keyword along with a resource_name.

Normally, each resource usage line is shown with the fields listed in Table 4-5.

Table 4-5. Resource Usage Line Fields
Label	Description
Current	The number of resources currently in use
Peak	The highest amount since counters were cleared
Limit	The limit imposed on a resource
Denied	How many times a resource use has been denied because of a limit
Context	The context using the resource

If you enter the counter keyword, you can display results based one of the following specific counter_name values: current, peak, denied, or all.

You can also get a feel for the complete variety and number of firewall resources used by a context. By adding the detail keyword, you can see all resources being used, whether or not the resources can be limited.

Verifying Multiple-Context Operation

To see the current admin context name and configuration URL, you can use the show admin-context command, as in the following example from a PIX 7.0 platform:

 Firewall# show admin-context Admin: admin flash:/admin.cfg Firewall#

To see information about the configured contexts, you can use the following command:

 Firewall# show context [[detail] [name] | count]

You can specify a context name to see information about only that context. Otherwise, all the contexts are shown. Include the detail keyword to see a breakdown of each context resource, including the configuration URL and interface mappings.

The following example shows the output from a firewall running PIX 7.0 that has three configured contexts: admin, CustomerA, and CustomerB.

 Firewall# show context Context Name      Interfaces                    URL *admin            GigabitEthernet0              flash:/admin.cfg                   GigabitEthernet1.1  CustomerA        GigabitEthernet0,             tftp://172.30.1.10/customerA.cfg                   GigabitEthernet1.3  CustomerB        GigabitEthernet1.2,3          tftp://172.16.0.20/customerB.cfg Total active Security Contexts: 3 Firewall#

On an FWSM platform, the same command produces slightly different output:

 Firewall# show context Context Name      Class      Interfaces         URL *admin            silver     Vlan10,100         disk:/admin.cfg CustomerA         silver     Vlan20,100         tftp://172.30.1.10/customerA.cfg CustomerB         default    Vlan30,100         tftp://172.16.0.20/customerB.cfg

You can add the detail keyword to see a breakdown of the context configuration. The following example shows the detailed configuration for a context named CustomerA:

 Firewall# show context detail CustomerA Context "CustomerA", has been created   Desc: Virtual firewall for CustomerA's headquarters location   Config URL: tftp://172.30.1.10/customerA.cfg   Real Interfaces: GigabitEthernet0, GigabitEthernet1.3   Mapped Interfaces: intf0, intf1   Flags: 0x00000011, ID: 2   Failover group: 1 Firewall#

Finally, although the firewall can't limit CPU load as a resource that is shared across contexts, the firewall does keep CPU load statistics. You can see a breakdown of the CPU usage as it is distributed across all the configured contexts. Use the following command from the system execution space:

 Firewall# show cpu usage context {name | all}

The following example shows CPU usage on a firewall configured with three contexts:

 Firewall# show cpu usage context all  5 sec  1 min  5 min  Context Name   7.1%   8.0%   7.1%  system  12.0%  12.0%  10.0%  admin  27.7%  28.5%  27.0%  CustomerA   4.0%   4.0%   4.0%  CustomerB Firewall#