Hi Bruno, Thanks for your willingness to help. I didn't present the full config of the firewall in question saving time and space here. Of course there were ACE on the outside interface but they didn't have anything to do with IPSec traffic, just regular web and other standard traffic. The task explicitly asked not to add any ACL to the outside interface to allow IPSec traffic and this is how we ended up with "inspect ipsec-pass-through" rule in the global policy.
Eugene From: Bruno Silva [mailto:[email protected]] Sent: Tuesday, May 22, 2012 4:05 PM To: [email protected] Cc: Eugene Pefti Subject: Re: [OSL | CCIE_Security] "inspect ipsec-pass-thru" seems to have buggy behavior Hello Eugene, I`m trying to understand something here so forgive me if I missed something. You said you configured ipsec pass-thru correctly and even posted your configurations for us to analyze but, for the exercise you`re doing, do you have any other access-list configured on the outside interface for other traffic? To make my assumption clear, if you have any access-list previously configured for your outside interface, this is just a matter of "order of operation", because access-list comes first against MPF, so if you have any access-list applied to your interface the inspection engine will begin to work AFTER your traffic comes back and hits the ACL, what for me is what`s going on here. Hope it helps. BR, Bruno Silva. Em 22/05/2012, às 08:46, Alexei Monastyrnyi escreveu: Eugene, it does not go as deep as inspecting tunnel SAs. As per command line reference "The inspect ipsec-pass-thru command enables or disables application inspection. IPSec Pass Through application inspection provides convenient traversal of ESP (IP protocol 50) and/or AH (IP protocol 51) traffic associated with an IKE UDP port 500 connection." It does sound confusing because it doesn't do inspection the way we are used to it. I think it just means literally: - if I have UDP outside IP_ADDR_1:500 inside IP_ADDR_2:500 ... in my connections table and - if I have inspect ipsec-pass-thou in my policy-map applied either globally or on the interface then - I pass ESP/AH inbound from less secure interface to more secure interface. Cheers A. On 5/22/2012 7:33 AM, Eugene Pefti wrote: Thanks, Alexei and Kings, Yeah, permitting UDP 500 on the outside-inbound ACL made the trick. I remember doing it as well and it didn't work for me initially because as I realize it now there is a condition which slipped my mind. E.g. 1) I add "permit udp any any eq 500" to the outside ACL on the ASA while R1 and R6 have an active ISAKMP tunnel (QM_IDLE ACTIVE). Sending ICMP from R1 to R6 - no luck, the ASA still spits "Deny protocol 50 src outside" on the console and there's one way connection entry in the state table ESP outside 6.6.6.6 inside 1.1.1.1, idle 0:00:06, bytes 540 2) I clear the crypto session between routers and then initiate a new ICMP traffic between R1 and R6. This time it works and the ASA connections table contains both UDP500 and ESP states ESP outside 6.6.6.6 inside 1.1.1.1, idle 0:00:41, bytes 432 ESP outside 6.6.6.6 inside 1.1.1.1, idle 0:01:03, bytes 0 UDP outside 6.6.6.6:500 inside 1.1.1.1:500, idle 0:00:41, bytes 1628, flags - ESP outside 6.6.6.6 inside 1.1.1.1, idle 0:00:41, bytes 432 ESP outside 0.0.0.0 inside 0.0.0.0, idle 0:01:03, bytes 0 For me it means that the ASA keeps track of some connections parameters and it didn't allow the tunnelled traffic until I made routers build a new tunnel. I wonder what those parameters are? Tunnel SAs or something else ? Eugene From: Kingsley Charles [mailto:[email protected]] Sent: Sunday, May 20, 2012 11:30 PM To: Eugene Pefti Cc: [email protected]<mailto:[email protected]> Subject: Re: [OSL | CCIE_Security] "inspect ipsec-pass-thru" seems to have buggy behavior Addd an inbound acl permitting udp 500. With regards Kings On Mon, May 21, 2012 at 2:59 AM, Eugene Pefti <[email protected]<mailto:[email protected]>> wrote: Hello guys, I kindly ask for your fresh pair of eyes to help me understand what's wrong with IPSec traffic traversing the ASA. The setup is trivial: (1.1.1.1 - loopback0) R1 ----(inside)---- ASA ----- (outside) ------ R6 (6.6.6.6 - loopback0) The task asks to configure a tunnel between R1 and R6 but the specific requirement is not to use any ACL on ASA to allow IPSec. Ok, I did everything that is required and I assume the solution should work when the traffic is originated from R1 to R6 providing I have a static mapping on ASA and "inspect ipsec-pass-thru" in the global policy. Static (inside,outside) 1.1.1.1 1.1.1.1 policy-map global_policy class inspection_default inspect ipsec-pass-through Then an interesting things are observed. I originate ICMP traffic from R1 sourcing it from loopback0, the tunnel comes up (at least I see QM_IDLE on both routers in the ACTIVE state) I'm seeing that R6 sends ICMP replies to R1 loopback0 sourcing them from loopback0 as well while I debug ICMP. But the ASA reports the following: %ASA-4-106023: Deny protocol 50 src outside:6.6.6.6 dst inside:1.1.1.1 by access-group "OUTSIDE-INBOUND" [0x0, 0x0] Which absolutely doesn't make sense as there's "ipsec-pass-through" inspection configured. Note that it doesn't work (counters are 0) ASA1(config)# sh service-policy global inspect ipsec-pass-thru Global policy: Service-policy: global_policy Class-map: inspection_default Inspect: ipsec-pass-thru _default_ipsec_passthru_map, packet 0, drop 0, reset-drop 0 Then goes the most interesting part. I temporarily allow ESP traffic on ASA outside interface with an ACL access-list OUTSIDE-INBOUND extended permit esp any any And of course the traffic between routers loopback starts flowing flawlessly. Then I remove the above said ACL. Pings still are being exchanged between R1 and R6. Then I clear the crypto session on both routers and start sending pings again. This time it works without an ACL and what is the most important this time is that the IPSec inspection starts working as well (see counters for the corresponding inspection policy, I had them highlighted in red) ASA1(config)# sh service-policy global inspect ipsec-pass-thru Global policy: Service-policy: global_policy Class-map: inspection_default Inspect: ipsec-pass-thru _default_ipsec_passthru_map, packet 12, drop 0, reset-drop 0 Can some please explain me why the ASA acts like that ? Why doesn't the "inspect ipsec-pass-through" rule kicks in in the first place? Eugene _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com<http://www.ipexpert.com/> Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com<http://www.PlatinumPlacement.com/> _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com<http://www.ipexpert.com> Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com<http://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
