Have you ever had one of those things
where you thought was fantastic and great?
And as you get into it, you realize that, Oh,
it doesn't quite as good as I thought, or doesn't do this,
or doesn't do that.
Well, that's the case with crypto map based IPSec VPNs
because there are some features that are just not supported
if we're using crypto maps and IPSec tunnels by themselves.
So in this video, I'd like to share
with you what some of those limitations
are, but have no fear.
I'd like to show you a solution as well that involves
generic route encapsulation.
So let's use this topology as an example. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's use this topology as an example.
We'll call this site 1, and over here we'll have site 2.
You got it.
And if we're using the traditional IPSec,
we'd have our tunnel between R1 and R2.
And then there's traffic from PC1 one
is sent to the default gateway.
R1 would say, Oh, but is this coming from 10.1 going to 10.2?
If so, I need to go ahead and encrypt it.
It encrypts it, shoots it over the tunnel over to R2.
R2 decrypts it and forwards on its way.
So let's talk about some of the problems,
and ask the question what are some
of the problems about IPSec in this fashion?
One problem is that this leg of the journey right here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
One problem is that this leg of the journey right here,
it doesn't have a logical IP address, a network address.
So if we want to do manipulation based on that logical tunnel,
it doesn't have an IP network address.
There's no option for doing that.
We can't call this the 10.2 network, or the 172.16 network,
or anything else.
Because with traditional IPSec all by itself,
this connectivity, this tunnel, this logical security
association between R1 and R2, it
doesn't have an IP network address base.
Now another challenge with this logical tunnel
is that it doesn't support broadcasts, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is that it doesn't support broadcasts,
and it also doesn't support multicast.
And we might say to ourselves, Well, no big deal.
I really don't need a bunch of broadcast or multicast
going between these peers.
But there are some protocols that we might
want to use that need those.
Somewhat include things like routing protocols.
So if we want to have R1 and R2 dynamically exchange
routing information with OSPF or EIGRP
because those routing protocols collectively
require the use of broadcast and multicast traffic
in their operations.
Because this doesn't support it, and it doesn't have a network
address base. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
address base.
That means we cannot use routing protocols over an IPSec tunnel.
Also IPSec, if we look at the name of it,
IPSec is a suite of protocols that we
can use to protect traffic.
But what kind of traffic?
The answer is IP traffic.
So if we need to protect other type of protocols other than IP
going between R1 and R2, IPSec by itself cannot get the job
done.
So what do we do with this quandary?
Do we raise our hands up and then say, Oh, no?
No, we can use other solutions in combination with IPSec.
And one solution that really brings a lot to the table WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And one solution that really brings a lot to the table
is a three-letter acronym of GRE.
And the acronym stands for Generic Route Encapsulation.
And the benefit is we could make a GRE tunnel between these two
pairs first, and that GRE tunnel could
do lots of things, including having a network address base
associated with that tunnel.
We can also carry other protocols besides just IP.
And because we have the ability to have
that logical IP addressing, that network between them,
and we can now support broadcast and multicast, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we can now support broadcast and multicast,
we could run a routing protocol between R1 and R2,
and they could train each other about their interior networks
for reachability purposes.
So with GRE, think of it like a carrier
that can carry other protocols as its customers
or its payload, as it sends packets
back and forth between the two ends of that tunnel.
And let's take a peek of what that might look like with GRE.
With GRE, we'd still create a tunnel,
and it would start here at R1 and end at R2.
Or if you're at site 2, you say it starts at R2 and ends at R1.
It's a tunnel it goes both directions. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's a tunnel it goes both directions.
So now when PC1 sends a packet to 10.2.0.50,
he forwards it to the default gateway.
R1 sees it, and based on the routing,
it says, Oh, I need to send this the next hop as the IP
address of R2 over this tunnel.
So maybe this tunnel has a logical address of 10.12.12.0,
and R1 has dot 1, and R2 has that 2.
And so from a routing perspective,
if R1 saw that, Oh, to get to the 10.2 network,
the next hop is 10.12.12.2, it then say, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the next hop is 10.12.12.2, it then say,
I need to route up this tunnel interface.
And let's take a look at what that looks like.
So the original packet from PC1, I'm
going to put in the IP header here.
And then I'll put PC1 to PC2.
That's the original IP header.
And then we have the payload behind that.
[INAUDIBLE] that payload was an ICP echo request or maybe is
looking for a web services, or whatever it is,
but there's the IP header and then the payload.
And so what happens when R1 sees it?
R1 says, Oh, I'm going to route this with the GRE tunnel.
I'm going to go ahead and I'm going to add a header. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm going to go ahead and I'm going to add a header.
And here's the header.
It's going to add a GRE header.
And then in front of that, the outside header
is then going to have the IP addresses for source
would be R1's interface.
And the destination would be R2's interface that's
reachable over this network.
So I'm going to put R1, R2 here.
So in this outside header, it points
to the next protocol of GRE.
And then in the GRE header, it indicates
that the protocol being carried here is IP.
The internet would see a packet, a GRE packet, that source
from R1 going to R2.
And then if you didn't encapsulate that and look at it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then if you didn't encapsulate that and look at it
further, we get to the original payload.
So when the R2 see us, it would de-encapsulate that.
And then it would forward just the original IP packet
and payload going over to PC2.
So the benefit is with GRE, we now have a network address,
we can support multiple protocols, not just IP,
and we can support multicast and broadcast.
And those facts along with the fact
that we have an IP network address associated
with this tunnel, we can use dynamic routing protocols.
So R2 and R1 over this tunnel could become OSPF neighbors WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So R2 and R1 over this tunnel could become OSPF neighbors
or EIGRP neighbors, and share routing information
about their internal networks, 10.1 and 10.2 respectively.
Now the challenge with that is that
generic routing encapsulation by itself
doesn't do any type of protecting the data.
No encryption.
So here is the final nail in the coffin to get it all done.
We use GRE, we build that tunnel between the two peers,
and then what we do is we encrypt the GRE traffic
with IPSec.
And that's why it's called GRE, like going
over that internal network or that public network WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
over that internal network or that public network
inside of an IPSec encapsulated packet.
So the concept is GRE over IPSec--
the benefits of GRE and the protection of IPSec
all boiled into one.
So here's what I'd like to do.
In the next video, let you and I sit down for a moment
and let's just make a plan regarding what addresses
we want to use for the tunnels.
And we'll plan it all out, and then we'll
proceed to implement the GRE and verify it one step at a time.
And then as we progress what we'll
do is once we get the GRE tunnel in and working,
we'll then overlay on top of that the IPSec protection.
So I look forward to seeing you in the next video. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I look forward to seeing you in the next video.
Meanwhile, I hope this has been informative for you.
And I'd like to thank you for viewing.