PROFESSIONAL LICENSE 3 IN NETWORKS AND SERVICES

PROJECT: NETWORK SYSTEM AND SECURITY

Theme: DMVPN

Presenters:

Directed by:
 PLAN

INTRODUCTION

PRESENTATION OF DMVPN

THE COMPONENTS AND TERMINOLOGIES

DEPLOYMENT MODELS

ADVANTAGES OF DMVPN

IMPLEMENTATIONS
 INTRODUCTION

More and more companies are expressing the need to interconnect their different sites and
to use an encryption method to protect their communications. In the past, the
The only solution to this problem was the use of Layer-2 networks such as RNIS or Frame.
Relay. The implementation and cost being tedious, the deployment of these would be without
cheaper doubt if all sites had internet access to facilitate security of
IP communications through the use of IPsec tunnels to ensure authentication.
the integrity and confidentiality of data (IPsec VPN).
IPsec VPN is a reliable solution for secure communication, but it has some drawbacks.
limited names to know:
A maintenance and scaling limit: each addition of a new site leads to a
total modification of the central site's configuration. The configuration of the central site
can easily become unreadable after about ten sites.
To interconnect n sites, n(n-1)/2 tunnels and n routers must be configured;
equation that becomes difficult to solve as the number of sites increases
notably in the case of Full Meshed networks or fully meshed.

These main limitations have led the authors of IPsec VPN to turn to a technology
much more advantageous: the DMVPN (Dynamic Multipoint VPN). It is a
a mechanism that allows establishing IPsec + GRE tunnels directly between the routers that
want to dialogue together with a disconcerting simplicity and scalability and above all
completely dynamic way. Its main advantage is that it allows you to keep the configuration
static routers in case of adding a new site and creating tunnels between the sites
remote is fully automatic. Deploy this Cisco IOS software solution for the
The thrust construction of IPsec for virtual private networks (VPN) will be the objective of our presentation.
PRESENTATION OF DMVPN

DMVPN is actually a set of technologies (IPsec, mGRE, and NHRP) that,

combined, facilitates the deployment of IPsec virtual private networks. It is a solution
reliable, secure, and scalable, enabling flexible deployment and management of tunnels
IPsec. Cisco DMVPN is based on a centralized architecture and takes into account various
types of users including mobile workers, remote workers, and even users
extranet. Cisco DMVPN takes into account VoIP between the different connected sites
and does not require a permanent VPN connection between the sites. It significantly reduces
latency and jitter, while optimizing bandwidth usage.

THE COMPONENTS AND TERMINOLOGIES

IPsec: a encryption protocol that allows encrypting traffic between two sites, by
the use of pre-shared keys. It is probably not the most secure protocol but
allows for simple and quick implementation.
mGRE (multipoint GRE): protocol that allows creating multipoint tunnels between
different sites; that is to say, creating multiple tunnels from a single pseudo interface
Tunnel.
NHRP (Next Hop Resolution Protocol): a protocol that allows remote routers to do
to know their IP address used to establish the GRE tunnel with the server. The server, from its
side, store the IP addresses to allow each router to know the address of its
neighbor and thus establish a direct tunnel with him.
OSPF (Open Shortest Path First): routing protocol allowing the central site's router
to propagate the different routes to remote sites. It also allows the routers of the sites
assistants to announce their local network to the central site.
Hub and Spoke: the two terms refer respectively to the central router and the routers.
distant. The central site served by the central router acts as an NHRP server.

DEPLOYMENT MODELS
DMVPN offers two possible deployment models:
The Hub-and-spoke model: each spoke has a GRE interface allowing for connection.
the tunnel to the HUB. All traffic between the spokes goes through the HUB. This model does not take into account
taking into account the links between the spokes.

The Spoke-to-Spoke model: each spoke must have an mGRE interface allowing
the dynamic tunnels to transit to the other spokes. This model takes into account the
links between different spokes and offers great scalability of the configuration for the
devices.

ADVANTAGES OF DMVPN

The main advantages of DMVPN are:

R
 eduction of operating and capital expenditures by integrating voice and video
to VPN security
S
 implification of branch communication through direct branch connectivity
branch for applications such as voice over IP
R
 eduction of deployment complexity through the establishment of a configuration
simple, reducing the difficulties of deploying VPNs
I mprovement of activity resilience by preventing disruptions and services
Routing is done using IPsec technology.

IMPLEMENTATIONS

Prerequisites
IOS 12.4 and above (Using the Cisco 7200 router to have DMVPN functionality).
-48 MB of RAM
-12 Mo of flash

Context

ESMT is a large company with several branches in the regions of Senegal.

The ESMT center being in Dakar, we want to establish a secure communication between it and the
other sites located in Thiès and KAOLACK. The aim here is to connect ESMT-Dakar to
sites ESMT-Thiès and ESMT-KAOLACK using DMVPN.
A few clarifications before we begin:
T
 hat the IKE policy (crypto isakmp policy) be identical on each of the routers.
T
 hat the IPSec policy (crypto ipsec transform-set) be identical on each of the
routers.
 hat the EIGRP routing protocol should be configured consistently, that is to say that the
T
WAN network ([Link]/24) should be declared in a different area from the LAN networks.
(192.168.x.0/24) and the network used for VPN tunnels ([Link]/24). Indeed, if this
The condition is not met, your VPN tunnels may have an unstable connection.

CONFIGURATION OF HUB R1

 e configure the public interface as well as the Loopback interface to emulate the LAN.
W
R1(config)# int FastEthernet0/0
WAN Interface Description
R1(config-if) #ip add [Link] [Link]
R1(config-if) # no shutdown
R1(config)# int Loopback0
LAN Interface description
R1(config-if) # ip add [Link] [Link]
O
 nce these basic parameters are configured, we can move on to the configuration of
the Tunnel0 interface for the NHRP.

R1(config)# interface Tunnel0

IP address of the tunnel
R1(config-if) # ip address [Link] [Link]
NHRP Configuration
R1(config-if) # ip nhrp map multicast dynamic
R1(config-if) # ip nhrp network-id 1
GRE tunnel configuration
R1(config-if) # tunnel source [Link]
R1(config-if) # tunnel mode gre multipoint

CONFIGURATION OF SPOKE R2
R2(config)# interface FastEthernet0/0
WAN Interface Description
R2(config-if) # ip address [Link] [Link]
R2(config)# interface Loopback0
LAN Interface description
R2(config-if) # ip address [Link] [Link]
R2(config)# interface Tunnel0
R2(config-if) # ip address [Link] [Link]
In NHRP, manually map the public address of the hub to
the establishment of the permanent tunnel between the spoke and the hub.
R2(config-if) # ip nhrp map [Link] [Link]
R2(config-if) # ip nhrp map multicast [Link]
R2(config-if) # ip nhrp network-id 1
We identify the NHRP resolver agent which will be hub R1.
R2(config-if) # ip nhrp nhs [Link]
GRE tunnel configuration
R2(config-if) # tunnel source [Link]
R2(config-if) # tunnel mode gre multipoint

CONFIGURATION OF SPOKE R3
R3(config)# interface FastEthernet0/0
WAN Interface description
R3(config-if)# ip address [Link] [Link]
R3(config)# interface Loopback0
LAN Interface
R3(config-if)# ip address [Link] [Link]
R3(config)# interface Tunnel0
R3(config-if)# ip address [Link] [Link]
Manually mapping in NHRP the public address of the hub for
the establishment of the permanent tunnel between the spoke and the hub.
R3(config-if)# ip nhrp map [Link] [Link]
R3(config-if)# ip nhrp map multicast [Link]
R3(config-if)# ip nhrp network-id 1
We identify the NHRP resolving agent that will be hub R1.
R3(config-if)# ip nhrp nhs [Link]
GRE tunnel configuration
R3(config-if)# tunnel source [Link]
R3(config-if)# tunnel mode gre multipoint
Routing protocol configuration
We chose EIGRP. The configuration applies once again in a similar way on
the entire set of routers (hub and spokes).

R1(config-if)# router eigrp 1

R1(config-if)# network [Link]! Activation and sharing of eigrp in the tunnel
R1(config-if)# network [Link]! Activation and sharing eigrp for the LAN
R1(config)# int Tunnel0
We disable the Split-Horizon mechanism.
R1(config-router)# no ip split-horizon eigrp 1
We ask EIGRP not to rewrite the next-hop address with that of
router that announces since it directly serves for the establishment of
dynamic link with the help of NHRP.
R1(config-router)# no ip next-hop-self eigrp 1
R2(config)# router eigrp 1
R2(config-router)# network [Link]
R2(config-router)# network [Link]
R2(config)# interface Tunnel0
R2(config-if)# no ip split-horizon eigrp 1
R2(config-if)# no ip next-hop-self eigrp 1

R3(config)# router eigrp 1

R3(config-router)# network [Link]
R3(config-router)# network [Link]
R3(config)# int Tunnel0
R3(config-if)# no ip split-horizon eigrp 1
R3(config-if)# no ip next-hop-self eigrp 1

TESTS

To verify that everything is working correctly, you can perform packet captures.
through the Wireshark software, which will allow you to glimpse ESP packets
(Encapsulating Security Payload) passing between the different routers for the
communications LAN-to-LAN. Or simply ping from the LAN of R2 to the LAN of
R3.
J ust before, notice the output of the command show dmvpn:

R2 informs us that the permanent NHRP tunnel is established between the hub R1 and the spoke R2.
It's already a good sign.

A
 lso run a show ip route
We can clearly see here that R2 knows the path to send information to the LAN of R3 via
The Tunnel0 interface and the address [Link]. NHRP will do the rest.
Let's try now to ping and trigger the NHRP resolution and the dynamic tunnel.
R2#ping [Link] source lo0

We can see that it pings without any problem! Let's run the command again now.
dmvpn:

You now see that a dynamic tunnel (designated by D in the Attrb column) has been
established directly to route traffic directly from R2 to R3. This confirms to us that
the relationship is indeed direct between the equipment and that except for the NHRP resolution, the hub
is not used in the data transfer, in other words the data plane, between R2 and R3.
AND SECURITY IN ALL THAT?

You have surely noticed by now that we have not implemented any
safety mechanism. Strictly speaking, we have only carried out so far
just the GRE side and not the IPsec implementation.
You will see nonetheless that the configuration overload is classic, light, and similar.
to be applied both on the hub and the spokes.
Creation of the ISAKMP policy
R1(config)# crypto isakmp policy 10
R2(config-isakmp)# authentication pre-share
ISAKMP key configuration
R2(config)# crypto isakmp key p@sser address [Link] [Link]
IPsec transform set configuration
R1(config)# crypto ipsec transform-set DMVPN_TRFSET esp-aes esp-sha-hmac
IPSEC profile configuration
R1(config)# crypto ipsec profile DMVPN_PROFILE
R1 (ipsec-profile)# set transform-set DMVPN_TRFSET
R1 (config)# int Tunnel0
Profile assignment in the tunnel.
R1(config-if)# tunnel protection ipsec profile DMVPN_PROFILE

And if everything goes well, you will see that ISAKMP is indeed ON.

Once this configuration is replicated on the hub and the spokes, you will be able to
to do DMVPN with IPsec and GRE combined.

To verify, we restart unpingdeR2 to R3:

Leping works, let's check what is happening at the ISAKMP and IPsec level:

We can see directly here that we have two active IPsec connections now, one
regarding the permanent tunnel between the hub and the router that was renegotiated upon activation
our new IPsec parameters and the dynamically established dynamic tunnel that has
also renegotiated as it was already established during our tests.

Use these commands to set up the tunnel establishment:

debug crypto ikev2
debug crypto isakmp
debug crypto ipsec
Debug the crypto