DMVPN over IPsec

Mark,
They are definitely compatible. Unfortunately, I am not able to see an attachment for your configs. Could you paste in your configs–ideally, your working phase 3, then the addition/changes you make with the IPSEC?

Andrew,

Thank you. I deleted the entire project out of GNS3. I recreated it, using the same
exact config files. It works perfectly. I will chalk it up to GNS3 goofiness.

Hi Rene,
What is the exact DMVPN frame size? As I am trying to apply QoS over iWAN frame, I would like to dimension the iWAN Frame size to know exactly which quantity of bandwidth should be apply to the voice trafic over iWAN.

Thanks for your help

Hi Alexia,

There are a couple of things to keep in mind:

  1. the GRE overhead. That’s 28 bytes (4 GRE header, 20 IP header and 4 bytes for DMVPN key)
  2. IPSec overhead. For example, ESP / tunnel mode is 60 bytes or so.

Rene

19 posts were merged into an existing topic: DMVPN over IPsec

Hello laz,
I have a few questions.

  1. Would you please let me know the order of operations when a packet is being sent over a DMVPN protected with IPSEC tunnel?
    My understanding is route lookup which is the tunnel interface-----GRE encapsulation-----IPSEC encapsulation—exit out of the interface. Please let me know if it is correct?
  2. If the IPSEC tunnel goes down still I should be able to send out traffic through the GRE tunnel. The only problem is the traffic will not be encrypted. Is it correct?
  3. For the sake of this conversation, let’s just say I have only one SPOKE in a DMVPN setup and I do not want to run any routing protocol over them. The tunnel IP addresses are from two different subents. If I configure static route pointed to the tunnel interface, should both hub and spoke not be able to communicate back and forth? Needs clarification.

Thanks as usual.

Azm

Hello Azm

For this question, Cisco has an excellent example and explanation as to the order of operations for the scenario you describe. This information can be found here.

Actually, if the IPSec goes down, the GRE tunnel line protocol state will remain down until the IPsec session is fully established. This desired behaviour was established as a result of a Cisco bug with ID CSCum34057 and was included in Cisco IOS Software Releases 15.4(3)M and 15.4(3)S and later. More information about this can be found here.

This will not be able to function. The IP addresses on the tunnel interfaces on both ends of the tunnel must be in the same subnet, just like any other type of connected layer 3 interfaces.

I hope this has been helpful!

Laz

Hello Laz,
Thanks for your help again. I like to start with question number 3. I have tested in a lab with a default route pointed to the tunnel interface as the screenshot above and traffic was flowing successfully.

Azm

Hello Azm

Can you share the relevant portions of your configs so we can take a closer look? Also, please specify what traffic was flowing, that is, from what source to what destination address.

Thanks!

Laz

Hello Laz,
The config is below

HUB#sho run inter tunnel 0

!
interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 no ip redirects
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip nhrp redirect
 tunnel source 1.1.1.1
 tunnel mode gre multipoint
end


HUB#sho run inter ethernet 0/1

!
interface Ethernet0/1
 description WAN INTERFACE
 ip address 1.1.1.1 255.255.255.0

ip route 0.0.0.0 0.0.0.0 Tunnel0

HUB#ping 10.10.10.4 source tunnel 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.4, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/3/4 ms

===============================================================
====================================================================

SPOKE#sho run inter tunnel 0
!
interface Tunnel0
 ip address 10.10.10.4 255.255.255.0
 no ip redirects
 ip nhrp map multicast dynamic
 ip nhrp map 10.0.0.1 1.1.1.1
 ip nhrp network-id 1
 ip nhrp nhs 10.0.0.1
 ip nhrp shortcut
 tunnel source 1.1.1.4
 tunnel mode gre multipoint
end


SPOKE#sho run inter ethernet 0/0
description WAN INTERFACE
interface Ethernet0/0
 ip address 1.1.1.4 255.255.255.0
end

ip route 0.0.0.0 0.0.0.0 Tunnel0

SPOKE#ping 10.0.0.1 source tunnel 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/3/4 ms

Thank you so much.

Azm

Hello Azm.

I’d like to lab this one up. Give me some time and I’ll get back to you…

Laz

hello Rene
can you please advice on difference between IPEC over GRE and GRE over IPSEC
i mean , practically it apply crypto profile to tunnel interface does it mean ipsec over gre … ?
pleases if you share example of this 2 thing would be really helpful…

Hi Prashant,

When these two confuse you, think of “Voice over IP”. What it means is that IP is the underlying protocol and voice is the upper layer protocol.

So let’s look at GRE over IPSec. This means that GRE is the upper layer protocol and IPSec is the underlying protocol. An example is this configuration:

The crypto map is applied on the interface and if you look at crypto ipsec sa you see this:

   local  ident (addr/mask/prot/port): (192.168.12.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (192.168.23.3/255.255.255.255/47/0)

The protocol number (47) is GRE so it’s GRE that is encrypted by IPSec.

IPSec over GRE means that IPSec is the upper layer protocol and GRE the underlying protocol.

An example of could be packets that you encrypt with IPSec transport mode and then send them down a GRE tunnel.

Hope this helps!

Rene

Good Day,

There seems to be alot of variations when coming to this topic. What are the benefits or even limitations of using the approach outline in your article as oppose to the approach below:

HUB ROUTER CONFIGURATION
Step 1: Configure the crypto keyring for pre-shared keys
Step 2: Configure the IKEv2 proposal.
Step 3: Configure the IKEv2 policy.
Step 4: Configure the IKEv2 profile.
Step 5: Define the IPsec transform set.
Step 6: Configure the IPsec profile.
Step 7: Increase the IPsec anti-replay window size.

SPOKE ROUTER CONFIGURATION
Step 1: Configure the crypto keyring for pre-shared keys
Step 2: Configure the IKEv2 proposal.
Step 3: Configure the IKEv2 policy.
Step 4: Configure the IKEv2 profile.
Step 5: Define the IPsec transform set.
Step 6: Configure the IPsec profile.
Step 7: Increase the IPsec anti-replay window size.

Note: The steps outlined above was taken from Cisco’s IWAN deployment guide?

What’s the difference in using IKEv2 and ISAKMP?

Hello Vern,

In my example, I used a crypto isakmp profile which is IKEv1. In the Cisco example, they use IKEv2.

Nowadays, it’s best to use IKEv2 since it’s support on all devices and it has a couple of improvements over IKEv1.

GETVPN is also interesting for DMVPN, if you haven’t seen it yet:

Rene

Thanks for the reply Rene.

1 Like

Hello Rene,

I would really appreciate if you share configuration for IPsec over GRE setup. I understood the theory but wondering how to lab it up. Thanks

Hello Shailesh

In the lesson that Rene shared in the above post, there is a section at the end that contains the configurations of all the devices used in the lesson. Here’s the link to the lesson once again:


Look for the Configurations tab at the end that looks like this:

There you will find everything you need.

I hope this has been helpful!

Laz

Hi Rene,

What is the difference between the command ‘crypto isakmp key’ and “crypto keyring”? do they both do the same thing of configuring the key?

Hello Onyi

The command crypto isakmp key command is used to configure a preshared authentication key. The crypto keyring command, on the other hand, is used to create a repository of preshared keys. The keyring is used in the ISAKMP profile configuration mode. The ISAKMP profile successfully completes authentication of peers if the peer keys are defined in the keyring that is attached to this profile.

The term keyring is used to denote that the keyring includes multiple preshared keys, much like a physical keyring contains many keys. For more information about creating and maintaining keyrings, take a look at the following Cisco documentation.

I hope this has been helpful!

Laz