DMVPN over IPsec

Hello Brian

Yes, that is the case. The amazing thing is that in Cisco’s documentation, it explicitly states that:

It is highly recommended that you do not use wildcard preshared keys because the attacker will have access to the VPN if one spoke router is compromised.

Even so, in all of their examples, they use a wildcard preshared key. :crazy_face:

But your syntax is correct for configuring individual keys for each pair of routers in the DMVPN topology.

I hope this has been helpful!

Laz

1 Like

Hi Rene.

I can see that we will need ACL when configuring site-to-site IPsec VPN.
However for DMVPN over IPsec, is there an exception or do we need to configure ACL too ?

Thanks!

Hello Nur

When implementing IPSec on a regular GRE tunnel, one of the things you must create is a crypto map, which tells IPSec what traffic must be encrypted. The crypto map references an access list and matched traffic will be encrypted. This kind of configuration is detailed in the following lesson:

Now, a newer method of configuration for IPSec tunnels, known as virtual tunnel interfaces (VTIs) was created to simplify configuration especially if you have many remote peers. Instead of crypto maps, this uses crypto profiles used for tunnel interfaces. This kind of configuration is detailed in the following lesson:

Now, when applied to DMVPN, you use VTIs, and crypto profiles to enable IPSec over DMVPN, thus no access list is necessary to identify traffic.

I hope this has been helpful!

Laz

1 Like

Thank you very much Laz for the detailed explanations. Really appreciate it :smile:

1 Like

HI,

I’ve question, as always, i’ve replicated this lab on gns3.
When i do show crypto isakmp sa on spokes (after ping ) i can see only a single SA.


SPOKE1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
192.168.123.1   192.168.123.2   QM_IDLE           1001 ACTIVE

IPv6 Crypto ISAKMP SA

SPOKE2#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
192.168.123.1   192.168.123.3   QM_IDLE           1001 ACTIVE

IPv6 Crypto ISAKMP SA

If I configure a DMVPN Phase 3 I can see the same output of Rene.

SPOKE2#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
192.168.123.3   192.168.123.2   QM_IDLE           1002 ACTIVE
192.168.123.2   192.168.123.3   QM_IDLE           1003 ACTIVE
192.168.123.1   192.168.123.3   QM_IDLE           1001 ACTIVE

IPv6 Crypto ISAKMP SA

SPOKE2#

I see that Rene didn’t configure a DMVPN Phase3 on this lesson but he get 3 security associations entry in spokes routers.

Did I miss something?

Hello Giovanni

I went and labbed this up on CML and replicated Rene’s topology which uses DMVPN Phase 2 which was used in the lab. I too got three security associations like so:

Spoke1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
192.168.123.2   192.168.123.3   QM_IDLE           1003 ACTIVE
192.168.123.3   192.168.123.2   QM_IDLE           1002 ACTIVE
192.168.123.1   192.168.123.2   QM_IDLE           1001 ACTIVE

What I did find interesting however is as soon as I performed the ping, I and issued the above command, I initially only got two associations:

Spoke1#show crypto isakmp sa         
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
192.168.123.3   192.168.123.2   QM_IDLE           1002 ACTIVE
192.168.123.1   192.168.123.2   QM_IDLE           1001 ACTIVE

Only after a couple of seconds did I get the third. Now for both DMVPN Phase 2 and 3, this is expected, since we have direct spoke-to-spoke communication, and the IPSec secures a multipoint GRE tunnel. Therefore you should see an SA for communication with the hub, and communication with the other spoke.

The third SA comes in a little later when there is communication initiated by Spoke 3 towards Spoke 1. You can see that the src IP is that of Spoke 3 while the dst IP is that of Spoke 1. This may be a routing update via RIP that initiates it or some other control plane process.

Beyond that I can’t see why you only get one SA other than GNS3 may be acting up again! :stuck_out_tongue:

I hope this has been helpful!

Laz

So because this is a Phase 2 DMVPN example, this is why we see the SA being created between spoke 1 and 2 when a ping to the loopback is created? Else, on a phase 1 you would only see the SA to the HUB correct?

Thank you for the great explanation. I have dug and dug and dug through Cisco and other documentation and just get more and more confused on IPSEC config and this helped greatly with a great example to help me get through adding a new device to an existing HUB/SPOKE DMVPN setup and to understand the steps, than just copy/paste existing config!

Hello Pietro!

Yes, that is the case. We’re glad that you find these lessons and the forum useful!

I hope this has been helpful!

Laz

Hi rene,

Why would using tunnel mode add overhead to DMVPN?
I understand that the transport mode does not encrypt the original IP header (Private Addresses) and preserves it, so what would happen to the packets from the hosts that go from LAN to LAN that travel through the tunnel (Public Addresses)?

Hello Christian

Tunnel mode always adds more overhead than transport mode, regardless of whether it is a DMVPN implementation or otherwise. Indeed transport mode does not encrypt the original IP header and preserves it. However tunnel mode encrypts the header, which necessitates a new IP header to be prepended, which is where the extra overhead is found.

Using ESP, this is what transport mode looks like:

And this is what tunnel mode looks like:

You can see that in tunnel mode we are preserving the original IP header and encapsulating the whole IP packet within the ESP header and a new IP header. It is this new IP header that results in the additional overhead. The above diagrams are taken from the following lesson which further describes these concepts in more detail:

I hope this has been helpful!

Laz

Hello lagápides, thanks for the answer.

So in the DMVPN solution, what is preserved when setting the transport mode is the external GRE IP header, otherwise there would be 2 external IP headers (GRE and IPsec). I am right?

If 2 hosts on different LANs (private IPs) communicate, due to the GRE header (public IPs) their packets can travel through the tunnel right?

Hello Christian

Yes, you are correct. Transport mode preserves the GRE IP header, meaning it does not encrypt it. Otherwise, there would indeed be two IP headers, one for GRE and one for IPsec.

The original IP header contains the original IP addresses of the source and destination (which are those of the 2 hosts you mention). These hosts will indeed be able to communicate with each other over the GRE tunnel using the GRE header with the public IPs.

I hope this has been helpful!

Laz

Hi,

For the spokes, you are using a static multicast mapping command on the hub:

ip nhrp map multicast 192.168.123.1

Does that mean multicast traffic will always go via the hub, even after spoke-to-spoke tunnels are created?

Thanks,

Sam

Hello Samir

In this particular scenario, we are using DMVPN Phase 2. This means that we are creating spoke-to-spoke tunnels, so traffic will go directly from spoke to spoke. However, to create a spoke-to-spoke tunnel, initially, traffic is sent to the hub. Using NHRP, the hub directs all subsequent traffic to be routed directly between spokes.

For multicast traffic, the behavior is similar:

The ip nhrp map multicast command on the hub helps to initially establish multicast traffic flow from the hub to the spokes. When you configure this command, multicast traffic is initially sent to the hub, which then forwards the traffic to the spokes.

Once spoke-to-spoke tunnels are established using NHRP to dynamically discover the public IP address of the other spokes, subsequent multicast traffic can flow directly between the spokes, bypassing the hub. This is possible because of the use of NHRP in a similar manner as with unicast traffic to dynamically discover the public IP addresses of the other spokes and create direct GRE tunnels between them.

When a spoke wants to send multicast traffic to another spoke, it first checks its NHRP cache to see if it has a direct GRE tunnel to the destination spoke. If it does, it will send the traffic directly through that tunnel. If it doesn’t have a direct tunnel, it will send the traffic to the hub, which will then forward it to the destination spoke.

So, once spoke-to-spoke tunnels are created, multicast traffic will not always go via the hub. Instead, it will be sent directly between the spokes, providing a more efficient traffic flow.

I hope this has been helpful!

Laz

Hi Laz,

Thanks for the explanation. I just want to clear something up.

The multicast traffic only flows directly to a spoke once a unicast packet sent to that spoke has caused a tunnel to be built. i.e. the multicast traffic itself cannot cause the tunnel to be built. Is that correct?

Thanks.

Sam

Hello Samir

Yes you are correct. Multicast traffic will not be able to initiate the creation of point to point GRE tunnel between spokes. If this tunnel does not exist, multicast traffic will be routed via the hub. Only unicast traffic will trigger the creation of a spoke-to-spoke tunnel. This is simply due to the design and behavior of the NHRP protocol.

Specifically, the NHRP resolution process is triggered only by unicast traffic and not multicast traffic.

When multicast traffic is sent to the hub, it is forwarded to all registered spokes. Since the multicast traffic is not specifically addressed to a single spoke, it does not provide an opportunity for NHRP to learn about the other spokes’ public IP addresses or establish direct GRE tunnels.

This is a design choice for NHRP, which helps to optimize network traffic flow and reduce unnecessary overhead. If multicast traffic were used to establish spoke-to-spoke tunnels, it could result in numerous unnecessary tunnels being built, which could consume additional resources and complicate the network. Thus it is more efficient to rely only on unicast to trigger the NHRP resolution process.

I hope this has been helpful!

Laz

1 Like

I had a question, is there anyway we can get a lesson with DMVPN and IPsec with OSPF instead of RIP?

Hello David

If you have suggestions for specific lessons and lesson topics, feel free to use the Member Ideas page below. There you can make your suggestions for additional lessons that Rene can add in the future. You may find that others have suggested something similar, so you can add your voice to theirs.

In the meantime, take a look at the following Cisco documentation which describes a scenario where DMVPN with IPSec and OSPF are being used, along with a few more features.

Doing a search online, I was able to find some additional resources that describe such a setup.

I hope this has been helpful!

Laz

Hello!
Can you provide any resources I can use to better understand the IKEV2 configuration on an iOS router using DMVPN & Cisco router for a PKI server.

Hello James

The following lesson shows how to set up DMVPN with IPsec:

This doesn’t include the use of a PKI server, however you can find further information about that for a DMVPN environment at the following Cisco documentation:

This documentation describes a DMVPN network using IPSec along with a CA server, a role which is played by the hub of the DMVPN topology.

If you would like Rene to create a new lesson with your particular setup in mind, feel free to make your suggestion at the following member ideas page:

There, you may find that others have made similar suggestions, and you can add your voice to theirs.

I hope this has been helpful!

Laz