Cisco Firewalling Solutions: Cisco IOS Zone-Based Firewall and Cisco ASA - Threat Control and Containment - Implementing Cisco IOS Network Security (IINS) Foundation Learning Guide, Second Edition (2013)

Implementing Cisco IOS Network Security (IINS) Foundation Learning Guide, Second Edition (2013)

Part III: Threat Control and Containment

Chapter 10. Cisco Firewalling Solutions: Cisco IOS Zone-Based Firewall and Cisco ASA

Two of the Cisco Firewall solutions, Cisco IOS Zone-Based Policy Firewalls and Cisco Adaptive Security Appliance, can be configured to perform basic security operations on a network. At the end of this chapter, you will be able to do the following:

• Introduce and describe the function, operational framework, and building blocks of Cisco IOS Zone-Based Firewalls

• Describe the functions of zones and zone pairs, as well as their relationship in hierarchical policies

• Describe Cisco Common Classification Policy Language for creating zone-based firewall policies

• List the default policies for the different combinations of zone types

• Demonstrate the configuration and verification of zone-based firewalls using Cisco Configuration Professional and the CLI

• Demonstrate the configuration of NAT services for zone-based firewalls

• Describe the Cisco ASA family of products, identifying key supported features

• Describe the building blocks of Cisco ASA configuration

• Describe the navigation options, features, and requirements of Cisco ASDM

• Describe the use of access control lists on Cisco ASA

• Describe the deployment of policies using the Cisco Modular Policy Framework

• Describe the configuration procedure to deploy basic outbound access control on Cisco ASA using Cisco ASDM

The zone-based policy firewall changes the original implementation of Cisco IOS Classic Firewall stateful inspection from the older interface-based model to a more flexible, more easily understood zone-based configuration model. The first section of this chapter focuses on the features of Cisco IOS Zone-Based Policy Firewalls and how to use Cisco Configuration Professional to configure them.

Cisco Adaptive Security Appliance (ASA) implements a rich set of security technologies and can be effectively implemented as a perimeter firewall using several deployment modes. The second section of this chapter introduces Cisco ASA functionality, features, and underlying technologies and demonstrates how to configure the Cisco ASA 5505 model for basic connectivity using Cisco Adaptive Security Device Manager (ASDM).

Cisco Firewall Solutions

Cisco offers multiple different firewall solutions, each geared to a different environment. Currently, Cisco Firewall offerings include

• Cisco IOS Firewall

• Cisco ASA 5500 Adaptive Security Appliances

• Cisco ASA 1000V Cloud Firewall

• Cisco Virtual Security Gateway for Nexus 1000V Series Switch

• Cisco Catalyst 6500 Series ASA Services Module

• Cisco Catalyst 6500 Series Firewall Services Module

• Cisco Small Business SA500 Series Security Appliances

In this chapter, we cover the two first firewall technologies: Cisco IOS Firewall and Cisco ASA firewall.

Cisco IOS Zone-Based Policy Firewall

Many different types of techniques are used for firewalling. Cisco IOS routers have been using many different techniques for firewalling over the years. Recently, Cisco introduced Zone-Based Policy Firewall as an alternative to the older technology called Context-Based Access Control.

Zone-Based Policy Firewall Overview

The original implementation of Cisco IOS Classic Firewall stateful inspection used an interface-based configuration model, in which a stateful inspection policy was applied to an interface. All traffic passing through that interface received the same inspection policy. This configuration model limited the granularity of the firewall policies and caused confusion of the proper application of firewall policies, particularly in scenarios when firewall policies must be applied between multiple interfaces.

Zone-based policy firewalls (sometimes referred to as ZBF, or zone-policy firewall [ZPF]) change the firewall from the older interface-based model to a more flexible, more easily understood configuration model where interfaces are assigned to zones, and an inspection policy is applied to traffic moving between the zones. To demonstrate this model, Figure 10-1 shows three zones:

Untrusted: Represents the Internet

DMZ: Demilitarized zone, which contains the corporate servers accessed by the public

Trusted: Represents the inside network

Figure 10-1. Cisco IOS Zone-Based Policy Firewall


Notably missing from Figure 10-1 is the self zone, the zone used for traffic generated by the router or destined to it, such as routing protocol traffic. The self zone is covered later in the chapter.

Interzone policies offer considerable flexibility and granularity, and thus enable you to apply different inspection policies to multiple host groups that are connected to the same router interface. The interzone policies in Figure 10-1 are as follows:

Public-DMZ: DMZ policy that sets the rules for traffic originating from the untrusted zone with the DMZ as destination

DMZ-Private: Private policy that sets the rules for the traffic originating from the DMZ with the trusted zone as destination

Private-DMZ: DMZ policy that sets the rules for the traffic originating from the trusted zone with the DMZ as destination.

Private-Public: Pubic policy that sets the rules for the traffic originating from the trusted zone with the untrusted zone as destination

Rules are bidirectional. As an example, traffic originating from the trusted zone going to the DMZ would be allowed to return due to the Private-DMZ policy, which would permit the connection and allow the return traffic to come back in the trusted zone. The DMZ-Private policy is not involved for return traffic that originated from the trusted network and for which the reply is now going from the DMZ to the trusted network. The DMZ-Private policy is only needed for traffic originating from the DMZ and destined for the trusted network. This could be the case for email: all the incoming mail could end up in the DMZ to be analyzed by the Cisco IronPort Email Security Appliance (ESA). The ESA would forward to Microsoft Exchange Server, located on the trusted network, email it considered appropriate. The connection would originate from the ESA located in the DMZ and go to MS Exchange Server located on the trusted network. In this case, the DMZ-Private policy would be invoked to permit this traffic. This is likely the only permit action on the DMZ-Private policy: let email flow from the ESA to MS Exchange Server.

The firewall will have a rule that denies email to flow directly from the Internet to MS Exchange Server located on the trusted network.

Zone-based policy firewalls are configured with the Cisco Common Classification Policy Language (C3PL), which uses a hierarchical structure to define inspection for network protocols and the groups of hosts to which the inspection will be applied.

Cisco IOS Zone-Based Policy Firewalls support the following features:

• Stateful inspection

• Application inspection

• URL filtering

• Per-policy parameter

• Transparent firewall

• Virtual routing and forwarding aware firewall

First-generation firewalls, which were essentially packet filters, used only ACLs to control traffic. For this reason, it was relatively easy for attackers to breach a firewall, because no state data was examined. Second-generation firewalls, known as proxy firewalls, were concerned with the state of the connection, but they were application dependent. Third-generation firewalls, which were stateful packet filters, were developed to provide state tracking, application independence, and speed. Context-Based Access Control (CBAC), from the legacy Cisco IOS Firewall feature set, is an example of this type of third-generation firewall. CBAC performed traffic filtering using stateful filters, whereby selected outbound traffic created a temporary opening in the filter for replies to return through.


CBAC can still be implemented on Cisco IOS Firewalls; however, interfaces that participate in a zone-based policy firewall cannot also participate in CBAC.

The legacy stateful inspection done by CBAC was very complicated because there was a combination of ACLs and inspection rules, all of which worked together to accomplish the stateful packet filtering done by the firewall.

The Cisco IOS Zone-Based Policy Firewall completely changes the way a Cisco IOS Firewall is configured.

The first major change to the firewall configuration is the introduction of a zone-based configuration. The classic Cisco IOS Firewall stateful inspection (CBAC) used an interface-based configuration model that you configured using the ip inspect command. This changed with the introduction of the Cisco IOS Zone-Based Policy Firewall, which does not use the stateful inspection (CBAC) commands but rather uses C3PL. You could use the two configuration models concurrently on routers, but not on the same interfaces; you cannot configure an interface as a security zone member and for ip inspect simultaneously.

Zones establish the security borders of your network. A zone defines a boundary where traffic is subjected to policy restrictions as it crosses to another region of your network. The default policy of a zone-policy firewall between zones is to “deny all.” If no policy is explicitly configured, all traffic moving between zones is blocked. This policy is a significant departure from the stateful inspection model, in which traffic is implicitly allowed unless it is explicitly blocked with an ACL entry.

The second major change is the introduction of the new classification policy language known as C3PL. The C3PL structure is similar to the Modular QoS CLI (MQC) structure in which class maps specify the traffic that is affected by the action that the policy map applies. C3PL will be discussed later in this chapter.


Interface ACLs are still relevant and are applied before zone-based policy firewalls when they are applied inbound. Interface ACLs are applied after zone-based policy firewalls when they are applied outbound.

Key benefits of zone-based policy firewall are as follows:

• It is not dependent on ACLs.

• The router security posture is restrictive (which means block unless explicitly allowed).

• C3PL makes policies easy to read and troubleshoot.

• One policy affects any given traffic instead of needing multiple ACL and inspection actions.

Zones and Zone Pairs

A zone is a collection of networks that are reachable over a specific router interface and are designated to require the same security policies. Zone-based policy firewall access control policies then control access between two or more zones that are configured on the router, using a flexible configuration language that allows you to specify simple or complex access policies in a manageable manner.

Once zones are created, default rules apply. These default rules will be presented in more detail later in this chapter. Default rules generally allow unrestricted access between interfaces that belong to the same zone, while denying all interzone traffic. Figure 10-2 shows two interfaces belonging to Zone 2. These two interfaces can pass traffic between them without any restrictions.

Figure 10-2. Interfaces Belong to Zone


An interface can belong to one zone and one zone only.

A zone pair allows you to specify a unidirectional firewall policy between two security zones, thus changing the default policy. The direction of the traffic is indicated by specifying a source zone and a destination zone. The source and destination zones of a zone pair must be previously created security zones.

To permit traffic between zone-member interfaces, you must configure a policy permitting (or inspecting) traffic between that zone and another zone.

Self Zone

If desired, you can select the default or self zone as either the source zone or the destination zone. The self zone is a system-defined zone. It does not have any interfaces as members. A zone pair that includes the self zone, along with the associated policy, applies to traffic directed to the router or traffic that is generated by the router. A zone pair does not apply to traffic through the router. Traffic to or from the self zone is by default permitted.

Zone-Based Topology Examples

A zone-based firewall approach results in multiple deployment options that will represent your security domains, which is a more intuitive way to implement firewall policies than a per-interface approach.

Figure 10-3 shows a simple firewall with two security domains, suitable for remote office environments where outbound access is required only to the Internet or to a hub network. Trusted internal interfaces belong to an “inside” zone, while untrusted external interfaces belong to an “outside” zone.

Figure 10-3. Simple Firewall Topology with Two Security Domains

Figure 10-4 shows a medium-sized location requiring inbound access to a few public servers, in addition to outbound user access. A third zone, the DMZ, includes the interfaces and assets that are related to the servers located in DMZ interfaces, which require restricted access from the outside, and perhaps a more granular permissive policy from the inside.

Figure 10-4. Medium-Sized Organization with Three Zones

If an interface doesn’t belong to a zone, it can’t communicate with an interface that is part of a zone.

Introduction to Cisco Common Classification Policy Language

A class is a way to identify a set of packets based on their contents. A class is a particular type of traffic; it can be thought of as a precise flow of traffic. Examples of a class of traffic would be traffic for destination port 80 or traffic with a specific subnet source IP address. Normally, you define a class to then apply to the traffic identified by that class an action that reflects a particular policy. A class is designated through class maps.

An action is a specific functionality. It typically is associated with a traffic class. For example, inspect, drop, and pass are actions.

To create firewall policies, complete the following tasks:

Step 1. Define a match criterion (class map).

Step 2. Associate actions to the match criteria (policy map).

Step 3. Attach the policy map to a zone pair (service policy).

A packet arriving at the target (such as the input interface, output interface, or zone pair) is checked against the match criterion that is configured for a class map to determine whether the packet belongs to that class. If so, the policy map defines the action that applies to the specific class. The assignment of the policy to zone pairs is configured using a service policy.

There are three major components to C3PL, as shown in Figure 10-5: class map, policy map, and service policy.

Figure 10-5. Components of Cisco Common Classification Policy Language

Cisco Common Classification Policy Language policies are modular, object oriented, and hierarchical in nature:

Modular and object oriented: These traits give the firewall administrator the flexibility to create building-block objects such as class maps and policy maps, and reuse them within a given policy and across policies.

Hierarchical: This feature results in powerful policies that can be expanded to include customized inspection, application layer rules, and advanced inspection features. These advanced policies are outside the scope of this book, but are based on the hierarchical structure depicted in Figure 10-6.

Figure 10-6. C3PL: If-Then-Else Structure

Any given policy map is then applied to traffic flows that move in a given direction between zones by using service policies. The policy map processes traffic flows in that direction by matching sessions against one or more pre-created class map objects and performing access rule actions that are defined for each class.

As shown in Figure 10-6, policy maps can be thought as “if-then-else” statements, something similar to saying: “If a traffic flow matches the first class map, then the associated action is performed, and no other class map in the same policy is evaluated. Else, if the traffic flow matches the next class map in the configuration, then the associated action is performed.” If traffic is not matched by any class map in a policy, a default action is performed.

In Figure 10-7, two class maps—Class 1 and Class 2—are reused across policies Policy 1 and Policy 2. The class maps identity two different traffic classes that will be subject to a different policy for different interface pairs.

Figure 10-7. Modular Object-Oriented Configuration Design

By the same token, the policy-level objects can also be reused. In Figure 10-7, the Policy 1 policy map is applied to two different zone pairs for the traffic source on the outside and moving toward the DMZ interfaces. However, only one of those DMZs is applied to the Policy 2 policy map, indicating a different set of policies for the same traffic in each instance.

The following are characteristics of class map objects that you should consider:

• Class maps that analyze Layer 3 and Layer 4 traffic sort the traffic based on the following criteria:

Access-group: A standard, extended, or named ACL can filter traffic based on source and destination IP addresses and source and destination ports.

Protocol: The class map can identify Layer 4 protocols such as TCP, UDP, and Internet Control Message Protocol (ICMP), and application services such as HTTP, Simple Mail Transfer Protocol (SMTP), and Domain Name System (DNS). Any well-known or user-defined service known to Port-to-Application Mapping (PAM) can be specified. PAM is used to support services that use port numbers that are different from the registered or well-known ports associated with a specific application: An example is an SMTP server listening at port 2525 instead of the standard port 25.

Class-map: A subordinate class map that provides additional match criteria can be nested inside another class map.

• Each class map can have multiple match statements, as shown in Figure 10-8. The match type defines how multiple match statements are processed to match the class:

• If match-any is specified, traffic must meet any one of the match criteria in the class map.

• If match-all is specified, traffic must match all of the class map criteria to belong to that particular class.

Figure 10-8. Class Map with Multiple Match Statements

Other considerations apply to policy map creation and usage:

• Class maps are evaluated in the order in which they are configured and added to the policy map. Consider pushing the more specific traffic classes to the top of the policy, while pushing the less generic traffic classes to the bottom.

• Possible actions are inspect, pass, and drop (and, optionally, log for dropped packets). These actions will be explained in more detail later in this section.

• In addition to user-defined classes, a system-defined class map named class-default represents all packets that do not match any of the user-defined classes in a policy, as shown in Figure 10-9. It is always the last class in a policy map. You can define explicit actions for this group of packets. If you do not configure any actions for class-default in an inspect policy, the default action is drop.

Figure 10-9. Implicit Default Action of the class-default Map

Zone-Based Policy Firewall Actions

The Cisco IOS Zone-Based Policy Firewall can take three possible actions when you configure it using CCP or the CLI:

inspect: This action configures Cisco IOS stateful packet inspection.

drop: This action is analogous to deny in an ACL. An additional log option can be added to drop to log dropped packets.

pass: This action is analogous to permit in an ACL. The pass action does not track the state of connections or sessions within the traffic; pass allows the traffic only in one direction. A corresponding policy must be applied to allow return traffic to pass in the opposite direction.


The pass action does not perform stateful inspection.


Possible actions are inspect, drop, and pass, though some documentation might refer to pass as permit. Also remember that dropped packets can also be logged. So log can be considered as a fourth possible action, though only in combination with drop.

ZBF Terminology

When editing firewall policies, if you see:

Permit Firewall: Interpret this as “inspect according to class-map”

Permit ACL: Pass

Drop: Drop

Service Policy Zone Pair Assignments

Service policy assignments are unidirectional, as defined by the zone pair where the policy map is assigned. Remember, zone pairs define traffic behavior between zones in a unidirectional manner, based on source and destination zones. A policy map applied to a given zone pair will match traffic and perform action for that traffic in the direction defined by the zone pair. In other words, the policy map applies to traffic originating at the source zone and flowing toward the destination zone.

The final rule is that one and only one service policy can be applied to a given zone pair at any given time. If you apply a different service policy to a zone pair that already has one, you will overwrite the previous service policy.


Zone pairs define traffic behavior between zones based on source and destination zones. There can be one and only one service policy per zone pair. The policy map applies to traffic originating at the source zone and flowing toward the destination zone.

Zone-Based Policy Firewall: Default Policies, Traffic Flows, and Zone Interaction

The membership of the router network interfaces in zones is subject to several rules governing interface behavior, as is the traffic moving between zone member interfaces:

• A zone must be configured before you can assign interfaces to the zone.

• You can assign an interface to only one security zone.

• Traffic is implicitly allowed to flow by default among interfaces that are members of the same zone.

• To permit traffic to and from a zone member interface, a policy allowing or inspecting traffic must be configured between that zone and any other zone.

• Traffic cannot flow between a zone member interface and any interface that is not a zone member. You can apply pass, inspect, and drop actions only between two zones.

• Interfaces that have not been assigned to a zone function as classical router ports and might still use classical stateful inspection (CBAC) configuration.

• If you do not want an interface on the router to be part of the zone-based firewall policy, it might still be necessary to put that interface in a zone and configure a “pass all” policy (sort of a dummy policy) between that zone and any other zone to which traffic flow is desired.

• From the preceding rules it follows that if traffic is to flow among all the interfaces in a router, all the interfaces must be part of the zoning model (each interface must be a member of a zone).

Table 10-1 shows a number of examples of different interface and configuration combinations.

Table 10-1. Zone-Based Policy Firewall: Rules for Application Traffic

Zone-Based Policy Firewall: Rules for Router Traffic

The rules for a zone-based policy firewall are different when the router is involved in the traffic flow, whether as the source of traffic or the destination. A zone-based policy firewall is used to control router administration where the router is the destination. Table 10-2 illustrates various scenarios that involve traffic in or out of the router.

Table 10-2. Zone-Based Policy Firewall: Rules for Router Traffic

When an interface is configured to be a zone member, the hosts connected to the interface are included in the zone, but traffic flowing to and from the interfaces of the router is not controlled by the zone policies. Instead, all the IP interfaces on the router are automatically made part of the self zone when a zone-based policy firewall is configured. To limit IP traffic moving to the IP addresses of the router from the various zones on a router, policies must be applied to block, allow, or inspect traffic between the zone and the self zone of the router, and vice versa. If there are no policies between a zone and the self zone, all traffic is permitted to the interfaces of the router without being inspected.

If desired, you can define a policy using the self zone as either the source or destination zone. The self zone is a system-defined zone. It does not require any interfaces to be configured as members. A zone pair that includes the self zone, along with the associated policy, applies to traffic that is directed to the router or to traffic that the router generates. It does not apply to traffic traversing the router.

The following are additional rules for zone-based policy firewalls that govern interface behavior when the router is involved in the traffic flow:

• All traffic to and from a given interface is implicitly blocked when the interface is assigned to a zone, except traffic to or from other interfaces in the same zone, and traffic to any interface on the router.

• All the IP interfaces on the router are automatically made part of the self zone when a zone-based policy firewall is configured. The self zone is the only exception to the default deny-all policy. All traffic to any router interface is allowed until traffic is explicitly denied.

The following considerations should be weighted when designing Cisco IOS Zone-Based Policy Firewalls:

• An interface can be assigned to one zone and one zone only.

• An interface pair can be assigned one policy and one policy only.

• Consider default traffic flows for interfaces without zones, traffic flows between zones, and traffic flows to or from the router interfaces themselves.

• Inspection actions cannot be applied to the class-default class.

• The default policy action for unclassified traffic is drop.

Watch for Misconfiguration

It is considered a misconfiguration to put an inspect action from the self zone (the router) to another zone or, vice versa, to put an inspect action from a zone to the self zone. The results will vary.

Configuring Basic Interzone Policies Using CCP and the CLI

The CCP Firewall Wizard helps you to implement a firewall. The wizard walks you through creating the firewall by asking you for information about the interfaces on the router, whether you want to configure a DMZ network, and what rules you want to use in the firewall.

CCP Demo Mode

Recall from Chapter 3 that a Demo Mode version of CCP is available for practice. For a helpful tutorial on CCP Demo Mode, check out Parts I and II of “Cisco Configuration Professional Demo Mode,” by Doug McKillip of Global Knowledge, the URLs for which are provided in the “References” section toward the end of this chapter.

The configuration scenario shown in Figure 10-10 depicts a simple policy for a remote location that uses an untrusted network for corporate connectivity. We will configure two zones: the inside zone, which includes internal, trusted LAN interfaces, and the outside zone, which represents the untrusted network. The goal is to configure zone-based policy firewall rules that allow selected traffic to travel outbound from inside zone interfaces, while being inspected by the firewall. Inbound traffic, originating at the untrusted, outside interfaces, should be denied and logged.

Figure 10-10. Cisco IOS Zone-Based Firewall Configuration Scenario

Using the scenario in Figure 10-10, we will use CCP to configure and verify the firewall, and we will use the CLI to verify the configuration.

The CCP Firewall Wizard is available in two versions, Basic Firewall and Advanced Firewall. We will use the Basic Firewall wizard. These are the steps to configure a firewall using the Basic Firewall wizard:

Step 1. Start the Basic Firewall wizard.

Step 2. Select trusted and untrusted interfaces.

Step 3. Review and verify the resulting policies.

Step 4. (Optional) Enable logging.

Step 5. View firewall status and activity.

Step 6. (Optional) Modify basic policy objects.

Step 7. Verify CLI configuration.

The CCP Basic Firewall wizard will perform the specific operations related to zone-based policy firewalls. The operations include creating zones, creating zone pairs, creating C3PL components (class maps, policy maps, and service policies), and assembling the command hierarchy that implements the zone-based access control policy.

Step 1: Start the Basic Firewall Wizard

The first step is to access and run the Basic Firewall wizard, which you access by navigating to Configure > Security > Firewall > Firewall, clicking the Create Firewall tab, and then clicking the Basic Firewall radio button, as shown in Figure 10-11. To run the wizard, click the Launch the Selected Task button. The Basic Firewall wizard asks you to identify the interfaces on your router, and then it uses CCP default access rules and inspection rules to create the firewall. (The Advanced Firewall wizard, on the other hand, shows you the default inspection rules and allows you to use them in the firewall or create your own inspection rules.) CCP will use a default access rule in the firewall.

Figure 10-11. Starting the Basic Firewall Wizard


The LAN and WAN configurations must be complete before you can configure a firewall.

Step 2: Select Trusted and Untrusted Interfaces

The first step of the Basic Firewall wizard is to identify the interfaces on the router so that the firewall will be applied to the correct interfaces, as shown in Figure 10-12. The following interface categories are available:

Outside (untrusted) interface: Select the router interface that is connected to the Internet or to your organization’s WAN.


Do not select the interface through which you accessed CCP as the outside (untrusted) interface. Doing so will cause you to lose your connection to CCP. Because it will be protected by a firewall, you will not be able to launch CCP from the outside (untrusted) interface after the Firewall Wizard completes.

Inside (trusted) interfaces: Check the physical and logical interfaces connecting to the LAN. You can select multiple interfaces.

Figure 10-12. Selecting Trusted and Untrusted Interfaces

The first page of the wizard also has an Allow Secure Cisco CP Access from Outside Interfaces check box. Check this box if you want users outside the firewall to be able to access the router using CCP. The wizard will display a screen that allows you to specify a host IP address or a network address. The firewall will be modified to allow access to the address you specify. If you specify a network address, all hosts on that network will be allowed through the firewall.

Click Next when you are finished identifying interfaces.

The next screen of the wizard allows you to specify more lenient or strict firewall policies to match your requirements, as shown in Figure 10-13. Three levels are available, implementing the following policies:

• High Security

• The router identifies inbound and outbound instant messaging and peer-to-peer traffic and drops it.

• The router checks inbound and outbound HTTP traffic and email traffic for protocol compliance, and drops noncompliant traffic.

• The router returns traffic for other TCP and UDP applications if the session was initiated inside the firewall.

• Choose this option if you want to prevent use of these applications on the network.

• Medium Security

• The router identifies inbound and outbound instant messaging and peer-to-peer traffic, and checks inbound and outbound HTTP traffic and email traffic for protocol compliance.

• The router returns TCP and UDP traffic on sessions initiated inside the firewall.

• Choose this option if you want to track use of these applications on the network.

• Low Security

• The router does not identify application-specific traffic.

• The router returns TCP and UDP traffic on sessions initiated inside the firewall.

• Choose this option if you do not need to track use of these applications on the network.

Figure 10-13. Defining Security Levels for the Policy

High Security Setting

The High Security setting enables many deep packet inspection features. Some 300 commands are then sent to the router to secure it. Use prudence with the High Security setting because it takes drastic steps to secure your firewall and the traffic going through it. Test amply in a lab environment before implementing it in a production environment. Be sure to preview the commands during your test, and to research them prior to implementing.

Step 3: Review and Verify the Resulting Policies

Click Next, and the wizard ends by displaying the configuration and settings, as shown in Figure 10-14. Click Finish to continue.

Figure 10-14. Reviewing the Wizard Configuration Resulting from Selecting the Low Security Setting

Verifying and Tuning the Configuration

Firewall verification can be accomplished using several CCP tools. You can view the configured policies by navigating to Configure > Security > Firewall > Firewall and clicking the Edit Firewall Policy tab, as shown in Figure 10-15. Use this tab to view the access and inspection rules in a context that displays the interfaces that the rules are associated with. You can also use it to modify the access and inspection rules that are displayed.

Figure 10-15. Verifying Firewall Policies Using CCP

Unmatched Traffic

Traffic that does not match any inspection rules which are created dynamically from allowed outbound traffic may be allowed inbound in a non-stateful manner, as long as the ACLs assigned to the interfaces permit the traffic bidirectionally.

Once the configuration is completed using CCP, you will want to turn on logging to monitor the status and activities of the firewall by viewing the logs. Depending on your findings, you might want to modify the zone-based firewall configuration.

Step 4: Enabling Logging

Activity on the firewall is monitored through the creation of log entries. If logging is enabled on the router, then whenever an access rule that is configured to generate log entries is invoked—for example, a connection is attempted from a denied IP address—a log entry is generated and can be viewed in monitor mode.

Before you attempt to view the firewall log, you must enable logging by navigating to Configure > Router > Logging. Then, follow these steps:

Step 1. On the Additional Tasks > Logging screen, shown in the background of Figure 10-16, select Logging to Buffer and click Edit to open the Logging dialog box, shown in the foreground.

Figure 10-16. Enabling Logging to the Buffer

Step 2. In the Buffer Size field, enter the amount of router memory that you want to use for a logging buffer. The default value is 4096 bytes. A larger buffer will store more log entries, but you must balance your need for a larger logging buffer against potential router performance issues. Leave the other settings to their default values.

Step 3. Click OK.

Logging to the Console and Logging Dropped Packets

As explained in Chapter 4, it is preferable to send logging results to vty sessions rather than to the console port. The console port performs at a much lower speed than vty lines. If you decide nevertheless to send logs to the console port, use a lower level than debugging. Use at most the informational logging level.

Earlier in this chapter, we saw that it is possible to log packets that are dropped based on the policy. Though we haven’t looked at the CLI for ZBF, the command would look like this: Router(config-pmap-c)# drop log. This log action is available for packets that are dropped because they match a policy that explicitly says to drop the packets. Malformed or noncompliant packets dropped by the firewall, such as those with invalid UDP Header length, incompatible TCP options, and so forth, are not logged. To see packets dropped by the firewall, use the global command ip inspect log drop-pkt.

Step 5: Verifying Firewall Status and Activity

You can now view the firewall status and logs at Monitor > Security > Firewall Status. In the firewall statistics display, shown in Figure 10-17, you can verify that your firewall is configured and view how many connection attempts have been denied. The table shows each router log entry that is generated by the firewall, including the time and the reason that the log entry was generated.

Figure 10-17. Verifying Firewall Status and Activity


The default rule that is created by the Basic Firewall wizard enables logging for denied actions, and this log will display those messages. If logging is not enabled at the policy level, you will have to modify the policy maps to enable logging as an additional action.

Viewing Firewall Logs

Firewall logs can also be viewed by navigating to Monitor > Router > Logging > Firewall Log. The log entries are determined by log messages generated by the firewall. In order for the firewall to generate log entries, you must configure the following:

• Logging for the router. To obtain firewall logging messages, you must configure a logging level of debugging (7).

• Individual access rules to generate log messages when they are invoked.

The top-attacks table below the View drop-down menu displays the top attack entries. You can use the View drop-down menu to switch from a port-based report to an attacker-based report, which displays the IP addresses of the top attackers.


Log entries are not refreshed automatically. You must click Update to refresh the view and display newly generated entries.

Step 6: Modifying Zone-Based Firewall Configuration Objects

The optional step of modifying zone-based policy firewall base objects uses the Configure > Security >Firewall > Firewall Components > Zones navigation option. This step allows you to add or change zones; add or modify zone pairs, as shown in the upper-right side of Figure 10-18; or add or modify C3PL objects (class maps, policy maps, and service policies), as shown in the bottom portion of Figure 10-18.

Figure 10-18. Modifying ZBF Configuration Objects

General Steps to Create ZBF

ZBF policies are built from the bottom up. You first define the class map, which specifies interesting traffic for the policy maps. You then define the policy maps, specifying which actions to take on the traffic defined in the class maps. Then, the zone pairs reference both the policy maps and the zones. The following list shows the sequence of what is created and referenced:

1. ACL to identify the traffic

2. Zones

3. Class map

4. Policy map (actions can be inspect, pass, and drop, and dropped traffic can also be logged)

5. Zone pair (policy map + zones)

Step 7: Verifying the Configuration Using the CLI

Example 10-1 shows an example of what the resulting CLI commands might look like after configuring a Cisco IOS Zone-Based Policy Firewall that uses two interfaces and the default inspection parameters. The breakdown is as follows:

First, the class map named OUTBOUND-PROTOCOLS is created. It identifies three protocols that are to be inspected: HTTP, SMTP, and FTP.

A policy map named ACCESS-POLICY is created. It applies stateful inspection to the protocols that are listed in the OUTBOUND-PROTOCOLS class map.

Two zones, named PRIVATE and INTERNET, are created. FastEthernet 0/0 is made a member of the PRIVATE zone and FastEthernet 0/1 is made a member of the INTERNET zone.

Finally, a zone pair named PRIV-TO-INTERNET is created with a source zone of PRIVATE, a destination zone of INTERNET, and the policy map ACCESS-POLICY applied to it.

Example 10-1. Commands of a Basic Cisco IOS Zone-Based Policy Firewall Configuration

class-map type inspect match-any OUTBOUND-PROTOCOLS
match protocol http
match protocol smtp
match protocol ftp
policy-map type inspect ACCESS-POLICY
class type inspect OUTBOUND-PROTOCOLS
zone security PRIVATE
zone security INTERNET
interface fastethernet 0/0
zone-member security PRIVATE
interface serial 0/0/0
zone-member security INTERNET
zone-pair security PRIV-TO-INTERNET source PRIVATE destination INTERNET
service-policy type inspect ACCESS-POLICY

Configuring NAT Services for Zone-Based Firewalls

Network Address Translation (NAT) can be added to zone-based firewall configurations by applying NAT rules at the interface level for interfaces that belong to zones. The configuration scenario that is shown in Figure 10-19 illustrates an example of outbound dynamic Port Address Translation (PAT), where trusted hosts on the inside zone are translated dynamically, using PAT, to the IP address on the router’s untrusted interfaces, in this example FastEthernet 0/1.

Figure 10-19. NAT with ZBF Configuration Scenario

There are three main steps to configure a NAT with Cisco IOS zone-based firewall:

Step 1. Run the Basic NAT wizard.

Step 2. Select NAT interfaces:

• Outside interface with global IP address

• Inside interface with original IP address

Step 3. Verify the configuration.

Step 1: Run the Basic NAT Wizard

The first step is to access and run the Basic NAT wizard by navigating to Configure > Router > NAT and clicking the Create NAT Configuration tab, as shown in Figure 10-20. The options include the following:

Basic NAT: Choose the Basic NAT wizard if you want to connect your network to the Internet (or the outside), and your network has hosts but no servers. Look at the sample diagram that appears to the right when you choose Basic NAT. If your network is made up only of PCs that require access to the Internet, choose Basic NAT and click Launch.

Advanced NAT: Choose the Advanced NAT wizard if you want to connect your network to the Internet (or the outside), and your network has hosts and servers, and the servers must be accessible to outside hosts (hosts on the Internet). Look at the sample diagram that appears to the right when you choose Advanced NAT.

Figure 10-20. Starting the Basic NAT Wizard

Click the Launch the Selected Task button to launch the wizard.

Step 2: Select NAT Inside and Outside Interfaces

The only configuration that is needed in the Basic NAT wizard is the definition of original versus translated interfaces:

• From the drop-down menu, shown in Figure 10-21, choose the outside interface, which connects to the Internet or untrusted network. This is the router’s WAN interface.

Figure 10-21. Starting the Basic NAT Wizard

• From the list of available networks, shown with check boxes, choose which networks will share the WAN interface in the NAT configuration. To choose a network, check its check box in the list of available networks.


Do not choose a network that is connected to the WAN interface set up in this NAT configuration. Remove that network from the NAT configuration by unchecking its check box.

The list of available networks shows the following information for each network:

• IP address range allocated to the network

• Network LAN interface

• Comments entered about the network

To remove a network from the NAT configuration, uncheck its check box.


If Cisco Configuration Professional detects a conflict between the NAT configuration and an existing virtual private network (VPN) configuration for the WAN interface, it will inform you with a dialog box after you click Next. The only configuration that is needed in the Basic NAT wizard is the definition of original versus translated interfaces.

Click Next, and the wizard ends with a summary of the configuration, as shown in Figure 10-22. Click Finish.

Figure 10-22. Finishing the Wizard

Step 3: Verify NAT with CCP and the CLI

Verification can be accomplished by looking at the various NAT rules, found by navigating to Configure > Router > NAT and clicking the Edit NAT Configuration tab, as shown in Figure 10-23.

Figure 10-23. Verifying NAT Configuration with CCP

The resulting CLI configuration is shown in Example 10-2. Notice the commands ip nat outside and ip nat inside, which define the location of original and translated IPv4 addresses. Also notice that the original addresses are matched using an ACL, list number 1 in Example 10-2.

Example 10-2. NAT CLI Configuration

interface FastEthernet0/0
ip address
ip nat outside
interface FastEthernet0/1.4
ip address
ip nat inside
ip nat inside source list 1 interface FastEthernet0/0 overload
access-list 1 permit

The show ip nat translations command, shown in Example 10-3, displays the current translation for live traffic, including parameters such as inside local, inside global, outside local, and outside global addresses, as well as local and global ports.

Example 10-3. Current Translation for Live Traffic

Router# show ip nat translations
Pro Inside global Inside local Outside local Outside global

ZBF: Work in Progress

Cisco keeps coming out with improvements to ZBF. One of the latest improvements, which came out with Cisco IOS Release 15, is intrazone support, which allows for zone configuration to include users both inside and outside a network. This allows for traffic inspection between users belonging to the same zone but different networks. Check regularly for updates to ZBF.

Cisco ASA Firewall

Cisco ASA 5505 Adaptive Security Appliance (ASA) implements a rich set of security technologies and can be effectively implemented as a perimeter firewall using several deployment modes. This section introduces Cisco ASA functionality, features, and underlying technologies. This section will demonstrate how to configure the Cisco ASA 5505 model for basic connectivity using Cisco Adaptive Security Device Manager (ASDM).

Cisco ASA 5500 Series are easy-to-deploy solutions that integrate a world-class firewall, Cisco Unified Communications (voice and video) security, Secure Sockets Layer (SSL) and IP Security (IPsec) VPNs, intrusion prevention systems (IPS), and content security services in a flexible, modular product family. The Cisco ASA 5500 Series provides intelligent threat defense and secure communications services that stop attacks before they affect business continuity. Designed to protect networks of all sizes, Cisco ASA 5500 Series security appliances enable organizations to lower their overall deployment and operations costs while delivering comprehensive multilayer security.

Cisco ASAs scale to meet a range of requirements and network sizes. At the time of publication, the Cisco ASA 5500 Series includes the Cisco ASA 5505, 5510, 5512-X, 5515-X, 5520, 5525-X, 5540, 5545-X, 5550, and 5555-X, the four different footprints of the 5585-X (each one offering a different footprint of the Security Services Processor, or SSP), and the ASA Security Services Modules.

Stateful Packet Filtering and Application Awareness

The Cisco ASA security appliance is fundamentally a stateful packet filter with application inspection and control, with a rich set of additional integrated software and hardware features that enable you to expand its functionality beyond those fundamental filtering mechanisms.

The heart of the Cisco ASA is an application-aware stateful packet inspection algorithm, which controls flows between networks that are controlled by the security appliance. The connection-oriented stateful packet inspection algorithm design creates session flows based on source and destination addresses and ports. The information is kept in a state table, as shown in Figure 10-24. The stateful packet inspection algorithm randomizes TCP sequence numbers, port numbers, and additional TCP flags before completion of the connection. This function is always in operation, monitoring return packets to ensure that they are valid, and it transparently allows any additional dynamic transport layer sessions of the same application session. This fundamental function of the security appliance allows you to minimize host and application exposure and only allow the minimal traffic on OSI network and transport layers that is required to support your applications.

Figure 10-24. State Table Created for All Inspected Traffic

Interface Names

You will also notice in Figure 10-24 that interfaces receive names. With the Cisco ASA, to pass traffic, an interface needs to have a name (configured with the nameif command), and if you wish to route IP traffic, that interface also needs an IP address, which we will cover later. The nameif inside command assigns automatically the security level 100. This topic will be discussed later in this section.

Network Services Offered by the Cisco ASA 5500 Series

The Cisco ASA 5500 series offers services in addition to firewalling. Some of those additional services, examined in this section, are NAT, DHCP server, and routing.

Network Address Translation

The Cisco ASA security appliance includes support for many different varieties of NAT.

Cisco ASA Pre-8.3 to 8.3 NAT

Cisco has significantly changed the way NAT is done, starting with Cisco ASA version 8.3. If you have invested time and effort learning NAT pre-8.3, read the document “ASA Pre-8.3 to 8.3 NAT Configuration Examples,” found at There is also a good video to help you make the transition, “Cisco ASA Version 8.3 and 8.4 NAT Configuration Example,” available at The terminology has changed with NAT 8.3. As an example, if you run Packet Tracer (a troubleshooting tool covered later in this chapter), you might notice the term UN-NAT, which refers to a packet using its real IP address and port (typically the private IP address). Another significant change with version 8.3 is that NAT exemption, introduced with Cisco ASA 7.0, is no longer used. For detailed information about Cisco ASA 8.3 NAT, refer to CCNP Security FIREWALL 642-618 Official Cert Guide (Cisco Press, 2012).

Another substantial difference with 8.3 is that when creating an ACL, you must always use the real IP address, whereas in pre-8.3, the IP address had to be either the real IP address or the NATted IP address, depending on where the ACL was applied.

Note that for the purpose of passing the IINSv2 certification exam, knowing the material presented in this section suffices.

These different varieties of NAT allow for flexible deployment of NAT services:

Inside and outside NAT: These terms are typically used in reference to the physical location of the hosts that require and use NAT services. If the host resides on the inside network and its address is translated for outbound traffic flows, inside NAT is used. If the host resides on the outside network and its address is translated for inbound traffic flows, outside NAT is used. The terminology of inside and outside NAT has its origins in how the interfaces were named by the Cisco ASA predecessor, the PIX Firewall; this nomenclature is still used today: inside interface and outside interface. The inside interface, as its name implies, is the secure side of the firewall. The outside interface points to the less secure side of the firewall, usually the Internet.

Dynamic NAT and PAT: Dynamic NAT translates a group of real addresses to a pool of mapped addresses that are routable on the destination network. The mapped pool may include fewer addresses than the real group, in which case source ports are used to map multiple local addresses to one or a few global addresses. When a host that you want to translate accesses the destination network, the Cisco ASA assigns to the host an IP address from the mapped pool. The translation is added only when the real host initiates the connection. The translation is in place only for the duration of the connection, and a given user does not keep the same IP address after the translation times out. Users on the destination network, therefore, cannot initiate a reliable connection to a host that uses dynamic NAT, although the connection is allowed by an ACL, and the Cisco ASA rejects any attempt to connect to a real host address directly. If all the real addresses are translated to one single IP address instead of a pool of multiple addresses, it is then referred to as Dynamic PAT. On a Cisco ASA firewall, the default dynamic NAT timeout is 3 hours. That is, after 3 hours of no activity seen for a translated address, the entry is removed from the translation table. This timer is adjustable. Note that on the Cisco IOS router, the default idle timeout for translation is 24 hours.

Static NAT and PAT: Static NAT creates a fixed translation of real addresses to mapped addresses. With dynamic NAT and PAT, each host uses a different address or port for each subsequent translation. Because the mapped address is the same for each consecutive connection with static NAT, and a persistent translation rule exists, static NAT allows hosts on the destination network to initiate traffic to a translated host, if an ACL exists that allows it.

The main difference between using dynamic NAT and using a range of addresses for static NAT is that static NAT allows a remote host to initiate a connection to a translated host (if an ACL exists that allows it), while dynamic NAT does not. You also need an equal number of mapped addresses as real addresses with static NAT.

Static PAT is the same as static NAT, except that it lets you specify the protocol (TCP or UDP) and port for the real and mapped addresses.

Policy NAT: Policy NAT lets you identify real addresses for address translation by specifying the source and destination addresses. You can also optionally specify the source and destination ports. Regular NAT can consider only the source addresses and cannot consider the destination. For example, with policy NAT, you can translate the real address to mapped address A when it accesses server A, and translate the real address to mapped address B when it accesses server B.

NAT exemption: NAT exemption exempts addresses from translation and allows both real and remote hosts to originate connections. NAT exemption lets you specify the real and destination addresses when determining the real traffic to exempt (similar to policy NAT), so you have greater control using NAT exemption than dynamic identity NAT. However, unlike policy NAT, NAT exemption does not consider the ports.

Cisco ASA Connection Table

In addition to the translation table kept by the Cisco ASA, which you can look at with the show xlate command, the Cisco ASA maintains a connection table. You can see it with the show conn command. A TCP connection has a 1-hour idle timeout. A UDP connection has a 2-minutes idle timeout. These default timeouts are adjustable.

Additional Network Services

The Cisco ASA can provide a DHCP server or DHCP relay services to DHCP clients attached to Cisco ASA interfaces. The DHCP server provides network configuration parameters directly to DHCP clients. DHCP relay passes DHCP requests received on one interface to a DHCP server located behind a different interface. DHCP relay takes a DHCP broadcast and forwards it to the DHCP server located on a different network as a unicast. You can configure a DHCP server on each interface of the Cisco ASA. Each interface can have its own pool of addresses to draw from.

The Cisco ASA security appliance supports Routing Information Protocol (RIP) (versions 1 and 2), Open Shortest Path First (OSPF), and Enhanced Interior Gateway Routing Protocol (EIGRP) dynamic routing protocols to integrate into existing routing infrastructures. Where dynamic routing is not available, the Cisco ASA security appliance can use static routing instead.

Cisco ASA Security Technologies

Many other features and technologies are available in Cisco ASA. The appliances implement a rich set of firewall and security features. Some of these features are enabled by default, while others can be enabled to implement multiple levels of access and threat control and protection. In addition to the basic security features presented in this section, the following functions are available in Cisco ASAs:

• Stateful inspection and application level controls

• ACL packet filtering

• Object groups

• Application Inspection and Control (AIC)

• User-based access control (cut-through proxy)

• Identity firewall

• Session auditing

• Threat control and containment

• IPS via Cisco ASA Advanced Inspection and Prevention Security Services Module (AIP-SSM) and Advanced Inspection and Prevention Security Services Card (AIP-SSC)

• Botnet traffic filtering

• Category-based URL filtering

• Threat detection (basic, advanced, scanning)

• Network integration

• Virtualization

• Security modules

• IPv6 and multicast support

• NAT and DHCP services

• Site-to-site and remote-access IPsec and SSL VPNs

• Transparent firewall mode

• IP routing

• High-availability failover

The majority of these advanced functions and features are beyond the scope of this book and are covered in Cisco Press’s CCNP Security FIREWALL 642-618 Official Cert Guide.

Cisco ASA Configuration Fundamentals

In Cisco ASA, default and custom access rules are based on interface security levels. Security levels define the level of trustworthiness of an interface, and help implement a layered, defense-in-depth approach to security. The higher the level, the more trusted the interface. The numbers themselves are not really important, but the relationship between the numbers is. In that sense, traffic flows are defined as inbound or outbound like this:

Inbound traffic: Travels from a less trusted interface to a more trusted interface; that is, from a lower security level to a higher security level

Outbound traffic: Travels from a more trusted interface to a less trusted interface; that is, from a higher security level to a lower security level

Each interface must have a security level from 0 (lowest) to 100 (highest). For example, as shown in Figure 10-24, you should assign your most secure network, such as the inside host network, to level 100, while the outside network connected to the Internet can be level 0. Other networks, such as DMZs, can be in between. You can assign interfaces to the same security level, but additional configuration will be needed for traffic to traverse interfaces of the same security level.

Default Security Policy

Security levels define default behavior and processing of traffic flows. Merely by assigning numbers to interfaces, this policy applies the following:

• Outbound traffic is allowed and inspected by default.

• Returning traffic is allowed because of stateful packet inspection.

• Inbound traffic is denied by default.

• When you access the Cisco ASA (for management), you have to access the nearest interface.

Remembering the Default Security Policy

Remember this rhyme: “High to low, good to go. Low to high, must die.” In other words, traffic entering by an interface with security level 100 and leaving the interface with security level 0 is allowed and the returning traffic can come in. However, traffic originating from an interface with security level 50 destined for an interface with security level 100 would by default be denied.

The security level controls the following 'margin-bottom:0cm;margin-bottom:.0001pt;line-height: normal'>• Network access: By default, there is an implicit permit from a higher security interface to a lower security interface (outbound). Hosts on the higher security interface can access any host on a lower security interface. You can limit access by applying an ACL to the interface. If you enable communication for same security level interfaces, there is an implicit permit for interfaces to access other interfaces on the same security level or lower.

Inspection engines: Some application inspection engines are dependent on the security level. For same security level interfaces, inspection engines apply to traffic in either direction.

NetBIOS inspection engine: Applied only for outbound connections.

SQL*Net inspection engine: If a control connection for the SQL*Net (formerly OraServ) port exists between a pair of hosts, then only an inbound data connection is permitted through the Cisco ASA.

Filtering: As an example, HTTP(S) and FTP filtering applies to outbound connections (from a higher level to a lower level). If you enable communication for same security level interfaces, you can filter traffic in either direction.

Figure 10-25 illustrates an example of security levels in action.

Figure 10-25. Cisco ASA Security Levels and Interface Names

The traffic flows from the inside network to the outside network are permitted by default, because they go from more trusted to less trusted interfaces. In a real network, this means that internal users on the inside interface can access resources on the DMZ freely. They can also initiate connections to the Internet with no restrictions and without the need for an additional policy or additional commands.

By the same token, traffic that is sourced on the outside network, originating from the Internet and going into either the DMZ or the inside network, is denied by default. Return traffic, however, originating on the inside network and returning via the outside interface, would be allowed.

These default traffic flows match the requirements of real-life networks. It is worth noting that firewalls should not be the only security countermeasure in your security architecture. A sound security policy, along with effective countermeasures, should be put in place. For instance, a restrictive policy for outbound traffic should be implemented to overwrite the default permissive behavior based on security levels, to prevent malicious attackers from initiating attacks from the inside network and abusing the default policies based on those security levels.

Managing the Cisco ASA Using the CLI

Cisco ASAs contain a command set that is based on Cisco IOS Software. The appliance provides five configuration modes, similar to Cisco IOS devices:

• ROM monitor mode

• User EXEC mode

• Privileged EXEC mode

• Global configuration mode

• Specific configuration modes

Upon first accessing a Cisco ASA, you are presented with a standard prompt, as shown in Figure 10-26. Multiple configuration and monitoring modes are available at this point:

EXEC mode: Allows view-only capabilities on a restricted group of settings.

Privileged EXEC mode: Expands the set of available commands and settings in EXEC mode to a set with full administrative privileges. It also allows for maintenance actions in addition to the read-only and monitoring capabilities.

Global configuration mode: Allows changes to the system configuration.

Component-specific configuration modes: Allow changes to specific components, such as interfaces.

Figure 10-26. Cisco ASA Prompts

You can transition between modes using these commands and keystrokes:

• Use the enable command to access the privileged EXEC mode.

• Use exit or disable to return to the user EXEC mode.

• Use configure terminal to access the global configuration mode.

• Use exit to exit from global configuration mode, or to exit from a component-specific configuration mode into the previous level.

• Use Ctrl-Z or end to exit any configuration mode, any number of levels deep, and return to privileged EXEC mode.

Cisco ASA 5505

The Cisco ASA 5505 is designed for small offices, home offices, and enterprise teleworker environments. As shown in Figure 10-27, the appliance showcases an eight-port built-in Layer 2 switch that provides flexible VLAN configuration. Two of the ports are Power over Ethernet capable, and all of the ports can be assigned to specific VLANs to implement outside, inside, and DMZ subnets. Layer 2 ports are assigned to VLANs, and VLAN interfaces are created for Layer 3 connectivity. VLAN interfaces are used to assign IP addresses, security levels, and other Layer 3 components.

Figure 10-27. Cisco ASA 5505

There are two types of ports and interfaces to configure:

Physical switch ports: The eight Fast Ethernet switch ports of the Cisco ASA forward traffic at Layer 2, using the switching function in hardware. You can configure these interfaces either in access mode or as trunk ports.

Logical VLAN interfaces: Logical VLAN interfaces forward traffic between VLANs at Layer 3, using the configured security policy to apply firewall and VPN services. VLAN interfaces let you divide your Cisco ASA 5505 into separate VLANs, such as home, business, and Internet VLANs.

To segregate the switch ports into separate VLANs, you assign each switch port to a VLAN interface. Switch ports on the same VLAN can communicate with one another using hardware switching. However, when a switch port on VLAN 1 wants to communicate with a switch port on VLAN 2, for instance, the Cisco ASA applies the security policy to the traffic and routes or bridges between the two VLANs.

Other components shown Figure 10-27 include the following:

Power connector: Used for attaching the power cord

SSC slot: Used to install the optional Cisco AIP SSC-5 network IPS module

Console port: Used to connect a computer to the Cisco ASA 5505 using an RJ-45 cable for console operations

Reset button: Reserved for future use

USB ports: Reserved for future use

Cisco ASDM

Cisco ASDM is to the Cisco ASA what Switch Database Management (SDM) or CCP is to Cisco IOS routers, and more. It is a configuration tool that is designed to facilitate the setup, configuration, monitoring, and troubleshooting of Cisco ASAs. The application hides the complexity of commands from administrators, and allows streamlined configurations without requiring extensive knowledge of the security appliance CLI. Cisco ASDM can be used to monitor and configure multiple security appliances that run the same ASDM version.

Cisco ASDM features include the following:

• Runs on a variety of platforms

• Implemented in Java to provide robust, real-time monitoring

• Works with SSL, as shown in Figure 10-28, to ensure secure communication with the security appliance

Figure 10-28. Cisco ASDM

• Comes preloaded in flash memory on new Cisco ASA security appliances running version 7.0 or later

• Can manage multiple security appliances from a single ASDM interface, one at a time

• Cisco ASDM sessions:

• Five Cisco ASDM sessions per unit (single mode) or context (multimode)

• 32 sessions per unit in multimode

• Supported on all Cisco ASAs

Cisco ASDM Demo Mode

Similar to the CCP Demo Mode version mentioned earlier in the chapter, Cisco ASDM also has a Demo Mode version. For a tutorial on how to install and use the ASDM Demo Mode, check out “ASDM Demo Mode Tour,” also by Doug McKillip, the URL for which is provided in the “References” section at the end of this chapter.

Preparing the Cisco ASA 5505 for ASDM

Cisco ASDM access requires some minimal configuration so that you can communicate over the network with a management interface.

With a factory default configuration, you can connect to Cisco ASDM using the following interface and network settings:

• The management interface depends on your model:

Cisco ASA 5505: The switch port to which you connect to Cisco ASDM can be any port, except for Ethernet 0/0.

Cisco ASA 5510 and later: The interface to which you connect to Cisco ASDM is Management 0/0.

• The default management address is

• The clients that are allowed to access Cisco ASDM must be on the network.

Cisco ASA 5510 and Later and Cisco ASDM

With Cisco ASA 5510 and later, the firewall looks for an interface with the name Management for the setup to be allowed to run. The nameif management command doesn’t need to be applied to the actual Management 0/0 interface for setup to run. It’s not a significant issue, but interesting to know.

If you do not have a factory default configuration, or want to change the firewall or context mode, the following steps are required.

To run Cisco ASDM on a Cisco ASA 5505, perform the following steps:

Step 1. Assign the name “inside” to one interface.

Step 2. Run the interactive setup dialog using the setup command.

Step 3. (Optional) Specify which Cisco ASDM image file to use.

Cisco ASDM Features and Menus

Once initialized and connected, the Cisco ASDM Home page, shown in Figure 10-29, lets you view important information about your Cisco ASA. Status information in the Home page is updated every 10 seconds. This page usually has two tabs, Device Dashboard and Firewall Dashboard. If you have a hardware module such as the CSC-SSM (Content Security and Control Security Service Module) installed in your Cisco ASA, the module-specific tab also appears in the Home page. The additional tab displays status information about the software on the specific module. If you have IPS software installed in your Cisco ASA, the Intrusion Prevention tab also appears in the Home page. The additional tab displays status information about the IPS software.

Figure 10-29. Cisco ASDM Home Pane

The Device Dashboard tab lets you view at a glance important information about your Cisco ASA, such as the status of your interfaces, the version you are running, licensing information, and performance.

The Cisco ASDM user interface is designed to provide easy access to the many features that the Cisco ASA supports. It includes the following elements, shown in Figure 10-30:

• A menu bar that provides quick access to files, tools, wizards, and help. Many menu items also have keyboard shortcuts.

• A toolbar that enables you to navigate Cisco ASDM. From the toolbar, you can access the Home, Configuration, and Monitoring pages. You can also get help and navigate between pages.

• A dockable left navigation pane to move through the Configuration and Monitoring pages. You can click one of the buttons in the header to maximize or restore this pane, make it a floating pane that you can move, hide it, or close it. To access the Configuration and Monitoring pages, you can do one of the following:

• Click links on the left side of the application window in the left navigation pane. The content pane then displays the path in the title bar of the selected pane.

• If you know the exact path, you can type it directly into the title bar of the content pane on the right side of the application window, without clicking any links in the left navigation pane.

• A maximize and restore button in the right corner of the content pane that lets you hide and show the left navigation pane.

• A dockable Device List pane with a list of devices that you can access through Cisco ASDM. You can click one of the three buttons in the header to maximize or restore this pane, make it a floating pane that you can move, hide it, or close it.

• A status bar at the bottom of the application window that shows the time, connection status, user, memory status, running configuration status, privilege level, and SSL status.

• The left navigation pane, as mentioned earlier, that shows various objects that you can use in the rules tables when you create access rules, NAT rules, authentication, authorization, and accounting (AAA) rules, filter rules, and service rules. The tab titles within the pane change according to the feature that you are viewing. In addition, the Cisco ASDM Assistant appears in this pane.

• Above the left navigation pane, but not shown in Figure 10-30, is an optional Device List useful when toggling between two or more firewall configurations.

Figure 10-30. Cisco ASDM Interface Elements

When deploying Cisco ASAs, your access policy is made up of one or more access rules per interface or globally for all interfaces. An access rule permits or denies traffic based on the protocol, a source and destination IP address or network, and, optionally, the source and destination ports. Note that global ACLs are only available starting with Cisco ASA version 8.3.

The order of rules is important. When the Cisco ASA decides whether to forward or drop a packet, the Cisco ASA tests the packet against each rule in the order in which the rules are listed, as shown in Figure 10-31. After a match is found, no more rules are checked. For example, if you create an access rule at the beginning that explicitly permits all traffic for an interface, no further rules are ever checked.

Figure 10-31. Example of Stateful Packet Filtering on Cisco ASA

There is an implicit deny-all rule at the end of each interface access rule list. Therefore, if a connection does not match any of the rules, by default, it will be denied.


Interface access rules apply to through traffic—that is, traffic entering the appliance on one interface and then leaving the appliance on the same interface or another interface. Traffic that is directed to the IP addresses or interfaces of the appliance is not subject to these rules, and requires an additional set of rules to implement access control.

Access rules apply based on the security levels described earlier in this chapter. In that sense, these defaults apply if you do not apply an interface access ruleset to an interface:

• All outbound (that is, from higher to lower security level interfaces) connections for hosts on that interface are permitted.

• All inbound (that is, from lower to higher security level interfaces) connections for hosts on that interface are denied.

You need to specifically allow connectivity between interfaces with the same security levels, as well as traffic in and out of the same interface. All such connectivity is then still controlled by the access rules of the relevant interface.

The Cisco ASA supports two types of ACLs:

Ingress: Ingress ACLs apply to traffic as it enters an interface. An ingress ACL can bind an ACL to a specific interface or apply a global rule on all interfaces.

Egress: Egress ACLs apply to traffic as it exits an interface. An egress ACL is useful, for example, if you want to allow only certain hosts on the inside networks to access a web server on the outside network. Rather than creating multiple ingress ACLs to restrict access, you can create a single egress ACL that allows only the specified hosts. The egress ACL prevents any other hosts from reaching the outside network.


The terms ingress and egress refer to the application of an ACL on an interface, either to traffic entering the Cisco ASA on an interface or traffic exiting the Cisco ASA on an interface. These terms do not refer to the movement of traffic from a lower security interface to a higher security interface, commonly known as inbound, or from a higher to lower interface, commonly known as outbound.

Access rules can be created and maintained using the Access Rules pane in Cisco ASDM, which you can reach by navigating to Configuration > Firewall > Access Rules, as shown in Figure 10-32. Note that the screenshot shown in Figure 10-32 was captured on a Cisco ASA 5505 running code 8.4(2), which explains the presence of the extra column titled User.

Figure 10-32. Cisco ASA Interface Access Rules Configured with Cisco ASDM

Using the options that are shown Figure 10-32, you can add, delete, or edit rules either by using the options in the top menu or by right-clicking a particular rule and choosing from the context menu. You can also temporarily disable and enable rules.

Cisco Modular Policy Framework

For application layer inspection, as well as other advanced options, the Cisco Modular Policy Framework (MPF) is also available on Cisco ASAs. Cisco MPF on ASAs is similar to C3PL on Cisco IOS routers. Cisco MPF uses these three configuration objects to define modular, object-oriented, hierarchical policies:

Class maps: Define a match criterion to identify qualifying traffic

Policy maps: Associate actions to the match criteria

Service policies: Attach the policy map to an interface, or globally to all interfaces of the appliance

Cisco MPF, illustrated in Figure 10-33, allows granular classification of traffic flows, in order to apply different advanced policies to different flows. These features, among others, use Cisco MPF:

Hardware modules: Traffic is redirected granularly from the Cisco ASA to the modules using Cisco MPF.

Advanced Inspection and Control: Traffic can be classified at Layers 5 through 7 for application layer inspection.

• Rate limiting and quality of service (QoS) features.

Figure 10-33. Cisco ASA and Modular Policy Framework

Class Map: Identifying Traffic on Which a Policy Will Be Enforced

Cisco ASA class maps allow a richer set of match criteria, as compared to their counterparts in Cisco IOS Zone-Based Policy Firewalls. The list includes these criteria for matching information at Layers 3 and 4:

• Access list

• Any packet

• Default inspection traffic

• IP differentiated services code point (DSCP)

• IP flow

• TCP and UDP ports

• IP precedence

• Real-Time Transport Protocol (RTP) port numbers

• VPN tunnel group

Layers 5 through 7 class maps are also available, and provide an even richer set of criteria for application-specific parameters. For instance, you can match HTTP URLs and request methods.

Policy Map: Configuring the Action That Will Be Applied to the Traffic

Cisco ASA policy maps also allow a more rich set of actions, as compared to their router counterparts for Cisco IOS Zone-Based Policy Firewalls. The actions include not only firewall-related functions, such as application inspection and advanced connection settings, but also QoS actions, such as traffic prioritization, and traffic rerouting to hardware modules integrated into the security appliance. The list of possible actions includes

• Sending traffic to the Advanced Inspection and Prevention Security Services Module (AIP-SSM) or the Trend Micro InterScan for Cisco CSC-SSM

• Sending NetFlow information

• Prioritizing, policing, or shaping traffic (QoS)

• Configuring advanced connection settings (such as maximum number of simultaneous embryonic connections per client)

• Application inspection (such as preparing for dynamic port for FTP sessions)

When creating a policy map, you need to provide it with a name. You also need to refer to class maps, where traffic is identified.

Service Policy: Activating the Policy

The service policy, defined in the policy map configuration, will be applied to an interface or globally. You can apply only one service policy per interface. However, a service policy might contain multiple policy maps, and thus different actions to be applied on different flows of traffic.


Interface service policies take precedence over the global service policy for a given feature. For example, if you have a global policy with FTP inspection and an interface policy with FTP inspection, then only the interface policy FTP inspection is applied to that interface.

Cisco ASA Modular Policy Framework: Simple Example

Figure 10-34 provides an example of MPF at work. Three map classes have been created:

Internet: Traffic that has port 80 listed in its TCP header will be classified as Internet traffic.

Engineers: Traffic with IP subnet will be classified as Engineers traffic.

Voice: Traffic with Layer 3 DSCP bits set to decimal value 46 will be recognized as VoIP traffic and will be classified as Voice traffic.

Figure 10-34. Example of How Modular Policy Framework Can Be Used on Cisco ASA

The traffic identified as Internet will be passed to the IPS module inserted in the Cisco ASA firewall. This module is the Advanced Inspection and Prevention Security Services Module (AIP-SSM). Traffic identified as Engineers will be throttled using rate limitation. Traffic identified asVoice will be prioritized on the way out.

With the example in Figure 10-34, the outside interface is made aware with the service-policy command that it is responsible for enforcing the three policy-map commands, which themselves list the actions to be applied on the different flows of traffic created by the class-map commands.

First Packet Dictates the Policy Used

The policy is assigned upon receipt of the first packet. As an example, in a TCP communication, the policy is “chosen” upon the SYN packet transmission. All subsequent packets from the same session will use the action that was stipulated when the policy was selected at the beginning of the connection. Any changes made to that policy during the session lifetime do not affect that specific connection. Only new connections will be affected. Therefore, if you make a change to a policy, it is best to clear all current connections that could be affected by the policy, to ensure that the new policy will be used.

Basic Outbound Access Control on Cisco ASA Using Cisco ASDM

Cisco ASDM can be used to initialize Cisco ASAs for basic operations. The Cisco ASDM Startup Wizard is available to configure interface settings, basic access control, NAT, DHCP, basic management features, and others.

Figure 10-35 describes a configuration scenario for the use of the Cisco ASDM Startup Wizard. This network, using a Cisco ASA 5505 security appliance, requires outbound access for clients on the subnet. No public servers are required, and inbound access that is originated at the untrusted network should be blocked. The Cisco ASA will act as DHCP server for the subnet, and will perform dynamic PAT (NAT overload) on outbound traffic using the outside interface IP address of the appliance.

Figure 10-35. Configuration Scenario for Outbound Traffic Control on Cisco ASA

Scenario Configuration Steps Using Cisco ASDM

The configuration steps are as follows:

Step 1. Prepare Cisco ASA for Cisco ASDM access via the CLI.

Step 2. Run the interactive setup dialog in Cisco ASDM.

Step 3. Verify the configuration.

Step 4. Verify firewall activity using the Packet Tracer tool.

The preparation steps are configured using the CLI. Once the appliance is ready, Cisco ASDM is used to invoke the Startup Wizard and continue the basic configuration. Verification is shown for both the CLI and ASDM, and the Packet Tracer tool is used for verification and troubleshooting.

Step 1: Prepare Cisco ASA for Cisco ASDM Access Using the CLI

In preparing a Cisco ASA 5505 security appliance for Cisco ASDM access, the first step is to enable an interface and configure it with a logical name. The nameif command, mentioned earlier in a sidebar in this chapter, assigns a name to an interface when in interface configuration mode. Security levels are automatically assigned when you issue the nameif command. The inside interface acquires security level 100, while other interfaces acquire level 0 by default. This default security level can be changed with the security-level command.

Notice that in the case of the Cisco ASA 5505 model, security levels and IP addresses are assigned to VLAN interfaces, as shown in Example 10-4. Physical interfaces in this model are Layer 2 ports, and VLAN interfaces are needed to provide Layer 3 connectivity and configure the appliance with IP addresses, security levels, ACLs, and other components.


These guidelines and configuration examples apply to the Cisco ASA 5505 model. Other models, such as 5510, 5520, 5540, and 5580, are subject to different rules and requirements. As examples, with the Cisco ASA 5510, an interface would be referred to as Ethernet 0/0; with the Cisco ASA 5520, it would be referred as GigabitEthernet 0/0.

Example 10-4. Configuring an Interface on Cisco ASA 5505

asa5505(config)# interface vlan21
asa5505(config-if)# nameif inside

The next task is to enter the setup command to run the setup initialization dialog, as shown in Example 10-5. The setup command configures the following:

• Device settings, such as the firewall mode, clock settings, enable password, and DNS information.

• Interface settings, such as IP addresses and subnet masks.

• Cisco ASDM settings, specifically access restrictions in the form of IP addresses and subnets that are allowed to access the appliance via Cisco ASDM. In Example 10-5, this address is

Example 10-5. Running the Cisco ASA Setup

asa5505(config)# interface vlan21
asa5505(config-if)# nameif inside
INFO: Security level for "inside" set to 100 by default. ciscoasa(config)# setup
Pre-configure Firewall now through interactive prompts [yes]? <Enter> Firewall Mode
[Routed]: <Enter>
Enable password [<use current password>]: cisco123
Allow password recovery [yes]? <Enter>
Clock (UTC):
Year [2012]: <Enter>
Month [Aug]: <Enter>
Day [26]: <Enter>
Time [10:21:49]: 15:34:00
Inside IP address []:
Inside network mask []:
Host name [ciscoasa]: ASA Domain name:
IP address of host running Device Manager:
Use this configuration and write to flash? Y

Routed Versus Transparent

In the setup dialog of Example 10-5, you might have noticed Firewall Mode [Routed]. The Cisco IOS Firewall, like the Cisco ASA firewall, can operate in routed mode or transparent mode. The default mode is routed mode, where the firewall is a routed hop and acts as a default gateway. In transparent mode, the firewall can perform its duties at Layer 2. Transparent firewalls are beyond the scope of this book.

Optionally, you should define the location of Cisco ASDM files in the flash memory of the appliance, as shown in Example 10-6. This is especially important when using multiple versions of Cisco ASDM.

Example 10-6. Specifying the Cisco ASDM File to Use

asa5505(config)# asdm image disk0:/asdm-641.bin


Cisco ASA’s internal flash is referred to as disk0, while its external flash (compact flash) is referred to as disk1. We refer to Cisco PIX Firewall flash, even when running code 8.x, as flash0.

Figure 10-36 illustrates and explains the CLI commands that result from the Setup Wizard. Notice how the Cisco ASA 5505 security appliance uses a VLAN interfaces to define the inside interface. The VLAN for VLAN interface 21, in this example, is assigned to the physical interface Ethernet 0/1, which is physically connected to the inside network.

Figure 10-36. Verifying and Understanding the Setup Configuration of a Cisco ASA

Step 2: Run the Startup Wizard from Cisco ASDM

You can start Cisco ASDM using either of two methods, shown in Figure 10-37:

ASDM-IDM Launcher (Windows only): The Launcher is an application (downloaded from the Cisco ASA using a web browser) that you can use to connect to any Cisco ASA IP address. You do not need to re-download the Launcher if you want to connect to other Cisco ASAs. The Launcher also lets you run a virtual Cisco ASDM in Demo Mode using files that are downloaded locally.

Java Web Start: For each Cisco ASA that you manage, you need to connect with a web browser and then save or launch the Java Web Start application. You can optionally save the application to your PC. However, you need separate applications for each Cisco ASA IP address.

Figure 10-37. Launching Cisco ASDM

Once started, the security appliance will prompt you for credentials for administrative access.


ASDM uses SSL for communications between the management station and the security appliance. By default, a self-signed certificate is generated for use by Cisco ASA. Your browser will prompt you for confirmation that you want to accept and use this digital certificate.

The next task is to run the Startup Wizard. To access this feature in the main Cisco ASDM application window, choose one of the following:

• Navigate to Wizards > Startup Wizard.

• Navigate to Configuration > Device Setup > Startup Wizard, and then click Launch Startup Wizard.

Step 1 of the Startup Wizard is to define the starting point in terms of configuration, as shown in Figure 10-38. The options are as follows:

• To change the existing configuration, click the Modify Existing Configuration radio button.

• To set the configuration to the factory default values, click the Reset Configuration to Factory Defaults radio button.

• To configure the IP address and subnet mask of the Management 0/0 (Cisco ASA 5510 and later) or VLAN 1 (Cisco ASA 5505) interface to be different from the default value (, check the Configure the IP Address of the Management Interface check box.

• Choose the first option and click Next if, like in our case, you wish to modify the current configuration.

Figure 10-38. Starting the Cisco ASDM Startup Wizard and the First Screen


If you reset the configuration to factory defaults, you cannot undo these changes by clicking Cancel or by closing this screen.

Step 2 of the Startup Wizard defines the basic configuration of the appliance, as shown in Figure 10-39. The following components can be configured:

Configure the Device for Teleworker Usage: Check this check box to specify a group of configuration settings for a remote worker. This is available only for Cisco ASA 5505 security appliances.

Cisco ASA Host Name: The hostname appears in the command-line prompt, and if you establish sessions to multiple devices, the hostname helps you keep track of where you enter commands. The hostname is also used in system messages.

Domain Name: The Cisco ASA appends the domain name as a suffix to unqualified names. For example, if you set the domain name to “,” and specify a syslog server by the unqualified name of “jupiter,” then the security appliance qualifies the name to “”

Change Privileged Mode (Enable) Password: Checking this check box enables you to change the configured enable (privilege 15) password. The enable password lets you access privileged EXEC mode after you log in. Also, this password is used to access Cisco ASDM as the default user, which is blank. The default user shows as “enable_15” in the User Accounts pane. (If you configure user authentication for enable access, then each user has their own password, and this enable password is not used. In addition, you can configure authentication for HTTP/ASDM access.)

Figure 10-39. Second Screen of the Cisco ASDM Startup Wizard

Multiple screens allow the configuration of the appliance interfaces. In Step 3 of the wizard, (running the Plus code instead of the Base code), you group the eight Fast Ethernet switch ports on the Cisco ASA 5505 into three VLANs. These VLANs function as separate Layer 3 networks. You can then choose or create the VLANs that define your network—one for each interface: Outside, Inside, or DMZ. You have the option to not define a DMZ by not creating a DMZ VLAN.

Security levels are configured automatically when you use the wizard, but you can change them later using Cisco ASDM options. The outside interface acquires a security level of 0, the DMZ interface acquires a security level of 50, and the inside interface acquires a security level of 100.

In Figure 10-40, VLAN 21 is allocated to the inside interface, while VLAN 22 is allocated to the outside interface. No DMZ VLAN is created.

Figure 10-40. Interface Selection from Cisco ASDM Startup Wizard

Step 4 of the wizard is switch port allocation, which lets you allocate switch ports to outside, inside, or DMZ interfaces. By default, all switch ports are assigned to VLAN 1 (inside).

Figure 10-41 shows the example for a Cisco ASA 5505 security appliance, which includes an eight-port switch. In this example, the Ethernet 0/1 interface is allocated to the inside VLAN, while the Ethernet 0/0 interface is allocated to the outside VLAN.

Figure 10-41. Switch Port Selection from Cisco ASDM Startup Wizard (Cisco ASA 5505 Only)

Step 5 of the wizard lets you configure the IP address for each VLAN interface, as shown in Figure 10-42. Notice the options to configure Cisco ASA interfaces to obtain their IP address, as well as a default route, automatically from the network via DHCP.

Figure 10-42. Interface IP Address Configuration from Cisco ASDM Startup Wizard

Step 6 of the wizard enables you to configure network services, either DHCP or PPPoE, depending on what selections you made in Step 5. Figure 10-43 illustrates the options to configure the Cisco ASA as a DHCP server. The options allow the inside interface to deliver DHCP services to DHCP clients reachable through that interface.

Figure 10-43. DHCP Server Configuration from Cisco ASDM Startup Wizard

In our scenario, the inside interface provides DHCP servers using the range of addresses to

Step 7 of the wizard is to define NAT and PAT settings, if required. You can enable dynamic NAT or dynamic PAT. You have the option to define additional Cisco ASA objects such as IP addresses and IP subnets, in order to define the PAT IP addresses or the ranges of source IP addresses to match. You configure these objects in additional windows that open from the main wizard window when you choose the different options.

As shown in Figure 10-44, you can configure PAT and define the IP address on the outside interface to overload for all traffic heading outbound when originated on the inside interface.

Figure 10-44. NAT and PAT Configuration from Cisco ASDM Startup Wizard

Step 8 of the wizard enables you to configure administrative access. The following options are available:

• Configure ASDM, Telnet, or SSH access. Clicking the Add button enables you to configure the IP address or range of addresses that are allowed to use the protocol to manage the Cisco ASA, as well as the interface where they are allowed.

• To enable a secure connection to an HTTP server to access Cisco ASDM, check the Enable HTTP Server for HTTPS/ASDM Access check box.

• To allow Cisco ASDM to collect and display statistics, check the Enable ASDM History Metrics check box.

In Figure 10-45, SSH services are defined on the inside interface to allow the whole subnet to have SSH access to the appliance.

Figure 10-45. Administrative Access Configuration from Cisco ASDM Startup Wizard

The final wizard screen, shown in Figure 10-46, summarizes all of the configuration settings that you have made for the ASA. The following are your options:

• To change any of the settings in previous screens, click Back.

• Choose one of the following:

• If you ran the Startup Wizard directly from a browser, when you click Finish, the configuration settings that you created through the wizard are sent to the Cisco ASA and saved in flash memory automatically.

• If you ran the Startup Wizard from within Cisco ASDM, you must explicitly save the configuration in flash memory by choosing File > Save Running Configuration to Flash.

Figure 10-46. Cisco ASDM Startup Wizard Summary

Step 3: Verify the Configuration Created by the Cisco ASDM Startup Wizard

Verification can be accomplished using the Cisco ASDM Device Dashboard tab from the Home page. This screen displays interface status and statistics, as well as overall information about device health.

The access rules and NAT rules that result from the Startup Wizard can be verified by navigating to the Cisco ASDM options shown in Figure 10-47 and Figure 10-48. Note that the screenshots shown in these figures were captured on a Cisco ASA 5505 running code 8.4(2). This explains the extra column titled User, in Figure 10-47, that you might not be seeing on your Cisco ASA.

Figure 10-47. Verifying Access Rules Created by Cisco ASDM Startup Wizard

Figure 10-48. Verifying NAT Rules Created by Cisco ASDM Startup Wizard

The last required step to enable connectivity through the appliance is to define a default route for outbound traffic. This task can be accomplished by navigating to Configuration > Device Setup > Routing > Static Routes and clicking Add to create a static route. The options include the outgoing interface, the destination prefix for the route, and the next hop.

In Figure 10-49, a default route is created using the any keyword on the Network field. The Network field indicates the destination prefix of the route, and using any is similar to using as a destination. The outgoing interface for traffic following this route is the outside interface.

Figure 10-49. Adding a Static Route Using Cisco ASDM

Notice that this is a change made outside of the wizard, so it must be synchronized from Cisco ASDM to the appliance by clicking Apply at the bottom of the Static Routes window.

Step 4: Verify Firewall Activity Using the Packet Tracer Tool

The Packet Tracer tool provides packet tracing for packet sniffing and network fault isolation, as well as detailed information about the packets and how they are processed by the Cisco ASA. If a configuration command did not cause the packet to drop, Packet Tracer provides information about the cause in an easily readable manner.

In addition, you can use the Packet Tracer tool to trace the lifespan of a packet through the Cisco ASA to see whether the packet is operating correctly. This tool lets you do the following:

• Debug all packet drops in a production network

• Verify that the configuration is working as intended

• Show all rules applicable to a packet, along with the CLI commands that caused the rule addition

• Show a timeline of packet changes in a data path

• Inject tracer packets into the data path

To open the Packet Tracer, perform the following steps, shown in Figure 10-50:

Step 1. In the main Cisco ASDM application window, navigate to Tools > Packet Tracer.

Step 2. The Cisco ASDM Packet Tracer dialog box opens.

Step 3. Choose the source interface for the packet trace from the Interface drop-down list.

Step 4. Specify the protocol type for the packet trace. Available protocol types include TCP, UDP, ICMP, and IP.

Step 5. Enter the source address for the packet trace in the Source IP Address field.

Step 6. Choose the source port for the packet trace from the drop-down list.

Step 7. Enter the destination IP address for the packet trace in the Destination IP Address field.

Step 8. Choose the destination port for the packet trace from the drop-down list.

Step 9. Click Start to trace the packet.

Figure 10-50. Packet Tracer Tool Using Cisco ASDM

The information display area shows detailed messages about the packet trace.


To display a graphical representation of the packet trace, check the Show Animation check box.


In this chapter, you learned that a firewall is a set of rules designed to enforce an access control policy between two networks. You learned how to create firewall rules to implement your security policies. Cisco provides a range of firewall products that help you implement your security policies in a cost-effective way. ACLs provide packet-filtering capabilities for routers and firewalls to protect internal networks from the outside.

Cisco offers many different types of firewalls. In this chapter, we looked at two types: Cisco IOS Zone-Based Firewall and Cisco ASA firewall.

A zone-based policy firewall changes the firewall from the older interface-based model to a more flexible, more easily understood zone-based configuration model. Cisco IOS Zone-Based Policy Firewalls provide a more flexible way to implement your security policy on Cisco Router and Cisco Configuration Professional (CCP) makes it easier for you to configure and maintain the firewall capabilities of your routers.

The Cisco ASA family of products includes solutions for teleworkers, branch offices, Internet edge environments, and data centers. Cisco ASA uses security levels and access rules to control traffic. You also saw briefly how Modular Policy Framework rules provide a richer set of options than what is offered with a Cisco IOS Zone-Based Firewall. You learned, though, that the Cisco ASA ACLs have similar structure and operational framework than how ACLs are implemented on Cisco IOS routers. You also saw that Cisco ASDM provides protected, authenticated, GUI management for Cisco ASAs and that the Startup Wizard can be used to quickly and effectively deploy basic Cisco ASA configurations.


For additional information, refer to these resources Resources

Cisco ASA 5500 Series Configuration Guide Using ASDM, 6.4 and 6.6,

Getting Started with Cisco Configuration Professional,

Zone-Based Policy Firewall Design and Application Guide,

Other Resources

Beaver, K. “Firewall Best Practices” (2009),

Hucaby, D., Garneau, D., and Sequeira, A. CCNP Security FIREWALL 642-618 Official Cert Guide (Cisco Press, 2012)

CCP and ASDM Demo Mode Tutorials

McKillip, Doug. “Cisco Configuration Professional Demo Mode – Part I,”

McKillip, Doug. “Cisco Configuration Professional Demo Mode – Part II,”

McKillip, Doug. “ASDM Demo Mode Tour,”

Review Questions

Use the questions here to review what you learned in this chapter. The correct answers are found in the Appendix, “Answers to Chapter Review Questions.”

1. Which of the following is not an action of zone-based policy firewalls?

a. drop

b. reset

c. pass

d. inspect

2. When using zone-based policy, for traffic to flow among all the interfaces in a router, all of the interfaces must be which of the following?

a. Configured with the CCP Wizard

b. A member of a security zone

c. Placed in a virtual template

d. A member of a dialer interface

3. What is the role of class maps?

a. They group interfaces to which security policies will be applied.

b. They allow you to specify a unidirectional firewall policy between two security zones.

c. They specify the actions to be taken when traffic matches the criteria.

d. They identify traffic and traffic parameters that a Cisco IOS Zone-Based Policy Firewall selects for policy application.

4. What programming mechanism is used to provide zone-base firewall services in a Cisco IOS router?

a. Adaptive Security Algorithm

b. Access Control Lists

c. Cisco Common Classification Policy Language

d. Modular Policy Framework

5. In CLI, the zone-pair command is used to associate together which of the following? (Choose two.)

a. zones

b. class-map

c. access-list

d. service-policy

e. interface

f. class-type

6. An interface belongs to a zone for which a zone pair with the self zone was created. No policies have yet been created. Which action will be applied when traffic originating on the interface that belongs to the zone is destined to the router itself?

a. inspect

b. pass

c. drop

d. log

e. drop and log

7. Multiple service policies can be applied to the same zone pair.

a. True

b. False

8. You want to apply a restrictive policy to traffic between interfaces that belong to the same zone in a zone-based policy firewall. Which of the following options can be used?

a. Define the zone as the source and destination of a zone pair and create a policy for the zone pair

b. Create a new zone and change interface zone membership

c. Create a zone-based policy that applies ACLs to interfaces of the zone

d. Use ACLs on the interfaces on the zone

9. Which Cisco Configuration Professional feature can be used to create zone-based firewalls?

a. Advanced Firewall wizard only

b. Basic Firewall wizard only

c. Zone-based Firewall wizard

d. Both Advanced Firewall and Basic Firewall wizards

10. Your Cisco ASA has multiple interfaces configured. There are two DMZ interfaces—DMZ1 with security level 51 and DMZ2 with security level 52. Which of the following is to be expected from this environment?

a. All traffic between the two DMZs requires an explicit policy.

b. Traffic originating at DMZ2 and destined to DMZ1 is allowed.

c. Traffic originating at DMZ1 and destined to DMZ2 is allowed.

d. None of the above.

11. Which condition would require a special configuration on Cisco ASA 8.3?

a. Connectivity for through traffic

b. ARP traffic for devices on the same interfaces

c. Outbound connectivity

d. Connectivity between interfaces of the same security level

12. What action is not available on Cisco ASA when using Modular Policy Framework?

a. Sending SNMP traps

b. Connection settings

c. NetFlow-related actions

d. QoS policies

13. Which function is not available using the Packet Tracer tool?

a. Traffic simulation

b. Testing ICMP traffic

c. Capturing packets for further analysis

d. Showing the rules applied to a packet flow

14. What is the significance of the nameif command with Cisco ASAs?

a. An interface needs to have a name to pass traffic.

b. Naming interfaces is useful for troubleshooting.

c. The interface name appears in CDP packets.

d. IP name resolution is based on name of interfaces.

15. Which statement is true regarding the default behavior of the Cisco ASA?

a. Traffic is allowed to flow from a lower security level interface to a higher security level interface.

b. Traffic is allowed to flow from a higher security level interface to a lower security level interface.

c. Traffic is allowed to flow between interfaces of the same security level.

d. Traffic is allowed to flow in and then out of the same interface.