For our discussion regarding an IPsec site site tunnel that involves an NSX
environment,
let's imagine we have two sites. So over here on the left we have site A, and
that's
beyond done, we have site B over here. So on the left with our NSX environment,
here is a segment
with a VM connected to it. And over here on the right, we're not using NSX, we
just have a
traditional router, which is connected to a network segment. And then we have a
computer over here
as well. So perhaps this physical router is routing for a virtualized
environment, and that's why
there's also a VM over here on this site. In either case, this is a T0 router WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
there's also a VM over here on this site. In either case, this is a T0 router
over here at site A,
and this is a physical router over here at site B. And they both have
connectivity to the internet
through a service provider. So if we wanted to provide connectivity between
this segment,
the 10330 network address space that we're using here, and the 1080 address
space for using over
here, there's a few problems with that. Number one, unless we do NAT, to send
that traffic out,
the internet's not going to forward it because these are RFC 1918 private
address spaces.
Or even if we did NAT, we have to do double NAT, where we're doing source now WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Or even if we did NAT, we have to do double NAT, where we're doing source now
on this end and
destination out over here. Once again, because we have RFC 1918 addresses, let
's assume just for
discussion that we're doing all the NAT required, we still don't want to just
send packets back and
forth over the internet if they're not encrypted. Because an eavesdropper who's
looking at those
packets, if they see that traffic going back and forth, and they can capture
that traffic,
they also, if it's not encrypted traffic, have access to the plain text context
of the payloads.
So if we want connectivity between this network segment over here and this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we want connectivity between this network segment over here and this
network segment over
here, and we want to send that data over a public or an untrusted network, and
we don't want to do
a whole bunch of games with NAT, what we can do is implement an IPsec site to
site VPN tunnel.
And when talking about IPsec VPN tunnels in general, there's two types. There's
the site to site where
we're building a tunnel between, for example, site A and site B, and there's
also an option for
something called a remote access VPN tunnel. And a situation like that would be
a user,
maybe at their home or a coffee shop, and they're building a VPN tunnel into WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
maybe at their home or a coffee shop, and they're building a VPN tunnel into
headquarters. Maybe
we're here to site A or they're building a VPN from their PC over here to site
B. And that's
an example of a remote access VPN tunnel. And now that we've mentioned that
that type of tunnel
exists, let's go ahead and clear that off, because our focus in this set of
videos is going to be a
site to site tunnel using an NSX gateway. So logically, the tunnel would look
like this. It
looks like a tunnel that goes from site A from this gateway here over to this
physical router at site
B at site A, that's an NSX gateway, who then take the traffic, encrypt it, and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
B at site A, that's an NSX gateway, who then take the traffic, encrypt it, and
then ship it
logically through the tunnel, which the transport network is going through the
internet. But because
we're encrypting that traffic, anybody who eavesdrops on the traffic and sees
it won't be able to make
sense of it because they don't have the correct keys to correctly unlock or
decrypt the data.
And then when that traffic is received here at the other side of the IP, site
site tunnel,
this device would decrypt that traffic, and then forward it, assuming it was
going to this
destination right here. And then for the response, the similar thing would WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
destination right here. And then for the response, the similar thing would
happen,
the traffic would go from this VM here up to this gateway, who would then
encrypt it, ship it
over to the IPsec tunnel, once again, using the internet as a transport network
, and then the
receiving side would decrypt it and then forward it down to the client. And
there's a couple different
flavors and varieties of IPsec that we could use. We could use one flavor
called Ike, and Ike is an
acronym for internet key exchange, version one, or we could use Ike version two
. And whether we're
using Ike version one or Ike version two for the implementation of our IPsec WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
using Ike version one or Ike version two for the implementation of our IPsec
site, site tunnel,
there's actually more than just one tunnel, regardless of which one of these
options we use.
At the end of the day, when we set up an IPsec tunnel, whether we're using Ike
version one or
Ike version two, we're going to have a tunnel that's used to carry the actual
data. So for example,
a device over here, I'll call this device left, this VM here. If they're saying
traffic over to
this device over here at the right, I'll call that device right. That traffic,
if we're using
IPsec as it goes between the two sites, is going to be encrypted and shipped
over what's known as
this IPsec tunnel. Now, based on the flavor of Ike that we're using, this could WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this IPsec tunnel. Now, based on the flavor of Ike that we're using, this could
be called the child
SA, SA is a acronym for security association, or it could be called the Ike
phase two tunnel.
But in either case, the IPsec actual tunnel itself is the tunnel that's
carrying the actual user
traffic. However, there is one more tunnel involved in an IPsec session between
the gateway over here
on the left and the gateway over here on the right. And that is a tunnel I'd
like to refer to as the
control tunnel. And we can think of the control tunnel as a special purpose WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
control tunnel. And we can think of the control tunnel as a special purpose
tunnel or path that
can be used when this device on the left needs to communicate directly with
this device on the right,
the two ends of the IPsec tunnel. And based on the flavor of Ike that we're
using, this could be called
the Ike phase one tunnel, or it could be called the Ike tunnel. But again,
regardless of which flavor
we're using, we're going to have two tunnels at the end of the day, one for the
two endpoints to
negotiate and communicate directly with each other. And the IPsec tunnel being
used to carry the actual
data traffic from the devices who are sitting traffic back and forth over the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
data traffic from the devices who are sitting traffic back and forth over the
tunnel. And even
though logically that's how the traffic flows, the two tunnels are terminated
at the endpoints
of the IPsec VPN tunnel. So this Ike phase one or Ike control tunnel would
terminate here at the
gateway at site A and so would the IPsec tunnel. And over at site B would be
this router as the
termination point for both these tunnels as well. However, when users send
traffic, then these
you go through the tunnel, the actual gateways will use the IPsec tunnel for
that user traffic.
All right, let me clean that up just a little bit. I'd also like to identify WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right, let me clean that up just a little bit. I'd also like to identify
these tunnels with a
letter I'll call this control tunnel, the Ike phase one or Ike parent tunnel.
Let's call that tunnel A
and we'll call the actual IPsec tunnel. We'll call that tunnel B. Now both of
these tunnels
have to be negotiated and set up between the endpoints. And again, the end
points for the IPsec
tunnel for a site site tunnel is going to be the gateway here and the router
over here.
So for the control tunnel, there's a really cool way to help remember many of
the details they
have to negotiate and agree on if they want to go ahead and form that control WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
have to negotiate and agree on if they want to go ahead and form that control
tunnel between them.
And a great way to think about the details that these two peers on the site
site VPN tunnel,
when they set up this control tunnel, the great way to remember a lot of the
details they have to
set up is using this term of haggle, like they have to haggle to agree on these
certain parameters.
And that's also going to remind us of many of those parameters, including they
need to agree
on the encryption algorithm that they want to use. So today in modern networks,
we're going to be
using some flavor of AES, the advanced encryption standard, but they have to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
using some flavor of AES, the advanced encryption standard, but they have to
agree. If for example,
this site over here supports only one flavor of AES and the other side supports
only a different
flavor. They're never going to agree. And as a result, they won't set up that
initial control
tunnel. Another element they need to agree on is the authentication that they
are who they say
they are. And for the authentication, think of it like these two sides of the
VPN tunnel,
how are they going to prove who they are? Now the two main ways of doing it are
a pre shared key.
And that's basically where you just plug in a value like a password on this
side and you do the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
side and you do the
same thing on that side and they match it's great. Another option is use
digital certificates for
the authentication. So they need to agree on how they're going to authenticate.
And then secondly,
they also need to perform the actual authentication using the method they agree
to. Another element
they need to agree to is the lifetime. Now when it comes to lifetime, which is
done in seconds,
that's one of the parameters where if they're not exactly the same on both
sides for the actual
first initial control tunnel here, they can negotiate down to the one that has
the lesser time. So this
guy set for like 86,000 seconds and this guy set for 20,000 seconds, they can WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
guy set for like 86,000 seconds and this guy set for 20,000 seconds, they can
agree on that 20,000
seconds and keep moving forward. So at the end of the day, they're going to
come to an agreement on
what that lifetime is. And then once that lifetime is about to expire, they can
go ahead and negotiate
a new tunnel and build the tunnel again. Another element that they need to
agree on for this
initial tunnel is the hashing hashing is a great method of validating data
integrity. So on building
this tunnel, if one side says, you know what, we can use shop 256 only. And the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this tunnel, if one side says, you know what, we can use shop 256 only. And the
other side says,
we can do shop 512 only. That's going to be a problem. They need to agree on
what hashing algorithm
can be supported, because then they're going to start using that for this
tunnel to do data
integrity on the packets going back and forth. And last but not least, for the
encryption algorithm,
we need some keying material that can be used to lock and unlock the data
respectively.
And that keying material is developed through a process called Diffie-Hellman.
And so the G
here is for a group. And I'll put in parentheses, DH for Diffie-Hellman group. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here is for a group. And I'll put in parentheses, DH for Diffie-Hellman group.
And the Diffie-Hellman
group is done with numbers. For example, there's group five and group 14, and
there's several others,
and they need to agree on which Diffie-Hellman group they're going to run. So
even though it's
a big, longer story, at the end of the day, Diffie-Hellman allows these two
devices over a public
untrusted network to go ahead and calculate a shared secret key that they can
both use for
the encryption. And at the same time, anybody who's listening to that
conversation back and
forth as they're running Diffie-Hellman, they won't come up with that final key WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
forth as they're running Diffie-Hellman, they won't come up with that final key
. So that key or that
keying material to be more specific is to be used with the encryption algorithm
. So even though
the encryption algorithm is an open standard, AES, for example, because these
two peers have
negotiated and set up special key materials using that algorithm to lock and
unlock the data,
anybody on the internet, even if they know we're using AES 128 or AES 256, etc
., because they
don't have the keying material that only these two endpoints have, they won't
be able to decrypt
or unlock the encrypted payload. And as a result, our data can be sent back and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or unlock the encrypted payload. And as a result, our data can be sent back and
forth,
and it can be kept secure. So all of that, my friend, was the negotiation for
the initial
control tunnel between these two endpoints of the IPsec tunnel. And if the
control tunnel is built
and set up the Ike tunnel here, they can then proceed to set up the actual IP
sec tunnel as well.
So I'll put that as tunnel B here, and I'll put that here in pink. So they also
are going to
negotiate several parameters for the actual IPsec tunnel itself. They're going
to negotiate
encryption. For example, what type of encryption do we want to use for this IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
encryption. For example, what type of encryption do we want to use for this IP
sec tunnel? So up here
for the encryption, if we used AES 128, we could use AES 128 here as well, or
we could use something
different because they don't have to be the exact same algorithms for each of
the tunnels,
because at the end of the day, they are two separate and distinct tunnels. This
is the initial Ike
tunnel here in green. And then this is the IPsec tunnel or the child tunnel
here in pink. And in Ike
version two, which referred to as the child tunnel, because you can think of it
like a child that
was built or developed using the actual initial tunnel, the Ike tunnel up here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
was built or developed using the actual initial tunnel, the Ike tunnel up here.
But in either case,
it's also still called the IPsec tunnel. So for that IPsec tunnel, we need to
negotiate the
encryption we're going to use on that IPsec tunnel. We need to agree on the
lifetime for that IPsec
tunnel. And the reason we have lifetimes for tunnels is because if we'd have to
tunnel up for
years and years, the same exact tunnel using the same exact keys, there's more
of an opportunity
for that to be compromised. So by creating a new tunnel, for example, every day
up here for the
control tunnel, and then maybe every hour here for the IPsec tunnel, as we're WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
control tunnel, and then maybe every hour here for the IPsec tunnel, as we're
phasing out the old
tunnels and bringing in new tunnels. And if we're using new keying material
every time we do that,
that makes those tunnels more secure. Another element we'd want to negotiate
here for the
IPsec tunnel is the hashing algorithm that we're going to be using. Oftentimes,
that's referred to
as an HMac for hash message authentication code, which has the main purpose
here to go ahead and
new data integrity for each and every packet being sent. There's also an option
for the
IPsec tunnel to do what's called PFS, which is perfect forward secrecy. And WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
IPsec tunnel to do what's called PFS, which is perfect forward secrecy. And
when that's used as
part of the IPsec tunnel, it's going to go ahead and rerun Diffie Hellman once
again and create a
separate set of keying material to be used for the actual IPsec tunnel. So
using perfect forward
secrecy on the IPsec tunnel isn't required, but it is additional and better
security than not using
it at all. All right. And there's one other concept I want to share with you
regarding
IPsec site to site tunnels. And that is how they are implemented. One of the
options is a policy-based
tunnel with a policy-based tunnel. Think of it like rules where this gateway WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
tunnel with a policy-based tunnel. Think of it like rules where this gateway
receives a packet from
1033-0 and it's destined for 1080 and based on that policy in the rules that
trains this gateway
to go ahead and encrypt it, ship it through the tunnel, where it's received at
the other side,
who decrypts it and then forwards it down to the destination. And that's policy
-based. Now,
the other option is route-based. And with route-based, think of it like a
logical network that exists
between, for example, this gateway here at site A and this router here at site
B. And actually,
let me redraw that right here, because any traffic that goes over that logical WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
let me redraw that right here, because any traffic that goes over that logical
network segment,
because this route-based will go ahead and automatically be encrypted with IP
sec using the
IPsec tunnel. And the benefit of route-based is that we can add additional
networks and use dynamic
routing protocols like BGP to advertise additional routes and reachability
through network. And as
our dynamic routing changes, any traffic that's being sent over the logical
segment between site A
and site B will automatically be encrypted with IPsec. Whereas with policy- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and site B will automatically be encrypted with IPsec. Whereas with policy-
based, we'd have to
specify, okay, traffic from 1033-0 going to 1080, go ahead and encrypt that.
And vice versa over here
from the site B perspective. Any traffic from 1080, 0 going specifically to 10
33-0,
go ahead and encrypt that. And then if we added additional networks, we'd have
to modify our
configuration in our IPsec. Then go ahead and tell it to also include that,
again, if we're doing
policy-based IPsec tunnels. Now, because there are several options in setting
up an IPsec site,
site VPN tunnel, to help keep us out of the weeds, let's do this. In the next WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
site VPN tunnel, to help keep us out of the weeds, let's do this. In the next
video, let's put a
specific game plan together on what we intend to do, including which protocols
we're going to use
for the initial tunnel, as well as the IPsec tunnel. We'll identify the IP
addresses between our tier
zero gateway and the external router. And then with that game plan in place, we
can then proceed
to do the implementation and verification step by step of an IPsec tunnel
between an NSX gateway,
a tier zero gateway in our topology, and an external third-party router. So if WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a tier zero gateway in our topology, and an external third-party router. So if
you're ready,
I'm ready and I'll see you in the next video for the game plan.