Home > Articles > Cisco Network Technology > General Networking > Cisco ASA Security Contexts

Cisco ASA Security Contexts

Contents

  1. Architectural Overview
  2. Configuration of Security Contexts
  3. Deployment Scenarios
  4. Monitoring and Troubleshooting the Security Contexts
  5. Summary

Chapter Description

The virtual firewall methodology enables a physical firewall to be partitioned into multiple standalone firewalls. Each standalone firewall acts and behaves as an independent entity with its own configuration, interfaces, security policies, routing table, and administrators. In Cisco ASA, these virtual firewalls are known as security contexts. This chapter covers security contexts in detail.

Monitoring and Troubleshooting the Security Contexts

Cisco ASA provides show and debug commands that are useful to check the health of the appliance or to isolate a problem. The necessary show and debug commands that are used to manage multiple security contexts in the appliance are discussed here.

Monitoring

After the system is converted to multiple contexts, the first thing to verify is that the system is using the new mode by using the show mode command, as shown in Example 9-19.

Example 9-19. Output of show mode

Sydney# show mode

   Security context mode: multiple

Once you verify that the system is running in multiple mode, configure the necessary contexts and assign the appropriate interfaces. A good way to check if the interfaces have been correctly assigned to the right context is to use the show context command. It lists all the configured contexts, the allocated interfaces, and the configuration URL. Example 9-20 shows the output of show context in the Chicago ASA, while logged into the system execution space.

Example 9-20. Output of show context in the System Execution Space

Chicago# show context
Context Name      Interfaces                URL
*admin            GigabitEthernet0/0.1      disk0:/admin.cfg
                  GigabitEthernet0/1.1
 Cubs             GigabitEthernet0/0.2,     disk0:/Cubs.cfg
                  GigabitEthernet0/1.2,
                  GigabitEthernet0/1.5
 Bears            GigabitEthernet0/0.3      disk0:/Bears.cfg
                  GigabitEthernet0/1.3
Total active Security Contexts: 3

The asterisk (*) next to admin indicates that this is an admin context. Another way to find out which context is designated as the admin context is to use the show admin-context command, as illustrated in Example 9-21.

Example 9-21. Output of show admin-context in the System Execution Space

Chicago# show admin-context
Admin: admin disk0:/admin.cfg

A context administrator can view the context settings from within his security context. In Example 9-22, the administrator of the Cubs context is verifying the allocated interfaces and the configuration URL.

Example 9-22. Output of show context from a Security Context

Chicago/Cubs# show context
Context Name      Interfaces               URL
 Cubs             GigabitEthernet0/0.2,    disk0:/Cubs.cfg
                  GigabitEthernet0/1.2,
                  GigabitEthernet0/1.5

Cisco ASA allows monitoring of CPU usage per security context. This is useful to determine which context is utilizing the most of the CPU cycles. Use the show cpu usage context all command to check the CPU utilization on each of the configured security contexts. In Example 9-23, the total system CPU utilization is 9.5 percent averaged over 5 seconds, 9.2 percent averaged over 1 minute, and 9.3 percent averaged over 5 minutes. The Cubs security context is using the most of the CPU cycles, averaging 5 percent over 5 seconds, 1 minute, and 5 minutes.

Example 9-23. Output of show cpu usage context all from the System Execution Space

Chicago# show cpu usage context all
5 sec  1 min  5 min  Context Name
9.5%   9.2%   9.3%   system
0.3%   0.0%   0.1%   admin
5.0%   5.0%   5.0%   Cubs
4.2%   4.2%   4.2%   Bears

Troubleshooting

For troubleshooting purposes, Cisco ASA includes a number of important debug and syslog messages to help you isolate the issue. This section discusses four troubleshooting scenarios related to security contexts:

  • Security contexts are not added— When adding new contexts, the Cisco security appliance displays a message that the new security contexts creation failed, as shown in Example 9-24.

    Example 9-24. Security Context Creation Failure

             Chicago(config)# context WhiteSox
             
    Creating context 'WhiteSox'...
    Cannot create context 'WhiteSox': limit of 3 contexts exceeded
    ERROR: Creation for context 'WhiteSox' failed
          

    The Cisco ASA appliance complains about exceeding the maximum number of security contexts allowed in this device. To verify the maximum number of allowed security contexts, use the show version command, as shown in Example 9-25.

    Example 9-25. Verifying the Maximum Number of Security Contexts

             Chicago# show version | include Security Contexts
             
    
             Security Contexts            
             : 10
          

    Depending on the security appliance model number, the administrator can add the maximum allowed security context number. Refer to Chapter 3, "Hardware Overview," for more information about the allowed number of security contexts in a Cisco ASA.

  • Security contexts are not saved on the local disk— If the security context configuration files are stored locally on the disk, and the appliance is having trouble either retrieving or saving them, you can enable debug disk to gather information.In Example 9-26, debug disk file,file-verbose, and filesystem are enabled with a log level of 255. In this example, the administrator saves the running configuration into the Flash file system. The highlighted entries show that the appliance opens up the running configuration file from the disk and writes the new contents. If Flash is corrupt, the administrator will see failed attempts to read or write files. These messages are analyzed by the Cisco Technical Assistance (TAC) engineers.

    Example 9-26. Output of debug disk

             Chicago# debug disk file 255
             
    
             Chicago# debug disk file-verbose 255
             
    
             Chicago# debug disk filesystem 255
             
    
             Chicago# write memory
             
    Building IFS: Opening: file system:/running-config, flags 1, mode 0
    IFS: Opened: file system:/running-config as fd 0
    IFS: Fioctl: fd 0, fn 5, arg 370e7e0
    configuration...
    IFS: Read: fd 1, bytes 147456
    IFS: Read: fd 1, bytes 146664
    IFS: disk0:/.private/startup-config 100% chance ascii text
    <snip>
    1047 IFS: Close: fd 0
    bytes copied in 4.40 secs (261 bytes/sec)IFS: Write: fd 0, bytes 1
          
  • Security contexts are not saved on the FTP server— If the security appliance is having issues when saving and retrieving configuration files from an FTP server, use the debug ftp client command to isolate the issue. In Example 9-27, the appliance is being configured to use an FTP server. The debug shows that the user password is incorrect in the configuration URL.

    Example 9-27. Output of debug ftp client

             Chicago(config)# debug ftp client
             
    
             Chicago# context CustB
             
    
             Chicago(config-ctx)# config-url ftp://cisco:cisco123@172.18.124.27/CustB.cfg
             
    IFS: Opening: file ftp://cisco:cisco123@192.168.20.50/CustB.cfg, flags 1, mode 0
    IFS: Opened: file ftp://cisco:cisco123@192.168.20.50/CustB.cfg as fd 0
    IFS: Fioctl: fd 0, fn 5, arg 279bc64
    Loading CustB.cfg
    FTP: 220 Please enter your user name.
    FTP: ---> USER cisco
    FTP: 331 User name okay, Need password.
    FTP: ---> PASS *
    FTP: 530 Password not accepted.
    FTP: ---> QUIT
    FTP: 221 Goodbye. Control connection closed.
    IFS: Close: fd 0
  • User connectivity issues using shared security contexts— As shown in Figure 9-6, when Host A in the Students context is not able to reach Host B in the Faculty context, the administrator can take the following steps to isolate the issue:
    1. Ping the inside IP address of the S_inside interface from Host A. If successful, move to Step 2; otherwise, check to see if there is an inbound ACL applied to the inside interface. Also verify that physical connectivity exists between the host and the inside interface.
    2. Ping the outside IP address of the F_outside interface from Host A. If successful, move to Step 3; otherwise, check the outbound ACL and NAT configuration on the Students context. Additionally, verify that the inbound ACL on the F_outside interface allows ICMP traffic from Host A.
    3. Because this topology uses a shared interface, check the NAT configuration on the Faculty context. Ping from Host A to Host B and verify that the outbound ACL on F_inside does not block the ICMP packets.
    4. If Host A is still not able to communicate with Host B in the other context, follow Step 1 through Step 3 and ping from Host B to Host A to verify connectivity and the contexts' configuration.