Re: Viewing IOS ZBF inspect drops

From: Piotr Matusiak <pitt2k_at_gmail.com>
Date: Sun, 5 Feb 2012 14:51:55 +0100

Hi,

It should work with that config. Must be something wrong elsewhere.
I think you'll not see counters in nested class, but anyway, can you post
your whole config?

Regards,

--
Piotr Matusiak
CCIE #19860 (R&S, Security), CCSI #33705
Technical Instructor
website: www.MicronicsTraining.com <http://www.micronicstraining.com/>
blog: www.ccie1.com
If you can't explain it simply, you don't understand it well enough -
Albert Einstein
2012/2/5 Bogdan Sass <bogd.no.spam_at_gmail.com>
>  On 04/02/2012 23:27, Piotr Matusiak wrote:
>
> Hi,
>
> The command is 'ip inspect log drop-pkt'. In addition to that it is very
> useful to enable Audit-Trail via parameter-map and apply it to your policy.
>
>
>     Thank you! That is exactly what I was looking for!
>
>     However, this seems to have led me to something even stranger...
>
> R3#sh policy-map type in zone-pair OUTSIDE_DMZ sess
>
> policy exists on zp OUTSIDE_DMZ
>  Zone-pair: OUTSIDE_DMZ
>
>   Service-policy inspect : PM_OUTSIDE_DMZ
>
>     Class-map: CM_OUTSIDE_DMZ (match-all)
>       Match: access-group name TO_DMZ
>       Match: class-map match-any DMZ_PROTO
>         Match: protocol http
>           0 packets, 0 bytes
>           30 second rate 0 bps
>         Match: protocol ftp
>           0 packets, 0 bytes
>           30 second rate 0 bps
>         Match: protocol dns
>           0 packets, 0 bytes
>           30 second rate 0 bps
>         Match: protocol tacacs
>           0 packets, 0 bytes
>           30 second rate 0 bps
>         Match:* protocol icmp*
>          * 0 packets, 0 bytes*
>           30 second rate 0 bps
>
>    Inspect
>        Police
>         rate 512000 bps,6400 limit
>         conformed 1 packets, 64 bytes; actions: transmit
>         exceeded 0 packets, 0 bytes; actions: drop
>         conformed 0 bps, exceed 0 bps
>
>     Class-map: class-default (match-any)
>       Match: any
>       Drop
>         17 packets, 1248 bytes
> Rack1R3#
> *Feb  5 10:55:56.608: %FW-6-DROP_PKT: Dropping* icmp session 136.1.23.2:0
> 10.0.0.100:0 on zone-pair OUTSIDE_DMZ class class-default *due to  DROP
> action found in policy-map with ip ident 0
> Rack1R3#
> *Feb  5 10:56:52.172: %FW-6-LOG_SUMMARY: 5 packets were dropped from
> 136.1.23.2:8 => 10.0.0.100:0 (target:class)-(OUTSIDE_DMZ:class-default)
>
> R3#sh ip access-lists TO_DMZ
> Extended IP access list TO_DMZ
>     10 permit ip any 10.0.0.0 0.0.0.255 (23 matches)
>
>     So I have this policy map configured between two zones. However, when
> I ping between the zones, the ICMP packets get dropped.
>     The ACL does match (I can see the counter increasing), but the "match
> protocol icmp" line doesn't. So the packets just fall through to the
> default policy, which drops them.
>
>     Is there something I'm doing wrong here?
>
>     (Tested on a C2811, 12.4(24)T2)
>
>     Thank you!
>
>
> --
> Bogdan Sass
> CCSP,LPIC-1,VCP5,CCIE #22221 (RS)
> Information Systems Security Professional
> "Curiosity was framed - ignorance killed the cat"
>
>
>
>  Regards,
> --
> Piotr Matusiak
> CCIE #19860 (R&S, Security), CCSI #33705
> Technical Instructor
> website: www.MicronicsTraining.com <http://www.micronicstraining.com/>
> blog: www.ccie1.com
>
> If you can't explain it simply, you don't understand it well enough -
> Albert Einstein
>
>
> 2012/2/4 Bogdan Sass <bogd.no.spam_at_gmail.com>
>
>>    I've been working on some ZBF labs, and I was wondering - is there a
>> show or debug command that can allow me to see why a packet is being
>> dropped by inspection?
>>
>>    For example, in my case, I was trying to troubleshoot a scenario where
>> I couldn't ping the router due to inspection being activated.
>>
>>    R1-------R2
>>
>>    On R2, I had inspection configured for icmp traffic going from the
>> self zone to inside (R1), but nothing for the inside to self zone (which
>> means that all traffic is allowed). However, when pinging from R1 to R2, I
>> could see the pings going to R2 and the replies being generated, but those
>> replies never made it back to R1.
>>    I assumed that this was because the icmp inspection was seeing replies
>> without first seeing the corresponding requests - and sure enough, once I
>> changed the "inspect" to "pass", the pings started working.
>>
>>    This brings me back to my original question - is there a way to
>> monitor this? I miss the detailed logging on the ASA, where I can see
every
>> single packet drop (and the reason) :)
>>
>>    Thank you,
Blogs and organic groups at http://www.ccie.net
Received on Sun Feb 05 2012 - 14:51:55 ART

This archive was generated by hypermail 2.2.0 : Thu Mar 01 2012 - 11:46:56 ART