WEBVTT 00:00:01.000 --> 00:00:05.400 So now we get to start talking about IPsec. 00:00:06.400 --> 00:00:08.400 So let's introduce ourselves to IPsec. 00:00:08.500 --> 00:00:13.500 Now remember, we're doing IPsec here for Cisco IOS and IOS XE. 00:00:14.700 --> 00:00:17.400 But in general, what is IPsec VPN? 00:00:17.500 --> 00:00:23.799 So IPsec VPN gives us the opportunity to create site-to-site secure tunnels 00:00:24.200 --> 00:00:26.700 or site-to-site remote access tunnels. 00:00:27.400 --> 00:00:31.400 So what we have the opportunity to do is get a secure tunnel over an untrusted network. 00:00:31.500 --> 00:00:33.900 So an example of an untrusted network is the internet. 00:00:34.400 --> 00:00:37.400 So in this particular scenario here, we have our internet. 00:00:37.900 --> 00:00:40.400 So I'm creating a secure tunnel over the internet. 00:00:40.500 --> 00:00:48.900 A secure tunnel for remote access from a mobile worker device, like a laptop, a PC, a tablet, a phone, up to headquarters. 00:00:49.000 --> 00:00:53.900 A small office, home office environment, creating a VPN tunnel from that small branch office, 00:00:54.099 --> 00:00:58.099 from that small office, home office, whatever, up to the environment. 00:00:58.200 --> 00:01:02.099 So that way anybody in the site can use the VPN tunnel to get the resources in headquarters. 00:01:02.200 --> 00:01:06.099 Anybody in the site can use the tunnel to get the resources in the headquarters. 00:01:06.199 --> 00:01:14.099 Anybody using this device that is authorized to do so can use the remote access to get to secure resources in headquarters. 00:01:14.199 --> 00:01:17.099 So we get a secure tunnel over the untrusted network. 00:01:17.199 --> 00:01:23.099 And so what we're doing is we're going to be encrypting our IPv4 traffic or our IPv6 traffic. 00:01:23.300 --> 00:01:27.300 Unicast traffic as it crosses that untrusted network. 00:01:27.400 --> 00:01:32.300 So what you need to realize about this is that it does not support other protocols. 00:01:32.400 --> 00:01:38.300 So when you use IPsec, you can't set up OSPF neighborships across an IPsec tunnel. 00:01:38.400 --> 00:01:39.300 You can't do that. 00:01:41.300 --> 00:01:48.300 So it does not support other protocols except for IPv4 and IPv6 over top of that tunnel to protect it. 00:01:48.500 --> 00:01:51.500 Oh, and it's really great at is what? 00:01:51.599 --> 00:01:55.500 Encryption, authentication, integrity checking. 00:01:55.599 --> 00:01:57.500 That's the power of IPsec. 00:01:57.599 --> 00:01:58.500 So remember this. 00:01:58.599 --> 00:02:01.500 Site-to-site is about secure point-to-point connections between sites. 00:02:01.599 --> 00:02:08.500 And remote access is going to be about secure point-to-point connections between a device running software like Cisco AnyConnect VPN Client, 00:02:08.600 --> 00:02:12.500 which has been rebranded to Cisco Secure Access with the AnyConnect Client inside of it, 00:02:12.600 --> 00:02:17.500 up to something like an office, a site that you have. 00:02:17.699 --> 00:02:18.699 So IPsec is what? 00:02:18.800 --> 00:02:20.699 IPsec itself is a framework. 00:02:20.800 --> 00:02:21.699 That's what it is. 00:02:21.800 --> 00:02:22.699 And what is a framework? 00:02:22.800 --> 00:02:24.699 A framework gives you guidance. 00:02:24.800 --> 00:02:26.699 A framework gives you best practices. 00:02:26.800 --> 00:02:31.699 A framework gives you suggestions on what you need to do in order to successfully accomplish something. 00:02:31.800 --> 00:02:36.699 So with the IPsec framework, it's about having guidelines, best practices, suggestions. 00:02:36.800 --> 00:02:44.699 So that way there, you can provide security for your Layer 3 traffic, your IPv4 Layer 3 traffic, your IPv6 Layer 3 traffic. 00:02:44.800 --> 00:02:45.699 So your what? 00:02:45.800 --> 00:02:46.699 Your IP packets. 00:02:47.000 --> 00:02:52.899 So think of it as IP packet security, internet protocol security, IP packet security. 00:02:53.000 --> 00:03:01.899 So the underlying network has to be IPv4 or IPv6, and then the traffic you're transporting over top of it has to be IPv4 or IPv6. 00:03:02.000 --> 00:03:09.899 And with the IPsec framework, we have the opportunity to provide things like authentication, integrity checking, confidentiality, 00:03:10.000 --> 00:03:14.899 and anti-replay protection, as well as things like non-repudiation as well. 00:03:15.100 --> 00:03:21.100 So a great way to visualize IPsec is to look at it this way. 00:03:21.199 --> 00:03:23.100 This is my box. 00:03:23.199 --> 00:03:29.100 I need to implement IPsec on my router. 00:03:29.199 --> 00:03:34.100 And so the framework says, hey, Raymond, you need to pick a protocol. 00:03:34.199 --> 00:03:37.100 You need to pick a hashing algorithm for integrity checking. 00:03:37.199 --> 00:03:41.100 You need to pick something for authentication. 00:03:41.300 --> 00:03:44.300 You need to pick an encryption algorithm for confidentiality. 00:03:44.399 --> 00:03:47.300 You need to pick something for key management. 00:03:47.399 --> 00:03:54.300 And so my Cisco router right now, let's say, supports all of these options. 00:03:54.399 --> 00:03:58.300 So the IPsec framework tells me I need to do these. 00:03:58.399 --> 00:04:01.300 I need to pick something from each of these categories. 00:04:01.399 --> 00:04:05.300 But what it doesn't do is it tells me what I need to pick. 00:04:05.399 --> 00:04:07.300 That's up to me to decide. 00:04:07.500 --> 00:04:11.500 That is my choice, not the framework's choice. 00:04:11.600 --> 00:04:15.500 Obviously, the framework is going to suggest that you use the best of the best of the best. 00:04:15.600 --> 00:04:19.500 But I get to pick and choose. 00:04:19.600 --> 00:04:23.500 And what I get to pick and choose is based on what my devices actually support. 00:04:23.600 --> 00:04:27.500 So, for example, if my device doesn't support AES, then I can't pick it. 00:04:27.600 --> 00:04:29.500 Because if it does, then I can't pick it. 00:04:29.600 --> 00:04:31.500 But if it does, then I can't pick it. 00:04:31.700 --> 00:04:34.700 So, for example, if my device doesn't support AES, then I can't pick it. 00:04:34.799 --> 00:04:38.700 Because it wouldn't be on my device's shelf of options to use. 00:04:38.799 --> 00:04:42.700 Now, if my device didn't support AES, I'd be throwing that device in the garbage, by the way. 00:04:42.799 --> 00:04:46.700 Because you should be using AES today. 00:04:46.799 --> 00:04:49.700 But now let's just go ahead and pick some things here. 00:04:49.799 --> 00:04:52.700 Let's pick ESP for our protocol. 00:04:52.799 --> 00:04:55.700 Let's pick pre-shared keys for authentication. 00:04:55.799 --> 00:04:57.700 SHA-2 for integrity checking. 00:04:57.799 --> 00:04:59.700 AES for authentication. 00:04:59.899 --> 00:05:00.899 SHA-2 for integrity checking. 00:05:01.000 --> 00:05:02.899 AES for confidentiality. 00:05:03.000 --> 00:05:05.899 And then Diffie-Hellman for my key management. 00:05:06.000 --> 00:05:11.899 Now, with all of that stuff, I configure this on my router. 00:05:12.000 --> 00:05:14.899 And this would be true for any other implementation of IPSec you have. 00:05:15.000 --> 00:05:17.899 Whether it's on a firewall or any other type of device. 00:05:18.000 --> 00:05:21.899 It's the same methodology here we're talking about with a framework. 00:05:22.000 --> 00:05:24.899 So, I need something from every category. 00:05:25.100 --> 00:05:30.100 And what I choose is going to be based on the level of protection that I want. 00:05:30.200 --> 00:05:32.100 When it's all said and done. 00:05:41.100 --> 00:05:44.100 The great thing about frameworks is that they don't have to change. 00:05:44.200 --> 00:05:51.100 If all of a sudden a new hashing algorithm comes along, like SHA-3. 00:05:51.299 --> 00:05:53.299 We can put it on the shelf. 00:05:53.399 --> 00:05:54.299 Does that change the framework? 00:05:54.399 --> 00:05:55.299 No, it doesn't. 00:05:55.399 --> 00:06:01.299 It just means that now we can actually take this out and put SHA-3 in the box if we wanted to. 00:06:03.299 --> 00:06:05.299 That's what a framework allows us to do. 00:06:13.299 --> 00:06:17.299 So, when it comes to IPSec, we are going to dynamically negotiate tunnels 00:06:17.500 --> 00:06:19.500 to establish what are called security associations. 00:06:21.500 --> 00:06:26.500 So, the first one is our ISACAMP security association. 00:06:35.500 --> 00:06:40.500 So, our ISACAMP security association refers to the Internet Security Association 00:06:40.600 --> 00:06:41.500 and Key Management Protocol. 00:06:41.600 --> 00:06:44.500 So, it's about establishing a security association. 00:06:44.700 --> 00:06:49.700 A relationship between two different entities, like R1 and Branch A in this particular case. 00:06:49.799 --> 00:06:52.700 And exchanging keys. 00:06:52.799 --> 00:06:54.700 Key Management Protocol. 00:06:55.700 --> 00:06:57.700 And then we also have IKE. 00:06:57.799 --> 00:06:58.700 That can be utilized as well. 00:06:58.799 --> 00:07:00.700 Internet Key Exchange. 00:07:01.700 --> 00:07:02.700 And you'll see that we have multiple phases. 00:07:02.799 --> 00:07:07.700 We have phase one that creates the ISACAMP security association. 00:07:07.799 --> 00:07:10.700 And then we have phase two, which creates the IPSec security association. 00:07:10.899 --> 00:07:12.899 So, what is phase one all about? 00:07:13.899 --> 00:07:17.899 So, phase one is all about defining what we call your ISACAMP policy. 00:07:18.000 --> 00:07:20.899 So, your Internet Security Association and Key Management Protocol policy. 00:07:22.899 --> 00:07:24.899 And so, this is about creating our first tunnel. 00:07:25.000 --> 00:07:26.899 We actually create two tunnels here. 00:07:27.899 --> 00:07:31.899 This first tunnel is used to establish a secure initial connection, 00:07:32.000 --> 00:07:36.899 which will be used to exchange information with the real ISACAMP key. 00:07:37.100 --> 00:07:39.100 This second tunnel is used to establish a secure initial connection, 00:07:39.200 --> 00:07:43.100 which will be used to exchange information with the real tunnel we'll use for security. 00:07:44.100 --> 00:07:48.100 See, the problem we have here is if I just turn around over this untrusted network 00:07:48.200 --> 00:07:52.100 and share and do what we need to do to protect the real tunnel, 00:07:52.200 --> 00:07:54.100 then that could be captured by the cybercriminals. 00:07:55.100 --> 00:07:59.100 But what if instead we generate dynamically a secure tunnel 00:08:00.100 --> 00:08:05.100 that can be regenerated at a period of time by having lifetime specification 00:08:05.299 --> 00:08:12.299 and once that's created, then we can transport the real information inside of that 00:08:12.399 --> 00:08:15.299 so that way we can protect our data with the real information. 00:08:16.299 --> 00:08:17.299 That's what's really happening here. 00:08:18.299 --> 00:08:21.299 It's like a tunnel within a tunnel in order to get the job done. 00:08:22.299 --> 00:08:26.299 So, this first tunnel here, we need our hashing algorithm, our encryption algorithm. 00:08:26.399 --> 00:08:29.299 We need to specify our key exchange algorithm that we're going to use. 00:08:29.399 --> 00:08:33.299 So, Diffie-Hellman, authentication parameters, lifetime parameters. 00:08:33.500 --> 00:08:37.500 And then once this is done, then we can go on to phase two 00:08:37.599 --> 00:08:39.500 and we can do everything else we need to do. 00:08:39.599 --> 00:08:43.500 So, this is responsible for setting up the actual encrypted data tunnel. 00:08:43.599 --> 00:08:46.500 So, this is happening inside of the phase one tunnel. 00:08:47.500 --> 00:08:49.500 And so, we're setting up the actual encrypted data tunnel 00:08:49.599 --> 00:08:52.500 through which data is securely transmitted between IPsec pairs. 00:08:52.599 --> 00:08:56.500 So, this information is going to be transmitted in a safe and secure way 00:08:56.599 --> 00:08:57.500 where the ISA-CAMP information is not. 00:08:57.599 --> 00:09:00.500 And that's okay because the ISA-CAMP information in the end 00:09:00.700 --> 00:09:03.700 allows us to dynamically create a secure tunnel 00:09:03.799 --> 00:09:07.700 over an untrusted network in an unencrypted way 00:09:07.799 --> 00:09:09.700 which ultimately produces an encrypted tunnel. 00:09:10.700 --> 00:09:13.700 It's some pretty cool tech, folks. It really is. 00:09:13.799 --> 00:09:16.700 And then from there, build that other tunnel we need 00:09:16.799 --> 00:09:17.700 using that encrypted tunnel. 00:09:17.799 --> 00:09:20.700 Whoo! That's beautiful. Absolutely beautiful. 00:09:22.700 --> 00:09:24.700 And so, with the phase two, we get to define where is the tunnel going, 00:09:24.799 --> 00:09:26.700 what's going in the tunnel, how is the traffic changing, 00:09:26.900 --> 00:09:27.900 And then, what do we do? 00:09:28.000 --> 00:09:29.900 We apply it to our interface. 00:09:31.900 --> 00:09:33.900 Physical interface in this case. 00:09:34.900 --> 00:09:36.900 And so, our tunnel goes from physical interface to physical interface. 00:09:37.000 --> 00:09:37.900 Just like with GRE, right? 00:09:38.000 --> 00:09:39.900 We had our tunnel that we created, 00:09:40.000 --> 00:09:43.900 but then we indicated what physical interfaces we're using 00:09:44.000 --> 00:09:44.900 from point A to point B. 00:09:45.000 --> 00:09:48.900 Whereas in this case, we actually put it on the physical interface. 00:09:49.000 --> 00:09:50.900 Now, what I want you to realize, too, is that 00:09:51.000 --> 00:09:52.900 when you're building a tunnel, 00:09:53.099 --> 00:09:55.099 you actually put it on the physical interface. 00:09:55.200 --> 00:09:57.099 Now, what I want you to realize, too, is that 00:09:57.200 --> 00:10:02.099 these types of tunnels are going to be initiated or brought up, 00:10:02.200 --> 00:10:05.099 meaning the security association only comes up 00:10:06.099 --> 00:10:09.099 if there's interesting traffic that arises at the router. 00:10:09.200 --> 00:10:11.099 So, the tunnel won't even be established 00:10:11.200 --> 00:10:14.099 unless traffic arrives that needs to go through the tunnel. 00:10:14.200 --> 00:10:16.099 If traffic arrives that needs to go through the tunnel, 00:10:16.200 --> 00:10:18.099 then we go through phase one, we go through phase two, 00:10:18.200 --> 00:10:20.099 we establish that, then we can use that. 00:10:20.200 --> 00:10:22.099 And then if traffic stops flowing, 00:10:22.299 --> 00:10:24.299 then after our timeout period, 00:10:24.400 --> 00:10:26.299 then all of that just gets torn down 00:10:26.400 --> 00:10:28.299 and we renegotiate, reestablish everything. 00:10:28.400 --> 00:10:34.299 So, that way there, we don't have the same parameters being used 00:10:34.400 --> 00:10:37.299 for the tunnel for a prolonged period of time. 00:10:37.400 --> 00:10:40.299 It gives us the opportunity to reestablish keying, 00:10:40.400 --> 00:10:44.299 change keying, depending on the lifetime of phase one. 00:10:44.400 --> 00:10:46.299 We have the opportunity to do that. 00:10:47.299 --> 00:10:48.299 So, there we go. 00:10:48.400 --> 00:10:50.299 We have our phase one, we have our phase two. 00:10:50.500 --> 00:10:53.500 So, in phase one, authentication can be done 00:10:53.599 --> 00:10:57.500 with things like pre-shared keys, X509 certificates. 00:10:57.599 --> 00:10:59.500 So, in production environments, X509 certificates 00:10:59.599 --> 00:11:01.500 are better than the pre-shared keys. 00:11:01.599 --> 00:11:04.500 We have Diffie-Hellman that we're going to use as an example 00:11:04.599 --> 00:11:08.500 to securely generate keys and exchange keys 00:11:08.599 --> 00:11:11.500 over the untrusted network to produce our phase one. 00:11:11.599 --> 00:11:13.500 Diffie-Hellman is absolutely amazing. 00:11:13.599 --> 00:11:15.500 If you want to learn more about Diffie-Hellman, 00:11:15.599 --> 00:11:17.500 just check out YouTube videos on Diffie-Hellman. 00:11:17.700 --> 00:11:18.700 Diffie-Hellman. 00:11:22.700 --> 00:11:24.700 With Diffie and Martin-Hellman, my gosh, 00:11:24.799 --> 00:11:26.700 to come up with this, that's just incredible. 00:11:26.799 --> 00:11:28.700 Incredible minds these two individuals had 00:11:28.799 --> 00:11:31.700 in order to come up with a secure key generation. 00:11:31.799 --> 00:11:33.700 It's really, really amazing. 00:11:33.799 --> 00:11:35.700 And it's still in use today, and they invented it 00:11:35.799 --> 00:11:37.700 in like the 80s, if I recall correctly. 00:11:37.799 --> 00:11:39.700 So, anyways, been around a long time, still works to this day. 00:11:39.799 --> 00:11:42.700 So, Diffie-Hellman for the key exchange. 00:11:42.799 --> 00:11:43.700 Keep that in mind for the exam. 00:11:43.799 --> 00:11:45.700 You get your encryption algorithms. 00:11:45.900 --> 00:11:47.900 The asymmetric algorithm that's going to be used 00:11:48.000 --> 00:11:50.900 to protect the traffic, like AES as an example. 00:11:51.000 --> 00:11:52.900 And then a hashing algorithm that's going to be used 00:11:53.000 --> 00:11:56.900 for integrity checking of that actual phase one tunnel. 00:11:57.000 --> 00:11:59.900 So, something like SHA-256 as an example. 00:12:00.000 --> 00:12:01.900 And then we also have lifetime. 00:12:02.000 --> 00:12:05.900 So, how long the policy is valid until the renegotiation happens. 00:12:06.000 --> 00:12:07.900 So, something to keep in mind here about phase one 00:12:08.000 --> 00:12:10.900 is that all of these must match 00:12:13.900 --> 00:12:14.900 between peers. 00:12:16.400 --> 00:12:17.900 Right? 00:12:18.000 --> 00:12:19.900 And then this one doesn't have to match, 00:12:20.000 --> 00:12:25.900 but the lowest value between peers is used. 00:12:28.900 --> 00:12:29.900 Okay? 00:12:30.000 --> 00:12:31.900 Keep that in mind for the exam. 00:12:32.900 --> 00:12:33.900 All right? 00:12:34.000 --> 00:12:34.900 So, that is phase one. 00:12:35.900 --> 00:12:39.900 Now, for phase two, we define things 00:12:40.000 --> 00:12:41.900 like where is the tunnel going, what is going in the tunnel, 00:12:42.000 --> 00:12:43.900 and how is the traffic going to be treated. 00:12:44.099 --> 00:12:46.099 So, in phase two, how is the traffic treated? 00:12:46.200 --> 00:12:49.099 That's going to be done with what we call an IPsec transform set. 00:12:49.200 --> 00:12:51.099 So, inside of our IPsec transform set, 00:12:51.200 --> 00:12:53.099 that's where we have to specify a security protocol, 00:12:53.200 --> 00:12:58.099 an IPsec security protocol, either AAH or ESP. 00:12:58.200 --> 00:13:01.099 So, AAH or ESP is what? 00:13:01.200 --> 00:13:06.099 AAH is called authentication header. 00:13:06.200 --> 00:13:10.099 So, we only do authentication and integrity checking in that case. 00:13:10.200 --> 00:13:13.099 Whereas with ESP, we do encryption authentication 00:13:13.400 --> 00:13:14.299 and integrity checking. 00:13:14.400 --> 00:13:17.299 So, this is not an option that you want to use 00:13:17.400 --> 00:13:20.299 when you're trying to do VPNs over the internet 00:13:20.400 --> 00:13:23.299 because you want ESP because it does encryption as well. 00:13:23.400 --> 00:13:25.299 Keep that in mind for the exam. 00:13:25.400 --> 00:13:26.299 Okay? 00:13:26.400 --> 00:13:28.299 Encapsulation mode, tunnel versus transport. 00:13:28.400 --> 00:13:30.299 So, this just determines how you're actually going 00:13:30.400 --> 00:13:32.299 to encrypt your traffic. 00:13:32.400 --> 00:13:36.299 Are you going to encrypt the entire contents of it, 00:13:36.400 --> 00:13:40.299 or are you just going to encrypt what you need 00:13:40.400 --> 00:13:42.299 in order to successfully deliver it? 00:13:42.599 --> 00:13:43.500 So, here's the difference. 00:13:43.599 --> 00:13:44.500 I'm going to show you a diagram 00:13:44.599 --> 00:13:46.500 on the difference between the two here. 00:13:46.599 --> 00:13:48.500 So, in transport mode, notice, 00:13:48.599 --> 00:13:51.500 if this is our original packet, I should say, 00:13:51.599 --> 00:13:53.500 when we use transport mode, 00:13:53.599 --> 00:13:57.500 notice how this header is reused here. 00:13:57.599 --> 00:14:01.500 So, we're really only encrypting from here to here. 00:14:01.599 --> 00:14:04.500 So, notice our data is the only thing that's being encrypted. 00:14:04.599 --> 00:14:08.500 The original IP header is not being encrypted. 00:14:08.599 --> 00:14:10.500 Whereas with tunnel mode, 00:14:10.700 --> 00:14:15.700 you see the original IP header is being encrypted now. 00:14:15.799 --> 00:14:17.700 And then we have a new IP header 00:14:17.799 --> 00:14:20.700 that is added on outside of that. 00:14:20.799 --> 00:14:22.700 So, what you need to realize 00:14:22.799 --> 00:14:25.700 is there's really two different purposes for this. 00:14:25.799 --> 00:14:28.700 So, tunnel mode is what you're going to have to use 00:14:28.799 --> 00:14:29.700 over the internet. 00:14:29.799 --> 00:14:32.700 And it's not because of the encryption of the IP header. 00:14:32.799 --> 00:14:34.700 Let's be clear about that. 00:14:34.799 --> 00:14:36.700 You're going to use tunnel mode over the internet 00:14:36.799 --> 00:14:39.700 because this is typically going to be what? 00:14:40.000 --> 00:14:41.900 Private IP addressing. 00:14:42.000 --> 00:14:42.900 Right? 00:14:43.000 --> 00:14:45.900 Somebody in 10.0.0.10 00:14:46.000 --> 00:14:50.900 trying to go to 10.0.255 or 254.5 as an example. 00:14:51.000 --> 00:14:52.900 That's private IP addressing. 00:14:53.000 --> 00:14:55.900 And then we're trying to do a site-to-site tunnel over the internet. 00:14:56.000 --> 00:14:58.900 So, that has to be public IP addressing anyways. 00:14:59.000 --> 00:15:01.900 So, this is typically what you're going to use over the internet. 00:15:02.000 --> 00:15:03.900 However, this one here, 00:15:04.000 --> 00:15:05.900 since it preserves the private IP addressing, 00:15:06.099 --> 00:15:10.099 if you ever want to do IPSec tunnels inside of your organization, 00:15:10.200 --> 00:15:13.099 maybe you want to secure traffic going from one site, 00:15:13.200 --> 00:15:14.099 not one site, 00:15:14.200 --> 00:15:17.099 but one department to another department 00:15:17.200 --> 00:15:19.099 or maybe even one site to another site, 00:15:19.200 --> 00:15:22.099 let's say over a WAN connection. 00:15:22.200 --> 00:15:26.099 A WAN connection that allows you to preserve your private IP addressing. 00:15:26.200 --> 00:15:27.099 Well, then in that particular case, 00:15:27.200 --> 00:15:30.099 you can encrypt it from end to end 00:15:30.200 --> 00:15:33.099 and just keep that same IP address in there. 00:15:33.200 --> 00:15:35.599 So, that's the difference between the two. 00:15:35.599 --> 00:15:39.799 So, typically, because we're going to be tested on in the certification exam, 00:15:39.900 --> 00:15:43.299 running IPSec over an internet connection of some type, 00:15:43.400 --> 00:15:44.799 tunnel mode is the one you're going to use 00:15:44.900 --> 00:15:48.299 because this addressing has to be different than that addressing. 00:15:48.400 --> 00:15:50.299 But in scenarios where the addressing can be the same, 00:15:50.400 --> 00:15:53.299 then you can use transport mode instead if you want to. 00:15:53.400 --> 00:15:56.299 So, that's the difference between tunnel mode and transport mode. 00:15:56.400 --> 00:15:57.299 And then what do we have next? 00:15:57.400 --> 00:15:58.799 We have encryption next. 00:15:58.900 --> 00:16:00.299 So, when it comes to encryption, 00:16:00.400 --> 00:16:02.299 what type of encryption are we going to use? 00:16:02.400 --> 00:16:04.299 Are we going to use AES-256 as an example 00:16:04.299 --> 00:16:07.200 or something else to protect our traffic and transit across the network? 00:16:07.299 --> 00:16:10.000 And then what are we using for authentication? 00:16:10.099 --> 00:16:11.200 Authentication in this case. 00:16:11.299 --> 00:16:15.000 So, hashing algorithms is what they're referring to for authenticity, 00:16:15.099 --> 00:16:20.000 for integrity checking is what we're talking about in this particular case. 00:16:20.099 --> 00:16:24.200 Now, the other item here we see is what is going inside the tunnel. 00:16:24.299 --> 00:16:27.000 So, what is going inside the tunnel? 00:16:27.099 --> 00:16:31.799 And so, we do ACLs for that and we call those proxy ACLs. 00:16:31.799 --> 00:16:35.299 So, we'll set up an ACL that specifies traffic 00:16:35.400 --> 00:16:41.500 that is coming from 10.0.0.0.24 going to 10.0.254.0.24 00:16:41.599 --> 00:16:44.099 is going to be allowed to go through the tunnel. 00:16:44.200 --> 00:16:47.500 And so, if traffic arrives and it needs to be routed over this way 00:16:47.599 --> 00:16:49.099 and it meets the proxy ACL, 00:16:49.200 --> 00:16:52.500 then it's going to generate the IPSec tunnel for us. 00:16:52.599 --> 00:16:53.700 And then where is the tunnel going? 00:16:53.799 --> 00:16:59.400 So, what is the physical or the public IP address of the interface 00:16:59.599 --> 00:17:02.799 that we're trying to reach on the other side of that particular tunnel? 00:17:02.900 --> 00:17:04.800 All right, then we apply all of this interface 00:17:04.900 --> 00:17:08.000 and we can generate traffic to initiate our tunnel. 00:17:10.400 --> 00:17:14.000 So, that is our overview of IPSec, folks. 00:17:17.199 --> 00:17:19.599 Will you be tested on anything specific there for the exam? 00:17:21.099 --> 00:17:22.400 It's tough to say. 00:17:22.500 --> 00:17:24.699 It's mostly just theory we covered there, 00:17:24.800 --> 00:17:26.500 but if you understand that theory, 00:17:26.599 --> 00:17:28.699 then you shouldn't have any trouble answering any questions 00:17:28.699 --> 00:17:31.199 that do come up about that theory on the certification exam.