Which crypto policy should be connected with which tunnel-group in ASA ?

Hi Expert, When there are two or more than two L2L vpn in ASA, Which crypto policy should be associated with which tunnel-group ? It took a little long time for me to think about the issue. But now I am still confused about the issue. Anyone can give me suggestion ? Thank you
eemoonAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

btanExec ConsultantCommented:
Crypto maps are the instructions for how the VPN work. They include encryption, hashing, who their talking to and what access-list rules to use. After that you define tunnel-group attributes which are the pre-shared key if one is used.

So I do see it depends first on crypto map priority number, then to ACL in the list of matched tunnel-group esp if both (or multiple) tunnels catch the same source scope. Eventually the tunnel-group for phase 1 & phase 2 must still match exactly for both ends before tunnel can be up. If none matches, the default is used for either LAN or remote.

For info - Verify that ACLs are Correct and Binded to Crypto Map
•If you have multiple VPN tunnels and multiple crypto ACLs, make sure that those ACLs do not overlap.

Note: On VPN concentrator, you might see a log like this:

Tunnel Rejected: IKE peer does not match remote peer as defined in L2L policy

In order to avoid this message and in order to bring the tunnel up, make sure that the crypto ACLs do not overlap and the same interesting traffic is not used by any other configured VPN tunnel.

•Do not use ACLs twice. Even if your NAT Exemption ACL and crypto ACL specify the same traffic, use two different access lists.
http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/81824-common-ipsec-trouble.html#solution14
0
arnoldCommented:
Only a remote VPN  can share a crypto map with multiple users using xauth to authenticate each user separately.

Each VPN l2L has to be uniquely matched to avoid a connecting VPn from being denied on one end and being established by kicking the established VPN.

If you would specify what context you are talking,
0
eemoonAuthor Commented:
Thank you so much for your reply.
If there are two VPN(l2l) in one ASA, the ASA must have two tunnel-groups. The two tunnel-groups can share one crypto policy ? In another word, there is only one crypto policy in the ASA. The crypto policy can be used for the two tunnel-groups ?
0
The IT Degree for Career Advancement

Earn your B.S. in Network Operations and Security and become a network and IT security expert. This WGU degree program curriculum was designed with tech-savvy, self-motivated students in mind – allowing you to use your technical expertise, to address real-world business problems.

arnoldCommented:
No, each VPN has to have its own crypto policy if not mistaken peer address is part of the crypto policy.
You can have every crypto policy have the same phase 1 and phase 2 references encryption (though preshared should be unique) you could have them use the same one, with the peer address as the differentiator.

Could you provide detail on what it is you are looking to do so that I can understand the full picture.
Do you have two VPNs but only one needs to be established at a time, I.e. You have. Two feeds and your VPN is either going out over the preferred path, or via secondary.
0
eemoonAuthor Commented:
We have one failover ASA. There are a lot crypto policy and also a lot tunnel-group in the ASA. I want to know which cryptp policy should be associated with which tunnel-group. Whether one crypto policy can be shared by several tunnel-groups? That is why I gave an example above to try to understand what relation they have. My final goal is try to clear all crypto policy and tunnel-group relation and migrate these VPN from one ASA to another.

For one VPN, we can know one crypto map can be associated with what peer, what ACL and what crypto ipsec. but we cannot know which crypto policy are associated with the crypto map.
0
arnoldCommented:
What do you mean, "you have one failover ASA"?
If you have an HA Pair one active. Other is dormant, the VPN is only active on the active?



As I asked, could your provide as much detail on your setup and what it is you are looking to be answered?
0
eemoonAuthor Commented:
Sorry, I should not have mentioned failover ASA. I do not have any failover ASA issue.

My question is whether one crypto policy can be shared by several tunnel-groups. Thank you
0
arnoldCommented:
Please provide context to what it is you are talking about with an example using

Each crypto/tunnel-group re unique identifier of the peer that will be completing the VPN connection.
It sounds as though having a need for 10 L2L VPNs you want to minimize as much as possible the configuration to have all 10 functional through the reuse of crypto maps, and/or tunnel-groups., correct?

Often as was referenced in the initial response, you should use unique references for each VPN.

This requirement is in place to avoid having to grant one location additional access that is then extended to all because you are using a common access-list, etc.
0
eemoonAuthor Commented:
Each VPN has to have its one tunnel-group and its one crypto map. It looks like that several VPN can share one crypto policy. If there  are several crypto policy in the ASA, how can we know which crypto map is associated with which crypto policy ? Please see example below.

The below two crypto policy have their own number, one is 1 and another is 10. How can crypto map know which crypto policy is associated with the crypto map ?

crypto map can be associated with crypto ipsec, peer, tunnel-group and ACL through their own name or number. but crypto policy' number is not associated with crypto map. So it looks like that crypto policy do not have direct relation with crypto map. That is why we do not know which crypto policy is associated with the crypto map, right ? Thank you


----------------------
crypto ikev1 policy 1

 authentication pre-share

 encryption 3des

 hash md5

 group 2

 lifetime 28800

crypto ikev1 policy 10

 authentication pre-share

 encryption 3des

 hash sha

 group 2

 lifetime 86400
0
arnoldCommented:
They differ through negotiation one is 3des hash md5 while the other is 3des hash sha
If you look within the VPN, one will reference 1 while another will have a reference to 10
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
btanExec ConsultantCommented:
the only constraint specific to only one crypto map is to one interface only.
You can assign only one crypto map set to an interface. If multiple crypto map entries have the same map-name but a different seq-num, they are part of the same set and are all applied to the interface. The adaptive security appliance evaluates the crypto map entry with the lowest seq-num first.

The adaptive security appliance lets you change crypto map, dynamic map, and ipsec settings on the fly. If you do so, the adaptive security appliance brings down only the connections affected by the change. If you change an existing access-list associated with a crypto map, specifically by deleting an entry within the access-list, the result is that only the associated connection is brought down. Connections based on other entries in the access-list are not affected.

Every static crypto map must define three parts: an access list, a transform set, and an IPsec peer. If one of these is missing, the crypto map is incomplete and the adaptive security appliance moves on to the next entry. However, if the crypto map matches on the access-list but not on either or both of the other two requirements, this adaptive security appliance drops the traffic.
0
eemoonAuthor Commented:
Thank you for discussing with me. A friend has a answer. I would like to share the answer with  you.

These are phase 1 policies, they work from top to bottom.  When you try to negotiate the tunnel between two peers, in the background they send you all your policies and whichever matches first (top to bottom) is used.

For eg.

If your peer device is using (3des, md5, pre-share and group 2), it will match policy 1 and rest of the policies will not be checked.

That also means that several tunnel-groups can share one crypto policy as long as other endpoints' crypto policy can match the common crypto policy in this side ASA
0
arnoldCommented:
i am still at. Loss on what it is you are after.
Try this.  There are five individuals. Each has a set of Papers, one indicates the languages the person can speak. The second the topic on which a person can or wants to talk. The stuff written on each paper is in the respective languages..

I.e. First establishing a common language I important. (This deals with the phase one negotiating a secure channel.
Second temp I then matches the other set of data.

In a VPN context authorization is part of the multi-level negotiation.

The two steps having matched the first phase mismatch on the sevond will issue a no available sa error.

We are likely circling the

Are you looking to setup a broad range of crypto-maps, and the. An assortment of tunnel-groups as to avoid having a specific setup/settings for site a to site B, site a to site c, site c to sure b etc.
0
btanExec ConsultantCommented:
eventually if you are looking at which crypto map (closest) to match, it is the phase 1 (SA exchange params) to be matched and peer to be authenticated at both end based on ACL. It all in the primer for vpn/IPsec (if that is really the interest). You can try out to "show crypto ipsec sa" to shows status of IPsec SAs to know which is active
"https://supportforums.cisco.com/document/12013476/crypto-map-based-ipsec-vpn-fundamentals-negotiation-and-configuration

The number after the crypto map statement is just the sequence number that identifies one crypto map from another, that is how you can have multiple tunnels bound to a single interface, this also does not bound the crypto map to the isakmp policy. So if you increase the crypto map number, it will move down on the list of existing tunnels ("lower" priority implicitly when come to matching ones). Good practice is also to have dynamic maps have highest number so that they have the lowest priority so that routers don't negotiate with them, and possibly obtain inappropriate settings intended for wildcard, dynamically addressed vpn end users
0
eemoonAuthor Commented:
Thank you so much for your explanation! and the link is best one I have ever seen to totally understand VPN. Thank you again!
0
btanExec ConsultantCommented:
noted only if our subseq sharing can still be tagged to aid the community in their review when searching for similar challenges.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
VPN

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.