Now we're going to hop in the lab and check out IPsec in action.
First,
we're going to check out our packets going back and forth
across the VPN link that I already established.
This will be without IPsec applied to it.
Then we'll apply our IPsec config to the VPN and see what's going on
in Wireshark with them and how they're different.
After that,
we'll hop into the CLI again and see some of the information that we
talked about throughout this module in action.
Well, let's get into it.
All right, so here we are back in our lab.
The reason why we're doing this lab is to get a feel for how the IPsec
suite functions when it's fully implemented and to be able to see the
different pieces and components in action.
This will give you a taste of what it can do for us as we compare the normal VPN
packet visibility with that of the IPsec packet visibility.
You'll be so surprised at what we can see.
So our setup is the same as in the previous module.
I haven't touched our internet router at all.
The only changes I made were to our Globomantics routers.
I configured a quick, simple DMVPN connection between the two.
I also configured the IPsec suite,
but I didn't apply the configurations to the tunnel just yet.
Doing a show run, you see this basic DMVPN setup.
I'm using the 192.168 .1 .0 /30 network for this VPN link.
Note that the tunnel protection is not on here.
We'll talk about that later on.
Looking at the IPsec configuration with the show run pipe section crypto,
you see that there are a few familiar items that we've been talking about.
I have my ISAKMP policy defined so it can help us establish the SAs.
We're encrypting with AES using a pre-shared key
and using Diffie-Hellman group 2.
Our key is Cisco, and the peer address is here.
For IPsec, I define what security protocol,
ESP or AH, here, along with the crypto algorithms for the components.
I made the IPsec profile named PRO here.
Now, running the same show command on the Site1 router,
you see that the configuration is almost exactly the same
with the exception of the peer address.
These configurations must be the same; otherwise,
IPsec won't work with the exception of that address.
Now I'm going to start our capture really quickly on the
internet router interface so that we can see the traffic and
figure out how the protocol works.
Now that that's turned on,
I'm going to hop into our Globo_HQ router and do a ping test.
And it's good to go.
Now I'm going to telnet into the remote site so that we
can get some good data in our capture.
Remember, this is without IPsec applied to the datagrams.
I'm logging in with my username, joe, and my super-secret password.
While I'm in here, I'm going to create a user really quickly.
I'm giving this test user privilege 15 access even though I shouldn't.
But let's say someone did this.
I'll give it this password, which is not very complex.
Even if it were complex though, it wouldn't matter in this situation.
Let's see why.
I'm just going to exit out of the telnet session and flip back into VM Maestro.
I need to download the capture so that we can investigate what we see.
So here we go.
It's opening up in Wireshark for us.
I love this program.
It gives us such a great view of the data.
We can see here we have our five echo requests and replies from the ping
test that we did as soon as we started the capture.
With ICMP packets, you can see anything that's inside.
Moving down the packet list, we see a packet from the VPN connection.
DMVPN uses GRE tunnels for its functionality, which is why it's here.
Scrolling all the way down, there's just a lot of telnet packets now.
Let's take a look.
I'm going to click the easy button and right-click one of these telnet packets.
I want to follow the TCP stream.
What this is going to do for us is it's going to put together all
of the data in the packets to show me the big picture of what's
going on during this telnet session.
I love this feature of Wireshark.
And would you look at this.
You can see everything.
This is due to the fact that a normal VPN connection is not
encrypted unless you apply encryption to them.
We can see my password that I entered,
as well as the username and password that I created
when I was telnetted into the router.
It even shows a mistyped password that I was typing
out and changed my mind mid-command.
Every single character that you type goes back and forth.
So this is all plain text.
That's crazy, huh?
Now,
I want to go into the tunnel configurations on each router and
configure the IPsec protection for them.
As I stated earlier, I'm using ESP for this,
so our packets should be encrypted, and the capture will reflect that.
On these routers, going into the tunnel interface,
I have to type in the command tunnel protection ipsec profile and then
the name of the profile to be applied to the interface.
As you can see when I hit Enter,
the router is already giving me a thumbs up saying,
hey, ISAKMP is turned on, meaning it's ready to help us establish the SAs.
I'll just apply it in the other router, and here we go.
Moving back into the HQ router, I'm going to do our ping test again,
and I'm going to do the exact same thing that we did
before by telnetting into the Site1 router,
logging in, and creating a user with a high privilege level.
Now it's time to pull down the capture and show you the magic of encryption.
As I'm scrolling,
I want to stop here and show you the start of the IPsec SA negotiation.
Here, the ISAKMP protocol is running in main mode,
which is one of the modes of IKE version 1.
We see information such as SPIs and versions,
as well as the payload information.
We'll cover this extensively later on in the course.
So with this SA establishment happening,
we know our IPsec connection is forming,
and anything after that, aside from non-tunnel traffic,
should be encrypted.
Now, what's next after all of these IPsec connection packets is an ESP packet,
or actually, several ESP packets.
And check this out.
We have ESP not showing us anything about the payload.
In fact, it barely shows us anything at all.
Scrolling, we don't see our ping or telnet packets at all.
It also won't give us the option to follow the TCP
stream since everything is encrypted.
Look, our internal VPN IP addresses are hidden as well.
Remember,
ESP encrypts the entire packet and replaces the header if it's in tunnel mode,
which is what we're configured for.
Okay, now going back to the router for a second,
we have a few show commands that really help us see the IPsec components.
The first three commands are show crypto ISAKMP commands.
The option of peers shows us the information like the peers that
our SA goes to and what port is being used.
The policy option gives us the information about the ISAKMP
policy that was configured with the algorithms,
methods, and lifetime for the SAs.
The sa option tells us the status of the SA,
which for this, it means we're established and good to go.
The detail version of this command shows us a little bit more information,
almost combining the sa and policy options of the command.
There are a few IPsec show commands that I want to demo that help
us with this information about IPsec as well.
The first one is the sa option, which gives us so much information.
It tells us all about the peers and identities.
It tells us how many packets were encapsulated and
decapsulated and encrypted and decrypted.
It also gives us the MTU information about the link,
as well as the outbound SPI for it.
Viewing more info, we get the inbound SPI information as well,
along with a lot of the connection options.
The spi-lookup option just gives us a little bit of
information about the active SPIs in the device.
And finally,
the ipsec profile command allows us to see the configurations for
the profiles that are currently on the router.
Whoa, we talked about a lot of stuff in this module,
and my head is now full of this wonderful knowledge.
This is all very informative,
so let's break it down really quickly and review what we learned.
We started out this module by talking about building up IPsec,
and we learned that there are several building blocks to it,
such as the security protocols and the key management.
We then detailed several components that help all of the
inner workings of IPsec function properly.
These included things like the SPI and the SA and peer authorization databases.
After,
we configured the SA establishment protocols that make up
IKE and how they fit into the puzzle.
These included ISAKMP, OAKLEY, and SKEME.
Finally, we hopped into the lab and saw IPsec in action.
In the next module,
we'll be talking about using IPsec in the enterprise and
detail many different implementation options for it so that
you can use it how you see fit. Join me in the next module.