WEBVTT 00:00:00.000 --> 00:00:06.440 VPN tunnels. All right, so now that we've successfully introduced ourselves to IPsec, 00:00:06.440 --> 00:00:11.080 let's go ahead and configure and verify IPsec tunnels to get ourselves ready for the exam. So 00:00:11.080 --> 00:00:17.559 here is what we're gonna have to do. We're gonna have to start off with phase one. We'll then have 00:00:17.559 --> 00:00:21.799 to do phase two. We'll then have to apply to the interface and then we'll have to attempt to 00:00:21.799 --> 00:00:28.600 generate interesting traffic to initiate the actual tunnel. And everything works. If everything is 00:00:28.600 --> 00:00:33.880 configured correctly, then it should work. Now the last time I taught this course, it didn't work. 00:00:33.880 --> 00:00:44.959 Yeah. And then we troubleshot for a little bit of time and we gave up. And after class, 00:00:44.959 --> 00:00:49.279 while I was uploading my videos, I went ahead and made a slight adjustment to my access control 00:00:49.279 --> 00:00:54.279 list and everything worked just fine. Just misconfigured. But the ACL is weird, right? 00:00:54.279 --> 00:00:59.520 Because the ACL I picked should have worked. It just didn't work for some reason. So it can be a 00:00:59.520 --> 00:01:04.680 little bit finicky when it's all said and done, especially when you're setting up IPsec in a live 00:01:04.680 --> 00:01:12.480 environment or a lab environment, demo environment. Sometimes what you've done could possibly work in 00:01:12.480 --> 00:01:16.559 the production environment. The lab environment just doesn't work for some reason. So even though 00:01:16.559 --> 00:01:21.279 I specified specific ACLs, they want to do it for me. If I went with a generic ACL, it works. So 00:01:21.279 --> 00:01:24.480 today we're just going to use a generic ACL and see if it works. So that way they were not 00:01:24.480 --> 00:01:28.959 troubleshooting deep into the night when it comes to IPsec today. All right. So let's do phase one 00:01:28.959 --> 00:01:34.000 right now and show you how to do this configuration for the certification exam. So we're going to do 00:01:34.000 --> 00:01:40.120 R1 to branch, just like we did for GRE. So I destroyed my GRE tunnels here, folks. They are 00:01:40.120 --> 00:01:46.680 all gone. And I've shut down the link between R2 and branch. So the only way we can go right now is 00:01:46.680 --> 00:01:52.160 over the Internet. We can't go any other way. So let's go over to R1. And the first thing we're 00:01:52.160 --> 00:01:59.760 going to do is create our phase one ISACAMP policy. And we do that in global configuration mode by 00:01:59.760 --> 00:02:08.199 typing crypto and then ISACAMP and then type in policy and then give the policy a number. So you 00:02:08.199 --> 00:02:15.839 can have many, many, many policies for ISACAMP on your device. And so I'm going to create policy 00:02:15.839 --> 00:02:20.679 number 10 here today. Now, once we're in this configuration mode, you'll see there's not very 00:02:20.679 --> 00:02:25.320 many options and most of them line up with what we're doing here. So you need a hash. You need 00:02:25.320 --> 00:02:29.960 encryption. You're going to need a group that is Dippy Hellman group. You need authentication and 00:02:29.960 --> 00:02:35.199 then lifetime. But you don't have to specify a lifetime because there is a default value for 00:02:35.199 --> 00:02:39.600 that lifetime. And if the lifetimes do not match, that's OK. It's just going to use the lowest 00:02:39.600 --> 00:02:46.559 lifetime between the two. So let's go ahead and type in first and foremost authentication. I'm 00:02:46.559 --> 00:02:52.199 going to pick pre-shared key today because I don't have any certificates set up for authentication. 00:02:52.199 --> 00:02:57.119 But if we wanted to use RSA encryption or RSA signatures, we can go ahead and do that for 00:02:57.119 --> 00:03:02.520 authentication. But today we're just going to use pre-shared keys. So what does that mean? It means 00:03:02.520 --> 00:03:05.800 we're going to have to set up our key later on. And I'll show you how to do that key here 00:03:05.800 --> 00:03:12.479 momentarily. Next thing I want to do is I want to specify my encryption. So encryption, you'll see 00:03:12.479 --> 00:03:17.679 that this device supports triple DES, AES and DES. I'm going to use AES because it's the best option 00:03:17.679 --> 00:03:23.520 that we have. And then I can pick the key size I want. So let's go with 256 in this particular case. 00:03:23.520 --> 00:03:28.839 Next, I'm going to pick my group for Dippy Hellman. You'll see that on this device, we have a lot of 00:03:28.839 --> 00:03:33.520 different options for our group. Remember, this goes back to that diagram I showed you earlier 00:03:33.520 --> 00:03:40.199 about the box and our IPSec framework. And what did we say? We said we pick and choose things off 00:03:40.199 --> 00:03:47.600 our shelf. And that's what makes IPSec so flexible and so scalable. So that's all I'm doing right now 00:03:47.600 --> 00:03:52.479 with IPSec. I'm just going through the framework motions of picking and choosing what I want. So 00:03:52.479 --> 00:03:57.320 let's just say here we're going to use Dippy Hellman group number 16 today. And then what else 00:03:57.320 --> 00:04:02.199 do we want to specify? I want to specify a hashing algorithm. So for our hashing algorithm, let's use 00:04:02.520 --> 00:04:13.320 SHA-512 today. All right. And that is all of them except for the lifetime. I'll type in lifetime. 00:04:13.320 --> 00:04:18.399 And we'll see that our lifetime in seconds can be anywhere from 60 seconds all the way up to 00:04:18.399 --> 00:04:27.920 86,400 seconds. And 86,400, folks, is actually the default. So this is a lifetime of phase 1. 00:04:28.040 --> 00:04:33.799 What does that mean? It means if I pick 60 seconds, it means that every 60 seconds we'll 00:04:33.799 --> 00:04:42.559 renegotiate phase 1, which means we'll have new keys every time we renegotiate. So if your corporate 00:04:42.559 --> 00:04:50.320 policy states that you can't use a set of keys for longer than, let's say, 3 hours, then you would 00:04:50.320 --> 00:04:56.559 set this to 3 hours in seconds, that is. And therefore, your tunnel would always create new 00:04:56.760 --> 00:05:08.440 keys every 3 hours. All right. So let me exit out of here. Do show run pipe to section crypto. 00:05:08.440 --> 00:05:15.040 All right. And then you'll see our policy. Now, the other thing we need to do here is we need to 00:05:15.040 --> 00:05:23.239 specify the password because we indicated pre-shared keys. So we need to create a crypto 00:05:23.559 --> 00:05:34.920 isocamp key in this case. And then we specify what we want the key to actually be. So we are 00:05:34.920 --> 00:05:41.720 going to use the key today of password, which I don't recommend using the real world. Yeah. So 00:05:41.720 --> 00:05:45.839 this is gonna be for authentication purposes. So password would have to be configured on this 00:05:45.839 --> 00:05:51.640 device and this device. Now, though, we also have to specify who we're using this password with. 00:05:51.640 --> 00:05:57.920 And so this is gonna be branch. So what is branches IP address? Branches IP address is 00:05:57.920 --> 00:06:03.119 one nine eight fifty one one hundred dot forty six. So I'll put that in right there. All right. 00:06:03.119 --> 00:06:07.399 Let's look at the output of show run section crypto. That's what we have at this point in 00:06:07.399 --> 00:06:15.519 time. Right. So the phase one is now set up on our one. We now have to go ahead and set up phase 00:06:15.519 --> 00:06:21.880 one on the branch router. But great news. Everything has to match except for the lifetime 00:06:21.880 --> 00:06:31.239 and the policy number. In addition. The password has to match, but this address would have to be 00:06:31.239 --> 00:06:37.679 changed. So technically speaking, we can copy and paste all of this if we really wanted to go over 00:06:37.679 --> 00:06:44.679 to branch, paste it all in. And then put the address of our one in there, which is going to 00:06:44.679 --> 00:07:00.839 be what? Two or three zero one thirteen ninety. And there you go. That was pretty easy, wasn't it? 00:07:00.839 --> 00:07:06.600 To do the branch after our one was done. Pretty straightforward. So let's just verify that we 00:07:06.600 --> 00:07:12.359 have what we need on both of these. So something to be able to do on the exam, compare and contrast. 00:07:12.359 --> 00:07:26.440 The policy, the crypto policy, one, two, three, one, two, three on both of them. So comparing 00:07:26.440 --> 00:07:32.399 this one to this one. Keep in mind, if any of these values of this is different on the two, 00:07:32.399 --> 00:07:35.920 if this is different on the two, if this is different on the two or this is different on 00:07:35.920 --> 00:07:44.679 the two, that's why IPSEC is not working and getting past phase one. If this address is not 00:07:44.679 --> 00:07:51.720 the right address, if this address is not the right address again, that is why phase one is 00:07:51.720 --> 00:08:04.000 not working. So I'll show you later how we identify a phase one is working or not. But essentially, 00:08:04.279 --> 00:08:16.799 you'd be looking for in the output. Of our output later, QMIDLE. If we see QM idle in an output 00:08:16.799 --> 00:08:21.160 later, that means phase one is working. So keep that in mind. That's going to come back later. 00:08:21.160 --> 00:08:26.160 If we don't see QM idle, it means we have a problem. We can't either reach each other or 00:08:27.000 --> 00:08:36.880 we have mismatching parameters. So now that phase one is done, let's go ahead and deal with phase 00:08:36.880 --> 00:08:43.799 number two. Phase number two is about the IPSEC policies. So defining where is the tunnel going, 00:08:43.799 --> 00:08:48.840 what is going in that tunnel, how is the traffic going to be treated when it's all said and done. 00:08:49.000 --> 00:08:57.080 So the first thing we have to do is create an access control list. The access control 00:08:57.080 --> 00:09:06.479 list is going to be used to define what traffic is allowed to go in that tunnel, 00:09:06.479 --> 00:09:15.359 or what traffic is allowed to use that particular tunnel. So let's type an IP access list. We're 00:09:15.359 --> 00:09:24.159 going to create an extended access control list here called IPSEC underscore VPN underscore ACL. 00:09:24.159 --> 00:09:41.760 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 00:09:41.760 --> 00:09:57.880 our entire 10 network, going to where? Going to our entire 10 network anywhere else. So what does 00:09:57.880 --> 00:10:06.200 that mean? It means that if traffic is coming from let's say 10.0.0.10, going to 10.0.255.4, 00:10:06.479 --> 00:10:15.760 then it would match both of those. Because there's our source, there's our destination. 00:10:15.760 --> 00:10:35.159 Next, we need to specify how the traffic is going to be treated. So how do we do that? We use our 00:10:35.280 --> 00:10:42.719 transform set it's called. So the transform set is created by typing in crypto. 00:10:42.719 --> 00:11:12.640 Oh, crypto, and then IPSEC, and then trans. Come on. 00:11:13.200 --> 00:11:20.440 IPSEC and then transform. I typed something wrong somewhere. That's the problem. There it is. IPSEC 00:11:20.440 --> 00:11:28.719 transform set. And then you have to give the transform set a name. So we'll call it today 00:11:28.719 --> 00:11:40.479 IPSEC underscore VPN underscore transformers. And then you'll see here that this is where we can 00:11:40.479 --> 00:11:48.640 start specifying the IPSEC protocol we want to use. And then the encryption algorithm we want 00:11:48.640 --> 00:11:54.640 to use. And then the hashing algorithm we want to use. So for example, remember, I said we want to 00:11:54.640 --> 00:12:03.760 use ESP and not a H for IPSEC protocol, because ESP allows me to do encryption, whereas a H doesn't 00:12:03.760 --> 00:12:09.359 allow me to do encryption. So I'm going to type in ESP. And now that I've done that, you'll see 00:12:09.359 --> 00:12:22.640 my options change. So let's go with ESP AES and AES 256 to protect our actual user traffic. And 00:12:22.640 --> 00:12:29.119 then when it comes to our integrity checking, what hashing algorithm do you want to use? Let's pick 00:12:29.119 --> 00:12:42.599 ESP SHA 512 HMAC for authentication purposes. Right now we are in transform set configuration 00:12:42.599 --> 00:12:52.280 mode. And there's not a whole lot of options here. As you can see, the only real option we have is 00:12:52.359 --> 00:12:59.159 mode. And this is where you specify tunnel mode, or transport mode. So in this case, 00:12:59.159 --> 00:13:05.080 what are we doing, we're creating a VPN tunnel over the internet. So I would need tunnel mode, 00:13:05.080 --> 00:13:11.479 because tunnel mode gives me the opportunity to do what? Do you remember folks? Tunnel mode gives 00:13:11.479 --> 00:13:23.559 me the opportunity to create a new header. So the public IP addressing can go in this header now. 00:13:24.440 --> 00:13:29.880 Whereas if we want transport mode, I wouldn't have a new header for the public IP addressing. 00:13:29.880 --> 00:13:42.840 Oh, we're gonna go with tunnel mode. Now tunnel mode is the default, folks. I'm pulling on a 00:13:42.840 --> 00:13:46.919 cable down here. That's not good. Alright, so tunnel mode is the default. So you don't actually 00:13:46.919 --> 00:13:55.679 have to specify tunnel mode. It's the default. Alright, let's exit out of here. So now that 00:13:55.679 --> 00:14:01.599 we've done that, what's next? Now we have to put it all together. And we do that with what is called 00:14:01.599 --> 00:14:12.320 a crypto map for this configuration. So we'll type in crypto. We'll type in IP sec. Wait, no. Crypto 00:14:12.320 --> 00:14:20.880 map. There you go. Crypto map. Now I type in the name of my crypto map today. So we're gonna call 00:14:20.880 --> 00:14:29.440 IP sec VPN underscore crypto map. And then we need need a little bit of help here. Sequence 00:14:29.440 --> 00:14:35.039 number, because our crypto maps can have multiple sequences, just like a route map can, you can have 00:14:35.039 --> 00:14:40.320 multiple sequences. So same idea, we're building this construct kind of like a route map. So in 00:14:40.320 --> 00:14:45.919 this case, I have sequence number 10 for this crypto map. And what I now need to specify after 00:14:45.919 --> 00:14:57.280 I specify my sequence number is how is phase one being accomplished. So if you remember, phase one, 00:14:57.280 --> 00:15:05.919 we are using ISA camp, right, we created an ISA camp policy. But if we wanted to use a manual 00:15:05.919 --> 00:15:11.039 keying, we could do manual keying for phase one if we wanted to, which is not recommended for 00:15:11.039 --> 00:15:17.760 the internet. Because with ISA camp, I can use Diffie Hellman for dynamic keying. So IP sec ISA 00:15:17.760 --> 00:15:22.479 camp is what we're using here. You can also use GDOI, which is beyond the scope and course in the 00:15:22.479 --> 00:15:27.119 certification again. But that is another option that you have available to you when it comes to 00:15:27.119 --> 00:15:35.440 your keying material. So I'm now in crypto map configuration mode. And what do I now need to do, 00:15:35.440 --> 00:15:40.799 I now need to specify things like my transform set. And I need to specify the access control 00:15:40.799 --> 00:15:46.640 list. And I need to specify where the tunnel is going. So who is my peer now. So this is where I 00:15:46.640 --> 00:15:51.599 just put it all together. So we've already created the ACL. So let's go ahead and apply that. So you 00:15:51.599 --> 00:15:59.599 type in match IP. Nope, just match address, match address. And then what is the name of that access 00:15:59.599 --> 00:16:16.559 control list you created. And then we need to set our transform set. And so what was the name of 00:16:16.559 --> 00:16:26.320 the transform set that we created? IP sec VPN transformers. And then we need to specify the 00:16:26.320 --> 00:16:35.359 peers IP address. So set peer and who is that it's going to be branch and what is their IP address, 00:16:35.359 --> 00:16:50.880 this is their IP address. All right. So let's exit out of here. Do show run pipe to section 00:16:50.880 --> 00:16:57.280 crypto and do show run pipe to section ACL. 00:17:02.799 --> 00:17:09.359 All right, so here's what we're going to do. We need we can use we can use this exact same ACL 00:17:10.160 --> 00:17:13.439 over on branch. So let's go ahead and use that over on branch two. 00:17:14.000 --> 00:17:23.119 Because the numbers work for us. What else do we want to do here? We need our 00:17:25.599 --> 00:17:31.599 transform set. So let's copy and paste the transform set over. 00:17:31.599 --> 00:17:40.239 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 00:17:40.239 --> 00:17:45.680 different. So let's go ahead and paste that all in. But the peer address has to be different. So let's type in 00:17:46.400 --> 00:18:05.199 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. 00:18:08.400 --> 00:18:11.839 All right, so show run pipe to section crypto. 00:18:12.719 --> 00:18:22.479 Beautiful. Looks good. And show run pipe to section access for access lists. And there we go. 00:18:24.239 --> 00:18:29.199 So far, so good, folks. We've completed our configuration of phase one. We've completed our 00:18:29.199 --> 00:18:36.640 configuration of phase two. So what does that mean for us now? It means that we're gonna have to apply 00:18:37.599 --> 00:18:47.920 it to our interface. So how do we apply it to our outgoing interface? What we're going to use 00:18:47.920 --> 00:18:55.119 is the crypto map command in interface configuration mode. So if we go here, you'll see the crypto map 00:18:55.119 --> 00:19:00.719 command specifying the crypto map you created on the actual physical interfaces. So let's do that 00:19:00.719 --> 00:19:06.880 in both our cases and keep our fingers crossed. So we've got interface gigabit ethernet 0 slash 1. 00:19:10.800 --> 00:19:16.000 Crypto map. IPsec VPN crypto map. 00:19:22.640 --> 00:19:27.920 Let's go over to R1 and it's going to be interface fast ethernet 0 slash 0 slash 0. 00:19:28.880 --> 00:19:32.640 Crypto map and the name of the crypto map. 00:19:38.319 --> 00:19:43.599 So now you'll see that it's actually turned on on our interface. And we type in show 00:19:46.000 --> 00:19:57.439 isocamp show crypto isocamp security association. You'll see there's no security associations right 00:19:57.439 --> 00:20:04.719 now. Let's go over to branch and look at the same output. Why is it blank? Why is everything blank? 00:20:05.280 --> 00:20:09.280 Because we haven't generated any interesting traffic to actually trigger the tunnel to be 00:20:09.280 --> 00:20:17.119 formed. So let's go ahead and trigger some interesting traffic from DSW one right now. 00:20:17.920 --> 00:20:25.520 Let's do something like this. Let's type in ping 10.0.254.1 00:20:27.839 --> 00:20:31.040 and we're going to source it from 10.0.0.1. 00:20:40.000 --> 00:20:43.280 Whoa! Whoa! It worked first. 00:20:45.520 --> 00:20:52.400 Sorry. Last time I did a demo. Nope. Didn't work. Failed. All right. We got it. So let's just check 00:20:52.400 --> 00:20:57.680 to make sure it's actually working. Let's go over to R1 and let's check our crypto isocamp 00:20:57.680 --> 00:21:05.359 security association. QM idle. There you go. QM idle. That's what I was referring to a while ago. 00:21:05.359 --> 00:21:09.920 How do we know if the isocamp security association is working? You're going to see QM idle. If you 00:21:09.920 --> 00:21:15.920 see anything else, folks, it's not working properly for you. All right. In regards to this course, 00:21:15.920 --> 00:21:20.560 the certification exam and all that stuff. So the certification exam, if they show you anything else 00:21:20.560 --> 00:21:26.319 here, that means you need to go back and troubleshoot phase one. Phase one. All right. 00:21:26.319 --> 00:21:30.079 But if it says QM idle, then you don't have to go back and troubleshoot phase one. 00:21:32.719 --> 00:21:37.760 Everything's good for phase one. All right. Let's go over to branch. 00:21:39.839 --> 00:21:47.280 All right. Same idea here. So this is fantastic. So we should be able to ping. Let's try this 00:21:47.280 --> 00:22:01.760 from our source or ping 10.0.0.1 from a source of 10.0.24.1. All right. Beautiful. I love it. 00:22:01.760 --> 00:22:07.199 All right. So we know phase one is working so far. Okay. But now the question is, is phase two 00:22:07.199 --> 00:22:12.400 working? Right. Are we actually encrypting the traffic? How can we figure that out? 00:22:12.400 --> 00:22:18.319 Use the command, show crypto, ISACAMP, no, show crypto, IPSEC. 00:22:23.359 --> 00:22:30.239 A little bit of lag. Security Association. So ISACAMP Security Association, phase one, 00:22:30.239 --> 00:22:36.640 IPSEC Security Association, phase two. So you'll see here that the crypto map has been applied to 00:22:36.640 --> 00:22:43.760 this interface. My local address is 203.0.1.13.90. It says here that local identity, 00:22:43.760 --> 00:22:50.800 this is the access control list we created, the ACL. So any traffic from 10.0.0.0 to all the way 00:22:50.800 --> 00:22:59.520 to 10.255.255.255 that arrives at me is allowed to use this tunnel as long as it's going to any 00:22:59.520 --> 00:23:05.359 IP address in this exact same range. Right. And so you could create any ACL that you need in order 00:23:05.359 --> 00:23:09.280 to accomplish your objective. If you only want a certain subnet to use the tunnel, then you only 00:23:09.280 --> 00:23:14.640 put the subnet for that particular tunnel. The peer, this is the IP address on the other side 00:23:14.640 --> 00:23:22.479 of the tunnel. This is how you know that it's working. You see here it says encapsulation, 00:23:22.479 --> 00:23:30.719 decapsulation, encryption, decryption. So we go back to DSW1 and we ping and we repeat 00:23:31.680 --> 00:23:40.160 a bunch of times. Let's go back to R1 now and let's take a peek at that. You see it going up. 00:23:43.040 --> 00:23:48.479 Now we're at 3000. So we know it's working. We absolutely know that phase two is doing its job 00:23:48.479 --> 00:23:52.640 now. So now we're encrypting our packets as they go over the internet 00:23:55.439 --> 00:23:58.400 between R1 and branch, and then they get decrypted on the other side. 00:24:00.959 --> 00:24:02.959 Notice down here 00:24:05.280 --> 00:24:10.959 that our MTU is 1422. That's what the recommendation is right now. 00:24:15.760 --> 00:24:19.520 So when you think about all the encryption that's happening 00:24:21.839 --> 00:24:22.640 with IPsec, 00:24:23.599 --> 00:24:31.599 going back to this diagram, we're adding on in tunnel mode headers. So we've got 20 bytes here. 00:24:32.319 --> 00:24:38.640 So now you've got 20. So this gets dropped down to what? This data and IP header, this is now 1480 00:24:39.760 --> 00:24:46.079 because now you got 20 there. But this stuff here, folks, this stuff here is variable, 00:24:46.079 --> 00:24:52.079 meaning that it really depends on the algorithms you are using. The greater the algorithms like 00:24:52.079 --> 00:24:59.920 AES-256, SHA-512, and stuff like that, results in these being much larger, much larger. 00:25:02.479 --> 00:25:09.439 Meaning that you don't really know what the actual size of these are going to be in the real world. 00:25:10.000 --> 00:25:13.439 So one of the things you might want to do is simply just do a test 00:25:14.160 --> 00:25:20.160 to find out what that might possibly be. So for example, let's see if we can do a little test right 00:25:20.160 --> 00:25:30.079 now. If we go back here and stop this, let's do this. 00:25:30.719 --> 00:25:34.719 But let's say, do not fragment, do not fragment. 00:25:46.640 --> 00:25:51.119 Oh, packets too small, packets 100, right? So we got to set our packet size. 00:25:51.680 --> 00:25:55.119 So let's set our size. I'm like, why did that work so well? I'm like, oh, 00:25:55.839 --> 00:26:00.160 right, so we got to set our packet size. So let's set our size. I'm like, why did that work? It 00:26:00.160 --> 00:26:05.839 shouldn't have worked. Let's set our size to something like 1500. Okay, you'll see that it's 00:26:05.839 --> 00:26:11.680 not going to get through. That's what that M means. Fragmentation needs to happen, but it's not allowed. 00:26:12.400 --> 00:26:17.839 So 1500 is too big right now. Let's just drop this down to 1400, 00:26:17.839 --> 00:26:22.880 and you'll see that that works. So let's go to 1450. Okay, that doesn't work. 00:26:25.760 --> 00:26:31.680 Let's go ahead and drop this down to 1425. Okay, that doesn't work. 00:26:33.680 --> 00:26:39.680 Let's drop this down to 1420. Okay, you'll see that that works. Remember what it said to us? 00:26:40.400 --> 00:26:50.319 It said to us approximately 1422. So if we come back here, 1422, that works. 1423 doesn't work. 00:26:51.199 --> 00:26:57.920 So what we know is that the MTU should be set on our interface to approximately 1422. But again, 00:26:59.359 --> 00:27:06.479 that might still not be enough for all scenarios and circumstances. So you should drop it down a 00:27:06.479 --> 00:27:11.680 bit more, like 1400 would be better. So now going to the physical interface, for example. 00:27:14.319 --> 00:27:18.959 So configure terminal, what is that interface, fast ethernet, zero size, zero size, zero. 00:27:19.280 --> 00:27:25.520 IPMTU 1400 would be a recommendation on that physical interface. 00:27:28.560 --> 00:27:35.839 So that way there, we can rely on things like path MTU discovery and other things to ensure that 00:27:36.719 --> 00:27:39.839 we don't have to end up doing fragmentation when it's all said and done. 00:27:42.719 --> 00:27:46.560 The MTU is still 1500 on the interface. I always want you to remember that. 00:27:46.560 --> 00:27:50.640 When you are setting this command, it doesn't physically change the interface. 00:27:50.640 --> 00:27:57.839 It just changed the reference value that other services use. So for example, with path MTU 00:27:57.839 --> 00:28:03.599 discovery, path MTU discovery can now figure out, oh, one of the MTUs is 1400. Now the interface 00:28:03.599 --> 00:28:09.680 is still 1500. Let's not forget that. But it says it's 1400. So now with path MTU discovery, 00:28:09.680 --> 00:28:15.599 my PCs will not send anything greater than 1400. And as a result of that, fragmentation will not 00:28:15.599 --> 00:28:21.439 occur then, which is great, which is great. So now that you have your 1400 that's being sent 00:28:21.439 --> 00:28:26.000 from the clients, you add on your encapsulation, your encryption and everything else. Now you get 00:28:26.000 --> 00:28:32.959 something that is approximately, let's say 1479, 1480 in this case, because 1422 was the number 00:28:32.959 --> 00:28:37.280 that we saw that kind of worked. So we get something like 1480. That's fine. It's perfect. 00:28:37.280 --> 00:28:44.239 We got what we want, right? As long as all of this is not greater than 1500, it's perfect. 00:28:44.239 --> 00:28:48.319 It's perfect. So when you change this, a lot of people are misleading to think when you do this, 00:28:48.319 --> 00:28:52.160 it actually changes the MTU of the physical interface. No, no, no, no, no. The physical 00:28:52.160 --> 00:28:59.280 interface, folks, is always 1500. Always, always, always 1500. This is just a reference value so 00:28:59.280 --> 00:29:04.479 other things can adjust themselves. So that way they're in the end, everything is the right size 00:29:04.479 --> 00:29:10.400 when it's all said and done, meaning 1500 or less. So if we go back to DSW1 now, this one shouldn't 00:29:10.400 --> 00:29:15.920 work anymore. So 1420 shouldn't work because the interface is now set to what? 1400 as we said. 00:29:17.280 --> 00:29:20.079 So if we now go and type in something like 1400, 00:29:21.280 --> 00:29:30.319 right, that doesn't work. But something like 1399 does. Oops. What's going on right now? 00:29:30.319 --> 00:29:39.599 Wow. What, I broke it? Did I break my whole interface? 00:29:45.199 --> 00:29:46.400 All right. So that one's working. 00:29:46.400 --> 00:30:01.199 Perfect. All right. So the idea here is for you to recognize for the certification exam 00:30:01.199 --> 00:30:06.239 that when it comes to setting things like your MTU, all right, so in this case, 00:30:06.239 --> 00:30:11.760 since I set it to 1400, it's actually taking into consideration the 1400 minus 00:30:12.719 --> 00:30:17.280 the actual header information and so on and so forth as well in that particular case. 00:30:18.160 --> 00:30:20.000 All right. So in my case, setting it to 00:30:25.680 --> 00:30:29.199 setting it to something like 1422 would work perfectly for us when it's all said and done. 00:30:30.079 --> 00:30:34.479 Okay. So in the end anyways, the key here for you to realize for the certification exam 00:30:34.479 --> 00:30:40.400 is that this is not a science. This is an art. Okay. Meaning that in the end, when it comes to 00:30:40.400 --> 00:30:45.680 figuring out your MTU, you have to understand exactly what's being done on that particular 00:30:45.680 --> 00:30:51.920 link, on that particular connection. And then from there, adjusting your MTU to ensure that 00:30:51.920 --> 00:30:57.280 it meets your particular requirements. So that way their fragmentation is not occurring. Right. 00:30:57.280 --> 00:31:01.520 And this is all because of what? All the added headers we're adding. So you are going to be 00:31:01.520 --> 00:31:06.079 tested on this, meaning that you are going to be tested on, hey, look at this. We've got IPsec 00:31:06.079 --> 00:31:11.199 being used. We have GRE being used. What is one of the problems we could face? Fragmentation. 00:31:11.199 --> 00:31:16.079 How do we solve our problems of fragmentation? Adjusting our MTUs. So that way there in the end, 00:31:16.079 --> 00:31:22.640 we are going to make sure that packets are of the right size and they're not bigger than the 00:31:24.000 --> 00:31:28.160 1500 max that our interface is actually physically able to support. 00:31:30.319 --> 00:31:33.680 That's your goal for the certification exam. All right. And then knowing the commands, 00:31:33.680 --> 00:31:36.959 we have to change it on the interface. IPMTU is the way that you're going to change it on 00:31:36.959 --> 00:31:42.880 the particular interface. Right. So we know that we're up and running here. Everything's working 00:31:42.880 --> 00:31:49.599 well. I'm going to change some things back here because I want to have more of a discussion as 00:31:49.599 --> 00:31:56.880 we move on here. All right. So change that back. Change this. Make sure everything's the way I 00:31:56.880 --> 00:32:05.359 want it right now. That looks good. Go to DSW1. Just go with our regular size. Looks good. All 00:32:05.359 --> 00:32:09.359 right. So that's just 100 bytes, those particular packets. So those are going to make it through no 00:32:09.359 --> 00:32:18.319 matter what. So we've had the opportunity to take a look at the output of show crypto 00:32:19.119 --> 00:32:23.760 security association, show crypto security association. 00:32:25.680 --> 00:32:30.160 And what else do we want to take a peek at here as we're verifying? So we'll take a look at our 00:32:30.160 --> 00:32:34.719 slides just to make sure we've got everything covered. So crypto security association, 00:32:35.359 --> 00:32:39.280 crypto security association. We've already covered all of that. So we're good. 00:32:39.920 --> 00:32:43.599 If you want to check out the actual key that's being utilized, like the pre-shared key, 00:32:43.599 --> 00:32:48.239 the password, in case you ever need to verify it, show crypto key or you can just look at 00:32:48.239 --> 00:32:53.119 the running config. You can see it there too. You want to view your policy. You can type in 00:32:53.119 --> 00:32:57.520 secure crypto ISA camp policy. Remember the policy on one side has to match the policy on the other 00:32:57.520 --> 00:33:02.479 side. The only thing that I don't have to match are things like the lifetime or the priority 00:33:02.479 --> 00:33:10.000 number. They can be different on each side. Oh, and another thing about their lifetime is that 00:33:10.000 --> 00:33:17.280 you can specify your lifetime in seconds, or you can also specify in the amount of bytes that have 00:33:17.280 --> 00:33:23.760 been exchanged. So if you want to re-key, for example, every one gig that has been transported 00:33:23.760 --> 00:33:29.760 over the tunnel, then you can re-key for every one gig of traffic or every 10 gig of traffic, 00:33:29.760 --> 00:33:34.079 as opposed to setting it based on time. You can set it based on the number of packets, 00:33:34.079 --> 00:33:38.479 the amount of traffic bytes that have crossed the actual tunnel as well. And then phase one 00:33:38.479 --> 00:33:42.400 will re-key based on the amount of traffic that has been exchanged at that point in time, 00:33:42.400 --> 00:33:49.359 as opposed to timers. Show crypto IPsec transform set, so to verify your transform set. 00:33:49.359 --> 00:33:55.359 So in this case, we set it up with ESP AES and ESP SHA HMAC, and we're in tunnel mode. 00:33:55.920 --> 00:34:00.959 This is the one we created here. So it wasn't that one. Pardon me. It was this one, ESP-256 AES 00:34:00.959 --> 00:34:06.959 and ESP SHA-256 HMAC in tunnel mode. And there is a default transform set. So if you just wanted to 00:34:06.959 --> 00:34:10.719 use it, if you could use the default transform set, you could go ahead and use that by just 00:34:10.719 --> 00:34:16.399 specifying that one by name as default instead. But if you look, it's not using the best AES or 00:34:16.399 --> 00:34:20.639 the best SHA. So it's highly recommended you always create your own custom transform sets. 00:34:22.000 --> 00:34:26.080 And then to verify your crypto map, show crypto map, and you'll be able to verify all the 00:34:26.080 --> 00:34:29.520 parameters of your crypto map. So what is the crypto map? It's the amalgamation of what? 00:34:30.080 --> 00:34:36.879 Your phase two information. So your phase two ACL, your phase two transform set, 00:34:36.879 --> 00:34:41.199 and then the peer that you're actually trying to communicate with in that case. 00:34:43.280 --> 00:34:49.760 All right. So that is our configuration example. It worked for the first time. One try. Got it 00:34:49.760 --> 00:34:55.199 working this time. Didn't have to do any troubleshooting for our IPsec site-to-site VPN 00:34:55.199 --> 00:34:58.399 tunnel. So be familiar with everything we talked about there, folks, so that way you can pick them 00:34:58.399 --> 00:35:00.800 out of a lineup on the exam and potentially do a configuration if you have to.