Nowadays, security is the topmost priority of every organization. Firewalling is one of the basic yet essential forms of network security that organizations rely on. Over the years, the firewalling functionality was performed by separate hardware appliances (FWs) that sit behind WAN edge routers. This contributed to the network sprawl at branches. 

Cisco has taken a more modern security approach and has integrated an Application-aware Enterprise Firewall directly into the firmware of Edge routers, eliminating unnecessary network sprawl at remote sites. The firewall is represented as a localized security policy (firewall policy), which brings all the benefits that the policy framework provides. It allows the security teams to add and edit firewall rules to hundreds of sites at the same time through the vManage's device and feature templates.  

What is Zone-based FW architecture?

You must understand the zone-based firewall model to really understand the Cisco SD-WAN enterprise firewall.

In the past, stateful firewalls used the Context-Based Access Control (CBAC) architecture, where individual interfaces were configured with a stateful inspection policy. This architecture introduces many inefficiencies, such as:

• manual configuration of multiple interfaces
• a high chance of human error
• an interface change requires a change in the firewall policy
• often in conflict with high-availability techniques such as ECMP and Active-Active forwarding
• limits the granularity of the firewall policies
• does not scale sufficiently

The zone-based firewall architecture (ZBFW) overcomes these inefficiencies by utilizing zones instead of interfaces and applying inspection policies to the traffic between zones instead of between individual interfaces. This abstracts the router's interfaces away from the security inspection policies. You can add and remove interfaces from zones without changing the inspection policy. The ZBFW architecture is much more flexible, has a hierarchical structure, and scales more efficiently than the old CBAC architecture.

Types of Zones

A zone is a logical abstraction that represents multiple router interfaces. Since SD-WAN utilizes the concept of VPNs and each interface on an edge router is always assigned to a VPN id, a zone in Cisco SD-WAN is a grouping of one or more VPNs. However, in the end, a zone translates to a group of interfaces. For example, if we define a zone named "Employees," that includes VPNs 3 and 4. All router interfaces that are assigned with VPN ids 3 and 4 would be part of zone "Employees." 

There are a few different types of zones, depending on whether the zone is user-defined or system-defined, or on how it is configured. Figure 1 shows an example of each zone type, as shown in figure 1 above.

VPN-based Zones

The most general type of zone is a VPN-based zone which is a grouping of one or more VPNs. The output below shows how we define a VPN-based zone.

zone security WEB
 vpn 2
!
zone security DATABASE
 vpn 3
!

Since the VPN id is a globally significant value for the SD-WAN domain, a zone defined by a grouping of VPNs could be reused in many device templates, which makes it very scalable. Notice that a VPN can be part of only one zone.

Interface-based Zones

Another way of defining a zone is by assigning individual interfaces to the zone. This allows for greater granularity for the firewall policy configuration. For example, different interfaces part of the same VPN segment can be assigned to different zones (hence applying different firewall policies). 

zone security DATABASE
!
interface GigabitEthernet3
   vrf forwarding 3
   ip address 172.16.1.3 255.255.255.0
   zone-member security DATABASE
  !

Notice that the same interface can be assigned to an interface-based and a VPN-based zone. Additionally, we can pair a VPN-based zone with an interface-based zone and vice-versa.

Default Zone

Apart from the user-defined zones, there are two system-defined zones. The first one is the Default zone. Each VPN or router interface that has not been explicitly assigned to a security zone belongs to the default zone.

zone security default

Self Zone

The second system-defined zone is the self-zone. It includes all router's IP addresses. All traffic to and from the self-zone is allowed by default. The solution allows us to apply a firewall policy to the traffic between the self-zone and another security zone. However, you must be very careful when applying security to the self-zone as it may impact the sd-wan control connections.

zone security self

Zone Pairs

A zone establishes the security boundary where traffic is subject to firewall inspection. By default, if no firewall policy is explicitly applied between zones, all traffic within a zone is allowed, while all traffic between zones is dropped.

A zone pair is a logical association between two zones - one being a source zone and the other being a destination zone. A firewall policy is always applied to a zone pair and acts upon the traffic in the direction from the source toward the destination zone.

The configuration representation of the zone-pairing is as shown in the output below:

zone-pair security WEB-TO-DB source WEB destination DATABASE
 service-policy type inspect FIREWALL-POLICY

It is important to notice that the zone pair is a unidirectional association between two zones. Hence when a firewall policy is applied to the zone, only the traffic crossing the zones from source to destination is subject to the firewall policy.

Firewall Policy Configuration Workflow

Let's now quickly go through the process of configuring and applying a firewall policy. The following sequence of steps describes the general firewall policy workflow:

1. Define zones -  we define one source and one destination zone using one of the configuration types described above.
2. Define a zone-pair - since zone associations are directional, we must ensure that we pair the zones in the intended traffic direction.
3. Create a security policy - a security policy is a container for all policies such as Firewall, IPS, URLF, AMP, etc. 
   1. Define a firewall policy - within the security policy, we define a firewall policy.
   2. Define traffic rules - we match interesting traffic using object-groups and class-maps. Then we specify a firewall action for the matching traffic. Ultimately, we define a default firewall action (drop by default).
   3. Apply the firewall policy to a zone pair - a firewall policy is always applied to a zone-pair. Notice that within the security policy, we can define many firewall policies applied to different zone pairs.
4. Attach the security policy to a device template

Figure 3 below illustrates the firewall policy workflow.

Firewall Actions

When a firewall policy is applied to a zone pair, the traffic flows crossing the source zone are subject to the following three firewall actions: 

• Inspect — The "inspect" firewall action provides stateful traffic control. The router creates connections for the matching flows and tracks their state. Subsequently, the router automatically allows return traffic from the destination zone back to the source zone in reply to connection requests. Additionally, a parameter map can be applied to record connections' start/stop times, duration, data volume, etc.
• Pass — The "pass" firewall action provides stateless traffic control. The router simply forwards the matching traffic from the source to the destination zone. It does not track the state of connections. Returning traffic isn't allowed, so a parallel firewall policy must be configured and applied for the traffic in the opposite direction. This firewall action is typically used with protocols such as ISAKMP, IPsec, and DTLS/TLS, which have predictable behavior and are inherently secure. 
• Drop — The "drop" firewall action silently discards the matched traffic. Silently means that the router does not notify the relevant end host. (when traffic is dropped by an ACL, the router sends an ICMP "host unreachable" message to the relevant end-host).

Firewall Scenario Use Cases

Cisco's Enterprise Application-Aware Firewall can perform intra-zone-based firewalling and inter-zone-based firewalling based on zone pair association and traffic flow between zones.

Inter-zone Firewall

Figure 4 illustrates an inter-zone security use case where hosts in different zones on the same router are secured with a firewall policy. At the same time, the same policy also secures hosts across the fabric in different zones (assuming the same security policy is applied to both edge routers). 

Notice that for connectivity between different zones (different VPNs) to occur, we must configure route leaking on the vSmart controller first using the "export-to" policy action.

Intra-zone Firewall