if you are trying to use acls, you should have two class maps. the first to match the protocols you want to inspect, and the second to match an acl.
ip access-list extended inside_outside permit icmp any any eq echo permit udp any any eq 53 permit tcp any any eq 23 class-map type inspect match-any cm_protocols match protocol ftp match protocol icmp match protocol http match protocol tcp match protocol udp class-map type inspect match-all cm_inside_outside match class cm_protocols match access-group name inside_outside policy-map type inspect pm_inside_outside class cm_inside_outside inspect the first classmap is for instructing the router to inspect the defined protocols, you could just specify tcp, udp and icmp, but then you do not get the l7 inspection capabilities of some protocols. The second class map must match both the acl, and one of the predefined protocols in the first class-map. If you only match against an acl, then it will not be statefull. You must inspect a protocol to make it statefull.For instance, if you did not specify to match the ftp protocol but allowed port 21, the router would have no idea about the data connections initiated through the control channel. Jimmy Larsson wrote: > > Hi > > I am trying some zone based firewall configurations am getting > confused. My background is that I am very familiar with Pix/ASA and > not very familiar at all with the Firewall-features of IOS. Therefore > I always compare these which gets me confused. > > Now I´ve done a simple 2-zone firewall out of my 3-legged router. My > goal is this: > * Allow all outbound telnet stateful > * Allow all icmp-echos initiated from inside (and ofcourse the > corresponding echo replies) > * Deny everything else between the zones. > > I have configured the two zones and a policy-map that inspects and > allows my outbound telnet. It looks like this: > > > > class-map type inspect match-any class-INSIDE-TO-OUTSIDE > match protocol telnet > ! > ! > policy-map type inspect policy-INSIDE-TO-OUTSIDE > class type inspect class-INSIDE-TO-OUTSIDE > inspect > class class-default > drop > ! > zone security OUTSIDE > zone security INSIDE > zone-pair security INSIDE-TO-OUTSIDE source INSIDE destination OUTSIDE > service-policy type inspect policy-INSIDE-TO-OUTSIDE > > > interface FastEthernet0 > description Outside > zone-member security OUTSIDE > ! > interface FastEthernet1 > description Inside > zone-member security INSIDE > ! > interface Vlan13 > zone-member security INSIDE > ! > > So, now I can telnet from outside to telnet. But what about the > icmp:s? My idea was to create a class-map referring to an acl that > defines non-stateful outbound-traffic that should be allowed. > Something like this: > > ip access-list extended acl-INSIDE-TO-OUTSIDE-no-inspect > permit icmp any any eq echo > > class-map class-INSIDE-TO-OUTSIDE-no-inspect > match access-group acl-INSIDE-TO-OUTSIDE-no-inspect > > But when trying to apply this to my policy-map (my goal was to do > "pass"-action on this) I get this error: > r1(config-pmap)#class class-INSIDE-TO-OUTSIDE-no-inspect > % class class-INSIDE-TO-OUTSIDE-no-inspect of type default is not > allowed in policy-map policy-INSIDE-TO-OUTSIDE of type inspect > > In what way am I thinking wrong here? > > Also, in my scenario, how should my interface acl:s look like when > doing this zone-thing? Since traffic between zones are blocked by > default and traffic inside a zone is permitted, I guess that I > should´nt have any interface acl:s since all transit traffic security > is taken care of by the zone-configuration. Right? Can there be any > situation where interface acl:s are needed when doing ZBFW? > > Thanks in advance! > -- > ------- > Jimmy Larsson > Ryavagen 173 > s-26030 Vallakra > Sweden > http://blogg.kvistofta.nu > ------- > ------------------------------------------------------------------------ > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
