In the previous couple of videos,
we configured the key server and then the group members
and now, it's time to take a look
and verify that they are working and they're
working as expected.
So speaking of expected, what do we expect?
Well, the traffic policy was that traffic from the 10
networks from 10 and two 10 should be encrypted,
and the crypto amounts are being applied
on these egress interfaces right here.
So if we-- in these addresses on the inside,
I've got R2 at dot two, and R1 at dot one, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I've got R2 at dot two, and R1 at dot one,
and R3 at dot three, so we can generate traffic.
So as we send traffic-- if we did
a ping, if we sourced it from 10.2.0.2
and we destined to 10.1.0.1 or 10.3.0.3, what should happen
is, it would match the crypto ACL, as part of our policy,
the packet would be encrypted there being ESP header applied
and then outside of that, the actual IP
header used for the transport network
would be the same addresses.
So on the transport network, it would look like a packet
from 10.2.0.2 to 10.1.0.1 and then WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
from 10.2.0.2 to 10.1.0.1 and then
following that, the next protocol at layer 4
would be ESP and then behind that would
be the mostly encrypted payload that's probably the ESP header.
There are some details that can be determined
but the bulk of the payload is going
to be encrypted with IPsec, that's
what we expect to have happen.
So let's go to the CLI and take a look.
So just to make sure it's not too much change
since our last deployment, let's do on the key server--
show crypto gdoi, and we could just do a-- show crypto gdoi, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
show crypto gdoi, and we could just do a-- show crypto gdoi,
but we can also tap on key server, awesome.
Those are going to show us our key server
information and group members is three, fantastic.
So looks like everything is accounted for, and if we go
to R1, lets do a-- show crypto isakmp, and do--
SA detail.
Now the crypto ISAKMP SA, that's the connection
that we used to build the secure tunnel up to the key server.
So after this times out, we don't
have to keep this tunnel alive.
It was just initially used, there's
a default life of like 24 hours. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a default life of like 24 hours.
But there's the [INAUDIBLE] phase
one policy detail that we used as we
built that initial connection up to the key server.
Now as we get our policy pushed to us,
if we do a show crypto ipsec SA and press enter,
so this is the security association they got pushed
to us by the key server and basically, it
says traffic that's from 10 and going to 10,
go ahead and encrypt it.
So currently, we look at packets encrypted and decrypted.
We've got nothing and that's because we haven't
had any engine traffic yet.
So let's go and generate some, we're on our R1 list to a ping, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's go and generate some, we're on our R1 list to a ping,
to 10.2.0.2 but in order to make this work
and match this crypto ACL, they've got pushed to us,
we would need to source it from the 10 network as well.
So we would say source 10.1.0.1 and that flew, look at that.
That happened pretty darn quick, let's do a up arrow key couple
of times, they'll show crypto IPsec sa again,
so now, we have five packets that were encrypted
and 5 packets that were decrypted
using the policy that was pushed down from the key server. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
using the policy that was pushed down from the key server.
So and to see the details of that policy we do,
show crypto, let's do a gdoi and press Enter there.
So here's the information from show crypto gdoi,
there's a lot of data here, 848 is
UDB Port that we're using to communicate
with the key server, there is the IP
address of our key server.
As we scroll down, here is the ACL
that we got downloaded from the key server which
bases as traffic from 10 going to 10, anything is a match,
encrypt it, or if it's coming in, decrypt it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
encrypt it, or if it's coming in, decrypt it.
And want to deny everything else,
and we want to deny everything else, which means,
don't encrypt anything else besides traffic from 10 to 10.
Regarding the KEK policy, the key encryption key,
the Rekey is going to be unicast and then
we have information about the traffic encryption key, which
is based on the transforms, which
were configured on the key server
and pushed down to this router.
And what I thought would be really fun to do,
so heck, let's do it, right?
Is take a look at a packet capture, actually just do
a packet capture of traffic before it
hits the router and then after during the encryption, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
hits the router and then after during the encryption,
and just take a look at before and after,
and that will confirm the IP header preservation and also
the fact that it's being encapsulated with an ESP
header, and that the payload is encrypted.
So to pull this off, to capture the traffic
before it goes through the crypto map here on R2,
let's use the help of a little device here .50
of a little Linux box.
And what we can do is, we can have--
and he's got a default gateway pointing here,
we can go from 10.2.0.50 this device and let's go ahead
and send some traffic up to and in fact, let's do this,
I've got another device up here at 10.1.0.50, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I've got another device up here at 10.1.0.50,
and it's other than Linux box.
And what we are going to do is, we can send traffic
back and forth.
And we'll capture traffic here before it
goes through the crypto map and becomes encrypted
and then we'll see the traffic here as we capture--
there and see that it's the same source in this station IP
addresses, but we have an ESP header, now
and then the payload after that is encrypted.
So here on this device, let's verify its IP address.
This is at site 2 with a 10.2 network with an-- ip addr,
and for it's ethernet 0 interface, 10.2.0.50. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and for it's ethernet 0 interface, 10.2.0.50.
If we do a route and press Enter,
its default gateways 10.2.0.2 which is R2, fantastic.
Let's do a ping to 10.1 up at site 1, 10.1.0.50,
and let's also do a dash s for size,
and let's send 1,000 as far as the size and that way,
it'd be easier to pick up in the packet capture
as we look at the traffic that's been encrypted because we won't WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as we look at the traffic that's been encrypted because we won't
be able to longer see the payload
to see what was in there.
So we'll do that, and let that go for a few,
let me do a Control C, let's also open up a browser.
We'll send some additional traffic over.
So in the browser, we'll get a 10.1.0.50,
and that seems to work, I'll hit refresh a few times
to generate some additional traffic,
and now we've sent a nice healthy amount
of data over the network.
Let's take a look at the packet captures.
All right, so this is the traffic
it captured before it hit R2, this
is on a wire between the client and the edge router. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is on a wire between the client and the edge router.
So if we want to find some traffic here,
there's a whole bunch of ICMP that looks great.
In fact, there we go 1042, let's do a filter
on the size of the packet.
So I've just entered a filter to set
anything greater than 1,000, and there's our ping request.
We also have some TCP traffic that's larger than 1,000.
All right, so that'll help a little bit.
So this is the pre-traffic, we grab
one of these from 10.1.0.50 to 10.2.0.50,
and if we look at the details, this is ICMP traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and if we look at the details, this is ICMP traffic.
So if we look at the same set of traffic
after IPsec has happened to it, we
should have the same source and destination IP addresses
but with an ESP header protocol 50 and then beyond that,
all the payload is encrypted.
So let's check that out, so I'm going
to go ahead and grab that filter, right click, copy it,
and I'm going to use everything over here and the second one
as well, so I'll filter out everything
less than 1,000 bytes.
So we'll go ahead and go to apply that filter.
And look at that.
So here, we have all this ESP traffic, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So here, we have all this ESP traffic,
so the packets are going to be a little bit bigger because we
have the encapsulation with the ESP header
and then the new outside IP header which is same addresses
involved that's been applied.
So it can be a little bit bigger but we have 1126 here,
and we have 1510, so I think this was our TCP traffic,
and these were our ICMP traffic.
However, if we look at the details at layer 3,
it has a source and destination addresses, not a surprise,
but if we take a look at the next protocol, which
is protocol 50 and we look at the header there, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is protocol 50 and we look at the header there,
it's ESP and then the payload, is all encrypted.
So if we did a view and we looked at the packet bytes
as well, this is just a bunch of gobbledygook,
we can't make sense of what that is.
It could be a HTTP traffic for all we know,
or it could be a ICMP payload, we don't know,
it's all encrypted, so it will be decrypted on the other side
and then forwarded on to its final destination.
So in this video we've taken a look at some commands,
we can use at the CLI to verify our get VPN implementation
and also, verify its workings with some pre-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and also, verify its workings with some pre--
and during captures regarding the actual traffic.
So Thanks for joining me in this video,
and I'll see you in the next one.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing.