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] 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 Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
