ASA Crypto ACLs

I am just curious if anyone knows the behavior of crypto acls (for crypto maps matching traffic for a lan-to-lan tunnel) pertaining to more specific entries. For example, I have two maps pointing to two different peers. One map matched traffic 10.0.0.0/8 -> 192.168.0.0/16 and the other map match traffic to 10.1.1.0/24 -> 192.168.1.0/24. If a packet comes in with a source of 10.1.1.100 and destination of 192.168.1.100....will the ASA send the packet over the tunnel that matches the more specific crypto ACL? Or simply the one that matches first? Based on traditional routing I would expect the more specific entry gets matched...but I have way of testing this right now. Additionally, if a packet came in with a source of 10.100.100.1 and a destination of 192.168.100.50 I would expect it to go over the tunnel with the more generic summary.

Find more posts tagged with

Comments

cpartin

I believe that the crypto map priority is what determines which path it would go. Lowest priority crypto map with an ACL that matches wins, even if it's not the most specific ACL that you have defined.

RouteMyPacket

"Two maps to two different peers"

Ok, this is completely normal and each one should have the proxy traffic identified via an ACL.

access-list vpn_to_abc permit ip 10.0.0.0 255.0.0.0 192.168.0.0 255.255.0.0

crypto map MAP1 10 set ikev1 transform-set TS1
crypto map MAP1 10 set peer 1.1.1.1
crypto map MAP1 10 match address vpn_to_abc

access-list vpn_to_xyz permit ip 10.1.1.0 255.255.255.0 192.168.1.0 255.255.255.0

crypto map MAP1 20 set ikev1 transform-set TS1
crypto map MAP1 20 set peer 2.2.2.2
crypto map MAP1 20 match address vpn_to_xyz

Now explain to me how a L2L VPN works, I have given you a detailed phase 2 configuration. So from the peer side, explain how traffic traverses the tunnel, say 192.168.2.45 -> 10.0.1.230 comes in from 1.1.1.1

What about say 10.1.1.10 -> 192.168.1.180 from 2.2.2.2...how's that work? You are confusing Routing principles with Security features of L2L, there's no need to complicate this. How does this work. I see you have a CCNA-Sec so you are on your way, walk it down, it's right there and clear as day how traffic is marked.

MikeO5422

Thanks guys, I believe I found what I was looking for after reading through some documentation.

Table 23-2 Special Meanings of Permit and Deny in Crypto Access Lists Applied to Outbound Traffic

Match criterion in an ACE containing a permit statement - Halt further evaluation of the packet against the remaining ACEs in the crypto map set, and evaluate the packet security settings against those in the transform sets assigned to the crypto map. After matching the security settings to those in a transform set, the security appliance applies the associated IPsec settings. Typically for outbound traffic, this means that it decrypts, authenticates, and routes the packet.

RouteMyPacket

MikeO5422 wrote: »

Thanks guys, I believe I found what I was looking for after reading through some documentation.

Table 23-2 Special Meanings of Permit and Deny in Crypto Access Lists Applied to Outbound Traffic

Match criterion in an ACE containing a permit statement - Halt further evaluation of the packet against the remaining ACEs in the crypto map set, and evaluate the packet security settings against those in the transform sets assigned to the crypto map. After matching the security settings to those in a transform set, the security appliance applies the associated IPsec settings. Typically for outbound traffic, this means that it decrypts, authenticates, and routes the packet.

I still don't think you understand, posting a table description is not what I was expecting after trying to help you understand. You wanted to know how crypto ACL's function. I ask again, so what are they for?

CaptainJ

RouteMyPacket, thanks for putting it to a scenario. I would guess since they are part of the same crypto map that the sequence numbers matter.
But that would mean traffic coming from peer 2.2.2.2 would never find its way back?

RouteMyPacket

CaptainJ wrote: »

RouteMyPacket, thanks for putting it to a scenario. I would guess since they are part of the same crypto map that the sequence numbers matter.
But that would mean traffic coming from peer 2.2.2.2 would never find its way back?

No, No, and just No!

If we are ASA-1 and are 1.1.1.1 and our peer is ASA-2 and is 2.2.2.2 and we have a L2L VPN between us

Behind ASA-1 we have 192.168.100.0/24 and 192.168.200.0/24, behind ASA-2 we have 10.10.100.0/24 and 10.10.200.0/24

On ASA-1 we have multiple crypto statements because say we have more than one L2L VPN coming in. So how can we ensure traffic between ASA-2's 10.10.200.0/24 network can communicate with ASA-1's LAN segments (192.168.100.x and 192.168.200.x) and vice versa?

ASA-1

access-list vpn_to_asa2 permit ip 192.168.100.0 255.255.255.0 10.10.200.0 255.255.255.0
access-list vpn_to_asa2 permit ip 192.168.200.0 255.255.255.0 10.10.200.0 255.255.255.0

crypto map MAP1 10 set ikev1 transform-set TS1
crypto map MAP1 10 set peer 2.2.2.2
crypto map MAP1 10 match address vpn_to_asa2

access-list vpn_to_abc permit ip 192.168.100.0 255.255.255.0 172.16.30.0 255.255.255.0

crypto map MAP1 20 set ikev1 transform-set TS1
crypto map MAP1 20 set peer 11.11.11.11
crypto map MAP1 20 match address vpn_to_abc

ASA-2

access-list vpn_to_asa1 permit ip 10.10.200.0 255.255.255.0 192.168.100.0 255.255.255.0
access-list vpn_to_asa1 permit ip 10.10.200.0 255.255.255.0 192.168.200.0 255.255.255.0

crypto map MAP1 10 set ikev1 transform-set TS1
crypto map MAP1 10 set peer 1.1.1.1
crypto map MAP1 10 match address vpn_to_asa1

So how is the connection made from ASA-2 to ASA-1, once traffic is initiated across the L2L destined for 192.168.100.x or 192.168.200.x then how is it handled? How does the ASA know how to handle it and allow communication?