ZBF Part 3 of 3 – Caveats and an Example

By Anthony Sequeira on July 28th, 2011

With the zone-based firewall, we should be aware of many caveats and rules regarding its operation. These are as follows:

  • Configure your zones first as we described in the steps of the previous post. A zone must be configured before you can assign interfaces to the zone.
  • An interface can be assigned to only one security zone.
  • Traffic is always implicitly allowed to flow between interfaces within the same zone.

  • To permit traffic to and from a zone member interface, you must configure a policy allowing or inspecting traffic between that zone and any other zone.
  • Traffic cannot flow between a zone member interface and any interface that is not a zone member.
  • Interfaces that have not been assigned to a zone function as classic router ports. These ports are still capable of receiving a classic CBAC configuration.

Not that we have seen the steps, and we understand the caveats and rules associated with these new firewall structures, lets examine a sample configuration.

In this simple example, we have the following topology:

R1——-R2——-R3

We will pretend that R1 is in the inside (protected) network, while R3 is in the outside (unprotected) network. R2 will act as the zone-based firewall between the two networks. On R2, Fa0/0 is the protected side interface, and its Fa0/1 is the unprotected side interface. Lets run through our example, using the configuration steps from the last post as our guide:

Step 1 – Define and populate zones.

configure terminal
!
zone security ZONE_PRIV
zone security ZONE_INT
!
interface fa0/0
 zone-member security ZONE_PRIV
!
interface fa0/1
 zone-member security ZONE_INT

Step 2 – Define the class-maps that identify traffic flowing between zones.

configure terminal
!
class-map type inspect match-any CM_NET_TRAFFIC
match protocol http
match protocol https
match protocol ftp
match protocol telnet

Step 3 – Configure a policy-map that specifies actions for the traffic.

configure terminal
!
policy-map type inspect PM_PRIVATE_TO_INTERNET
class type inspect CM_NET_TRAFFIC
inspect

Step 4 – Configure the zone pair and apply the policy.

configure terminal
zone-pair security ZONEP_PRIV_INT source ZONE_PRIV destination ZONE_INT
service-policy type inspect PM_PRIVATE_TO_INTERNET

Very simple stuff when you break it down into the steps, and also very simple for those that have experience with the Modular Quality of Service Command Line Interface from QoS.

What about verification? Well, in our example, Telnet should be dynamically permitted from R1 to R3, but an ICMP PING should fail as this traffic is not inspected by the firewall. After testing those traffic forms, we should utilize the show policy-map command in order to review the session information and dropped traffic stats.

R1#telnet 23.23.23.3Trying 23.23.23.3 ... Open
User Access Verification
Password:
R3>exit
[Connection to 23.23.23.3 closed by foreign host]
R1#ping 23.23.23.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 23.23.23.3, timeout is 2 seconds:
.....Success rate is 0 percent (0/5)
R1#
R2#show policy-map type inspect zone-pair ZONEP_PRIV_INT Zone-pair: ZONEP_PRIV_INT
 Service-policy inspect : PM_PRIVATE_TO_INTERNET
 Class-map: CM_NET_TRAFFIC (match-any)     
 Match: protocol http        0 packets, 0 bytes        30 second rate 0 bps     
 Match: protocol https        0 packets, 0 bytes        30 second rate 0 bps     
 Match: protocol ftp        0 packets, 0 bytes        30 second rate 0 bps     
 Match: protocol telnet        1 packets, 24 bytes        30 second rate 0 bps     
 Inspect        Packet inspection statistics [process switch:fast switch]       
 tcp packets: [0:39]
 Session creations since subsystem startup or last reset 1       
 Current session counts (estab/half-open/terminating) [0:0:0]       
 Maxever session counts (estab/half-open/terminating) [1:1:1]       
 Last session created 00:06:39        Last statistic reset never       
 Last session creation rate 0        Maxever session creation rate 1       
 Last half-open session total 0
 Class-map: class-default (match-any)     
 Match: any     
 Drop (default action)       
 5 packets, 400 bytes
 R2#

In future posts, we will dig deeper into this new firewall paradigm and its advanced capabilities. Happy studying and thanks for reading this series here at blog.ipexpert.com.

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

Be Sociable, Share!

    Tags: CCIE, CCIE R&S, CCIE R&S 4.0 Lab, CCIE Security, CCIE Security 3.0, CCIE Training, zbf, zone-based firewall

    One Response to “ZBF Part 3 of 3 – Caveats and an Example”

    1. tom says:

      One of the things I don’t like with ZPF vice classic firewall (and interface ACLs) is the CLI output.

      The “log” keyword at the end of an ACL line outputs a very clear message telling you what was dropped or passed.

      Logging of drops in ZPF produces a much more cryptic output. Only the port is shown so it’s not immediately obvious whether the drop occurred on ICMP, TCP, UDP, or other protocols.

      Do any other debugs or outputs work well to determine firewall problems?

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)

    Leave a Reply