05-26-2010 03:29 AM
Hi,
I have a hub and spoke IPSec VPN using a Cisco ASA as the Hub and a PIX506e as the one of the spokes.
Two of the spokes also have an IPSec VPN between themselves.
The hub site connects back to a WAN.
The two spoke sites have the following ranges
Spoke 1 = 10.154.10.0/24
Spoke 2 = 10.156.10.0/24
Hub site = 10.8.0.0/24 - But also conects to all other addresses in the 10.0.0.0/8 range with a back end WAN connection.
I was looking for a "nice" way to configure the crypto acl's so that traffic between spoke 1 and 2 would go direct and then everything else starting 10 would go via the hub site. Rather than trying to specify all subnets in 10.0.0.0/8 except 10.156.10.0/24 & 10.154.10.0/24 in an ACL.
If I order the crypto maps on the spoke so the most specific is first (e.g. the spoke to spoke map) and then have a crypto map for 10.0.0.0/8 for the hub second, would that work?
So for Spoke 1 we have.
!
access-list to-spoke-2 permit ip 10.154.10.0 255.255.255.0 10.156.10.0 255.255.255.0
access-list to-hub permit ip 10.154.10.0 255.255.255.0 10.0.0.0 255.0.0.0
!
crypto map outside_map 100 ipsec-isakmp
crypto map outside_map 100 match address to-spoke-2
crypto map outside_map 100 set peer 1.2.3.4
crypto map outside_map 100 set transform-set standard
crypto map outside_map 200 ipsec-isakmp
crypto map outside_map 200 match address to-hub
crypto map outside_map 200 set peer 8.9.10.11
crypto map outside_map 200 set transform-set standard
!
Any thoughts?
Solved! Go to Solution.
05-26-2010 03:58 AM
Yes, deny statement is absolutely supported. Good one... i forgot about "deny" crypto ACL
05-26-2010 03:40 AM
Unfortunately that is not a supported configuration. Each crypto subnet needs to be unique. If there is any overlapping subnet, you would need to NAT those subnets.
In saying that, crypto map is checked from the lowest sequence to the highest sequence number (top to bottom), in your example: from sequence 100 then sequence 200. In normal perfect scenario, if you have the more specific subnet on the lower sequence (100), and the HUB (broader subnet) on the higher sequence (200), then it would match subnet 10.156.10.0 first and creates SA on the first peer: 1.2.3.4. However, if for whatever reason, peer 1.2.3.4 is down, and tunnel is not established, then it will try to match the 2nd peer - 8.9.10.11 and since the subnet matches (as it falls under the broad class-A 10.0.0.0/8), it will build an SA on that 2nd peer instead. This is incorrect as that is not what you want as traffic has been routed incorrectly to another peer.
As advised, in normal perfect scenario, it should work, however, when peer 1 breaks, you will have problem.
Hope that answers your question.
05-26-2010 03:52 AM
Thanks for the great response.What if i put a deny on the "to-hub" ACL for the spoke-to-spoke subnets?
Something like this?
!
access-list to-spoke-2 permit ip 10.154.10.0 255.255.255.0 10.156.10.0 255.255.255.0
access-list to-hub deny ip 10.154.10.0 255.255.255.0 10.156.10.0 255.255.255.0
access-list to-hub permit ip 10.154.10.0 255.255.255.0 10.0.0.0 255.0.0.0
!
crypto map outside_map 100 ipsec-isakmp
crypto map outside_map 100 match address to-spoke-2
crypto map outside_map 100 set peer 1.2.3.4
crypto map outside_map 100 set transform-set standard
crypto map outside_map 200 ipsec-isakmp
crypto map outside_map 200 match address to-hub
crypto map outside_map 200 set peer 8.9.10.11
crypto map outside_map 200 set transform-set standard
!
05-26-2010 03:58 AM
Yes, deny statement is absolutely supported. Good one... i forgot about "deny" crypto ACL
05-26-2010 06:34 AM
Dear halijenn,
that's suprising to me, can you confirm:
halijenn wrote:
Unfortunately that is not a supported configuration. Each crypto subnet needs to be unique. If there is any overlapping subnet, you would need to NAT those subnets.
In saying that, crypto map is checked from the lowest sequence to the highest sequence number (top to bottom), in your example: from sequence 100 then sequence 200. In normal perfect scenario, if you have the more specific subnet on the lower sequence (100), and the HUB (broader subnet) on the higher sequence (200), then it would match subnet 10.156.10.0 first and creates SA on the first peer: 1.2.3.4. However, if for whatever reason, peer 1.2.3.4 is down, and tunnel is not established, then it will try to match the 2nd peer - 8.9.10.11 and since the subnet matches (as it falls under the broad class-A 10.0.0.0/8), it will build an SA on that 2nd peer instead. This is incorrect as that is not what you want as traffic has been routed incorrectly to another peer.
As advised, in normal perfect scenario, it should work, however, when peer 1 breaks, you will have problem.
Hope that answers your question.
Are you saying: if a packet, which matches the acl of a crypto map entry triggers a negotiation for an IPsec SA and the configured peer of that crypto map entry does not respond then the crypto map processes the next crypto map entry? I only know of trying backup peers within the same crypto map entry and if none of them replies the packet will be discarded after getting stale in packet queue (debug crypto engine -> "packet could not be encrypted" or something similar). Further crypto map entries are not evaluated.
Let's think this to an end: what happens if the last crypto map entry where the acl matches was processed an none of the peers responded? Do you think the packet will be sent in clear?
In the sample config given, the two peers are configured for different crypto map entries (sequence number 100 resp. 200).
Just wondering,
MiKa
05-26-2010 07:12 AM
Hi,
If you have the same interesting traffic (same network on the crypto ACL) applied on several ACLs to
different peers, then it will try to find a match.
That's why the recommendation is to have unique entries in the crypto ACLs.
I've only seen packets sent in the clear when the crypto ACLs on a site-to-site tunnel won't match.
You will get an error ''packet should have been encrypted but no match'' or something like that.
If a device is expecting a packet to be encrypted but it received that packet in clear text I believe
it drop it.
However, I will let halijeen answer your questions (just posting what i've seen)
Federico.
05-26-2010 08:16 AM
Hi Federico
that would be indeed quite unsusual for sequenced policies within Cisco IOS. All cases I've seen have a simple rule:
Process the map top-down, first match decides, other entries are ignored.
So what you describe would look like:
+-----------------+
| first crypt map |
| entry |
+-----------------+
|
| +-------------------+
| | |
V V Yes
+---------------+ +-------------+
| ACL matches ? | No-> | next crypto |
+---------------+ | map entry? |
Yes +-------------+
| ^ last
V | entry
+---------------+ | |
| SA to peer | No------+ |
| success? | V
+---------------+ +------------------+
Yes | discard packet |
| | if there was a |
V | match, send in |
+---------------+ | clear if nothing |
| Send through | | matched |
| IPsec SA | +------------------+
+---------------+
That would be odd, I don't see anything in the documentation of crypto maps that would explain such a flow chart.
I always understood crypto maps to work like this:
+--------------+
| first crypto |
| map entry |
+--------------+
|
| +-------------------+
| | |
V V Yes
+---------------+ +-------------+
| ACL matches ? | No-> | next crypto |
+---------------+ | map entry? |
Yes +-------------+
| last entry
V |
+---------------+ V
| SA to peer | +-------------+
| success? | | send in |
+---------------+ | clear |
Yes No +-------------+
| |
| +---------+
V |
+---------------+ V
| Send through | +----------------+
| IPsec SA | | discard packet |
+---------------+ +----------------+
Please correct me if I'm wrong and please supply some link or descriptions, maybe I didn't get the whole picture.
Regds, MiKa
05-27-2010 03:50 AM
What I'm saying is this:
Let's say you have the following configuration
access-list vpn1 permit ip 192.168.1.0 255.255.255.0 10.0.0.0 255.0.0.0
crypto map mymap 10 match address vpn1
crypto map mymap 10 set peer x.x.x.x
access-list vpn2 permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0
crypto map mymap 20 match address vpn2
crypto map mymap 20 set peer y.y.y.y
In the above example, what happen if you intend to send a packet to a host on the 10.1.1.x?
The ASA will start checking the crypto map statements in sequential order.
So, since the traffic will match the vpn1 ACL, it will attempt to send the traffic to peer x.x.x.x, even though, you want to send that traffic to peer y.y.y.y
In other words, it does not matter that you have an specific ACL for the interesting traffic in a crypto map instance.... if you have a more general statement in a crypto map instance which has a lower ID number, then the traffic will be sent there (assuming that can establish that tunne).
So, we're talking about the same crypto map with different IDs (different tunnels).
This is why the ACLs for VPN have to be unique.
Federico.
05-27-2010 05:53 AM
Hi Federico,
My point was to have the more specific crypto map entry on the top, you hve the more specific at the bottom:
coto.fusionet wrote:
access-list vpn1 permit ip 192.168.1.0 255.255.255.0 10.0.0.0 255.0.0.0
crypto map mymap 10 match address vpn1
crypto map mymap 10 set peer x.x.x.x
access-list vpn2 permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0
crypto map mymap 20 match address vpn2
crypto map mymap 20 set peer y.y.y.y
swap the sequence numbers of the crypto map entries and it should work like intended
05-27-2010 05:24 AM
Actually, your argument is right. If the more specific crypto ACL entry is on the lower sequence, then even if it doesn't establish the SA, it should not go to the next sequence. Only when the lower sequence crypto ACL has broader subnet while you want to encrypt traffic to a more specific subnet like what Federico said, you will have issue. However, with deny crypto ACL statement, it will go to the next crypto map sequence to find a match. If there is no matching crypto ACL then it will be sent as clear text.
05-27-2010 05:57 AM
Thanks halijenn for clearing that
Serotonin's original proposal should work just perfectly:
So for Spoke 1 we have.
!
access-list to-spoke-2 permit ip 10.154.10.0 255.255.255.0 10.156.10.0 255.255.255.0
access-list to-hub permit ip 10.154.10.0 255.255.255.0 10.0.0.0 255.0.0.0
!
crypto map outside_map 100 ipsec-isakmp
crypto map outside_map 100 match address to-spoke-2
crypto map outside_map 100 set peer 1.2.3.4
crypto map outside_map 100 set transform-set standard
crypto map outside_map 200 ipsec-isakmp
crypto map outside_map 200 match address to-hub
crypto map outside_map 200 set peer 8.9.10.11
crypto map outside_map 200 set transform-set standard
!
Any thoughts?
Rgds, MiKa
05-27-2010 06:07 AM
Yes, it should work just perfectly in theory. But with software, sometimes you can unintentionally hit a bug.
I would still recommend non overlapping crypto ACL to be on the safest side, OR/ alternatively, the broadest subnet should be on the highest sequence number and preferably with deny crypto ACL statements, denying those overlapped subnets.
06-03-2010 12:04 AM
Thank you to everyone who helped on this question. I really appreciate your time.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide