Eugene,
I have just got an opinion from Cisco Security TAC engineer.
"Yes, this 'inspection' will only 'permit' ESP or AH traffic, if an
existing ISAKMP connection already exists between the two peers. One
use case for this is if you want to permit an 'inside' device to
initiate the tunnel, and then upon rekey, allow the outside device to
initiate a rekey. In this case, all you would need to permit is ISAKMP
outbound, and the ESP/AH flows would be allowed back through for those
peers (whether they are NATed or not).
Besides permitting the ESP/AH flows based on pre-existing ISAKMP tunnel
between those two peers, there is no additional security provided by
inspecting the ipsec-pass-thru traffic."
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]
*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
