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:
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 126.96.36.199Trying 188.8.131.52 ... Open User Access Verification Password: R3>exit [Connection to 184.108.40.206 closed by foreign host] R1#ping 220.127.116.11 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 18.104.22.168, 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