WB VolI 2.11 Zone Based Firewall

Hello

The WBVolI says on the solution for the 2.11 that if I add and zone-pair self to OTHERZONE i may need a pair to allow traffic back.

On this lab we have RIP going to R3 to R2(outside) and vice-versa.

On the solution on the WBVolI 2.11 I have the following config:

...

policy-map type inspect PMAP_OUTSIDE_TO_SELF
class CMAP_HTTPS_SSH
inspect
class CMAP_RIP
pass
!
...
policy-map type inspect PMAP_SELF_TO_ANY
class CMAP_TELNET
no pass
inspect
class CMAP_ICMP
no pass

...

zone-pair security ZP_OUTSIDE_TO_SELF source OUTSIDE destination self
service-policy type inspect PMAP_OUTSIDE_TO_SELF
!
...
zone-pair security ZP_SELF_TO_OUTSIDE source self destination OUTSIDE
service-policy type inspect PMAP_SELF_TO_ANY
!

Here we see that we allow the RIP on the zone-pair  ZP_OUTSIDE_TO_SELF with the inspection of PMAP_OUTSIDE_TO_SELF. But we dont explicity allow the RIP from the zone-pair ZP_SELF_TO_OUTSIDE.

I did this test on the graded labs and RIP was still able to pass from the self to the outside even not expliciting allowing it.

 

R3
     136.1.0.0/24 is subnetted, 2 subnets
C       136.1.13.0 is directly connected, FastEthernet0/0
C       136.1.23.0 is directly connected, FastEthernet0/1.23
     10.0.0.0/24 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, FastEthernet0/1.100
     150.1.0.0/24 is subnetted, 2 subnets
R       150.1.2.0 [120/1] via 136.1.23.2, 00:00:28, FastEthernet0/1.23
R       150.1.1.0 [120/1] via 136.1.13.1, 00:00:09, FastEthernet0/0


R2

     136.1.0.0/24 is subnetted, 2 subnets
R       136.1.13.0 [120/1] via 136.1.23.3, 00:00:08, FastEthernet0/0
C       136.1.23.0 is directly connected, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
R       10.0.0.0 [120/1] via 136.1.23.3, 00:00:08, FastEthernet0/0
     150.1.0.0/24 is subnetted, 2 subnets
C       150.1.2.0 is directly connected, Loopback0
R       150.1.1.0 [120/2] via 136.1.23.3, 00:00:08, FastEthernet0/0

 

Is there an explanation why RIP is still working?

PS. I also removed the class CMAP_RIP from PMAP_OUTSIDE_TO_SELF and RIP was still flowing from outside to self and vice-versa.

Thank you!

Comments

  • BUMP.  I have the same question.

  • guys,

    I hope i refer to the same question. if i am not wrong, this is on Hotfix workbook, 100.4 Zone based firewall.

    I think i found the reason, why RIP update is still accepted by zone SELF.

    If you try to execute "show policy-map type inspect zone-pair ZP_OUTSIDE_TO_SELF", then no traffic statistic for class CMAP_RIP.

     

    I try to read back the configuration guide on:

    http://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_zbf/configuration/12-4t/sec-zone-pol-fw.html

    You will find this:

    "Stateful inspection support for multicast traffic is not supported between any zones, including the self zone. Use Control Plane Policing for protection of the control plane against multicast traffic."

    It makes me think that RIP is a multicast traffic, so it makes sense that ZBF would not inspect RIP update.

    Then I try test using Control Plane configuration:

    class-map type port-filter match-all CP_RIP
     match  port udp 520
    !
    policy-map type port-filter PMAP_CP_RIP
     class CP_RIP
        log
       drop
    !
    control-plane host
     service-policy type port-filter input PMAP_CP_RIP

    then, a couple of second later you will get this log (all RIP updates from R1 and R2 are dropped by R3):

    *Mar  1 01:28:30.983: %CP-6-UDP: DROP TCP/UDP Portfilter  136.1.13.1(520) -> 224.0.0.9(520)
    Rack1R3#
    *Mar  1 01:28:40.919: %CP-6-UDP: DROP TCP/UDP Portfilter  136.1.23.2(520) -> 224.0.0.9(520)
    Rack1R3#
    *Mar  1 01:28:58.591: %CP-6-UDP: DROP TCP/UDP Portfilter  136.1.13.1(520) -> 224.0.0.9(520)
    Rack1R3#
    *Mar  1 01:29:07.795: %CP-6-UDP: DROP TCP/UDP Portfilter  136.1.23.2(520) -> 224.0.0.9(520)

    Before Control plane configuration, show ip route will look like this:

    Rack1R2#sh ip route
    < snip >
         136.1.0.0/24 is subnetted, 2 subnets
    R       136.1.13.0 [120/1] via 136.1.23.3, 00:00:05, FastEthernet0/0
    C       136.1.23.0 is directly connected, FastEthernet0/0
         150.1.0.0/24 is subnetted, 2 subnets
    C       150.1.2.0 is directly connected, Loopback0
    R       150.1.1.0 [120/2] via 136.1.23.3, 00:00:05, FastEthernet0/0

    Then, after control plane configuration, it will look like this:

    Rack1R2#sh ip route
    < snip >
         136.1.0.0/24 is subnetted, 2 subnets
    R       136.1.13.0 [120/1] via 136.1.23.3, 00:00:17, FastEthernet0/0
    C       136.1.23.0 is directly connected, FastEthernet0/0
         150.1.0.0/24 is subnetted, 1 subnets
    C       150.1.2.0 is directly connected, Loopback0

    there is only one RIP route, 136.1.13.0 which is sent by R3. RIP update from R3 is still allowed since control plane host only control traffic inbound to router not outbound.

     

    If any body out there could find different explanation/answer, please let me know !.

    If my explanation is correct, then there is no use to put class CMAP_RIP under policy-map, since RIP update still can pass zone based firewall what ever the action is !!

    Maybe experts from INE could verify this!!!

     

    thanks.

     

     

     

     

  • Hi Yudi,

     

    Thanks for contributing and labbing this out man.  That is the same conclusion I came to after researching the topic for a bit.  The documentation on zone self sure seems pretty cryptic if you ask me : ) What I understand is below.  These are just my assumptions after reading and playing with it for a bit so I wouldn't mind some re-assurance!  Happy labbing folks!

     

    - All traffic to/from zone self is permitted by default

    - As soon as you apply a policy to a zone-pair where zone self is the source or destination, anything sourced from or destined to zone self for that specific zone pair is dropped unless specifically permitted by the policy.  This does not effect other zone's communication with zone self.  If it did, we would need a policy for inside <--> self in this example too, but we don't. For example, I believe you could have a policy for outside --> zone self and still have traffic completely uneffected and permitted by default for inside --> zone self.

    - You may or may not need a policy from zone self to other zones depending on what you have done.  If you inspect the traffic to zone self, the return traffic is automatically permitted. For example, if you inspect SSH and HTTP traffic to the router itself, the return traffic from self back to the source is permitted.  Unsolicited traffic from zone self going out to other zones seems to be permitted by default so long as there is no zone self --> other zone policy configured.  Just like inbound traffic, once you apply a policy for traffic from zone self going to some other zone, everything is dropped unless specifically permited. For example, by default I believe you could telnet/ssh from the firewall anywhere you want, but as soon as a policy is applied for zone self going to some other zone, that would have to be specifically allowed in the policy

    - Multicast is not inspected.  That means in theory we don't need zone self exceptions for all the main IGPs if they are running "out of the box" as RIPv2, EIGRP and OSPF all use multicast by default.  Watch out for unicast configurations via "neighbor"!!! I also removed the inclusion of RIPv2 on the outside --> self zone for this task and it continued to work fine.  Also, as we have noted we do not need a specific exception for RIPv2 traffic sourced from the firewall going out to the otuside zone even though we have a specific zone self --> outside policy because the RIPv2 multicast is not inspected so it seems it is exempt by default.

Sign In or Register to comment.