Hi Marta, Yes, the Command Reference description makes much more sense! it's funny that the other description is in the "revised" config-guide:) I have tested the ICMP Timestamp Reply and it is allowed. Below is the debug output:
*Mar 11 06:08:22.067: FIREWALL: ICMP Timestamp pkt 136.1.121.100 => 136.1.122.6 *Mar 11 06:08:22.067: FIREWALL* OBJ_CREATE: Pak 67353330 sis 67C50124 initiator_addr (136.1.121.100:13) responder_addr (136.1.122.6:0) initiator_alt_addr (136.1.121.100:13) responder_alt_addr (136.1.122.6:0) *Mar 11 06:08:22.067: FIREWALL icmp_info created: 0x67681CD8 *Mar 11 06:08:22.067: FIREWALL OBJ-CREATE: sid 67A0613C acl deny-any Prot: icmp *Mar 11 06:08:22.067: Src 136.1.122.6 Port [0:0] *Mar 11 06:08:22.067: Dst 136.1.121.100 Port [14:14] *Mar 11 06:08:22.067: FIREWALL OBJ-CREATE: sid 67A06190 acl deny-any Prot: icmp *Mar 11 06:08:22.067: Src 0.0.0.0 Port [0:0] *Mar 11 06:08:22.067: Dst 136.1.121.100 Port [3:3] *Mar 11 06:08:22.067: FIREWALL OBJ-CREATE: sid 67A061E4 acl deny-any Prot: icmp *Mar 11 06:08:22.067: Src 0.0.0.0 Port [0:0] *Mar 11 06:08:22.067: Dst 136.1.121.100 Port [11:11] *Mar 11 06:08:22.067: FIREWALL: ICMP Timestamp Reply pkt 136.1.122.6 => 136.1.121.100 Thanks! Oszkar On Sat, Mar 10, 2012 at 11:41 AM, Marta Sokolowska < [email protected]> wrote: > To be honest I'm a little bit surprised by CBAC Configuration Guide > statement. ICMP Inspection description in "ip inspect name" in Cisco IOS > Security Command Reference seems to be more accurate: > * > ICMP inspection sessions are done on the basis of the source address of > the inside host that originates the ICMP packet. Dynamic ACLs are created > for return ICMP packets of the allowed types (echo-reply,destination > unreachable, time-exceeded, and timestamp reply) for each session. No port > numbers associated with an ICMP session, and the permitted IP address of > the return packet is a wild-card in the ACL. The wildcard address is > because the IP address of the return packet cannot be known in advance for > time-exceeded and destination-unreachable replies. These replies can come > from intermediate devices rather than the intended destination.* > > The description above matches your observation. In the debus you can see > that ICMP inspection creates opening hole not only for ICMP Echo Reply > (Type 0/Code 0): > > > *Mar 10 07:16:41.350: Src 136.1.122.6 Port [0:0] > *Mar 10 07:16:41.350: *Dst 136.1.121.100 Port [0:0]* > > but also for ICMP Port Unreachable (Type 3/Code 3): > > > *Mar 10 07:16:41.350: Src 0.0.0.0 Port [0:0] > *Mar 10 07:16:41.350: *Dst 136.1.121.100 Port [3:3]* > > and for ICMP Time Exceeded (Type 11): > > > *Mar 10 07:16:41.350: Src 0.0.0.0 Port [0:0] > *Mar 10 07:16:41.350: *Dst 136.1.121.100 Port [11:11]* > > Those last two ICMP messages are used for traceroute functionality and > that's why tracroute works then you turn on UDP inspection. In addition, > like the "ip inspect name" description says, source address for returning > packet is "any", which appears in the debug as "Src 0.0.0.0". > > The only thing I'm not sure about (based on "ip inspect name" description) > is allowing ICMP Timestamp Reply (Type 14) - I didn't find any information > proving that. > > Marta Sokolowska. > > > 2012/3/10 Imre Oszkar <[email protected]> > > Hi Guys, >> >> I think cisco doc is wrong on this one, can somebody please comment it? >> >> " ICMP traffic is not inspected by CBAC, meaning specific entries are >> needed in the access list to permit return traffic for ICMP commands." >> >> >> http://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_cbac_fw/configuration/12-4t/config-cbac-fw.html#GUID-34DF258E-A125-40B9-A451-CC8617B1DD1D >> >> I have the following config: >> >> ip inspect name inspection icmp >> ip access-list extended deny-any >> deny ip any any log >> >> interface FastEthernet0/1 >> ip address 136.1.121.5 255.255.255.0 >> ip inspect inspection in >> >> interface FastEthernet0/0 >> ip address 136.1.122.5 255.255.255.0 >> ip access-group deny-any in >> >> I have a PC on the 136.1.121.0/24 network and I'm able to >> ping/traceroute hosts on 136.1.122.0/24 network. >> If I enable the udp inspection unix style traceroute works as well. >> >> debug: >> >> icmp echo: >> >> *Mar 10 07:16:41.350: FIREWALL* OBJ_CREATE: Pak 6751B5F0 sis 67E17334 >> initiator_addr (136.1.121.100:8) responder_addr (136.1.122.6:0) >> initiator_alt_addr (136.1.121.100:8) responder_alt_addr (136.1.122.6:0) >> *Mar 10 07:16:41.350: FIREWALL icmp_info created: 0x67849F80 >> *Mar 10 07:16:41.350: FIREWALL OBJ-CREATE: sid 67BCE204 acl deny-any >> Prot: icmp >> *Mar 10 07:16:41.350: Src 136.1.122.6 Port [0:0] >> *Mar 10 07:16:41.350: Dst 136.1.121.100 Port [0:0] >> *Mar 10 07:16:41.350: FIREWALL OBJ-CREATE: sid 67BCE258 acl deny-any >> Prot: icmp >> *Mar 10 07:16:41.350: Src 0.0.0.0 Port [0:0] >> *Mar 10 07:16:41.350: Dst 136.1.121.100 Port [3:3] >> *Mar 10 07:16:41.350: FIREWALL OBJ-CREATE: sid 67BCE300 acl deny-any >> Prot: icmp >> *Mar 10 07:16:41.350: Src 0.0.0.0 Port [0:0] >> *Mar 10 07:16:41.350: Dst 136.1.121.100 Port [11:11] >> >> >> >> Thanks, >> Oszkar >> >> >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
