Hi Gents,
Let me jump in.
I’ve done that many times and you have two cases here:
1. Initiator is behind ASA so the connection is an Outbound connection. With
ipsec-pass-thru inspection enabled, all works without any issues. UDP is
‘inspected’ be default and ASA takes care of opening a hole for ESP.
The only issue here is when there is a Rekey from Responder. In this case you
must have a hole in Outside interface to allow that UDP traffic.
Normally, the Rekey will be initiated by Initiator because if there is not much
traffic, the rekey will be triggered by time and the time will end on Initiator
as bit sooner that on Responder.
2. If you want to initiate from Outside, then you need a hole for UDP/500.
My two cents.
Regards,
Piotr
From: Bruno Silva
Sent: Wednesday, May 23, 2012 4:09 AM
To: [email protected]
Subject: Re: [OSL | CCIE_Security] "inspect ipsec-pass-thru" seems to havebuggy
behavior
Sorry Eugene,
Guess I didn`t make myself clear on the explanation, sometimes I have this big
issue, too much thoughts in my mind and sometimes it`s hard to explain it in a
way that someone other than me can understand, let`s go again:
I have no ACL applied to the outside interface, none, and when I start traffic
from the inside it goes ok, but if I put any ACL allowing for example port 80
to a web server on the DMZ then the implicit deny takes place...otherwise it
doesn`t and the inspection engine works like a charm because it takes
precedence as it should...
Also, talking to a friend of mine, he thinks the exercise you`re doing is
trying to make you confused, because if the exercise you have asks you to put
an ACL on the outside interface and it knows about the order of operations then
asking you to add no ACL for the ESP traffic is just to make you confuse
because this will never work...
But if you think my thoughts on the reason you must add the ACL for the traffic
not being dropped are not correct, feel free to tell me, for me, again, it`s
just a matter of order of operation.
Again, this is a very good question, and if sometime you find the correct
reason for this, let us know.
BR,
Bruno
Em 22/05/2012, às 22:55, Eugene Pefti escreveu:
Hm...
Now I have to think it over again.
First question though, when you say “I tested it here without any ACL applied
to the outside interface and it works” for me it is another way to say that
there’s implicit deny ACL applied to the outside interface.
How does it work then if you don’t allow anything at all inbound on the
outside and only rely on the hole in the firewall made by the inspection engine
? Like I said, in my case the ISAKMP tunnel went up when I initiated it from
the higher security interface but the return ESP packets were dropped. It still
support the fact that Alexei mentioned earlier that there are no associated
ISAKMP states in the ASA states table even though both routers reported QM_IDLE
ACTIVE.
I didn’t try the inspection policy applied to the interface instead of global
one. I’ll try it of course but I don’t think it will have any effects because
it’s just making it prioritized over the global policy.
Eugene
From: Bruno Silva [mailto:[email protected]]
Sent: Tuesday, May 22, 2012 6:34 PM
To: [email protected]
Cc: Eugene Pefti
Subject: Re: [OSL | CCIE_Security] "inspect ipsec-pass-thru" seems to have
buggy behavior
Hi Eugene,
So as I said, so for me this seems a matter of order of operation. As I
stated before, ACLs take precedence over the MPF, of course there will not be
an ACE for the ipsec traffic once the task asked you to not use any to allow
IPSEC traffic but, once there is an ACL applied to the interface it will take
place on this traffic. Let me try to be clear on my point of view.
Even though you have MPF configured correctly and the inspection engine will
take place to allow a connection to pass from a higher to a lower secure
interface, if you have an ACL then the ACL will have preference over the
inspection engine. So having this in mind we will have:
1 - ACL
2 - MPF
So, knowing this, your specific problem is on the ACL that you already have
on the outside interface. And that, for me it`s fact, even more because I
tested it here without any ACL applied to the outside interface and it works.
Another thing is, did you try to make the ipsec-pass-thru with an acl inside
the class-map and applied it on the interface instead of globally?
BR,
Bruno Silva.
Em 22/05/2012, às 22:08, Eugene Pefti escreveu:
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]
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]> 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
visitwww.ipexpert.com
Are you a CCNP or CCIE and looking for a job? Check
outwww.PlatinumPlacement.com
_______________________________________________
For more information regarding industry leading CCIE Lab training, please
visitwww.ipexpert.com
Are you a CCNP or CCIE and looking for a job? Check
outwww.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
