myITmicroblog

In my last post I tested some features of ZBFP and how traffic is processed by the firewall and some interfaces are not part of ZBFP configuration. Today I’d like to test ‘self-zone’ because it works a bit different. I’m going to work on a configuration from my last post. As you remember I created policy for traffic from R2 to R3. I also tested connection from R2 to R4 and it didn’t work (R4 is not a member of any zone) but traffic from R5 to R4 is allowed (both are not members of any zone). With 'self-zone’ is works a bit different. Let’s do one test: R2->R1:   R2 #ping 2.2.2.1 Type escape sequence to abort . Sending 5 , 100 - byte ICMP Echos to 2.2 . 2.1 , timeout is 2 seconds : !!!!! Success rate is 100 percent ( 5 / 5 ), round - trip min / avg / max = 64 / 95 / 128 ms R2 # R5->R1:   R5 #ping 5.5.5.1 Type escape sequence to abort . Sending 5 , 100 - byte ICMP Echos to 5.5 . 5.1 , timeout is 2 seconds : !!!!! Success...

ZBFP is a successor of CBAC and it is the most flexible firewall implementation available on IOS. The main idea is to think about zones, not physical interfaces. With CBAC you couldn’t build policy based on flow or direction. For example a policy applied on OUTSIDE interface works the same for traffic to DMZ and to LAN. ZBFP can easily separate these flows and you can have two different rules depending on out interface. Let’s test one scenario: I’m going to add a policy for traffic from R2 to R3. Only telnet and icmp should be allowed. First I create a class and policy map:   ! class - map type inspect match - any CM - ICMP - TCP match protocol icmp match protocol tcp ! policy - map type inspect PM - ICMP - TCP class type inspect CM - ICMP - TCP inspect class class - default ! and then zones and a service policy:   ! zone security INSIDE zone security OUTSIDE ! zone - pair security INS -> OUT source INSIDE destination OUTSIDE service - policy...