IPSec Profile Issue - WAN Failover with IPsec DMVPN (Error: All interfaces sharing this IPSec profile must be configured using the 'shared' keyword)

[nwekechampion]

HI all,

So, I am configuring a failover DMVPN with IPSec. Everything works fine. However when I go to configure the ipsec profile for the second tunnel on the branch (Spoke router), I get the error below:

"Branch1(config-if)#tunnel protection ipsec profile cisco shared
Error: All interfaces sharing this IPSec profile must be configured using the 'shared' keyword'.
Eg: tunnel protection ipsec profile foo shared
"

Please can anyone help?

See config below please

Building configuration...

Current configuration : 2295 bytes
!
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname Branch1
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
no ip icmp rate-limit unreachable
ip cef
!
!
!
!
!
!
no ip domain lookup
no ipv6 cef
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
ip tcp synwait-time 5
!
!
!
!
!
crypto isakmp policy 10
hash md5
authentication pre-share
crypto isakmp key cisco123 address 0.0.0.0
!
!
crypto ipsec transform-set strong esp-3des esp-md5-hmac
mode tunnel
!
crypto ipsec profile cisco
set security-association lifetime seconds 120
set transform-set strong
!
!
!
!
!
!
!
interface Loopback0
ip address 4.4.4.4 255.255.255.0
!
interface Tunnel0
ip address 192.168.1.2 255.255.255.0
no ip redirects
ip mtu 1440
ip nhrp authentication cisco123
ip nhrp map multicast dynamic
ip nhrp map 192.168.1.1 209.168.20.1
ip nhrp map multicast 209.168.20.1
ip nhrp network-id 1
ip nhrp nhs 192.168.1.1
tunnel source POS1/0
tunnel mode gre multipoint
tunnel key 0
tunnel protection ipsec profile cisco
!
interface Tunnel1
ip address 192.168.2.2 255.255.255.0
no ip redirects
ip mtu 1440
ip nhrp authentication cisco123
ip nhrp map multicast dynamic
ip nhrp map 192.168.2.1 199.200.50.1
ip nhrp map multicast 199.200.50.1
ip nhrp network-id 2
ip nhrp nhs 192.168.2.1
tunnel source POS1/0
tunnel mode gre multipoint
tunnel key 1
!
interface FastEthernet0/0
no ip address
shutdown
duplex full
!
interface POS1/0
ip address 209.168.21.1 255.255.255.252
!
interface FastEthernet2/0
no ip address
shutdown
speed auto
duplex auto
!
interface FastEthernet2/1
no ip address
shutdown
speed auto
duplex auto
!
interface GigabitEthernet3/0
no ip address
shutdown
negotiation auto
!
interface FastEthernet4/0
no ip address
shutdown
duplex full
!
!
router eigrp 123
network 4.4.4.0 0.0.0.255
network 192.168.1.0
network 209.168.21.0
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip route 0.0.0.0 0.0.0.0 209.168.21.2
ip route 3.3.3.0 255.255.255.0 Tunnel0
!
!
!
!
control-plane
!
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line aux 0
exec-timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line vty 0 4
login
!
!

[rclaridg]

Your config is good. Everything from a DMVPN and IPSec perspective are mostly correct. We know you're underlay has reachability since your NHRP resolutions to the Hub are at least showing up. Since Tunnel 1 at your branch shares your source interface for Tunnel0, which is working, we know the return reachability is okay too. There's a very small (and common) mistake that is causing your problem. I threw this in a lab so I can show you some output. Your problem is specifically with the config for Tunnel1 at your branch site. I removed IPSec so we can show some WireShark data. Here's some output for your branch, your issues lies in there.

Information from a WireShark capture:

Source NBMA Address: 209.168.21.1
Source Protocol Address: 192.168.2.1
Destination Protocol Address: 192.168.2.1

Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 209.168.20.1 192.168.1.1 UP 00:05:55 S

Interface: Tunnel1, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 199.200.50.1 192.168.2.1 NHRP 00:05:52 S

Branch1#sh run int tun1
Building configuration...

Current configuration : 396 bytes
!
interface Tunnel1
ip address 192.168.2.1 255.255.255.0
no ip split-horizon eigrp 123
ip nhrp authentication cisco123
ip nhrp map multicast dynamic
ip nhrp map 192.168.2.1 199.200.50.1
ip nhrp map multicast 199.200.50.1
ip nhrp network-id 2
ip nhrp nhs 192.168.2.1

Let me know if you can't spot it and I let you know what it is. The information can be seen from the information from WireShark.

A couple items of cleanup and suggestions. Make sure you only have "no ip split-horizon eigrp 123" on your hub, you don't generally want this on your Spoke Routers. Try to avoid having "ip nhrp shortcut" on your Hubs unless you actually need to build spoke-to-spoke tunnels off of it. I like to do "ip nhrp server-only" on the hubs to prevent this behavior. This is personal preference, but you can truncate the commands: "ip nhrp map 192.168.2.1 199.200.50.1", "ip nhrp map multicast 199.200.50.1", and "ip nhrp nhs 192.168.2.1" with the following command: "ip nhrp nhs 192.168.2.1 nbma 199.200.50.1 multicast". Makes the readability of your tunnel config a little easier to follow.

Example:
ip nhrp nhs 192.168.2.1 nbma 199.200.50.1 multicast

Replaces:

ip nhrp map 192.168.2.1 199.200.50.1
ip nhrp map multicast 199.200.50.1
ip nhrp nhs 192.168.2.1

Consider using a front-door VRF in this design. This will allow you to have active-active load balancing of your WAN links (while maintaining predictability in which circuit is being used). You would throw POS1/0 in its own VRF, and POS6/0 in another (or have one in the global VRF and another in a fVRF, then source the tunnels off of that in your tunnels with the "tunnel vrf <vrf>" command. This way each circuit can have it's own default out. This would also eliminate the need for your IP SLA. This can impact how you're routing out for internet traffic however, so that becomes a consideration.

[nwekechampion]

Hi rclairdg,

Thanks again for your feedback.

The only thing I noticed was that the state attribute for the Branch router is "NHRP". I am pulling my hair out here trying to figure out what I need to change to get that show as up.

Also I need the nhrp shortcut, as I have 2 more spokes(Branches) connected to the Hub (is this still ok?) This would be phase 3 right?)

As per VRF, I will try this in a lab after I get this figured-out. Hopefully, that would be a more scalable and efficient solution.

Regards

Champ

[rclaridg · Accepted solution]

If you look at the information from the capture, you'll notice that the source and destination protocol addresses are the same address. This indicates that your IP address at your spoke is the same as at your Hub. Change your Spoke's address and your tunnel should come up. 

You do need shortcut at your Branch sites, just not usually on your hub routers. You need redirect on your hub routers. When traffic hits your hub router, and is switched back into your DMVPN cloud (like if the traffic is going to your other Branch site), the Hub will send a redirect message to your Branch router. This lets the originating Branch site to know a more direct path exists. The shortcut is what the originating Spoke will send towards the destination. In the shortcut message, the spoke will insert its reachability information directly in the packet.

The following article is one of my favorites for DMVPN's spoke-to-spoke behavior: https://blog.ine.com/2008/12/23/dmvpn-phase-3

[nwekechampion]

My goodness.. Can't beleive how dumb that was..
I totally could not see it.
That works awesome now!

Yessss!!!!
Thank you so much.
I really appreciate this.
Thanks again.
Will go through the material.

DO you have any material/link on VRF as well?

[nwekechampion]

Hopefully this is not asking too much, but what filters did you use to narrow down the search on wireshark?
I am not great with packet analysis using Wshark
Thank you!

[rclaridg]

Not asking too much at all!
As for the front-door VRF design, I just glanced over this article and looks like it does a fair job describing it: https://ttl255.com/dmvpn-and-ipsec-with-front-door-vrf/
For WireShark, you can filter via NHRP. WireShark is generally pretty good about having filters for most traffic. For instance, just typing nhrp, gre, isakmp, etc... you can filter without having to get too deep into filters. A great tip is you can right click on anything within a packet and apply it as a filter. That lets WireShark do the filters for you. You can even prepare multi-tiered filters that way by selecting prepare as filter.

[nwekechampion]

Thanks so much for the info on VRF.

I have played around with Wireshark to see. The searching for the protocol tip worked quite fine for me.

I just have one slight problem with the current one.

My PC sitting behind HQ fails to go back to the tunnel on the main link after the tunnel is brought back up. It still gets stuck in tunnel 1 (192.168.2.2). Would there be an easier way to make sure this goes back to main tunnel just like WAN link without having to do trackers and ip sla for both tunnels?

Please  see below:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

PC1 gets stuck in tunnel 1(Backup tunnel)

PC-1> trace 4.4.4.4
trace to 4.4.4.4, 8 hops max, press Ctrl+C to stop
1 192.168.3.1 9.993 ms 9.984 ms 8.994 ms
2 *192.168.2.2 40.975 ms (ICMP type:3, code:3, Destination port unreachable)

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Headq

Main link is back up now, so would need tunnel to on PC to switch to tunnel 0

HeadQ(config-ip-sla)#do sh ip int bri
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 192.168.3.1 YES NVRAM up up
POS1/0 209.168.20.1 YES NVRAM up up
FastEthernet2/0 unassigned YES NVRAM administratively down down
FastEthernet2/1 unassigned YES NVRAM administratively down down
GigabitEthernet3/0 unassigned YES NVRAM administratively down down
FastEthernet4/0 unassigned YES NVRAM administratively down down
POS6/0 199.200.50.1 YES NVRAM up up
Loopback0 1.1.1.1 YES NVRAM up up
Tunnel0 192.168.1.1 YES NVRAM up up
Tunnel1 192.168.2.1 YES NVRAM up up

Thanks again

Champ

[Georg Pauwen]

Hello,

you have only one IPSec profile configured, and both tunnel interfaces have the same source (POS1/0 in your case). You need to use the command:

tunnel protection ipsec profile cisco shared

on both tunnels.

[nwekechampion]

Hi Gerog,

Thanks so much.. command worked. However tunnels not connecting to hub. Not sure why.

Please see Hubs config below:

HeadQ(config)#do sh run
Building configuration...

Current configuration : 3132 bytes
!
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname HeadQ
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
no ip icmp rate-limit unreachable
ip cef
!
!
!
!
ip dhcp pool pool1
network 192.168.3.0 255.255.255.0
default-router 192.168.3.1
!
!
!
no ip domain lookup
no ipv6 cef
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
ip tcp synwait-time 5
!
track 1 ip sla 30 reachability
!
!
!
!
!
crypto isakmp policy 10
hash md5
authentication pre-share
crypto isakmp key cisco123 address 0.0.0.0
!
!
crypto ipsec transform-set strong esp-3des esp-md5-hmac
mode tunnel
!
crypto ipsec profile cisco
set security-association lifetime seconds 120
set transform-set strong
!
!
!
!
!
!
!
interface Loopback0
ip address 1.1.1.1 255.255.255.0
!
interface Tunnel0
ip address 192.168.1.1 255.255.255.0
no ip redirects
ip mtu 1440
no ip split-horizon eigrp 90
ip nhrp authentication cisco123
ip nhrp map multicast dynamic
ip nhrp network-id 1
tunnel source POS1/0
tunnel mode gre multipoint
tunnel key 0
tunnel protection ipsec profile cisco
!
interface Tunnel1
ip address 192.168.2.1 255.255.255.0
no ip redirects
ip mtu 1440
no ip split-horizon eigrp 123
ip nhrp authentication cisco123
ip nhrp map multicast dynamic
ip nhrp network-id 2
tunnel source POS6/0
tunnel mode gre multipoint
tunnel key 1
tunnel protection ipsec profile cisco
!
interface FastEthernet0/0
ip address 192.168.3.1 255.255.255.0
ip nat inside
duplex full
!
interface POS1/0
ip address 209.168.20.1 255.255.255.252
ip nat outside
shutdown
!
interface FastEthernet2/0
no ip address
shutdown
speed auto
duplex auto
!
interface FastEthernet2/1
no ip address
shutdown
speed auto
duplex auto
!
interface GigabitEthernet3/0
no ip address
shutdown
negotiation auto
!
interface FastEthernet4/0
no ip address
shutdown
duplex full
!
interface POS6/0
ip address 199.200.50.1 255.255.255.0
ip nat outside
!
!
router eigrp 123
network 1.0.0.0
network 192.168.1.0
network 192.168.3.0
!
ip nat inside source route-map NAT_01 interface POS1/0 overload
ip nat inside source route-map NAT_02 interface POS6/0 overload
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip route 0.0.0.0 0.0.0.0 209.168.20.2 track 1
ip route 0.0.0.0 0.0.0.0 209.168.20.2
ip route 0.0.0.0 0.0.0.0 199.200.50.2 2
ip route 209.168.21.0 255.255.255.252 209.168.20.2
ip route 209.168.22.0 255.255.255.252 209.168.20.2
ip route 209.168.23.0 255.255.255.252 209.168.20.2
!
ip access-list standard ACL_Dnat
permit 192.168.3.0 0.0.0.255
!
ip sla 30
icmp-echo 209.168.20.2 source-interface POS1/0
threshold 1000
timeout 1000
frequency 10
ip sla schedule 30 life forever start-time now
!
route-map NAT_01 permit 10
match ip address ACL_Dnat
match interface POS1/0
!
route-map NAT_02 permit 10
match ip address ACL_Dnat
match interface POS6/0
!
!
!
control-plane
!
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line aux 0
exec-timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line vty 0 4
login
!
!
end