When implementing IPSec site-to-site VPN,
there's a couple of different schools of thought
about how to get it done.
One is just throw some stuff in and maybe it'll
stick, and then troubleshoot your way out of there.
That's a very time consuming process.
Now I want to walk you through some of the verification
troubleshooting steps.
We'll do that for sure in this set of videos.
So to start, let's take a look at a topology.
Let's identify what we need to accomplish
with the IPSec site-to-site VPN tunnel.
And also just identify at a fairly high level
of those components that we have to think about before we
configure to make it work. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
configure to make it work.
So let's use this topology.
Let's imagine that we've got these two sites.
We'll call router 1 over here--
let's call this site 1.
And over here, we'll call this--
for lack of a better name, we'll call it site 2.
All Right, there we go.
Now if we have resource-- and these sites,
one could be a headquarters and it could be a data center.
It really doesn't matter.
The goal is we want to share information and resources
between these two sites.
And we want the traffic to be protected
as it crosses over the network or networks
between those sites. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
between those sites.
So over here on the left, we have 10.1.0,
over here we have 10.2.0.
We use that as an example to start with.
And what we want to have happen is that if PC1, for example,
is trying to ping PC2 at 10.2.0.50,
that traffic would be forwarded to the default gateway of PC1.
R1 would get that packet, look at the destination IP address
and say, well, this is coming from 10.1 and going to 10.2.
I need to go ahead and encrypt it.
So it's going to encrypt.
Also it'll use hash message authentication code or anything WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Also it'll use hash message authentication code or anything
else we specified with it as well,
and it'll take that, encrypt it, wrap it up, and then ship it
as a protected packet over to the reachable address of R2.
We will then decrypt it, or add it on to PC2 so--
PC1 and PC2 are totally unaware that this encryption happened.
They're just happy at the packet, or I don't know.
Are computer's happy, maybe.
So it gets the packet and responds back.
It would go back to the default gateway.
R2 would say, Oh, this is going from 10.2.0.50
over to 10.1.0.50.
That matches our interesting traffic for IPSec. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That matches our interesting traffic for IPSec.
He would encrypt it or she would encrypt it and send it over
to R1, who would then decrypt it and forward on its way back.
So that's great.
So what are some of the elements we
need to plan for to make this all
work if we're doing traditional IPSec site-to-site VPNs?
Well, if we're using IKE version 1--
and we'll have separate videos and sets
of videos on IKE version 2, but with IKE version 1,
there's two phases.
And one of those phases is called IKE.
IKE is an acronym for Internet Key Exchange, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
IKE is an acronym for Internet Key Exchange,
and it's called phase 1.
I'm very grateful because they were engineers.
I'm very grateful they didn't call it IKE phase 0,
but IKE phase 1 is the details about the initial tunnel
that R1 and R2 are going to set up with each other.
So it's called the IKE phase 1 tunnel.
And to set that up, we need to agree on certain things,
including the authentication.
So how are these two routers, that they built the tunnel,
how are they going to prove to each other they are authorized
and who they say they are?
Are we going to use a pre-shared key on each one? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Are we going to use a pre-shared key on each one?
Are we going to use digital signatures?
What are we going to use?
So we need to decide on that, and then
implement that solution if we want the IKE phase 1
tunnel to work.
We'd also need to plan on the hashing
that we're going to use.
Now the hashing is for data integrity.
So if a bit gets manipulated or a packet gets manipulated,
I should say, the other side can say, well,
this doesn't match up, and discard it, and not accept it.
So hashing is about data integrity.
And we might be limited by the iOS
as far as which hashing methods are supported.
So if this guy supports like five great options, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if this guy supports like five great options,
and this guy has two fairly good options,
we might have to settle on matching
on one of the good options and use that because it's
common between them.
Another thing we'd have to decide for IKE phase 1
is the encryption.
So are we going to use DES?
No.
Are we going to use triple DES?
No.
Are we going to use some flavor of AES?
Yes.
So we need to land on a flavor of AES supported by both sides.
And as I'm looking at the list here for IKE phase 1,
in our earlier videos, we talked about some of the fundamentals
for IPSec and we had the term HAGLE, which WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for IPSec and we had the term HAGLE, which
has been very helpful for me.
It helps me remember the options.
So we've covered H for hashing, we've
covered A for authentication, E for encryption right here.
The G-- OK, so we also have the Diffie-Hellman group.
Diffie-Hellman is a way to generate king material.
Think of it like how do you GRE secret keys that
are R1 and R2 can use for encryption, decryption,
and how can they negotiate those over an untrusted network?
And the answer is they can use Diffie-Hellman
to come to that result. And regarding Diffie-Hellman, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to come to that result. And regarding Diffie-Hellman,
there's just not one size fits all.
We have different moduluses and different ranges.
So we need to come together on a Diffie-Hellman group
that we can both support so we can generate the keys that we
can then use for our encrypted sessions back and forth.
So that's the G for Diffie-Hellman group,
and then the L is for lifetime.
So by default, the IKE phase 1 tunnel is one day.
Now the question might come up, OK, are we ready to go?
Can we start configuring?
The answer is no.
I don't know yet because we are taking a look at IKE phase
1 and the detail there, but we also
need to be aware that we need to configure, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
need to be aware that we need to configure,
and plan out, and implement the IKE phase 2 tunnel as well.
Which from our previous videos on IPSec fundamentals,
the IKE phase 2 tunnel is literally the IPSec tunnel.
So when a user from site 1 sends traffic to site 2,
it's the IPSec tunnel, the IKE phase 2 tunnel,
that's being used to encrypt and protect that data,
and ship it across the network.
And so for IKE phase 2, also called the IPSec tunnel,
what do we need to consider?
Well, we can use some defaults for a few pieces, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, we can use some defaults for a few pieces,
but here are some of the critical things
that we'd want to consider-- the encryption.
So even though we specify the encryption up here for IKE
phase 1, we'd also have to specify the encryption
for the IPSec tunnel itself.
They don't have to be the same.
They just have to be supported by both sides,
but we could use like AES 128 for IKE phase 1,
and AES 256 for phase 2 perfectly fine.
We'd also want to specify the interesting traffic.
Now when I say interesting from the perspective of IPSec,
that is the traffic that should be encrypted
if the router sees it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if the router sees it.
So in our case, the encrypted traffic
is going to be a source from 10.1.0 going to 10.2.0
from R1's perspective.
And from R2's perspective, it would be traffic source
from 10.2.0 going to 10.1.0.
So that would be specified as part of our IKE phase
2 instructions for the routers.
Another thing we need to specify is who is the peer.
So from R2's perspective, it will have to know R1,
and from R1's perspective, it will have to know about R2.
Think of those guys as the respective other end WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Think of those guys as the respective other end
of the VPN tunnel.
And then are going to use tunnel mode or transport mode?
Now in a site-to-site VPN-- and we
are going to use tunnel node because we're
going to take like PC1's traffic and take the entire IP
packet, including the original source [INAUDIBLE]
IP addresses, encapsulate that and then
add a new IP header for transport
over the external network or the transport network.
So we're taking all that data and canceling the whole thing,
which is tunnel mode.
So if we have some other VPN solutions, which
we have in separate videos, we might be using transport mode WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we have in separate videos, we might be using transport mode
with solutions like DNVPN.
But for a site-to-site VPN, we want to use tunnel mode.
And then one other option I'd like to specify here
is that we could recycle some of the king material
that was made by Diffie-Hellman during IKE phase 1,
or we could generate our own new king material
by running Diffie-Hellman again.
So if you want to run Diffie-Hellman again
for the IKE phase 2 tunnel, we could do that.
And that's referred to as PFS, perfect forward secrecy.
It's simply not recycling, you're
not reusing the king information from IKE phase 1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
not reusing the king information from IKE phase 1.
And has a whole new set, which it will create and run
Diffie-Hellman again just for the keys
involved with IKE phase 2.
So what's the next logical step?
Well, now that we know that all those details need
to be specified, or we know we want
to take some of the defaults-- whatever the case is,
we need to plan on those details that we are going to supply.
So here's what I'd like to do.
In the next video, let's consider--
let's design a plan together about what
we want to use for IKE phase 1, what authentication, and what
hashing, and what encryption, and so forth.
And we'll make that plan. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we'll make that plan.
And that way when we go into subsequent videos
and start to implement the IPSec, it won't be a mistake.
What should we use here?
That's the wrong time to think about it,
when you're at the CLI.
So in the next video, we'll do the planning
for our implementation.
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.