Separate IPSec Profiles for DMVPN Tunnel Protection

[rick505d3]

Hi,

This document has these restrictions on the use of IPSec profiles under tunnels - ref https://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_dmvpn/configuration/15-2mt/sec-conn-dmvpn-share-ipsec-w-tun-protect.html

• The tunnel source command on all tunnel interfaces using the same tunnel source must be configured using the interface type and number, not the IP address.
• All tunnels with the same tunnel source interface must use the same IPsec profile and the shared keyword with the tunnel protection command. The only exception is when only point-to-point generic route encapsulation (GRE) tunnel interfaces are configured with the same tunnel source in the system and associated with unique tunnel destination IP addresses. Shared tunnel protection can be used when the same local address between point-to-multipoint and point-to-point GRE interfaces are shared only if the device is an initiator of the point-to-point tunnels and not a responder.

But then it allows different IPSec profiles under tunnels using the same source-interface:

• Sometimes, it may be desirable to not share an IPsec session between two or more tunnel interfaces using the same tunnel source. For example, in a service provider environment, each DMVPN cloud can represent a different customer. It is desirable to lock the connections from a customer to a tunnel interface and not share or allow IPsec sessions from other customers. For such scenarios, Internet Security Association and Key Management Protocol (ISAKMP) profiles can be used to identify and bind customer connections to an ISAKMP profile and through that to an IPsec profile. This ISAKMP profile limits the IPsec profile to accept only those connections that matched the corresponding ISAKMP profile. Separate ISAKMP and IPsec profiles can be obtained for each DMVPN cloud (tunnel interface) without sharing the same IPsec SADB.

On a spoke router (ISR's 15.7(8)), I have two IPSec profiles each with separate referenced components i.e. IPSec transform-sets, IKEv2 profiles, Certificate Trustpoints, Certificate Map to match on cert parameters. The IPSec profile (one) is referenced under the Tunnel interface. Both tunnels are sourced from same physical interface - that's the only common ground between the two tunnels.

However, only the tunnel configured last (with regards to certificate enrollment, interface tunnel protection) will withstand shut/noshut. The other tunnel (configured first) will remain down if it does down due to shut/noshut or router reload. This kind of confirms the restrictions in the first two bullet points above. My question is how can we make these two tunnels with different IPSec Profiles share the same tunnel source interface? As indicated in the 3rd bullet point above.

UPDATE -relevant config attached.

Thanks,

Rick.

[MHM Cisco World]

simple by config the tunnel destination IP not GRE multipoint, 
this make two tunnel p-2-p but use same tunnel source.

[rick505d3]

Thanks MHM,

The Spoke end is in tunnel mode gre ip (default). The Hub needs to be gre multipoint to allow connecting all the spokes without requiring manual per spoke config on the hub. Is there another way?

Also, on the spoke under both tunnels, the destination IP (hub1 | hub2) and tunnel keys are different. Only common param is tunnel source.

Regards,

Rick.

[MHM Cisco World]

please can you share the topology

[rick505d3]

It a dual hub dual cloud design. Hub1 has Tun1 only with GRE Multipoint (tunnel mode gre multipoint). Hub2 has Tun2 only with similar config except different tunnel source IP, tunnel key, nhrp network-id and nhrp auth.

Hub1 Tun1 config below:

interface Tun1
 ip address 20.20.20.1 255.255.255.0  <<< Hub2 Tun2 will be 30.30.30.1
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip mtu 1400
 ip hold-time eigrp 10 35
 no ip next-hop-self eigrp 10
 no ip split-horizon eigrp 10
 ip nhrp authentication <AUTH1>
 ip nhrp map multicast dynamic
 ip nhrp network-id <ID1>
 ip nhrp holdtime 600
 ip tcp adjust-mss 1360
 delay 520
 tunnel source Loopback0   <<<< 10.10.10.7. Hub2 Tun2 will be 10.10.10.8.
 tunnel mode gre multipoint
 tunnel key <KEY1>
 tunnel path-mtu-discovery
 tunnel protection ipsec profile SEC_IPSEC_PROFILE

There are few 10's of spokes that connect to both the hubs. Spokes have Tun1 and Tun2 to respective Hubs as tunnel destination. These are configured as tunnel mode gre ip. Both share the same tunnel source interface. Rest all other relevant params are different. Spoke Tun1 config below:

interface Tun1
 ip address 20.20.20.5 255.255.255.0    <<< Tun2 will be 30.30.30.5
 no ip proxy-arp
 ip mtu 1400
 ip hold-time eigrp 10 35
 no ip next-hop-self eigrp 10
 ip flow ingress
 ip nhrp authentication <AUTH1>
 ip nhrp map multicast 10.10.10.7    <<< Tun2 will be 10.10.10.8
 ip nhrp map 20.20.20.1 10.10.10.7
 ip nhrp network-id <ID1>
 ip nhrp holdtime 300
 ip nhrp nhs 20.20.20.1
 ip tcp adjust-mss 1360
 delay 520
 qos pre-classify
 tunnel source Dialer0      <<<< Same Inteface under both Tun1 and Tun2 on each spoke
 tunnel destination 10.10.10.7
 tunnel key <KEY1>
 tunnel path-mtu-discovery
 tunnel vrf PUBLIC
 tunnel protection ipsec profile SEC_IPSEC_PROFILE

The crypto (ikev2, ipsec, etc) related config was attached before, under the main post.

It is working config with the limitation that Tun1 and Tun2 on the spoke will need to use the same IPSec profile with "shared" keyword for both tunnels to stay UP. When having different ipsec profiles (SEC_IPSEC_PROFILE under Tun1, PRI_IPSEC_PROFILE under Tun2) under them, only the last configured tunnel will come up and stay up. The first configured tunnel show UP but won't be after shut/noshut or router restart.

Thanks,

Rick.

[MHM Cisco World]

Dual Hub Dual DMVPN, Single ISP for spoke. 
why Dual DMVPN since only one is use? 

also please notice that Spoke Both tunnel must also config tunnel destination as GRE multipoint this make both tunnel work and for IPSec there is for same SA two different Proxy one for each tunnel.  

[rick505d3]

Thanks MHM. The Spoke won't allow "tunnel mode gre multipoint" because it currently has "tunnel destination 10.10.10.7" which tells it about the hub.

spoke1(config-if)#tunnel mode gre multipoint
 Tunnel set mode failed. p2mp tunnels cannot have a tunnel destination.

[MHM Cisco World]

reconfig and remove the tunnel destination.