Let's take a quick moment to talk about the phases again
before we jump into the IKEv2 demo.
I know we mentioned this briefly earlier,
but IKEv2 has two phases available, just like IKEv1.
Now these aren't named at all like they are in IKEv1,
but they're considered similar in fashion with regards to the purpose of them.
IKEv2 phase 1 establishes the ISAKMP SAs for us,
or the parent SAs,
that we use to securely transmit the information to build the IPsec SAs.
Phase 1 is what we consider the IKE_SA_INIT phase.
Now, I don't think anybody goes around talking about the IKE_SA_INIT phase,
so we'll continue to just call it phase 1 and know and understand that it
means we're establishing the first set of ISAKMP SAs.
The second phase, as we went over earlier,
is that IKE_AUTH phase where we're establishing the IPsec SAs just
like in quick mode and phase 2 for version 1.
The thing with this is that we're calling these IPsec
SAs in version 2 the child SAs.
I wouldn't really say that these are solid phase names or anything,
but it's important to know what they're being referred to as you're
having your watercooler conversations about IPsec.
So not much different with the purpose of the phases,
really just the exchanges that occur within them.
Now we're going to hop into the lab and practice configuring and
analyzing IKE version 2 so that we can see it in action.
We won't configure this with the remote access VPN like we did earlier,
but we will configure this for a site-to-site VPN to
see some of the options available.
We'll start out by configuring this connection so that we can
secure our traffic and get the packets captured.
Then,
we'll pull up the capture to see what's going on and investigate
the behavior of the exchanges that we see.
Let's hop in and get started.
Okay, this is going to be a fun lab.
I really like the security and benefits that IKEv2 provides us,
but the configuration can be a little bit tricky.
As you can see, they're a little longer than the IKEv1 basic configs.
These are available in the course downloads as well and go along
with the base configs from the first demo.
Let's review these configs before we start the capture and paste them into
the devices so we can understand what we're doing here.
The first section that we have here is for the IKE version 2 proposal.
This is where we define the encryption, integrity,
and the Diffie-Helman group strength for the
communication between the two devices.
Do you notice anything out of the ordinary here?
All of my commands here to start the sections are either IKEv2 or IPsec.
There's no ISAKMP commands in here.
This is because we're using version 2 instead of version 1,
so our commands changed to signify the difference.
Another difference here is that the encryption choice that
we have to choose from is not the same.
We're using aes-cbc-128.
You'll have options in the CLI, but this one stands for Cipher Block Chaining,
which is a mode of encryption that's available to us.
Then we move on to the IKEv2 policy where all we're really doing
in here in here is tagging the proposal that was in the previous
section so that it knows to use this.
This is the only option in here we're using for our basic demonstration.
After this, we have the IKEv2 profile being created.
Now this one is a doozy.
We're matching the identity of any address here,
similar to what we did in the IKEv1 demo.
Just under it,
we're required to define both the local and remote authentication types,
which we're using with pre-shared keys.
If you are using EAP or PKI authentication,
these commands will vary, along with the rest of the configuration.
The transform set commands are the same as before,
and we're using tunnel mode again.
It's my favorite since it hides everything.
Finally,
we have our IPsec profile that we create with an additional
command on top of tagging the transform set.
This here is where we identify the IKEv2 profile that we want to use for this
IPsec policy so that we can have our authentication methods,
keys, and identities matched to the right IPsec configuration.
The tunnel configuration is no different than what we've
been using since we're using DMVPN for it.
And on the other side,
it's all the exact same so that we don't have any
mismatches with the exception of our addresses.
So now let's hop into VM Maestro and turn on the packet capture
before we paste the configs into the routers.
And now that that's done, it's time to get our IPsec on.
As I'm copy-pasting these into the devices,
I want to point out this line right here.
After creating the IKEv2 profile,
the router is giving us a warning that we need to have both a
local and remote authentication method,
as well as a match identity or a certificate so
that we know who to authenticate.
As you're doing this in your lab,
be sure to get that syslog message saying that ISAKMP is turned on.
Now I'm doing my ping test to ensure that the link is up and
working with my 192.168 .1 .2 address as the destination since
that's my non-routable internal address.
And it works.
I want to show you something as we're looking at the
SAs in here about how this works.
We're using IKEv2,
so the syntax to check out the SAs for phase 1 is different now.
Notice how the how show crypto isakmp sa command gives you nothing?
It's because even though we're using ISAKMP still,
the router needs to be able to identify the difference between the two versions.
Before we check out the IKEv2 SA, let's check out the IPsec one.
Looking at it,
even this doesn't show the IKEv2 SA information or
even tell us which one it's using.
It's only showing the same normal IPsec SA information that
we've already seen throughout this course.
So let's issue the command show crypto ikev2 sa and see what we get out of it.
Okay, here we go.
We have all of our parameters shown,
and it gives us the info about the IKE version,
the two endpoints and ports,
as well as all the other information that we
programmed into the IKEv2 configurations.
That's pretty cool, huh?
I'm going go ahead and stop the capture now that we have enough
data to analyze the packets and see how they work.
I'll name it IKEv2 PCAP, and it's included in the exercise files for download.
Okay, this was easy to find.
Nice and short for the PCAP.
With some of these, if you need to,
feel free to filter out some of the data that's unnecessary.
So looking at these packets,
I see that IKEv2 SA establishment was successful as we're seeing the
ESP packets come across the internet interface.
Let's dive into these exchanges to see what they contain.
Looking at the first packet, notice how it says Initiator in the flags?
Yeah,
that means this device is responsible for the reliability that
we were discussing earlier on in the module.
So for this one, the exchange type is the IKE_SA_INIT,
and as I go through and explain all of the transform payloads,
we see our cryptographic algorithm is identified so that we
can see if the other end agrees on them.
So, looking at the second packet in the exchange from the responder,
it's sending back the same information, but it isn't like version 1.
It's just the peer telling the initiator that they're going to be
using the protocols identified within the exchange.
Remember, in version 2, the two ends don't negotiate the parameters here.
And then, as I move into the next exchange,
this one is kind of like the quick mode exchange where we
can't see any of the data that is transmitting because it's
encrypted data in the packet.
So after this short exchange, the SAs are built,
and our pings went through the IPsec tunnel that we built
as encrypted and authenticated packets.
The cool think about IKEv2 is that these exchanges only
took four packets to complete before we were able to start
setting out the encrypted ones.
Compare that with aggressive mode exchanges where you still have at
least six between aggressive mode and quick mode.
IKEv2 beats it from a speed factor.
One more thing to cover before we wrap up the module for this one.
Notice how the port doesn't change between the exchanges like
it did during the remote access VPN demo?
That's because the NAT-T mechanism did not detect any NAT
devices on the link between the two peers,
so it's not necessary to use that service.
Also,
think about the initiator/responder relationship and how this can
benefit your organization with reliability.
If that initiator never received a response,
which is also tagged in the Flags field,
then it would be forced to either resend it's packet and information or terminate the connection and try another time.