cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
20802
Views
8
Helpful
19
Replies

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

tolugbala
Level 1
Level 1

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

19 Replies 19

paolo bevilacqua
Hall of Fame
Hall of Fame

I desire to setup multiple parallel GREoIPSec connections from a single router WAN interface IP to multiple remote sites

Why ?

Sorry bevilacqua, by your question I guess you understood my WAN interfaces as private connections to my remote sites, hence you are wondering why tunneling through my own network. Actually, the WAN interfaces are connected to different ISPs at different locations for Internet connectivity. So the tunnels are to establish private connections through the Internet among the sites. Hope this clears it up?

I meant, why do you want multiple tunnels betwen the same endpoints ?

By the way, the general solution for connecting branches over the internet, is called DMVPN.

No, not multiple tunnels between the same endpoints, but multiple tunnels from one interace at one point to multiple remote endpoints. In order words, a specific point A has one tunnel to a remote point B and another tunnel to point C and another tunnel to point D. The tunnels from point A are however sourced from the same IP.

I know of DMVPN, having read about it and varied models, but being yet uncomfortable with the implementation, limitations and management I refrain from launching myself into it. I am still reading up on it. Since at the moment I just have 3 sites, I really do not think the overhead a manual multipoint VPN is that compelling to jump into the dynamic one.

The are no disavantages or overhad in DMVPN, and that is what should be done for professional, scalable results.

DMVPN is actually nothing more than multipoint GRE over IPSEC. The D as in Dynamic refers to NHRP and that part is optional.

You can terminate multiple DMVPNs to multiple hub sites, and use routing to establish priorities.

Please remember to rate useful posts clicking on the stars below.

Thanks bevilacqua.

I definitely would like to implement DMVPN seeing I have no doubt that it works and is the most professional thing to do. However, like I said before, I am yet to get a hang of it, it is in my plans for the future, certainly before the sites expand more than the present 3 to the projected maximum of 15.

I am not the kind of person that is comfortable with just implementing some configuration just because it works; I like to understand it fairly well first, especially how it will interact with other configurations of mine, before I do, so that I can manage and troubleshoot issues with it fairly. Since I am not yet so, I leave it off my present options. So, for now, I just would like someone to confirm if setting multiple peers in a crypto map entry supports parallel IPSec connections to the same tunnel source IP or otherwise.


Thanks again

What you want to do, is the wrong way to achieve results.

This said, seems like you are eager to learn from your mistakes instead of profiting established best practices, so good luck.

Seems like you too are eager to just push me unto what I am yet to  understand and you don't care about the fact that I am not yet comfortable with the design and implementation of the solution, just the fact that it is the more professional option it all that matters to you. A professional solution is not necessarily the only option excluding all others, just that it is likely more efficient and and manageable. Moreover, a professional solution requires someone who understands it to design, implement and manage it well. I am not yet, though I would like to, and I am already working towards that, but as a stopgap, I asked the question I asked. I really dont think thats too much to ask.


Then you said that my approach is the wrong way to achieve results. I really don't know what that means - that it will not work (which is what I really want someone to confirm to me) or that it will work just that it is not the best (which I am willing to accomodate as a stopgap)?

Anyway, thanks for the effort.

Sorry, can't help you further. I never divert from technical matters, and I have indicated you already what is the best solution.

Any other consideration and decision, is up to you.

Richard Burts
Hall of Fame
Hall of Fame

Boluwade

I have implemented GRE with IPSec from a single central router to multiple remote sites using a crypto map with multiple instances (unique sequence number for each remote peer). This works quite well. I do not believe that your proposed solution would work. For one thing it is my understanding that when you have multiple peer statements within a single instance of the crypto map that one peer is active at a time. If the active peer fails then the next peer becomes active. But I do not believe that multiple peers would be active at the same time. Also I believe that there are difficulties when the access list for IPSec traffic has permit any.

If you are interested in reducing the complexity of the crypto map you might consider configuring IPSec over GRE using Virtual Tunnel Interface. The VTI runs IPSec over the GRE tunnel but uses an IPSec profile rather than a crypto map. I have not used this feature but it doe appear that it provides the same functionality and does simplify the configuration quite a bit.

Here is a link that should get you started if you are interested in this possibility:

http://www.cisco.com/en/US/technologies/tk583/tk372/technologies_white_paper0900aecd8029d629.html

HTH

Rick

HTH

Rick

Thanks rburts,

Like I said, I know about using multiple instance crpyto maps as you mentioned. It just occurred to me to find out if anyone had tried out my proposal and confirmed if it works or not. I do intend to try it out using GNS3.

By the way, I'm already checking out the linked reference and it seems easier to understand and quiker to implement for me.

Thanks for also saying that you just do not believe my approach will work. I suppose that means you have never tried it out so and not that you have tried it and it did not work. Will get back to you

Hi rburts,

Just thought I should confirm to you that my proposed configuration of setting multiple peers within a single crypto map entry for parallel IPSec Peer conections is supported by Cisco IOS as much as for IPSec Peer failover. I just confirmed it in the Security Command Reference (both July & December 2009 editions).

It is affirmed under the usage guidelines section of crypto map (global IPSec) command. I have extracted below just the part that confirms it with the example used. Note that it says either (or both).

Crypto map “mymap 10” allows SAs to be established between the router and either (or both) of two remote IPSec peers for traffic matching access list 101....


crypto map mymap 10 ipsec-isakmp

  match address 101

  set transform-set my_t_set1

  set peer 10.0.0.1

  set peer 10.0.0.2

Thanks for your earlier reference still, it has helped too.

Hello Boluwade,

Security command reference says also the following:

Usage Guidelines

Use this command to specify an IPsec peer for a crypto map.

This command is required for all static crypto maps. If you are defining a dynamic crypto map (with the crypto dynamic-map command), this command is not required, and in most cases is not used (because, in general, the peer is unknown).

For crypto map entries created with the crypto map map-name seq-num ipsec-isakmp command, you can specify multiple peers by repeating this command. The peer that packets are actually sent to is determined by the last peer that the router heard from (received either traffic or a negotiation request from) for a given data flow. If the attempt fails with the first peer, Internet Key Exchange (IKE) tries the next peer on the crypto map list.

http://www.cisco.com/en/US/docs/ios/security/command/reference/sec_s2.html#wp1046908

the set peer allows to define multiple peers for redundancy not for using them at the same time.

The working solutions as explained by Rick and Paolo are: crypto map with multiple blocks for using multiple point-to-point GRE or DMVPN

Hope to help

Giuseppe

Hi Giuseppe,

Thanks for contributing to this question.

I should confess that the section you cited from the command reference was what had always kept me believing that setting multiple peers in a crypto map entry is for failover exclusively. I had always thought that the usage and functionality of the Set Peer  command should be conclusively found under its section but alas there  was something more about it that was only to be found under crypto  map (global IPSec) as I cited in my reference. I however just recently felt it was not really saying what we seem to believe it is saying. It just did not seem logical to me that the router would reject a connection with a peer with interesting traffic matching its configured crypto map just because another distinct peer already had a connection similar. I felt since they were distinctly listed then they should be distinctly treated if and when they simultaneously requested separate connections, hence my posting this question to find out if any one has actually  checked out the workability of my proposed configuration. Unfortunately, no one (of all that responded) could confirm having tried it out, just the same supposition as I had held before. I had intended testing it out with GNS3 but was sort of lazy to and thought I should still go through the command reference well until I found the section I previously quoted.

Now I am just coming off trying out my config with GNS3 and I can confirm to you that the it worked for multiple (2 in my case) parallel connections. I therefore think that what that section means to say is that if the router that has the crypto map entry set with multiple peers is the one initiating the IPSec connection it would try to contact the last peer it made a connection with first and not according to the order listed in the crypto map. Hence, the section means not to say that if all peers set in the crypto map entry initiate connections simultaneously that the router with the multiple peer crypto map entry would accept only one and reject the others. I suppose that has been our erroneous supposition.

See below my config for the three routers I used to simulate it in GNS3 as well as different sh crypto... commands outputs from R1000 after the connections were established:

hostname R1000
!
crypto isakmp policy 100
hash md5
authentication pre-share
encryption des
crypto isakmp keepalive 10
!
crypto ipsec transform-set test ah-md5-hmac esp-des comp-lzs
!
crypto map Test 100 ipsec-isakmp
set peer 192.168.0.2
set peer 192.168.0.3
set transform-set test
match address Test
crypto isakmp key test address 192.168.0.2
crypto isakmp key test address 192.168.0.3
!
interface Tunnel0
ip address 10.0.0.1 255.255.255.252
keepalive 10 3
tunnel source 192.168.0.1
tunnel destination 192.168.0.2
!
interface Tunnel1
ip address 192.168.1.1 255.255.255.252
keepalive 10 3
tunnel source 192.168.0.1
tunnel destination 192.168.0.3
!
interface FastEthernet0/0
ip address 192.168.0.1 255.255.255.0
no ip route-cache
no shut
speed auto
full-duplex
no mop enabled
crypto map Test
!
ip access-list extended Test
100 permit gre host 192.168.0.1 host 192.168.0.2
200 permit gre host 192.168.0.1 host 192.168.0.3


hostname R1001
!
crypto isakmp policy 100
hash md5
authentication pre-share
encryption des
crypto isakmp keepalive 10
!
crypto ipsec transform-set test ah-md5-hmac esp-des comp-lzs
!
crypto map Test 100 ipsec-isakmp
set peer 192.168.0.1
set transform-set test
match address Test
crypto isakmp key test address 192.168.0.1
!
interface Tunnel0
ip address 10.0.0.2 255.255.255.252
keepalive 10 3
tunnel source 192.168.0.2
tunnel destination 192.168.0.1
!
interface FastEthernet0/0
ip address 192.168.0.2 255.255.255.0
no ip route-cache
no shut
speed auto
full-duplex
no mop enabled
crypto map Test
!
ip access-list extended Test
100 permit gre host 192.168.0.2 host 192.168.0.1


hostname R1002
!
crypto isakmp policy 100
hash md5
authentication pre-share
encryption des
crypto isakmp keepalive 10
!
crypto ipsec transform-set test ah-md5-hmac esp-des comp-lzs
!
crypto map Test 100 ipsec-isakmp
set peer 192.168.0.1
set transform-set test
match address Test
crypto isakmp key test address 192.168.0.1
!
!
interface Tunnel0
ip address 192.168.1.2 255.255.255.252
keepalive 10 3
tunnel source 192.168.0.3
tunnel destination 192.168.0.1
!
interface FastEthernet0/0
ip address 192.168.0.3 255.255.255.0
no ip route-cache
no shut
speed auto
full-duplex
no mop enabled
crypto map Test
!
ip access-list extended Test
100 permit gre host 192.168.0.3 host 192.168.0.1

SH CRYPTO COMMANDS OUTPUT

R1000#sh crypto isakmp pee
Peer: 192.168.0.2 Port: 500 Local: 192.168.0.1
Phase1 id: 192.168.0.2
Peer: 192.168.0.3 Port: 500 Local: 192.168.0.1
Phase1 id: 192.168.0.3

R1000#sh  crypto isakmp sa
dst             src             state          conn-id slot status
192.168.0.1     192.168.0.3     QM_IDLE              2    0 ACTIVE
192.168.0.1     192.168.0.2     QM_IDLE              1    0 ACTIVE

R1000#sh crypto session
Crypto session current status

Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 192.168.0.2 port 500
  IKE SA: local 192.168.0.1/500 remote 192.168.0.2/500 Active
  IPSEC FLOW: permit 47 host 192.168.0.1 host 192.168.0.2
        Active SAs: 6, origin: crypto map

Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 192.168.0.3 port 500
  IKE SA: local 192.168.0.1/500 remote 192.168.0.3/500 Active
  IPSEC FLOW: permit 47 host 192.168.0.1 host 192.168.0.3
        Active SAs: 6, origin: crypto map

R1000#sh crypto ipsec sa

interface: FastEthernet0/0
    Crypto map tag: Test, local addr 192.168.0.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.0.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (192.168.0.2/255.255.255.255/47/0)
   current_peer 192.168.0.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 78, #pkts encrypt: 78, #pkts digest: 78
    #pkts decaps: 78, #pkts decrypt: 78, #pkts verify: 78
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 78, #pkts compr. failed: 0
    #pkts not decompressed: 78, #pkts decompress failed: 0
    #send errors 8, #recv errors 0

     local crypto endpt.: 192.168.0.1, remote crypto endpt.: 192.168.0.2
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0xCE50C0AB(3461398699)

     inbound esp sas:
      spi: 0x1A03B3EB(436450283)
        transform: esp-des ,
        in use settings ={Tunnel, }
        conn id: 2001, flow_id: SW:1, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4387529/3209)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:
      spi: 0x5E9D6102(1587372290)
        transform: ah-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 2001, flow_id: SW:1, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4387528/3203)
        replay detection support: Y
        Status: ACTIVE

     inbound pcp sas:
      spi: 0x8B4F(35663)
        transform: comp-lzs ,
        in use settings ={Tunnel, }
        conn id: 2001, flow_id: SW:1, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4387528/3203)
        replay detection support: Y
        Status: ACTIVE

     outbound esp sas:
      spi: 0xCE50C0AB(3461398699)
        transform: esp-des ,
        in use settings ={Tunnel, }
        conn id: 2002, flow_id: SW:2, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4387528/3200)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:
      spi: 0x15E1A208(367108616)
        transform: ah-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 2002, flow_id: SW:2, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4387528/3200)
        replay detection support: Y
        Status: ACTIVE

     outbound pcp sas:
      spi: 0x5938(22840)
        transform: comp-lzs ,
        in use settings ={Tunnel, }
        conn id: 2002, flow_id: SW:2, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4387528/3200)
        replay detection support: Y
        Status: ACTIVE

     local crypto endpt.: 192.168.0.1, remote crypto endpt.: 192.168.0.3
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0x0(0)

     inbound esp sas:

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:

     outbound ah sas:

     outbound pcp sas:

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.0.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (192.168.0.3/255.255.255.255/47/0)
   current_peer 192.168.0.3 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 68, #pkts encrypt: 68, #pkts digest: 68
    #pkts decaps: 68, #pkts decrypt: 68, #pkts verify: 68
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 68, #pkts compr. failed: 0
    #pkts not decompressed: 68, #pkts decompress failed: 0
    #send errors 14, #recv errors 0

     local crypto endpt.: 192.168.0.1, remote crypto endpt.: 192.168.0.2
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0x0(0)

     inbound esp sas:

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:

     outbound ah sas:

     outbound pcp sas:

     local crypto endpt.: 192.168.0.1, remote crypto endpt.: 192.168.0.3
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0x67C20DD2(1740770770)

     inbound esp sas:
      spi: 0x96B6C75B(2528560987)
        transform: esp-des ,
        in use settings ={Tunnel, }
        conn id: 2003, flow_id: SW:3, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4580038/3260)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:
      spi: 0x331DAB37(857582391)
        transform: ah-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 2003, flow_id: SW:3, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4580038/3260)
        replay detection support: Y
        Status: ACTIVE

     inbound pcp sas:
      spi: 0x4754(18260)
        transform: comp-lzs ,
        in use settings ={Tunnel, }
        conn id: 2003, flow_id: SW:3, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4580038/3259)
        replay detection support: Y
        Status: ACTIVE

     outbound esp sas:
      spi: 0x67C20DD2(1740770770)
        transform: esp-des ,
        in use settings ={Tunnel, }
        conn id: 2004, flow_id: SW:4, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4580038/3259)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:
      spi: 0xC829D4D(209886541)
        transform: ah-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 2004, flow_id: SW:4, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4580038/3258)
        replay detection support: Y
        Status: ACTIVE

     outbound pcp sas:
      spi: 0x387D(14461)
        transform: comp-lzs ,
        in use settings ={Tunnel, }
        conn id: 2004, flow_id: SW:4, crypto map: Test
        sa timing: remaining key lifetime (k/sec): (4580038/3258)
        replay detection support: Y
        Status: ACTIVE

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: