ZBF doubt ?

Hi Guys!

As per my understanding of ZBF we need to create individual zone pairs for every zone that is , if i want to pass traffic from "IN-ZONE to "OUT-ZONE" i need a zone pair for it. Similarly for the return traffic of "IN-ZONE" to come back in , i need a class-map, policy-map and zone pair for "OUT-ZONE" as well??

I did a small lab in Packet Tracer where i inspected all ip traffic from my "IN-ZONE'' with a policy of pass and corresponding zone-pair where source was in-zone and destination was out-zone .

This allowed me ping and HTTP traffic to external networks

. which according to me should not be possible without a corresponding zone pair for out-zone??

where am i wrong??

Find more posts tagged with

Comments

notgoing2fail

logicmyfoot wrote: »

Hi Guys!

As per my understanding of ZBF we need to create individual zone pairs for every zone that is , if i want to pass traffic from "IN-ZONE to "OUT-ZONE" i need a zone pair for it. Similarly for the return traffic of "IN-ZONE" to come back in , i need a class-map, policy-map and zone pair for "OUT-ZONE" as well??

I did a small lab in Packet Tracer where i inspected all ip traffic from my "IN-ZONE'' with a policy of pass and corresponding zone-pair where source was in-zone and destination was out-zone .

This allowed me ping and HTTP traffic to external networks. which according to me should not be possible without a corresponding zone pair for out-zone??

where am i wrong??

It is true you do need policies to be applied for incoming and outgoing traffic.

I'm trying to remember why your pings work. Becuase I do remember that an IN-2-OUT policy does not allow outside connections to be "initiated" back in.

I have to remember what is the fundamental reason why your ping responses were able to work...

I step away from ZBF for 2 weeks and I'm already forgetting it!!

logicmyfoot

i seriously hope Packet Tracer is not at fault here ,which i doubt

kalebksp

When you inspect traffic it keeps track of the ports and lets return traffic back in, if you had used an access-list instead of inspection it would have worked as you expected.

ilcram19-2

it is not what it goes in to the interface it actually what goes in to the zone the interface is part of the self zone with also needs to be confugure by default all traffic is allow to the self zone

for example

zoneA to allow http traffic to zoneB

class-map type inspect zoneA-to-ZoneB-http
match protocol http

policy-map type inspect zoneA-to-ZoneB-http
class type inspect zoneA-to-ZoneB-http
inspect
class class-default
drop log

zone-pair security zoneA-zoneB source zoneA destination zoneB
service-policy type inspect zoneA-to-ZoneB-http

if you have that http traffic should work and the rest should be drop
if you still have problems check the rules
•A zone must be configured before interfaces can be assigned to the zone.

•An interface can be assigned to only one security zone.

•All traffic to and from a given interface is implicitly blocked when the interface is assigned to a zone, except traffic to and from other interfaces in the same zone, and traffic to any interface on the router.

•Traffic is implicitly allowed to flow by default among interfaces that are members of the same zone.

•In order to permit traffic to and from a zone member interface, a policy allowing or inspecting traffic must be configured between that zone and any other zone.

•The self zone is the only exception to the default deny all policy. All traffic to any router interface is allowed until traffic is explicitly denied.

•Traffic cannot flow between a zone member interface and any interface that is not a zone member. Pass, inspect, and drop actions can only be applied between two zones.

•Interfaces that have not been assigned to a zone function as classical router ports and might still use classical stateful inspection/CBAC configuration.

•If it is required that an interface on the box not be part of the zoning/firewall policy. It might still be necessary to put that interface in a zone and configure a pass all policy (sort of a dummy policy) between that zone and any other zone to which traffic flow is desired.

•From the preceding it follows that, if traffic is to flow among all the interfaces in a router, all the interfaces must be part of the zoning model (each interface must be a member of one zone or another).

•The only exception to the preceding deny by default approach is the traffic to and from the router, which will be permitted by default. An explicit policy can be configured to restrict such traffic.

logicmyfoot

kalebksp wrote: »

When you inspect traffic it keeps track of the ports and lets return traffic back in, if you had used an access-list instead of inspection it would have worked as you expected.

i did use an ACL for my in-zone to let all ip traffic[ it makes no sense ,just did it to try it ]

notgoing2fail

I've had my head buried in my SWITCH book. But this is interesting to me so I'll see if I can lab it up soon. I'd like to know for myself as well...

logicmyfoot

ilcram19-2 wrote: »

it is not what it goes in to the interface it actually what goes in to the zone the iinterface is part of the self zone I thought self zones is for router generated or originated traffic only , so all interface will be a member be it in or out part of self zone so traffic should came to should passed by the rules?

with also needs to be confugure by default all traffic is allow to the self zone

for example

zoneA to allow http traffic to zoneB

class-map type inspect zoneA-to-ZoneB-http
match protocol http i used match any to allow all

policy-map type inspect zoneA-to-ZoneB-http
class type inspect zoneA-to-ZoneB-http
inspect
class class-default
drop log

zone-pair security zoneA-zoneB source zoneA destination zoneB
service-policy type inspect zoneA-to-ZoneB-http

if you have that http traffic should work and the rest should be drop
if you still have problems check the rules
•A zone must be configured before interfaces can be assigned to the zone.

•An interface can be assigned to only one security zone.

•All traffic to and from a given interface is implicitly blocked when the interface is assigned to a zone, except traffic to and from other interfaces in the same zone, and traffic to any interface on the router.

•Traffic is implicitly allowed to flow by default among interfaces that are members of the same zone.

•In order to permit traffic to and from a zone member interface, a policy allowing or inspecting traffic must be configured between that zone and any other zone. this is what is confusing me

•The self zone is the only exception to the default deny all policy. All traffic to any router interface is allowed until traffic is explicitly denied.

•Traffic cannot flow between a zone member interface and any interface that is not a zone member. Pass, inspect, and drop actions can only be applied between two zones.

•Interfaces that have not been assigned to a zone function as classical router ports and might still use classical stateful inspection/CBAC configuration.

•If it is required that an interface on the box not be part of the zoning/firewall policy. It might still be necessary to put that interface in a zone and configure a pass all policy (sort of a dummy policy) between that zone and any other zone to which traffic flow is desired.

•From the preceding it follows that, if traffic is to flow among all the interfaces in a router, all the interfaces must be part of the zoning model (each interface must be a member of one zone or another).

•The only exception to the preceding deny by default approach is the traffic to and from the router, which will be permitted by default. An explicit policy can be configured to restrict such traffic.

guys please help me sort this

peanutnoggin

logicmyfoot wrote: »

guys please help me sort this

the "match any" is a logical OR operator. So that is saying: match either http or smtp or ftp etc, etc...

in the case of the example, ilcram is saying match protocol http. If there were other protocols such as smtp, pop3, https, etc... then you would have to have a match statement saying match any (logical OR) or a match all (logical AND).

logicmyfoot wrote: »

•In order to permit traffic to and from a zone member interface, a policy allowing or inspecting traffic must be configured between that zone and any other zone. this is what is confusing me

This is a rule of ZBF... in fact, ilcram gave all the rules of the ZBF. Once you're able to commit those to memory, it'll all make sense after that.

-Peanut

logicmyfoot

peanutnoggin wrote: »

the "match any" is a logical OR operator. So that is saying: match either http or smtp or ftp etc, etc...

in the case of the example, ilcram is saying match protocol http. If there were other protocols such as smtp, pop3, https, etc... then you would have to have a match statement saying match any (logical OR) or a match all (logical AND).

This is a rule of ZBF... in fact, ilcram gave all the rules of the ZBF. Once you're able to commit those to memory, it'll all make sense after that.

-Peanut

i do understand match-any and match-all scenario my question does not pertains to the example given in ilcram post .

my question is regarding the ZBF rule . I read in one of the cisco press books that these zone pair rule are unidirectional and we need bidirectional zone pairs for initiated and return traffic.

I m at work right now im gonna past the phrase from the book whern i get back home.

Bear with me guys , i know i am sounding noobish

ilcram19-2

logicmyfoot wrote: »

i do understand match-any and match-all scenario my question does not pertains to the example given in ilcram post .

my question is regarding the ZBF rule . I read in one of the cisco press books that these zone pair rule are unidirectional and we need bidirectional zone pairs for initiated and return traffic.

I m at work right now im gonna past the phrase from the book whern i get back home.

Bear with me guys , i know i am sounding noobish

the only time you need bidirectional is when you are passing the traffic and not inspecting
here is an bidirectional example config the traffic still logged but the session is not inspected for protocol compliance

class-map type inspect match-all zoneA-zoneB-http-class
match access-group pass-traffic

ip access-list extended pass-traffic
permit tcp host 1.1.1.1 host 2.2.2.2 eq http

policy-map type inspect zoneA-zoneB-http-policy
class type inspect zoneA-zoneB-http-class
pass log <

traffic is pass as is not inspected
class class-default
drop

class-map type inspect match-all zoneB-zoneA-http-class
match access-group pass-traffic

ip access-list extended pass-traffic
permit tcp host 2.2.2.2 eq http host 1.1.1.1

policy-map type inspect zoneA-zoneB-policy
class type inspect zoneB-zoneA-class
pass log <

traffic is pass as is not inspected
class class-default
drop

zone-pair security zoneA-zoneB source zoneA destination zoneB
service-policy type inspect zoneA-zoneB-policy

zone-pair security zoneB-zoneA source zoneB destination zoneA
service-policy type inspect zoneB-zoneA-policy

when you do pass instead of inspect you will need to allow the traffic back and thats the only time you would need a bidirectional policy

logicmyfoot

ilcram19-2 wrote: »

the only time you need bidirectional is when you are passing the traffic and not inspecting
here is an bidirectional example config the traffic still logged but the session is not inspected for protocol compliance

class-map type inspect match-all zoneA-zoneB-http-class
match access-group pass-traffic

ip access-list extended pass-traffic
permit tcp host 1.1.1.1 host 2.2.2.2 eq http

policy-map type inspect zoneA-zoneB-http-policy
class type inspect zoneA-zoneB-http-class
pass log <
traffic is pass as is not inspected
class class-default
drop

class-map type inspect match-all zoneB-zoneA-http-class
match access-group pass-traffic

ip access-list extended pass-traffic
permit tcp host 2.2.2.2 eq http host 1.1.1.1

policy-map type inspect zoneA-zoneB-policy
class type inspect zoneB-zoneA-class
pass log <
traffic is pass as is not inspected
class class-default
drop

zone-pair security zoneA-zoneB source zoneA destination zoneB
service-policy type inspect zoneA-zoneB-policy

zone-pair security zoneB-zoneA source zoneB destination zoneA
service-policy type inspect zoneB-zoneA-policy

when you do pass instead of inspect you will need to allow the traffic back and thats the only time you would need a bidirectional policy

You Sir have just saved my life and my precious hair.

Man would it kill Cisco to mention this in the books

geezer

Yes, it wouldn't hurt and was an obvious omission (one of many in the cert guide...).

I suppose they assumed that people would realise the term "inspect" from CBAC (ip inpect...") means stateful inspection (i.e. state table tracking session information for that connection flow to allow return path).

CBT nugget video briefly mentions this 'inspect' command correlating to CBAC but was very brief and Jeremy does rattle along at 100MPH

Glad it was cleared up and helped me revisit just as I am looking at ZBF in my studies!

ilcram19-2

logicmyfoot wrote: »

You Sir have just saved my life and my precious hair.

Man would it kill Cisco to mention this in the books

no problem i ran in to this issue where an application wasnt working properly becasue it wsa being inspected i tried pretty much everything i find that out just by luck, i needed to find a way to avoid inspection and i saw pass being another option but couldnt find anything on the net or cisco docs i did the pass one way but still not working so i went to my log server and saw that the packets were being drop comming back than i just the ZBF config passig the traffic back and it was all well