Paul,
What code are you running on your routers? We may want to match and see if the issue follows, since we have seen a couple anomalies on 12.4(15)T1. Thanks, Jamie Brogdon, CCIE #6541 (SP and R&S) / JNCIE-M #381 Verizon Telecom, IP Networks _____ From: [email protected] [mailto:[email protected]] On Behalf Of Paul Stewart Sent: Saturday, October 24, 2009 11:59 AM To: Mack, David A (Dave) Cc: [email protected] Subject: Re: [OSL | CCIE_Security] LAb2A Zone Based Firewall Interesting. I would always make sure the "ip inspect log drop-pkt" is running. It is your best friend with cbac or zfw. That will usually telling you why things aren't passing. With a cursory glance at your configuration, I'm not sure why counters weren't incrementing. I would definitely add the command above. Many times, it will give you clues as to why something is being dropped. Post back and let us know what the issue was. On Sat, Oct 24, 2009 at 11:44 AM, Mack, David A (Dave) <[email protected]> wrote: Paul, Thanks for the quick reply! So to get this point I originally did have zone pairs and service policies. In fact, there were the ones in the PG. However I could not see the counters increment as traffic passed nor dis-allowed traffic drop. In the process of debugging I wanted to at least the default behavior and that is what got me to this point. This is what I started with: class-map type inspect match-all IN->OUT-ICMP-REPLY match access-group name IN->OUT class-map type inspect match-any IN->OUT-PROTO match protocol ssh match protocol http match protocol https match protocol dns match protocol smtp match protocol bootps class-map type inspect match-all IN->OUT-ICMP match access-group name ICMP class-map type inspect match-all OUT-IN match access-group name FW-IN ! ! policy-map type inspect FW-OUT->IN class type inspect OUT-IN pass class class-default drop policy-map type inspect FW-IN->OUT class type inspect IN->OUT-PROTO inspect class type inspect IN->OUT-ICMP inspect class type inspect IN->OUT-ICMP-REPLY pass class class-default pass ! zone security INSIDE zone security OUTSIDE zone-pair security IN->OUT source INSIDE destination OUTSIDE service-policy type inspect FW-IN->OUT zone-pair security OUT->IN source OUTSIDE destination INSIDE service-policy type inspect FW-OUT->IN ip access-list extended FW-IN permit icmp any any echo permit icmp any any unreachable permit udp host 9.9.156.9 eq ntp host 7.7.7.7 eq ntp permit tcp host 9.9.156.9 gt 1024 host 9.9.156.7 eq bgp permit tcp host 9.9.156.9 eq bgp host 9.9.156.7 gt 1024 ip access-list extended ICMP permit icmp any any echo ip access-list extended IN->OUT permit icmp any any echo-reply So at this point I wondering if ZBFW is totally broken with the HW/SW I am running? Thanks! Dave ______________________________________________________________ David A. Mack (703) 391-7787 (W) CCIE #6963 (SP and R&S) JNCIE-M #399 CISSP (703) 431-7617 (C) email: [email protected] ______________________________________________________________ "We are now the knights who say... Ping!" _____ From: Paul Stewart [mailto:[email protected]] Sent: Saturday, October 24, 2009 11:37 AM To: Mack, David A (Dave) Cc: [email protected] Subject: RE: LAb2A Zone Based Firewall Dave, I can certainly see your confusion. However, I think that if you just bind the zones to the interface it will still permit traffic as you indicated. I think you would have to create a zone-pair and quite possibly even add a service-policy before the default behavior changes to the implicit deny. Last night, I was working around with communications to the "self" zone and I found that to be the case. HTH, and anyone please correct my thinking if I am incorrect.
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
