VPN tunnels. All right, so now that we've successfully introduced ourselves to IPsec,
let's go ahead and configure and verify IPsec tunnels to get ourselves ready for the exam. So
here is what we're gonna have to do. We're gonna have to start off with phase one. We'll then have
to do phase two. We'll then have to apply to the interface and then we'll have to attempt to
generate interesting traffic to initiate the actual tunnel. And everything works. If everything is
configured correctly, then it should work. Now the last time I taught this course, it didn't work.
Yeah. And then we troubleshot for a little bit of time and we gave up. And after class,
while I was uploading my videos, I went ahead and made a slight adjustment to my access control
list and everything worked just fine. Just misconfigured. But the ACL is weird, right?
Because the ACL I picked should have worked. It just didn't work for some reason. So it can be a
little bit finicky when it's all said and done, especially when you're setting up IPsec in a live
environment or a lab environment, demo environment. Sometimes what you've done could possibly work in
the production environment. The lab environment just doesn't work for some reason. So even though
I specified specific ACLs, they want to do it for me. If I went with a generic ACL, it works. So
today we're just going to use a generic ACL and see if it works. So that way they were not
troubleshooting deep into the night when it comes to IPsec today. All right. So let's do phase one
right now and show you how to do this configuration for the certification exam. So we're going to do
R1 to branch, just like we did for GRE. So I destroyed my GRE tunnels here, folks. They are
all gone. And I've shut down the link between R2 and branch. So the only way we can go right now is
over the Internet. We can't go any other way. So let's go over to R1. And the first thing we're
going to do is create our phase one ISACAMP policy. And we do that in global configuration mode by
typing crypto and then ISACAMP and then type in policy and then give the policy a number. So you
can have many, many, many policies for ISACAMP on your device. And so I'm going to create policy
number 10 here today. Now, once we're in this configuration mode, you'll see there's not very
many options and most of them line up with what we're doing here. So you need a hash. You need
encryption. You're going to need a group that is Dippy Hellman group. You need authentication and
then lifetime. But you don't have to specify a lifetime because there is a default value for
that lifetime. And if the lifetimes do not match, that's OK. It's just going to use the lowest
lifetime between the two. So let's go ahead and type in first and foremost authentication. I'm
going to pick pre-shared key today because I don't have any certificates set up for authentication.
But if we wanted to use RSA encryption or RSA signatures, we can go ahead and do that for
authentication. But today we're just going to use pre-shared keys. So what does that mean? It means
we're going to have to set up our key later on. And I'll show you how to do that key here
momentarily. Next thing I want to do is I want to specify my encryption. So encryption, you'll see
that this device supports triple DES, AES and DES. I'm going to use AES because it's the best option
that we have. And then I can pick the key size I want. So let's go with 256 in this particular case.
Next, I'm going to pick my group for Dippy Hellman. You'll see that on this device, we have a lot of
different options for our group. Remember, this goes back to that diagram I showed you earlier
about the box and our IPSec framework. And what did we say? We said we pick and choose things off
our shelf. And that's what makes IPSec so flexible and so scalable. So that's all I'm doing right now
with IPSec. I'm just going through the framework motions of picking and choosing what I want. So
let's just say here we're going to use Dippy Hellman group number 16 today. And then what else
do we want to specify? I want to specify a hashing algorithm. So for our hashing algorithm, let's use
SHA-512 today. All right. And that is all of them except for the lifetime. I'll type in lifetime.
And we'll see that our lifetime in seconds can be anywhere from 60 seconds all the way up to
86,400 seconds. And 86,400, folks, is actually the default. So this is a lifetime of phase 1.
What does that mean? It means if I pick 60 seconds, it means that every 60 seconds we'll
renegotiate phase 1, which means we'll have new keys every time we renegotiate. So if your corporate
policy states that you can't use a set of keys for longer than, let's say, 3 hours, then you would
set this to 3 hours in seconds, that is. And therefore, your tunnel would always create new
keys every 3 hours. All right. So let me exit out of here. Do show run pipe to section crypto.
All right. And then you'll see our policy. Now, the other thing we need to do here is we need to
specify the password because we indicated pre-shared keys. So we need to create a crypto
isocamp key in this case. And then we specify what we want the key to actually be. So we are
going to use the key today of password, which I don't recommend using the real world. Yeah. So
this is gonna be for authentication purposes. So password would have to be configured on this
device and this device. Now, though, we also have to specify who we're using this password with.
And so this is gonna be branch. So what is branches IP address? Branches IP address is
one nine eight fifty one one hundred dot forty six. So I'll put that in right there. All right.
Let's look at the output of show run section crypto. That's what we have at this point in
time. Right. So the phase one is now set up on our one. We now have to go ahead and set up phase
one on the branch router. But great news. Everything has to match except for the lifetime
and the policy number. In addition. The password has to match, but this address would have to be
changed. So technically speaking, we can copy and paste all of this if we really wanted to go over
to branch, paste it all in. And then put the address of our one in there, which is going to
be what? Two or three zero one thirteen ninety. And there you go. That was pretty easy, wasn't it?
To do the branch after our one was done. Pretty straightforward. So let's just verify that we
have what we need on both of these. So something to be able to do on the exam, compare and contrast.
The policy, the crypto policy, one, two, three, one, two, three on both of them. So comparing
this one to this one. Keep in mind, if any of these values of this is different on the two,
if this is different on the two, if this is different on the two or this is different on
the two, that's why IPSEC is not working and getting past phase one. If this address is not
the right address, if this address is not the right address again, that is why phase one is
not working. So I'll show you later how we identify a phase one is working or not. But essentially,
you'd be looking for in the output. Of our output later, QMIDLE. If we see QM idle in an output
later, that means phase one is working. So keep that in mind. That's going to come back later.
If we don't see QM idle, it means we have a problem. We can't either reach each other or
we have mismatching parameters. So now that phase one is done, let's go ahead and deal with phase
number two. Phase number two is about the IPSEC policies. So defining where is the tunnel going,
what is going in that tunnel, how is the traffic going to be treated when it's all said and done.
So the first thing we have to do is create an access control list. The access control
list is going to be used to define what traffic is allowed to go in that tunnel,
or what traffic is allowed to use that particular tunnel. So let's type an IP access list. We're
going to create an extended access control list here called IPSEC underscore VPN underscore ACL.
And we are going to permit traffic, all IP traffic from 10.0.0.0. Let's put in 0.255.255.255. So from
our entire 10 network, going to where? Going to our entire 10 network anywhere else. So what does
that mean? It means that if traffic is coming from let's say 10.0.0.10, going to 10.0.255.4,
then it would match both of those. Because there's our source, there's our destination.
Next, we need to specify how the traffic is going to be treated. So how do we do that? We use our
transform set it's called. So the transform set is created by typing in crypto.
Oh, crypto, and then IPSEC, and then trans. Come on.
IPSEC and then transform. I typed something wrong somewhere. That's the problem. There it is. IPSEC
transform set. And then you have to give the transform set a name. So we'll call it today
IPSEC underscore VPN underscore transformers. And then you'll see here that this is where we can
start specifying the IPSEC protocol we want to use. And then the encryption algorithm we want
to use. And then the hashing algorithm we want to use. So for example, remember, I said we want to
use ESP and not a H for IPSEC protocol, because ESP allows me to do encryption, whereas a H doesn't
allow me to do encryption. So I'm going to type in ESP. And now that I've done that, you'll see
my options change. So let's go with ESP AES and AES 256 to protect our actual user traffic. And
then when it comes to our integrity checking, what hashing algorithm do you want to use? Let's pick
ESP SHA 512 HMAC for authentication purposes. Right now we are in transform set configuration
mode. And there's not a whole lot of options here. As you can see, the only real option we have is
mode. And this is where you specify tunnel mode, or transport mode. So in this case,
what are we doing, we're creating a VPN tunnel over the internet. So I would need tunnel mode,
because tunnel mode gives me the opportunity to do what? Do you remember folks? Tunnel mode gives
me the opportunity to create a new header. So the public IP addressing can go in this header now.
Whereas if we want transport mode, I wouldn't have a new header for the public IP addressing.
Oh, we're gonna go with tunnel mode. Now tunnel mode is the default, folks. I'm pulling on a
cable down here. That's not good. Alright, so tunnel mode is the default. So you don't actually
have to specify tunnel mode. It's the default. Alright, let's exit out of here. So now that
we've done that, what's next? Now we have to put it all together. And we do that with what is called
a crypto map for this configuration. So we'll type in crypto. We'll type in IP sec. Wait, no. Crypto
map. There you go. Crypto map. Now I type in the name of my crypto map today. So we're gonna call
IP sec VPN underscore crypto map. And then we need need a little bit of help here. Sequence
number, because our crypto maps can have multiple sequences, just like a route map can, you can have
multiple sequences. So same idea, we're building this construct kind of like a route map. So in
this case, I have sequence number 10 for this crypto map. And what I now need to specify after
I specify my sequence number is how is phase one being accomplished. So if you remember, phase one,
we are using ISA camp, right, we created an ISA camp policy. But if we wanted to use a manual
keying, we could do manual keying for phase one if we wanted to, which is not recommended for
the internet. Because with ISA camp, I can use Diffie Hellman for dynamic keying. So IP sec ISA
camp is what we're using here. You can also use GDOI, which is beyond the scope and course in the
certification again. But that is another option that you have available to you when it comes to
your keying material. So I'm now in crypto map configuration mode. And what do I now need to do,
I now need to specify things like my transform set. And I need to specify the access control
list. And I need to specify where the tunnel is going. So who is my peer now. So this is where I
just put it all together. So we've already created the ACL. So let's go ahead and apply that. So you
type in match IP. Nope, just match address, match address. And then what is the name of that access
control list you created. And then we need to set our transform set. And so what was the name of
the transform set that we created? IP sec VPN transformers. And then we need to specify the
peers IP address. So set peer and who is that it's going to be branch and what is their IP address,
this is their IP address. All right. So let's exit out of here. Do show run pipe to section
crypto and do show run pipe to section ACL.
All right, so here's what we're going to do. We need we can use we can use this exact same ACL
over on branch. So let's go ahead and use that over on branch two.
Because the numbers work for us. What else do we want to do here? We need our
transform set. So let's copy and paste the transform set over.
And then we also need what we also need the crypto map. So let's copy but the peer address is gonna have to be
different. So let's go ahead and paste that all in. But the peer address has to be different. So let's type in
no set peer. Whoops. No set peer. Because that's me. And then say set peer and put in the IP address of the peer.
All right, so show run pipe to section crypto.
Beautiful. Looks good. And show run pipe to section access for access lists. And there we go.
So far, so good, folks. We've completed our configuration of phase one. We've completed our
configuration of phase two. So what does that mean for us now? It means that we're gonna have to apply
it to our interface. So how do we apply it to our outgoing interface? What we're going to use
is the crypto map command in interface configuration mode. So if we go here, you'll see the crypto map
command specifying the crypto map you created on the actual physical interfaces. So let's do that
in both our cases and keep our fingers crossed. So we've got interface gigabit ethernet 0 slash 1.
Crypto map. IPsec VPN crypto map.
Let's go over to R1 and it's going to be interface fast ethernet 0 slash 0 slash 0.
Crypto map and the name of the crypto map.
So now you'll see that it's actually turned on on our interface. And we type in show
isocamp show crypto isocamp security association. You'll see there's no security associations right
now. Let's go over to branch and look at the same output. Why is it blank? Why is everything blank?
Because we haven't generated any interesting traffic to actually trigger the tunnel to be
formed. So let's go ahead and trigger some interesting traffic from DSW one right now.
Let's do something like this. Let's type in ping 10.0.254.1
and we're going to source it from 10.0.0.1.
Whoa! Whoa! It worked first.
Sorry. Last time I did a demo. Nope. Didn't work. Failed. All right. We got it. So let's just check
to make sure it's actually working. Let's go over to R1 and let's check our crypto isocamp
security association. QM idle. There you go. QM idle. That's what I was referring to a while ago.
How do we know if the isocamp security association is working? You're going to see QM idle. If you
see anything else, folks, it's not working properly for you. All right. In regards to this course,
the certification exam and all that stuff. So the certification exam, if they show you anything else
here, that means you need to go back and troubleshoot phase one. Phase one. All right.
But if it says QM idle, then you don't have to go back and troubleshoot phase one.
Everything's good for phase one. All right. Let's go over to branch.
All right. Same idea here. So this is fantastic. So we should be able to ping. Let's try this
from our source or ping 10.0.0.1 from a source of 10.0.24.1. All right. Beautiful. I love it.
All right. So we know phase one is working so far. Okay. But now the question is, is phase two
working? Right. Are we actually encrypting the traffic? How can we figure that out?
Use the command, show crypto, ISACAMP, no, show crypto, IPSEC.
A little bit of lag. Security Association. So ISACAMP Security Association, phase one,
IPSEC Security Association, phase two. So you'll see here that the crypto map has been applied to
this interface. My local address is 203.0.1.13.90. It says here that local identity,
this is the access control list we created, the ACL. So any traffic from 10.0.0.0 to all the way
to 10.255.255.255 that arrives at me is allowed to use this tunnel as long as it's going to any
IP address in this exact same range. Right. And so you could create any ACL that you need in order
to accomplish your objective. If you only want a certain subnet to use the tunnel, then you only
put the subnet for that particular tunnel. The peer, this is the IP address on the other side
of the tunnel. This is how you know that it's working. You see here it says encapsulation,
decapsulation, encryption, decryption. So we go back to DSW1 and we ping and we repeat
a bunch of times. Let's go back to R1 now and let's take a peek at that. You see it going up.
Now we're at 3000. So we know it's working. We absolutely know that phase two is doing its job
now. So now we're encrypting our packets as they go over the internet
between R1 and branch, and then they get decrypted on the other side.
Notice down here
that our MTU is 1422. That's what the recommendation is right now.
So when you think about all the encryption that's happening
with IPsec,
going back to this diagram, we're adding on in tunnel mode headers. So we've got 20 bytes here.
So now you've got 20. So this gets dropped down to what? This data and IP header, this is now 1480
because now you got 20 there. But this stuff here, folks, this stuff here is variable,
meaning that it really depends on the algorithms you are using. The greater the algorithms like
AES-256, SHA-512, and stuff like that, results in these being much larger, much larger.
Meaning that you don't really know what the actual size of these are going to be in the real world.
So one of the things you might want to do is simply just do a test
to find out what that might possibly be. So for example, let's see if we can do a little test right
now. If we go back here and stop this, let's do this.
But let's say, do not fragment, do not fragment.
Oh, packets too small, packets 100, right? So we got to set our packet size.
So let's set our size. I'm like, why did that work so well? I'm like, oh,
right, so we got to set our packet size. So let's set our size. I'm like, why did that work? It
shouldn't have worked. Let's set our size to something like 1500. Okay, you'll see that it's
not going to get through. That's what that M means. Fragmentation needs to happen, but it's not allowed.
So 1500 is too big right now. Let's just drop this down to 1400,
and you'll see that that works. So let's go to 1450. Okay, that doesn't work.
Let's go ahead and drop this down to 1425. Okay, that doesn't work.
Let's drop this down to 1420. Okay, you'll see that that works. Remember what it said to us?
It said to us approximately 1422. So if we come back here, 1422, that works. 1423 doesn't work.
So what we know is that the MTU should be set on our interface to approximately 1422. But again,
that might still not be enough for all scenarios and circumstances. So you should drop it down a
bit more, like 1400 would be better. So now going to the physical interface, for example.
So configure terminal, what is that interface, fast ethernet, zero size, zero size, zero.
IPMTU 1400 would be a recommendation on that physical interface.
So that way there, we can rely on things like path MTU discovery and other things to ensure that
we don't have to end up doing fragmentation when it's all said and done.
The MTU is still 1500 on the interface. I always want you to remember that.
When you are setting this command, it doesn't physically change the interface.
It just changed the reference value that other services use. So for example, with path MTU
discovery, path MTU discovery can now figure out, oh, one of the MTUs is 1400. Now the interface
is still 1500. Let's not forget that. But it says it's 1400. So now with path MTU discovery,
my PCs will not send anything greater than 1400. And as a result of that, fragmentation will not
occur then, which is great, which is great. So now that you have your 1400 that's being sent
from the clients, you add on your encapsulation, your encryption and everything else. Now you get
something that is approximately, let's say 1479, 1480 in this case, because 1422 was the number
that we saw that kind of worked. So we get something like 1480. That's fine. It's perfect.
We got what we want, right? As long as all of this is not greater than 1500, it's perfect.
It's perfect. So when you change this, a lot of people are misleading to think when you do this,
it actually changes the MTU of the physical interface. No, no, no, no, no. The physical
interface, folks, is always 1500. Always, always, always 1500. This is just a reference value so
other things can adjust themselves. So that way they're in the end, everything is the right size
when it's all said and done, meaning 1500 or less. So if we go back to DSW1 now, this one shouldn't
work anymore. So 1420 shouldn't work because the interface is now set to what? 1400 as we said.
So if we now go and type in something like 1400,
right, that doesn't work. But something like 1399 does. Oops. What's going on right now?
Wow. What, I broke it? Did I break my whole interface?
All right. So that one's working.
Perfect. All right. So the idea here is for you to recognize for the certification exam
that when it comes to setting things like your MTU, all right, so in this case,
since I set it to 1400, it's actually taking into consideration the 1400 minus
the actual header information and so on and so forth as well in that particular case.
All right. So in my case, setting it to
setting it to something like 1422 would work perfectly for us when it's all said and done.
Okay. So in the end anyways, the key here for you to realize for the certification exam
is that this is not a science. This is an art. Okay. Meaning that in the end, when it comes to
figuring out your MTU, you have to understand exactly what's being done on that particular
link, on that particular connection. And then from there, adjusting your MTU to ensure that
it meets your particular requirements. So that way their fragmentation is not occurring. Right.
And this is all because of what? All the added headers we're adding. So you are going to be
tested on this, meaning that you are going to be tested on, hey, look at this. We've got IPsec
being used. We have GRE being used. What is one of the problems we could face? Fragmentation.
How do we solve our problems of fragmentation? Adjusting our MTUs. So that way there in the end,
we are going to make sure that packets are of the right size and they're not bigger than the
1500 max that our interface is actually physically able to support.
That's your goal for the certification exam. All right. And then knowing the commands,
we have to change it on the interface. IPMTU is the way that you're going to change it on
the particular interface. Right. So we know that we're up and running here. Everything's working
well. I'm going to change some things back here because I want to have more of a discussion as
we move on here. All right. So change that back. Change this. Make sure everything's the way I
want it right now. That looks good. Go to DSW1. Just go with our regular size. Looks good. All
right. So that's just 100 bytes, those particular packets. So those are going to make it through no
matter what. So we've had the opportunity to take a look at the output of show crypto
security association, show crypto security association.
And what else do we want to take a peek at here as we're verifying? So we'll take a look at our
slides just to make sure we've got everything covered. So crypto security association,
crypto security association. We've already covered all of that. So we're good.
If you want to check out the actual key that's being utilized, like the pre-shared key,
the password, in case you ever need to verify it, show crypto key or you can just look at
the running config. You can see it there too. You want to view your policy. You can type in
secure crypto ISA camp policy. Remember the policy on one side has to match the policy on the other
side. The only thing that I don't have to match are things like the lifetime or the priority
number. They can be different on each side. Oh, and another thing about their lifetime is that
you can specify your lifetime in seconds, or you can also specify in the amount of bytes that have
been exchanged. So if you want to re-key, for example, every one gig that has been transported
over the tunnel, then you can re-key for every one gig of traffic or every 10 gig of traffic,
as opposed to setting it based on time. You can set it based on the number of packets,
the amount of traffic bytes that have crossed the actual tunnel as well. And then phase one
will re-key based on the amount of traffic that has been exchanged at that point in time,
as opposed to timers. Show crypto IPsec transform set, so to verify your transform set.
So in this case, we set it up with ESP AES and ESP SHA HMAC, and we're in tunnel mode.
This is the one we created here. So it wasn't that one. Pardon me. It was this one, ESP-256 AES
and ESP SHA-256 HMAC in tunnel mode. And there is a default transform set. So if you just wanted to
use it, if you could use the default transform set, you could go ahead and use that by just
specifying that one by name as default instead. But if you look, it's not using the best AES or
the best SHA. So it's highly recommended you always create your own custom transform sets.
And then to verify your crypto map, show crypto map, and you'll be able to verify all the
parameters of your crypto map. So what is the crypto map? It's the amalgamation of what?
Your phase two information. So your phase two ACL, your phase two transform set,
and then the peer that you're actually trying to communicate with in that case.
All right. So that is our configuration example. It worked for the first time. One try. Got it
working this time. Didn't have to do any troubleshooting for our IPsec site-to-site VPN
tunnel. So be familiar with everything we talked about there, folks, so that way you can pick them
out of a lineup on the exam and potentially do a configuration if you have to.