In a previous set of videos and in a previous skill, we looked at IPsec site
site VPN tunnels
that were policy-based.
And the example we used there was a T0 gateway building an IPsec tunnel over to
a third-party
device.
And in that previous skill, we were connecting over to a Cisco router.
And certainly a policy-based IPsec site-to-site tunnel is one of our options.
However, if we are connecting one site with gateways as part of NSX to another
site with
gateways as part of NSX. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
One of those options is an IPsec route-based site-to-site VPN.
And let's take a look at the concept.
So here we have, for example, a cloud that could represent a public network or
the internet.
And over here at site three, we have a T0 gateway with some edge nodes.
And let's imagine we're using this address right here.
23.1.2.30 as the virtual IP address supported by the edges.
And over here at site four, we have the address 24.1.2.40, which once again is
being supported
by the edge nodes.
So if we have that connectivity to the internet using these respective IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we have that connectivity to the internet using these respective IP
addresses, and we
can reach those two IP addresses that are being used by the T0 gateway's
respectively,
what we could do is we could leverage that connectivity.
And on top of that, build an IPsec site-to-site route-based VPN.
And one of the key differences between a route-based VPN and a policy-based VPN
is that with a
route-based VPN, we have a logical network between the two sites with the IPsec
tunnel.
And that's using a VTI virtual tunnel endpoint as the interface on each side WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that's using a VTI virtual tunnel endpoint as the interface on each side
for that connectivity.
So although the edges just have this one global address 23.1.2.30 they're
supporting, behind
the scenes they can also support a VTI.
So let's imagine for this virtual tunnel interface, we'll go ahead and use the
addressing
space of 10.0.34.34.0 with a 24-bit mask.
And we can use private RFC 1918 addresses here because the actual IP address
being used
on this virtual tunnel interface, on this network segment here between the two
sites,
that is all going to be encrypted and encapsulated as the traffic is being sent WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that is all going to be encrypted and encapsulated as the traffic is being sent
back and forth
with IPsec between the address 23.1.2.30 and 24.1.2.40.
And with IPsec behind the scenes, we're also going to have a couple of tunnels
where we
have the initial tunnel, which I'll go ahead and call the Ike tunnel.
And that's the tunnel that the endpoints are going to use to communicate back
and forth
as they're communicating directly with each other.
And then we're also going to have associate with that at IPsec Security
Association, fondly
called the IPsec tunnel.
And in our previous skill regarding setting up policy-based VPNs, we took a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And in our previous skill regarding setting up policy-based VPNs, we took a
closer look
at those two tunnels.
So if you need a refresher on why we have these two tunnels involved as part of
IPsec,
please feel free to check out that previous skill.
And unlike policy-based IPsec VPN tunnels, where we're specifying, for example,
over
here at site three, that traffic from 10.33, going over to 10.44, should be
encrypted and
vice versa with route-based VPNs, anything that's sent over this 10.34, 34
network here,
that's being supported by the VTI's on both sides.
Any traffic that goes across is going to be encrypted, leveraging the IPsec WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Any traffic that goes across is going to be encrypted, leveraging the IPsec
tunnel.
So as part of our configuration, not only do we want to set up the route-based
VPNs with
the logical tunnel interfaces with an IP dressing structure between those two
sites, but we
also want to make sure we set up routing so that if we want traffic, for
example, from
the 10.33 network here, that's going over to the 10.44 network here and vice
versa, we
want to logically send that traffic over the VTI interfaces.
And when we do that, which causes the traffic then to go with this logical
tunnel, any traffic
over that tunnel will automatically be encrypted by the IPsec tunnel. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
over that tunnel will automatically be encrypted by the IPsec tunnel.
So once we have our routing set up correctly, and traffic logically is going
over this 10.34,
34 network between the networks over here at site three and the networks over
here at
site four, because it's going over the tunnel, any tunnel traffic is going to
be encrypted
and protected with IPsec.
So as far as the routing goes, we have a few options.
One is we could do static routing on each of the sites, or we could use border
gateway
protocol and specify that we want to share and advertise routes.
And either way, either with static routes or dynamically learned routes via BGP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And either way, either with static routes or dynamically learned routes via BGP
, the
goal is that we train the gateways to use this logical segment, this 10.34, 10.
34 network
for any communications where we want to protect the traffic.
And another benefit of a site to site VPN tunnel is that we do not have to do
NAT on that traffic.
Because from the perspective of this network right here, all they're going to
see is traffic
coming from into this routable IP address 23, 1, 230, and this routable address
24, 1,
240.
And all the payload they'll see across the internet is encrypted traffic.
When behind the scenes, that traffic shows up at the respective edges, they'll WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
When behind the scenes, that traffic shows up at the respective edges, they'll
do the
decryption, and then they'll forward it down to the final destination.
And just to reconfirm the big differences between a policy-based VPN and a
route-based VPN is
that the route-based VPN, we have this new logical network between the two
sites that
we're going to use as part of IPsec.
And in a policy-based IPsec VPN tunnel, we do not have that logical network
between them.
But instead, we have policies that say if traffic is coming from 10, 330 and
going to
10, 40, 40, then go ahead and forward it over to the peer who then decrypt it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
10, 40, 40, then go ahead and forward it over to the peer who then decrypt it
without
the use of a logical IP network segment between those two sites.
So in this skill and instead of videos, we're going to focus on route-based VPN
s.
Now, to implement the IPsec route-based VPNs between two different sites, one
of the key
ingredients for success is to have a really concise game plan and have
everything documented
regarding what's in place and also what we want to accomplish.
So in that light, join me in the next video as we put a very specific game plan
together WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
together
to build and create IPsec route-based VPNs between site three and another NSX
environment
over at site four.
[BLANK_AUDIO]