All right, my friend.
It is time.
Time for what?
It is time to verify that what we configured
based on our IKEv2 and FlexVPN that it's actually working.
So let's go to the CLI, and let's verify.
All right, let's first of all, start with the IKEv2 stuff.
Let's do a show crypto IKEv2, and let's say proposal.
So based on our configuration, we tweaked the default.
So here's what we offered for encryption, data integrity,
the pseudorandom function, and also the Diffie-Hellman group. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the pseudorandom function, and also the Diffie-Hellman group.
And hopefully, here's what should happen,
if we negotiated a tunnel successfully with R2,
we should be using for IKEv2 Security Association
some of these parameters.
Hopefully the most secure of these parameters.
So the way we verify that is the show crypto, IKEv2, and SA.
And boom, that'll show us our security association.
There it is.
I love it when a plan comes together.
So this is showing the local and remote IDs.
The 500 is UDP port 500, which they used to negotiate. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The 500 is UDP port 500, which they used to negotiate.
And if we look at the Encryption, it's using AES-256.
Great, that's right from our proposal.
That's what we would expect.
And I notice that it's using the most secure
of those that were being offered,
and that were agreed to during the initial exchange.
For hashing, we have SHA512, which is represented
right here in our proposal.
And if we scroll a little over to right,
here for the Diffie-Hellman group, they chose 16.
And that's because we modified the default IKEv2 proposal
to say, hey, we'll support 16.
It's also showing here that they're using PSKs, Pre-Shared WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's also showing here that they're using PSKs, Pre-Shared
Keys for the authentication.
Fantastic.
So that's the IKEv2 security association as expected.
Next let's take a look at the IPsec SA.
Let's do a show crypto, IPsec, and let's do transform sets.
So we have a couple of transform sets.
We have the default, which we didn't use.
And we have our set, and we included that inside
of an IPsec profile.
So we do a show crypto, IPsec profile, spelled correctly. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we do a show crypto, IPsec profile, spelled correctly.
This shows us our IPsec profile here.
Our-v2-Profile, which includes the transform set
called Our-Set.
Fantastic.
So if this was used, we should actually
have a IPsec security association
that's using these parameters.
And to verify that, we do a show crypto, IPsec, SA.
And we're saying, hey, Keith, this command
looks like the other commands with IKEv1.
That's because it is the same command.
We're talking about the actual IPsec tunnel itself.
So currently we have encaps and decaps of 0. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So currently we have encaps and decaps of 0.
So we're not using the tunnel too effectively,
it would here at the moment.
And if we scroll down, check this out.
Here it's showing us the transforms involved,
they're AES-256 for encryption, and SHA 512 for hashed message
authentication code for data integrity.
Fantastic.
So there's an inbound security association,
and there's an outbound security association
is the two way street with IPsec SEC.
Now the next question is why are we
not encapsulating or decapsulating traffic.
Another command, this is pretty cool, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Another command, this is pretty cool,
even though we did not configure crypto maps,
because we applied a tunnel protection
profile on an interface for IPsec,
we can still do the show crypto map command is still
very, very useful.
Check this out.
So we do a show crypto map, and press Enter.
Here it's showing us that on tunnel 0,
it's showing us the details.
Here's our peer, there's the transform set and use, just
another way to peek at the information,
even though we didn't literally apply a crypto map.
Another interesting note here, if we didn't use tunnel mode WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Another interesting note here, if we didn't use tunnel mode
IPsec on the tunnel interface, it also
would show here that the entering traffic
is GRE traffic as opposed to just IPsec natively.
So let's solve the next problem of why are we
not encrypting or decrypting any traffic.
So show crypto, IPsec, SA, and sure enough,
it says encaps and decaps nada, zero, zippo.
Let's do a show IP route, and that would explain it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That would explain it.
So the problem here is that we have a great IKEv2 security
association.
We checked that, out matches our policy.
We have a great IPsec SA, we checked it out.
But the reason it's not being used to encrypt or decrypt
traffic, is because the tunnel interface
from the routing table isn't used for anything.
It's not even in the routing table
as far forwarding packets.
So to solve this, we need to add some routing.
So that the router will feel like,
oh, I need a forward traffic through that tunnel interface,
so that the encryption can go ahead and be done and protect
that traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that traffic.
So we'll address routing in the next video.
So I'll see you there in just a moment.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing.