DMVPN is not a protocol.
It's more of a solution.
GRE tunnels are used and encapsulated using the IPsec ones.
So it's GRE over IPsec if we're wanting to encapsulate the
entire packet within a DMVPN implementation.
DMVPN is what we already saw in the previous module when we were
looking at how ESP affects the IPsec packets.
We could get into a whole course just digging into the functionality of DMVPN,
but we're going to avoid that for now.
The solution is made up of three technologies that are
standards-based: Next Hop Resolution Protocol,
or NHRP; mGRE, which is multipoint Generic Routing Encapsulation; and IPsec.
The solution gives us the ability to provide a full mesh VPN topology
that's IPsec protected and can be dynamically established.
We're about to hop into the lab and start configuring,
verifying,
and analyzing the DMVPN connection between our two sites so that we can
see more about this protocol implementation and the underlying
functionality of the IPsec protocol in general.
We're first going to learn how to configure our basic DMVPN connection with
IPsec and walk through some of the configuration options.
I'm going to only use AH for this one so that we can see how it's helpful to us,
but that we still ideally need ESP to be as secure as we can.
Then,
we'll verify that it's working as expected and debug the router
to see how the router handles the packets.
After,
we'll go into Wireshark and look at the captures that we pull so that we can
see how AH works and how the IPsec negotiations occur.
Let's hop into the lab and get started.
Before we get configuring, I want to get the packet captures started.
We're not going to filter it on anything this time so that we can see
all of the traffic coming into the internet interface.
As you're following along, you can capture based on whatever criteria you want,
as long as we see those packets that are part of the
IPsec suite that we've been looking for.
Now that the capture is set and running,
we'll go back over to the CLI and get started.
So within this, as you can see, we have no tunnel configured.
This is because we're about to do so right now.
So we're going to go ahead and create our Tunnel0 interface
and define the tunnel mode as a GRE multipoint tunnel since
we're using it for DMVPN.
We set the source interface for the tunnel and then get
into the NHRP portion of the configs.
We set our network ID to 123 so that the tunnels know which ones to connect to
just in case there are multiple running out of the router.
We will map our multicast packets dynamically and
give it our 1.1 /30 IP address.
That's all we need to do for the tunnel setup.
Now for the basic IPsec configuration.
I know we showed this as completed in the previous module,
but we'll go through it and see what some of our options are here.
We'll first define our ISAKMP policy.
As we're defining this, we have a few options for the parameters to define.
We can choose authentication, encryption,
the Diffie-Hellman group, and the hash.
We can also define the SA lifetime for this if we wanted to.
Within the encryption option, we are presented with three choices.
I'm going to choose AES since it's the strongest encryption available here.
For the hash algorithm, we have a few more choices,
the MD5 and the various SHA hashes that we can select.
Let's go with 256 for this demo.
Remember, whatever your configuration is,
just make sure the other end of the connection is compatible and has
the same exact configuration options selected.
For the authentication, I'm just using the pre-shared key to make it easier.
Up next, I'm defining our pre-shared key for the ISAKMP setup.
The key is PSlab,
and I'm specifying the remote endpoint that we're going to use this key for.
You can use a 0.0 .0 .0 address in here to allow anybody in,
given that they have the right password and algorithms connected.
For security purposes though,
you should be as restrictive as possible when defining the address.
There are not too many other configuration options that we really want
to check out for this DMVPN implementation of IPsec,
so we'll move on to the IPsec portion of the configuration.
Here,
we have the ability to define some options as far as how the router
is going to handle different IPsec situations.
In here, we're going to only worry about the profile and the transform set.
The transform set is where we define what security protocols to use.
We can either use AH, ESP, or both.
For this demo, we're going to use AH so we can check that out in action.
So we're going to go with the SHA-256 setting for AH.
Within the transform set, we need to define what mode we're going to run this in.
Remember earlier when we were talking about the differences
between tunnel mode and transport mode?
If you need a refresher on that, check out that section earlier on in the course.
We'll select tunnel mode for this one.
The final thing that we need to do is set up the IPsec profile
that we'll apply to the tunnel interface.
Here, we'll call it PRO again,
and we need to tell it what transform set to use so that it knows
what security protocols are going to be used for it.
Now,
we need to apply this to the tunnel interface so that ISAKMP is
turned on and is ready to negotiate those SAs for us.
Hopping over to the Site1 router,
we're going to apply the exact same configuration with
the exception of a few small items.
Mostly, the IP addresses are going to change,
and there's a little bit of added information for the VPN connection
that's a little outside of the scope of this course.
Now I'm going to hop on over to the HQ router and do a ping test.
Before I do, look at this message that we received.
The router is telling us that we're receiving a packet,
most likely a part of the VPN connection trying to establish itself,
but it's not an IPsec packet.
The router is going to drop this because it's not
able to authenticate that packet.
Doing that ping test now, as you can see, it's not working.
Why do you think that is?
Well,
it's because we didn't apply the IPsec configuration to
the tunnel interface on the remote end,
which is also the reason for that syslog message on the router.
So we're sending the packets using AH from the HQ router,
but the Site1 router can't authenticate them and doesn't
know what to do with the information.
Even if it did, since it's not using IPsec going back yet,
the HQ router would drop the traffic because it's not
in the format that it's expecting.
Hopping over to the Site1 router,
we'll apply that configuration to the tunnel interface.
And now that it's turned on and we have verification, our ping is going to work.
Up next,
I'm going to configure EIGRP real quickly so that we can
exchange the routing information over the VPN link for our
actual HQ and Site1 employee networks.
This will give us the ability to connect to the resources at each site so that
the employees can work and access the resources as desired.
Our adjacencies come up, and we can ping each other.
Remember, this is all happening across our IPsec link,
so we're securing our traffic within the IPsec tunnel.
I'm telneting into the Site1 router so that we can do the same
verification checks that we did previously,
creating a user account after logging in with our own account.
Again, typing in my super-secret password,
I'm able to log in over the VPN connection and create this user account.
Now I'm going to pull up my capture of the traffic so
that we can investigate how HA really behaves and if it's
worthwhile to use this alone.
I'm going to scroll all of the way up to the bottom of the
capture so that I can see where the telnet session ends and
view the entire stream for it.
Remember, with ESP,
this option isn't available because everything is encrypted
and encapsulated into the ESP packets.
But check this out.
We're still using IPsec, but someone on the wire can still sniff the packets,
reassemble our TCP streams,
and get all of the information that we've sent over the connection.
We can see the passwords and the usernames and the banners.
We can see everything.
We would be able to grab financial documents or employee
personal identifiable information if we were a bad guy and
you set up IPsec using only AH.
This makes me go crazy because you're not really
protecting yourself or your organization.
The data is still there.
It's still visible.
All we're doing essentially is verifying the integrity of the data and
authenticating that it's coming from the right source,
but it provides us absolutely no confidentiality,
which is a must in today's world.
Scanning the authentication header, we see the interface,
source, and destination IP addresses just like we would have with ESP.
But look at this!
As we check out the other headers and fields,
we have this IP header that preserves the information about the
source and destination address for the VPN tunnels.
These are our addresses out in plain site.
This is another reason as to why AH doesn't really provide us with the
benefits that we want or need in an organization.
Okay, really quickly now,
we're going to check out the CLI outputs of the debug
commands that we'll use to investigate exactly what happens
when you stand up the AH connection.
Let's break this down as we're applying the IPsec configuration to the tunnel.
We can see that the router is starting to listen in for its
messages here and starting to build up everything.
Here, we can see some messages about the SADB that we talked about earlier.
It's creating the information for Tunnel0 and attaching the
configurations that we have to that interface within the database.
Right here,
the router is going through and taking care of the IKE
negotiations and figuring out the specific items to create
this secure connection that we want.
Finally, it's opening the sockets and connecting.
As you can see here,
we have our IPsec SAs that are created using IKE successfully.
This means that our SAs are created and ready to begin processing the IPsec packets.