You are very welcome, Bruno, with all your thoughts ;) Now I feel like an idiot and believe I have to start with CCNA.... The task question is indeed tricky and it assumed that there are already other ACE on the outside interface, e.g. I have to do application inspection for a Web traffic and allow two BGP speakers to talk through ASA hence I already have an ACL. I deleted the ACL and as you are saying it started working but my BGP speakers lost each other ;) But I wish some explains me the difference between not having the ACL at all on the outside interface and having an ACL with an active MPF rule. Don't we have an implicit deny for ISAKMP traffic in both cases ?
Eugene From: Bruno Silva [mailto:[email protected]] Sent: Tuesday, May 22, 2012 7:10 PM To: [email protected] Cc: Eugene Pefti Subject: Re: [OSL | CCIE_Security] "inspect ipsec-pass-thru" seems to have buggy 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]<mailto:[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]<mailto:[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 visitwww.ipexpert.com<http://www.ipexpert.com/> Are you a CCNP or CCIE and looking for a job? Check outwww.PlatinumPlacement.com<http://www.PlatinumPlacement.com/> _______________________________________________ For more information regarding industry leading CCIE Lab training, please visitwww.ipexpert.com<http://www.ipexpert.com> Are you a CCNP or CCIE and looking for a job? Check outwww.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
