A security zone is a group of interfaces to which a policy can be applied.

Grouping interfaces into zones involves two procedures:

• Creating a zone so that interfaces can be attached to it.

• Configuring an interface to be a member of a given zone.

By default, traffic flows among interfaces that are members of the same zone.

When an interface is a member of a security zone, all traffic (except traffic going to the device or initiated by the device) between that interface and an interface within a different zone is dropped by default. To permit traffic to and from a zone-member interface and another interface, you must make that zone part of a zone pair and apply a policy to that zone pair. If the policy permits traffic through inspect or pass actions, traffic can flow through the interface.

The following are basic rules to consider when setting up zones:

• Traffic from a zone interface to a nonzone interface or from a nonzone interface to a zone interface is always dropped; unless default zones are enabled (default zone is a nonzone interface).

• Traffic between two zone interfaces is inspected if there is a zone pair relationship for each zone and if there is a configured policy for that zone pair.

• By default, all traffic between two interfaces in the same zone is always allowed.

• A zone pair can be configured with a zone as both source and destination zones. An inspect policy can be configured on this zone pair to inspect, pass or drop the traffic between the two zones.

• An interface can be a member of only one security zone.

• When an interface is a member of a security zone, all traffic to and from that interface is blocked unless you configure an explicit interzone policy on a zone pair involving that zone.

• For traffic to flow among all interfaces in a device, these interfaces must be members of one security zone or another. It is not necessary for all device interfaces to be members of security zones.

• All interfaces associated with a zone must be contained in the same VRF (Virtual Routing Forwarding).

The figure below illustrates the following:

• Interfaces E0 and E1 are members of security zone Z1.

• Interface E2 is a member of security zone Z2.

• Interface E3 is not a member of any security zone.

The following situations exist:

• The zone pair and policy are configured in the same zone. Traffic flows freely between interfaces E0 and E1 because they are members of the same security zone (Z1).

• If no policies are configured, traffic will not flow between any other interfaces (for example, E0 and E2, E1 and E2, E3 and E1, and E3 and E2).

• Traffic can flow between E0 or E1 and E2 only when an explicit policy permitting traffic is configured between zone Z1 and zone Z2.

• Traffic can never flow between E3 and E0/E1/E2 unless default zones are enabled.

Note	On the Cisco ASR 1000 Series Aggregation Services Routers the firewall supports a maximum of 4000 zones.

A class identifies a set of packets based on its contents. Normally, you define a class so that you can apply an action on the identified traffic that reflects a policy. A class is designated through class maps.

An action is a functionality that is typically associated with a traffic class. Firewall supports the following type of actions:

inspect — once classified, firewall session is created in the connection table and the packets content is examined.

pass — the packet is simply classified and the traffic is allowed to pass through the system without further inspection.

drop — the packet is classified and dropped.

To create security zone firewall policies, you must complete the following tasks:

• Define a match criterion (class map).

• Associate actions to the match criterion (policy map).

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

The class-map command creates a class map to be used for matching packets to a specified class. Packets that arrive at targets (such as the input interface, output interface, or zone pair), determined by how the service-policy command is configured, are checked against match criteria configured for a class map to determine if the packet belongs to that class.

The policy-map command creates or modifies a policy map that can be attached to one or more targets to specify a service policy. Use the policy-map command to specify the name of the policy map to be created, added to, or modified before you can configure policies for classes whose match criteria are defined in a class map.

A virtual template interface is a logical interface configured with generic configuration information for a specific purpose or for a configuration common to specific users, plus device-dependent information. The template contains Cisco software interface commands that are applied to virtual access interfaces. To configure a virtual template interface, use the interface virtual-template command.

Zone member information is acquired from a RADIUS server and the dynamically created interface is made a member of that zone. The zone-member security command adds the dynamic interface to the corresponding zone.

For more information on the Per Subscriber Firewall on LNS feature, see the Release Notes for Cisco ASR 1000 Series Aggregation Services Routers for Cisco IOS XE Release 2.

A zone pair allows you to specify a unidirectional firewall policy between two security zones.

To define a zone pair, use the zone-pair security command. The direction of the traffic is specified by source and destination zones. The source and destination zones of a zone pair must be security zones.

You can select the default or self zone as either the source or the destination zone. The self zone is a system-defined zone which 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 device or traffic generated by the device. It does not apply to traffic through the device.

The default zone is applicable to interfaces where no security zone is associated. Default zones are by default not enabled. To enable default zones use the zone security default configuration command to create the default zone.

The most common usage of firewall is to apply them to traffic through a device, so you need at least two zones. For traffic to and from the device, ZBF supports the concept of a self-zone.

To permit traffic between zone member interfaces, you must configure a policy permitting (inspecting or passing) traffic between that zone and another zone. To attach a firewall policy map to the target zone pair, use the service-policy type inspect command.

The figure below shows the application of a firewall policy to traffic flowing from zone Z1 to zone Z2, which means that the ingress interface for the traffic is a member of zone Z1 and the egress interface is a member of zone Z2.

If there are two zones and you may require policies for traffic going in both directions (from Z1 to Z2 and Z2 to Z1). If traffic is initiated from either direction, you must configure two zone pairs.

If a policy is not configured between zone pairs, traffic is dropped. However, it is not necessary to configure a zone pair and a service policy solely for the return traffic. By default, return traffic is not allowed. If a service policy inspects the traffic in the initiator direction and there is no zone pair and service policy for the return traffic, the return traffic is inspected.

If a service policy passes the traffic in the forward direction and there is no zone pair and service policy for the return traffic, the return traffic is dropped. In both these cases, you need to configure a zone pair and a service policy to allow the return traffic. In the above figure, it is not mandatory that you configure a zone pair source and destination for allowing return traffic from Z2 to Z1. The service policy on Z1 to Z2 zone pair takes care of it. For the pass action, a policy must exist for packets in each direction and for inspect a policy need to exist for traffic from the initiator.

A zone-based firewall drops a packet if it is not explicitly allowed by a rule or policy in contrast to a legacy firewall, which permits a packet if it is not explicitly denied by a rule or policy by default.

A zone-based firewall behaves differently when handling intermittent Internet Control Message Protocol (ICMP) responses generated within a zone because of the traffic flowing between in-zones and out-zones.

A policy is not required for Internet Control Message Protocol (ICMP) error packets.

Note	A policy is required for ICMP informational messages such as ICMP_ECHO (ping) for packet arriving from an initiator.

In a configuration where an explicit policy is configured for the self zone to go out of its zone and for the traffic moving between the in-zone and out-zone, if any informational ICMP packets, such as ICMP_EHCO_REQUEST are generated, then the zone-based firewall looks for an explicit permit rule for the ICMP in the self zone to go out of its zone. An explicit inspect rule for the ICMP for the self zone to go out-zone may not help because there is no session associated with the intermittent ICMP responses.

Zone-based policy firewalls examine source and destination zones from the ingress and egress interfaces for a firewall policy. It is not necessary that all traffic flowing to or from an interface be inspected; you can designate that individual flows in a zone pair be inspected through your policy map that you apply across the zone pair. The policy map will contain class maps that specify individual flows. Traffic with the inspect action will create a connection in the firewall table and be subject to state checking. Traffic with the pass action will bypass the zone firewall completely, not creating any sessions. Once a firewall connection is created, the packets are no longer classified. That is, if the policy map changes, the underlying connections are not noticed. As connection is not established, a mirrored policy with a pass action must be created packets in the reverse direction.

You can also configure inspect parameters like TCP thresholds and timeouts on a per-flow basis.

Access control lists (ACLs) applied to interfaces that are members of zones are processed before the policy is applied on the zone pair. You must ensure that interface ACLs do not interfere with the policy firewall traffic when there are policies between zones. If a class map only contains an access list and does not contain a match protocol, then firewall attempts to match the flow protocol to known ALGs and process it as required.

Pinholes (ports opened through a firewall that allows applications-controlled access to a protected network) are not punched for return traffic in interface ACLs.

Layer 3 and Layer 4 class maps identify traffic streams on which different actions should be performed.

A Layer 3 or Layer 4 policy map is sufficient for the basic inspection of traffic.

The following example shows how to configure class map c1 with the match criteria of ACL 101 and the HTTP protocol, and create an inspect policy map named p1 to specify that packets will be dropped on the traffic at c1:

Device(config)# class-map type inspect match-all c1
Device(config-cmap)# match access-group 101
Device(config-cmap)# match protocol http
Device(config-cmap)# exit
Device(config)# policy-map type inspect p1
Device(config-pmap)# class type inspect c1
Device(config-pmap-c)# drop
	 

Note	On the Cisco ASR 1000 Series Aggregation Services Routers the firewall supports a maximum of 1000 policy maps and 8 classes inside a policy map. You can configure a maximum of 16 match statements in a class map and 1000 globally.

The following sections describe two different WAAS traffic flow optimization scenarios for branch office deployments. WAAS traffic flow optimization works with the Cisco firewall feature on a Cisco Integrated Services Router (ISR). ZBF inspects the clear text after WAAS has unoptimized the packet.

The figure below shows an example of an end-to-end WAAS traffic flow optimization with the Cisco firewall. In this particular deployment, a Network Management Equipment (NME)-WAE device is on the same device as the Cisco firewall. Web Cache Communication Protocol (WCCP) is used to redirect traffic for interception.