cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3334
Views
5
Helpful
12
Replies

Crypto ACL Question

serotonin888
Level 1
Level 1

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?

1 Accepted Solution

Accepted Solutions

Yes, deny statement is absolutely supported. Good one... i forgot about "deny" crypto ACL

View solution in original post

12 Replies 12

Jennifer Halim
Cisco Employee
Cisco Employee

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.

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

!

Yes, deny statement is absolutely supported. Good one... i forgot about "deny" crypto ACL

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

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.

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

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.

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

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.

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

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.

Thank you to everyone who helped on this question. I really appreciate your time.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: