- [Instructor] In this video, we want to see
how to set up a GRE over IPSEC tunnel
for the reasons we talked about in the prior video.
To begin with, I'm going to set up just a basic GRE tunnel,
no encryption or any security things going on here,
just a GRE tunnel.
Here's how we do that.
I'm going to go under router R1,
and I'll create a virtual tunnel interface
by saying interface tunnel.
And I'll just give it a number of one.
I'll assign an IP address that I'm going to be using
for this tunnel, and I'll use a private IP address
of 192.168.0.1.
And I'm going to give a 30-bit subnet mask,
255.255.255.252, because I only need two IP addresses
in the subnet, one on each end of the tunnel.
And the tunnel interface is up by default,
so I don't need to do a no shutdown.
And now, I just need to say who's the source of the tunnel
and who's the destination of the tunnel.
Well, this is going to be coming out of the bottom of R1
and going into the top of R4.
So my tunnel source from the perspective
of R1 is that interface of gigabit zero slash one,
and I'm going to that interface on the top of R4,
gigabit zero slash one.
And it has an IP address of 198.51.100.2.
So I'll say my tunnel destination is 198.51.100.2
and I'm done with the configuration on R1 for my GRE tunnel.
Let's move over to router R4
and I'll give a mirror configuration.
I'll say that I want to create a tunnel interface.
And I'll give it a locally significant number of one.
I'll assign it an IP address of 192.168.0.2,
again with a 30-bit subnet mask.
From the perspective of R4,
my source is going to be gigabit zero slash one,
I'll say tunnel source gigabit zero slash one
and the tunnel destination,
is going to be gigabit zero slash one on R1.
That has an IP address of 192.0.2.1 and we're done
with our GRE tunnel configuration.
In fact, we just saw an OSPF adjacency come up
between R1 and R4 over that tunnel connection
because it looks like they're adjacent to one another.
It looks like they're tied together using that tunnel.
Let's take a look at our GRE tunnel
before we move on to IPSEC.
If I do a show IP interface brief command,
we can see that we do have a logical Tunnel1 interface,
and it is administratively up, excellent.
I can do a show IP OSPF neighbor command, and I'm on R4
and I'm a neighbor with R1 over that Tunnel1 interface.
Again, it looks like I'm physically adjacent to R1
and now that we've configured and verified our GRE tunnel,
let's move on to IPSEC.
Remember there are two phases.
There's IKE Phase 1, also known as ISAKMP,
and IKE Phase 2 also known as IPSEC.
First, let's configure the IKE Phase 1 policy
that we're going to be using.
Let's go back over to router R1
and go into global configuration mode and I'll say crypto
and let's give some context sensitive help.
And right now I'm wanting to set
up the IKE Phase 1, or the ISAKMP policy.
So notice there's an option for ISAKMP.
I'll say crypto ISAKMP policy
and I'll give a priority number, I've only got one policy
so it doesn't really matter what number I give.
I'll just say 10 and now I'm
in ISAKMP policy configuration mode.
From here I can set up my encryption.
Encryption options include triple DES, DES and AES.
That's the one we want, advanced encryption standard.
That's the strongest of all three of these.
So I'll say AES.
For authentication, we want to use a pre-shared key and
that pre-shared key can be generated using Diffie-Hellman.
Diffie-Hellman is going to use asymmetric encryption
to create a symmetric key to allow us
to do symmetric encryption.
So I'll say authentication, pre-share
and the Diffie-Hellman group determines how secure it is.
I'll just use group two for this demo and I'll say exit.
And since we're going to be using a pre-shared key,
we need to specify what is that key
and who can it be used with.
Now in our example, in this lab example,
I'm going to make the key easy to remember.
I'll just call it kevinskey and since we're
in a lab environment, I'm going to make this key valid
with any peer that wants to talk with us.
To do that I'll say crypto ISAKMP and the key is going to
be kevinskey and the address
of any valid peer, I'm going to say anybody.
To do that I'll say 0.0.0.0 space 0.0.0.0,
that'll match anybody.
And now that we've specified our parameters
for IKE Phase 1, it's time to create a transform set
for IKE Phase 2, and the elements of this transform set,
that's what's going to be negotiated
between our two routers when they're setting up
this IKE Phase 2 or this IPSEC tunnel.
And the transform set, it's a collection of encryption
and hashing algorithms and we have to find a matching
algorithm on our peer, so we don't have
to specify just a single encryption algorithm.
We can say we'll support any of these
and during that negotiation that happens again
during IKE Phase 1, we can agree on,
hopefully, a transform set.
And we can also say that we're using a transport mode
or tunnel mode that we talked about in the previous video.
In this example, let's say
we're going to use transport mode, which is going
to encapsulate the payload rather than the entire packet,
we're going to keep our packet size a little bit smaller
by not encrypting the original header.
To do that, I'll say crypto IPSEC transform set
and let's give it a name.
I'll call it KWTRAIN and we'll use
some context sensitive help.
Here we're looking at our security algorithms
and I'm going to choose encapsulating security payload,
which is more secure
than authentication header, hyphen, AES.
Let's use some more context sensitive help and it says,
okay, I know how you want to do encryption there.
You're going to use AES.
What about for integrity?
How are you going to do hashing?
So from this list I'll say encapsulating security payload
hyphen shaw, secure hash algorithm, hmac, which is going
to do more than just hash a string,
it's going to add a secret key to that hash.
So somebody intercepts it, they're not going to be able
to generate a valid key.
Let's enter that and we can specify our mode
as either transport or tunnel.
Here I'm going to say transport.
And the next thing we need to do
is define interesting traffic.
When we're setting up an IPSEC tunnel,
interesting traffic is traffic that is going
to be sent through the tunnel.
We can send traffic that's not interesting, just fine.
It's not going to be encrypted though.
And we want to encrypt our GRE traffic,
so we want to make GRE traffic interesting.
To do that, I'm going to use an access control list.
I'll say IP access hyphen list,
and it's going to be an extended access list
and I'm going to call it GRE hyphen IN hyphen IPSEC.
And I want to permit GRE traffic from anywhere to anywhere.
Again, because I'm in a lab environment,
I'm not concerned about specifying source
and destination IP addresses.
And now we need to create a crypto map.
That's going to be the connective tissue
that ties everything together.
The interesting traffic of the transform set,
and we're going to point to our peer.
To do that, I'll say crypto map and let's name this VPN.
We'll give it a sequence number of 10 and this is going to be
for an IPSEC tunnel that uses ISAKMP,
which is what we typically use.
So I'll say IPSEC hyphen ISAKMP,
and it says this is going to be disabled
until we specify a peer and a valid access list.
Okay, let's do that.
Let's also specify our transform set
that we want to use to protect the traffic.
I'll say match address, GRE hyphen IN hyphen ISAKMP.
What this is saying is any traffic that's matching
that extended access control list,
we're going to put that inside the IPSEC tunnel.
We're going to protect it.
And what is matching that access control list?
All of our GRE traffic.
So let's enter that.
Let's say how we're going to protect that traffic.
We'll say, set transform, and we'll give
our transform set name of KWTRAIN, and who's my peer?
Well, my peer is that incoming interface
on R4, 198.51.100.2.
I'll say set peer 198.51.100.2, we'll exit that
and now we need to apply this crypto map
to the gig zero slash one interface,
which is the interface we're using
to send those GRE packets.
Let's go into interface configuration mode
for gigabit zero slash one and I'll say crypto map VPN.
We've now configured GRE and IPSEC on R1.
Let's now go over to R4 and give a mirrored configuration.
Oh and notice that our OSPF adjacency went down
because I'm encrypting traffic on R1,
but I'm not encrypting it on R4, so that's caused an issue.
Well, we're going to fix that, so no worries.
Let's go into global configuration mode and let's do this.
Instead of making you watch me type
in the exact same commands with a couple
of IP addresses maybe different, what I've done
is created this in a text file where I can just paste it in.
Again, this is simply a mirrored configuration
on R4 just for time sake.
I don't want you to have to watch me do it again.
If you want to watch me do it again,
you can just rewind and see me do it on R1,
but I'm just going to paste in the configuration
for R4 and it should be working now.
Hopefully our OSPF adjacency will come back up,
and there it is, so that's a good sign.
Let's do some configuration verification on R4.
First, I'll create some traffic.
Let's see if I can ping the loop back interface on R1.
Can I ping 1.1.1.1?
Yes, I can.
Let's now do a show crypto ISAKMP sa, and that stands
for security association, and we see that we've got R1
and R4 acting as both source and destination.
Our status is active for these security associations.
That's all good news, but that was for IKE Phase 1.
That was for ISAKMP.
What about IPSEC?
Let's do a show crypto IPSEC security association.
Things look good here as well.
In fact, we actually see evidence
that we have encapsulated packets.
Some of those were our ping packets,
some of those might have been some OSPF packets,
but we are getting confirmation now
that we are successfully sending GRE traffic
inside of our IPSEC tunnel.
And again, the big advantage of doing that is
that GRE can encapsulate just about anything,
IP, unicast, broadcast, multicast.
It encapsulates those traffic types inside of GRE packets,
which are unicast IP packets.
We then take those unicast IP packets,
put those inside of our IPSEC tunnel,
which can only protect IP unicast packets.
And then we allow IPSEC to do its security work
of encryption and hashing.
And that's a basic look
at a GRE in IPSEC tunnel configuration.