Does Setting Multiple Peers in a Crypto Map Also Support Parallel IPSec Connections

[tolugbala]

I desire to setup multiple parallel GREoIPSec connections from a single router WAN interface IP to multiple remote sites. I know that I can achieve this by applying to the interface a crypto map that is defined in multiples with different sequence numbers with each matched to a unique remote IPSec peer IP. I also read from the Command Reference that setting multiple peers for a crypto map entry provides for failover. I was just wondering if it could at the same time, using just the same crypto map, support parallel connections from all the peers set for it if all peers were to initiate IPSec connections to the interface at the same time where the crypto map match address command was matched to an extended IP access-list that specifies any as the destination host address for the GRE traffic that will trigger the negotiation. Would it refuse others if it already has established to one or would it accept others as well, all other things (IKE Policy, Transform Set) being equal?

I would just like to know if it works and any potential disadvantage with such a configuration if it works, as it seems a more efficient configuration to me if it did.

Below is my proposed configuration for the IP access-list and Crypto Map

Router(config)#ip access-list extended AllPeersCryptoACL

Router(config-ext-nacl)#100 permit gre host WANInterfaceIP any

Router(config)#crypto map AllPeersCryptoMap 1 ipsec-isakmp

Router(config-crypto-map)#set peer RemotePeer1-IP

Router(config-crypto-map)#set peer RemotePeer2-IP

Router(config-crypto-map)#set peer RemotePeer3-IP

Anyone confirmed workability or otherwise of this please respond. Thanks

[Davezenith]

Hi,

Did you manage to ge this working outside LAB environment? I'm faced with a similar challenge in that, using one crypto map, I have set multiple peers.

There is a diagram attached - IPs are fictional. I have managed to get the site-to-site IPsec working between remote peer 2 and local peer. However, the GRE over IPsec tunnel is not establishing. I want to identify this is not a design limitation with the way crypto map handles multiple remote peers. The topology will scale to the point when 1 local Cisco will establish parallel tunnels to 10 different remote peers (none remote peers are not associated with one another) = 10 tunnels

Based on the above logic, the desired config for setting multiple peers will be:

crypto map MY_MAP 10 ipsec-isakmp

match address 101

set peer 1

set peer 2

set peer 3

set peer 4

set peer 5

set peer 6

set peer 7

set peer 8

set peer 9

set peer 10

set transform-set 1 2 3 4 5 6 7 8 9  10

end

Questions:

- Will the local Cisco attempt to establish 10 unique sessions each with one of the remote peers?

lets assume:

a) the transform-sets match the peers

b) the access-list 101 has 10 rules to match which traffic to encrypt

c) the crypto isakmp keys match

Thanks

David

[Richard Burts]

David

I am not sure that anyone has come up with real proof whether the approach of specifying multiple peers within a single instance of a crypto map to establish multiple active IPSec sessions really works or not. Perhaps you may be the person who develops that proof.

I do know that a while back I had a TAC case open and asked the TAC engineer about this approach. The answer that I got was that the recommended approach was to have a separate instance of the crypto map for each remote peer. I have adopted that approach and it has worked well. I have a customer who is configured this way and has over 400 remote sites doing IPSec/GRE. The thought of trying to manage - or to troubleshoot a problem - a crypto map instance with 400 peers and an access list with 400 elements makes my head hurt.

HTH

Rick

[Davezenith]

Hi Rick,

Thanks for the info. Point noted, my head hurts already...

Your approach sounds logical and easier to scale / maintain - this is now my learning curve. Keeping it simple, Lets say for example, I have 10 remote peers. This means I will now configure 10 crypto maps 1, 2,3...10 and 10 access-lists 101, 102, 103...110. Each map includes a peer, transform-set, extended access-list.

Question: I understand that you may configure only one crypto map per signle interface ( FA in this instance). What approach did you take to get around this to have all 10 instances active simultaneously (or where may I read about technical detailed examples of your approach so I may ask more of the right questions)

Rgds

David

[Richard Burts]

David

The key thing is that you do not do 10 crypto maps but you do one crypto map with 10 entries. It might look something like this:

crypto map samplemap 10 ipsec-isakmp
set peer
set transform-set
match address

crypto map samplemap 20 ipsec-isakmp
set peer
  set transform-set
match address

crypto map samplemap 30 ipsec-isakmp
set peer
  set transform-set
match address

etc

HTH

Rick

[tolugbala]

Hi David,

Setting multiple peers in a crypto map supports parallel connections like I already noted, but only if all the peers listed initiate the connections. The local router would initiate connection with only the last successful from the list. If however, each peer separately and simultaneously initiate connections, the local router would accept all