Right so all http traffic other than http traffic destined to 10.20.30.40 gets inspected by the custom class correct?
On 3/23/12, Kingsley Charles <[email protected]> wrote: > It will not go to the default class because I have a permit any any in the > access-list and hence it fall into the custom class. > > With regards > Kings > > On Fri, Mar 23, 2012 at 6:40 AM, Eugene Pefti > <[email protected]>wrote: > >> And the second bullet to this question is whether any HTTP matching and >> inspection is expected in the first place by the default class as per >> Kings >> config.**** >> >> ** ** >> >> *From:* Joe Astorino [mailto:[email protected]] >> *Sent:* 22 March 2012 17:55 >> >> *To:* Piotr Kaluzny >> *Cc:* Eugene Pefti; [email protected] >> *Subject:* Re: [OSL | CCIE_Security] Application not inspected once >> deniede**** >> >> ** ** >> >> So if I am understanding you correctly, the end expected result in this >> situation is that HTTP flows to 10.20.30.40 are NOT inspected but HTTP >> flows to any other address ARE inspected? **** >> >> On Thu, Mar 22, 2012 at 5:38 PM, Piotr Kaluzny <[email protected]> >> wrote:**** >> >> Guys, >> >> "Deny" ACL entry actually matches a class. Not like with MQC (earlier I >> mentioned MPF - sorry for that, I was thinking about MQC). Then when you >> apply an action for this class in the policy, instead of enabling the >> feature (what normally happens for "permit" entries) you actually disable >> it. >> >> For example you don't want to inspect TCP 21 between host A and B as FTP >> but you want to keep inspection for all other src/dst over TCP 21 . If you >> create a class-map for this traffic and apply no action in the policy, the >> class inspection_default kicks in (with "inspect ftp") because inspection >> was NOT actually performed in user-defined class. >> >> For the class with "deny" + inspect, again the flow matches the class AND >> inspection is applied (actually being turned off), which means that other >> classes with "inspect" for this flow will not be checked (including class >> inspection_default). >> >> Hopefully makes more sense now. >> >> Regards, >> **** >> >> -- >> Piotr Kaluzny >> CCIE #25665 (Security), CCSP, CCNP >> Sr. Support Engineer - IPexpert, Inc. >> URL: http://www.IPexpert.com >> >> **** >> >> On Thu, Mar 22, 2012 at 9:44 PM, Joe Astorino <[email protected]> >> wrote:**** >> >> If both are doing action "inspect" that is the way I understood it yeah, >> but evidently I am missing something. Anxiously awaiting a response from >> somebody that knows what they are talking about more than I do haha**** >> >> ** ** >> >> On Thu, Mar 22, 2012 at 4:40 PM, Eugene Pefti <[email protected]> >> wrote:**** >> >> Oh, Christ...**** >> >> In plain old English it should have said:**** >> >> If you match the traffic for HTTP inspection in your custom class than the >> ASA will not match the same HTTP traffic in the default class.**** >> >> Correct ?**** >> >> **** >> >> *From:* Joe Astorino [mailto:[email protected]] >> *Sent:* 22 March 2012 13:31 >> *To:* Piotr Kaluzny**** >> >> >> *Cc:* Eugene Pefti; [email protected] >> *Subject:* Re: [OSL | CCIE_Security] Application not inspected once >> deniede**** >> >> **** >> >> You guys have made me go doubt myself (hate when that happens!) >> haha...here is how I understood the technology to work, based on the >> following from the 8.0 configuration guide. I take this to mean that if >> the packet matched the FIRST class map you have there matching on the ACL >> and it ALSO matched the class default policy, but the "feature type" was >> the same (inspect) that the action taken would be solely based on the >> first >> match (deny the flow in this case). What am I missing? >> >> *Feature Matching Guidelines Within a Policy Map >> >> See the following guidelines for how a packet matches class maps in a >> policy map: >> >> 1. A packet can match only one class map in the policy map for each >> feature type. >> >> 2. When the packet matches a class map for a feature type, the security >> appliance does not attempt to match it to any subsequent class maps for >> that feature type. >> >> 3. If the packet matches a subsequent class map for a different feature >> type, however, then the security appliance also applies the actions for >> the >> subsequent class map, if supported. See the "Incompatibility of Certain >> Feature Actions" section for more information about unsupported >> combinations. >> >> For example, if a packet matches a class map for connection limits, and >> also matches a class map for application inspection, then both class map >> actions are applied. >> >> If a packet matches a class map for HTTP inspection, but also matches >> another class map that includes HTTP inspection, then the second class map >> actions are not applied. * >> >> On Thu, Mar 22, 2012 at 4:27 PM, Joe Astorino <[email protected]> >> wrote: >> > This is probably a dumb question, but I don't care : ) I don't >> > understand the logic of this situation. Why should the traffic be >> > inspected if it is explicitly denied in the first class map? At first >> > glance, I would think it works as it should -- The traffic flow comes >> > in, it is denied for inspection in the first class-map. Why would it >> > pass through and be inspected by the class default? >> > >> > On Thu, Mar 22, 2012 at 4:05 PM, Piotr Kaluzny <[email protected]> >> wrote: >> >> Eugene, >> >> >> >> I don't believe "match not" is available in L3/4 class-map, at least it >> was >> >> not in older versions of code >> >> >> >> Regards, >> >> -- >> >> Piotr Kaluzny >> >> CCIE #25665 (Security), CCSP, CCNP >> >> Sr. Support Engineer - IPexpert, Inc. >> >> URL: http://www.IPexpert.com >> >> >> >> >> >> On Thu, Mar 22, 2012 at 7:48 PM, Eugene Pefti <[email protected]> >> >> wrote: >> >>> >> >>> Wouldn’t it be better to use “match not” statement in the first >> class-map >> >>> to pass it to the default inspection class ? >> >>> >> >>> >> >>> >> >>> From: Piotr Kaluzny [mailto:[email protected]] >> >>> Sent: 22 March 2012 11:43 >> >>> To: Kingsley Charles >> >>> Cc: Eugene Pefti; [email protected] >> >>> Subject: Re: [OSL | CCIE_Security] Application not inspected once >> deniede >> >>> >> >>> >> >>> >> >>> It won't hit any other class, again it is a little bit different with >> >>> "deny" in ACL than in MPF. >> >>> >> >>> The logic here is that the "deny" ACL entry actually matches the class >> as >> >>> long as an action (like e.g. inspect) is configured for this class. >> >>> The >> >>> action will not be performed, however - it turns the specified action >> off >> >>> for the flow - useful with "inspect" when you want to only allow >> passive or >> >>> active FTP, not both. >> >>> >> >>> Regards, >> >>> -- >> >>> Piotr Kaluzny >> >>> CCIE #25665 (Security), CCSP, CCNP >> >>> Sr. Support Engineer - IPexpert, Inc. >> >>> URL: http://www.IPexpert.com >> >>> >> >>> On Thu, Mar 22, 2012 at 7:04 PM, Kingsley Charles >> >>> <[email protected]> wrote: >> >>> >> >>> The denied http traffic should have been inspected by the next default >> >>> class map which is not happening. >> >>> >> >>> With regards >> >>> Kings >> >>> >> >>> >> >>> >> >>> On Thu, Mar 22, 2012 at 1:52 PM, Eugene Pefti <[email protected] >> > >> >>> wrote: >> >>> >> >>> I fear I didn't understand your question, Kings. >> >>> >> >>> Isn't what you are doing with placing the custom web class-map in >> front of >> >>> the default inspection class map to have the ASA inspection match >> first on >> >>> the traffic to 10.20.30.40. >> >>> >> >>> Or your point why HTTP is not inspected in the first place if we use >> >>> "deny" ACE? I believe we "permit" in the ACE to define the traffic >> that will >> >>> be matched and "deny" to exclude it from matching >> >>> >> >>> >> >>> >> >>> Eugene >> >>> >> >>> >> >>> >> >>> From: Kingsley Charles <[email protected]> >> >>> Date: Thu, 22 Mar 2012 12:59:24 +0530 >> >>> To: <[email protected]> >> >>> Subject: [OSL | CCIE_Security] Application not inspected once deniede >> >>> >> >>> >> >>> >> >>> Hi all >> >>> >> >>> In ASA, once if we deny the flow for inspection, it never gets >> inspected >> >>> back in other policies. In the below configuration, http traffic to >> >>> 10.20.30.40 is not inspected by the class inspection_default. >> >>> >> >>> Any comments? >> >>> >> >>> >> >>> HTTP traffic to 10.20.30.40 not inspect under class >> >>> inspection_default >> >>> >> >>> access-list web extended deny tcp any host 10.20.30.40 eq www >> >>> access-list web extended permit tcp any any eq www >> >>> >> >>> class-map web >> >>> match access-list web >> >>> >> >>> policy-map global_policy >> >>> class web >> >>> inspect http >> >>> class inspection_default >> >>> inspect dns preset_dns_map >> >>> inspect ftp >> >>> inspect h323 h225 >> >>> inspect h323 ras >> >>> inspect netbios >> >>> inspect rsh >> >>> inspect rtsp >> >>> inspect skinny >> >>> inspect esmtp >> >>> inspect sqlnet >> >>> inspect sunrpc >> >>> inspect tftp >> >>> inspect sip >> >>> inspect xdmcp >> >>> inspect http >> >>> >> >>> >> >>> >> >>> With regards >> >>> Kings >> >>> >> >>> _______________________________________________ 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 >> >>> >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 >> >>> >> >>> >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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 >> > >> > >> > >> > -- >> > Regards, >> > >> > Joe Astorino >> > CCIE #24347 >> > http://astorinonetworks.com >> > >> > "He not busy being born is busy dying" - Dylan >> >> >> >> -- >> Regards, >> >> Joe Astorino >> CCIE #24347 >> http://astorinonetworks.com >> >> "He not busy being born is busy dying" - Dylan**** >> >> >> >> >> -- >> Regards, >> >> Joe Astorino >> CCIE #24347 >> http://astorinonetworks.com >> >> "He not busy being born is busy dying" - Dylan**** >> >> ** ** >> >> >> >> >> -- >> Regards, >> >> Joe Astorino >> CCIE #24347 >> http://astorinonetworks.com >> >> "He not busy being born is busy dying" - Dylan**** >> >> _______________________________________________ >> 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 >> > -- Sent from my mobile device Regards, Joe Astorino CCIE #24347 http://astorinonetworks.com "He not busy being born is busy dying" - Dylan _______________________________________________ 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
