1 00:00:00,180 --> 00:00:01,020 In this lesson, 2 00:00:01,020 --> 00:00:03,540 we're going to talk all about IPSec. 3 00:00:03,540 --> 00:00:06,270 Now, IPSec is a secure network protocol suite 4 00:00:06,270 --> 00:00:07,470 that provides authentication 5 00:00:07,470 --> 00:00:08,970 and encryption of data packets 6 00:00:08,970 --> 00:00:11,250 to create a secure encrypted communication path 7 00:00:11,250 --> 00:00:14,220 between two computers over an internet protocol network. 8 00:00:14,220 --> 00:00:17,070 IPSec is the most popular protocol in use today 9 00:00:17,070 --> 00:00:19,440 for the creation and operation of VPNs, 10 00:00:19,440 --> 00:00:21,420 or virtual private networks. 11 00:00:21,420 --> 00:00:25,260 IPSec provides confidentiality, integrity, authentication, 12 00:00:25,260 --> 00:00:27,960 and anti-replay when using a VPN connection 13 00:00:27,960 --> 00:00:31,440 for both site-to-site and client-to-site VPNs. 14 00:00:31,440 --> 00:00:34,800 IPSec provides confidentiality by using data encryption. 15 00:00:34,800 --> 00:00:36,270 It's also going to provide integrity 16 00:00:36,270 --> 00:00:39,030 by ensuring the data was not modified in transit by checking 17 00:00:39,030 --> 00:00:43,020 that its hash before transmission and upon receipt match. 18 00:00:43,020 --> 00:00:44,490 Authentication is going to be provided 19 00:00:44,490 --> 00:00:46,530 by having each party verify that they are 20 00:00:46,530 --> 00:00:47,790 who they claim to be. 21 00:00:47,790 --> 00:00:50,550 And IPSec is also going to provide you with anti-replay 22 00:00:50,550 --> 00:00:51,780 by checking the sequence numbers 23 00:00:51,780 --> 00:00:54,510 on all the packets prior to transmission. 24 00:00:54,510 --> 00:00:56,910 This prevents the transmission of a duplicate packet, 25 00:00:56,910 --> 00:00:59,610 and it prevents an attacker from being able to capture 26 00:00:59,610 --> 00:01:02,490 and resend packets later as part of an attack. 27 00:01:02,490 --> 00:01:04,680 Before we go too deep into IPSec, 28 00:01:04,680 --> 00:01:07,890 let's take a big picture view of how IPSec works. 29 00:01:07,890 --> 00:01:10,890 There are five main steps in the process of establishing 30 00:01:10,890 --> 00:01:14,490 and using a secure VPN tunnel when you're using IPSec. 31 00:01:14,490 --> 00:01:17,310 First, there's a request to start a key exchange. 32 00:01:17,310 --> 00:01:20,580 Second, IKE phase one is going to authenticate the parties 33 00:01:20,580 --> 00:01:23,190 and establish a secure channel for negotiation. 34 00:01:23,190 --> 00:01:25,680 Third, IKE phase two is going to negotiate 35 00:01:25,680 --> 00:01:27,420 the security association parameters 36 00:01:27,420 --> 00:01:29,670 and fully establish the secure tunnel. 37 00:01:29,670 --> 00:01:31,680 Fourth, we're going to have data transfer, 38 00:01:31,680 --> 00:01:33,030 and this is going to allow data transfer 39 00:01:33,030 --> 00:01:35,160 between the two parties over the secure tunnel 40 00:01:35,160 --> 00:01:37,350 to occur using the IPSec parameters 41 00:01:37,350 --> 00:01:39,960 and keys stored from the security associations 42 00:01:39,960 --> 00:01:42,600 that were negotiated back in step three. 43 00:01:42,600 --> 00:01:45,660 Fifth IPSec tunnel termination's going to occur, 44 00:01:45,660 --> 00:01:47,790 and this happens when the security associations are 45 00:01:47,790 --> 00:01:50,550 terminated through either mutual agreement and deletion 46 00:01:50,550 --> 00:01:52,740 or due to timing out of the tunnel due 47 00:01:52,740 --> 00:01:55,200 to one party becoming non-responsive. 48 00:01:55,200 --> 00:01:57,510 All right, those are our five main steps, 49 00:01:57,510 --> 00:01:59,160 but it's important for us to fully understand 50 00:01:59,160 --> 00:02:00,900 how all this works in our networks, 51 00:02:00,900 --> 00:02:03,630 so that we can better troubleshoot these IPSec tunnels 52 00:02:03,630 --> 00:02:06,450 if we ever have a problem with or not working properly. 53 00:02:06,450 --> 00:02:09,090 Now, the first step is pretty self-explanatory here. 54 00:02:09,090 --> 00:02:11,460 We need to request to start a key exchange. 55 00:02:11,460 --> 00:02:13,380 This can be done by your devices automatically 56 00:02:13,380 --> 00:02:15,240 if you're using a site-to-site VPN, 57 00:02:15,240 --> 00:02:17,370 or it can be initiated by a software client 58 00:02:17,370 --> 00:02:19,230 on your laptop if you're going to be using 59 00:02:19,230 --> 00:02:20,820 a client-to-site method. 60 00:02:20,820 --> 00:02:21,990 Either way, the request 61 00:02:21,990 --> 00:02:24,270 to initiate a VPN connection is going to occur, 62 00:02:24,270 --> 00:02:27,750 and then we can move to our second step, the IKE phase one. 63 00:02:27,750 --> 00:02:29,310 Now, during IKE phase one, 64 00:02:29,310 --> 00:02:32,010 the IPSec peers have their identities authenticated 65 00:02:32,010 --> 00:02:33,960 and encrypted for protection. 66 00:02:33,960 --> 00:02:35,610 Then there's going to be a negotiation 67 00:02:35,610 --> 00:02:38,220 that occurs to create a matching IKE SA, 68 00:02:38,220 --> 00:02:41,070 or internet key exchange security association, 69 00:02:41,070 --> 00:02:42,960 between the two IPSec peers 70 00:02:42,960 --> 00:02:45,750 to protect the key exchange that's about to occur. 71 00:02:45,750 --> 00:02:48,090 Next, the IPSec peers are going to perform 72 00:02:48,090 --> 00:02:50,280 an authenticated Diffie-Hellman key exchange, 73 00:02:50,280 --> 00:02:52,620 so that both IPSec peers will have a copy 74 00:02:52,620 --> 00:02:54,510 of the same shared secret key, 75 00:02:54,510 --> 00:02:56,460 and that way they can use that to establish 76 00:02:56,460 --> 00:02:59,070 and secure an IKE phase two tunnel. 77 00:02:59,070 --> 00:03:01,500 The internet key exchange, or IKE phase one, 78 00:03:01,500 --> 00:03:04,230 can use one of two modes to conduct this process. 79 00:03:04,230 --> 00:03:06,870 We can use either main mode or aggressive mode. 80 00:03:06,870 --> 00:03:08,340 Now, when we're using main mode, 81 00:03:08,340 --> 00:03:09,930 it's going to conduct three two-way 82 00:03:09,930 --> 00:03:11,700 exchanges between the peers. 83 00:03:11,700 --> 00:03:14,160 This goes from the initiator to the receiver. 84 00:03:14,160 --> 00:03:16,590 Now the first exchange between the IPSec peers is 85 00:03:16,590 --> 00:03:19,500 to agree upon which algorithms and hashes are going to be used 86 00:03:19,500 --> 00:03:22,890 to secure the IKE communications throughout this process. 87 00:03:22,890 --> 00:03:25,020 The second exchange that they're going to do is going to be 88 00:03:25,020 --> 00:03:27,810 between the peers using a Diffie-Hellman key exchange 89 00:03:27,810 --> 00:03:30,300 to generate the shared secret key material that's going 90 00:03:30,300 --> 00:03:32,520 to be used to create these shared secret keys 91 00:03:32,520 --> 00:03:34,290 that we can then send to the other party 92 00:03:34,290 --> 00:03:36,150 by sending an assigned random number, 93 00:03:36,150 --> 00:03:38,970 and that way the two parties can prove their identities. 94 00:03:38,970 --> 00:03:40,350 Then we're going to have a third exchange 95 00:03:40,350 --> 00:03:42,570 between the IPSec peers, and this occurs 96 00:03:42,570 --> 00:03:44,400 so that each side can verify the identity 97 00:03:44,400 --> 00:03:46,770 of the other side by looking at an encrypted form 98 00:03:46,770 --> 00:03:48,990 of the other peer's IP address. 99 00:03:48,990 --> 00:03:51,180 Now, by the time these three exchanges are finished, 100 00:03:51,180 --> 00:03:54,360 both peers have received matching IKE security associations 101 00:03:54,360 --> 00:03:55,740 or IKE SAs. 102 00:03:55,740 --> 00:03:58,170 These can now be used for ISAKMP exchanges 103 00:03:58,170 --> 00:04:00,480 between the IPSec peers, moving forward 104 00:04:00,480 --> 00:04:02,130 throughout the rest of the process. 105 00:04:02,130 --> 00:04:04,170 These security associations are going to contain 106 00:04:04,170 --> 00:04:06,630 the authentication methods used by the peers. 107 00:04:06,630 --> 00:04:08,640 The encryption and hash algorithms used, 108 00:04:08,640 --> 00:04:10,230 the Diffie-Hellman groups used, 109 00:04:10,230 --> 00:04:14,070 the expiration of the IKE SA, and the shared secret values 110 00:04:14,070 --> 00:04:15,600 for the encryption algorithms. 111 00:04:15,600 --> 00:04:17,790 Basically, these IKE SAs have everything 112 00:04:17,790 --> 00:04:19,649 that both peers need in order to make 113 00:04:19,649 --> 00:04:22,019 and maintain their IPSec tunnels. 114 00:04:22,019 --> 00:04:23,910 Now, the second mode you can use is known 115 00:04:23,910 --> 00:04:26,430 as aggressive mode, and this has fewer exchanges 116 00:04:26,430 --> 00:04:27,450 than the main mode. 117 00:04:27,450 --> 00:04:29,700 So instead of having three, we're going to have less. 118 00:04:29,700 --> 00:04:31,080 This results in fewer packets 119 00:04:31,080 --> 00:04:34,170 and a faster initial connection than using main mode. 120 00:04:34,170 --> 00:04:36,870 Now in aggressive mode, almost everything needed 121 00:04:36,870 --> 00:04:38,790 for the proposed security association 122 00:04:38,790 --> 00:04:41,490 is going to be sent by the initiator at first. 123 00:04:41,490 --> 00:04:43,470 This includes the Diffie-Hellman public key, 124 00:04:43,470 --> 00:04:46,230 the signed random number, and an identity packet. 125 00:04:46,230 --> 00:04:48,240 Then it's going to be received, 126 00:04:48,240 --> 00:04:50,790 and the receiver is going to send everything back at once. 127 00:04:50,790 --> 00:04:53,280 So the initiator only needs to confirm the exchange 128 00:04:53,280 --> 00:04:54,930 to finish the association. 129 00:04:54,930 --> 00:04:56,790 This is why it's considered more aggressive 130 00:04:56,790 --> 00:04:58,140 because one side is saying, 131 00:04:58,140 --> 00:04:59,760 here's all the things I want to use, 132 00:04:59,760 --> 00:05:02,520 and the second side can say, okay, I'll go along with that. 133 00:05:02,520 --> 00:05:04,650 Now, this is considered less secure than main mode, 134 00:05:04,650 --> 00:05:07,200 but again, it's a lot faster than using main mode 135 00:05:07,200 --> 00:05:09,360 'cause we don't have to go through these three passes 136 00:05:09,360 --> 00:05:10,920 and three exchanges. 137 00:05:10,920 --> 00:05:13,500 Now, once you have the IKE security associations, 138 00:05:13,500 --> 00:05:15,570 and they've been received by either using main mode 139 00:05:15,570 --> 00:05:17,220 or aggressive mode, we can move 140 00:05:17,220 --> 00:05:18,990 into step three of our process. 141 00:05:18,990 --> 00:05:20,820 This is the IKE phase two portion 142 00:05:20,820 --> 00:05:22,500 of our tunnel establishment. 143 00:05:22,500 --> 00:05:24,150 Now, the purpose of IKE phase two is 144 00:05:24,150 --> 00:05:26,640 to negotiate IPSec security associations 145 00:05:26,640 --> 00:05:28,860 to set up the IPSec tunnel. 146 00:05:28,860 --> 00:05:31,140 IKE phase two is used to negotiate the IPSec 147 00:05:31,140 --> 00:05:33,330 Security Association parameters that are protected 148 00:05:33,330 --> 00:05:36,660 by the existing IKE SA that we created in phase one. 149 00:05:36,660 --> 00:05:39,930 This allows us to establish IPSec security associations 150 00:05:39,930 --> 00:05:42,450 to periodically renegotiate security associations 151 00:05:42,450 --> 00:05:44,190 we need to maintain that security 152 00:05:44,190 --> 00:05:46,800 and to perform additional Diffie-Hellman key exchanges 153 00:05:46,800 --> 00:05:48,120 if we need to. 154 00:05:48,120 --> 00:05:50,280 During IKE phase two, we can accomplish this 155 00:05:50,280 --> 00:05:51,600 by using quick mode. 156 00:05:51,600 --> 00:05:53,160 Now, quick mode can only occur 157 00:05:53,160 --> 00:05:55,200 after IKE has already been established 158 00:05:55,200 --> 00:05:57,420 in that secure tunnel during phase one, 159 00:05:57,420 --> 00:05:59,790 using either main or aggressive modes. 160 00:05:59,790 --> 00:06:03,210 Using quick mode, we can negotiate a shared IPSec policy, 161 00:06:03,210 --> 00:06:06,150 and we can also derive shared secret key materials 162 00:06:06,150 --> 00:06:08,670 using the IPSec security algorithms, 163 00:06:08,670 --> 00:06:12,480 and then we can use that to establish our IPSec SAs. 164 00:06:12,480 --> 00:06:14,160 Now, as discussed in phase one, 165 00:06:14,160 --> 00:06:17,700 each SA has a limited lifespan, and it will then expire. 166 00:06:17,700 --> 00:06:20,760 Now with quick mode, we can negotiate a replacement SA 167 00:06:20,760 --> 00:06:22,560 before the expiration occurs, 168 00:06:22,560 --> 00:06:24,690 and this lets us maintain that VPN tunnel 169 00:06:24,690 --> 00:06:26,880 for longer periods of time without worrying 170 00:06:26,880 --> 00:06:28,050 that the attacker could crack 171 00:06:28,050 --> 00:06:30,840 our security associations and enter that tunnel. 172 00:06:30,840 --> 00:06:32,670 Now the fourth step of this process is 173 00:06:32,670 --> 00:06:34,080 to conduct our data transfer 174 00:06:34,080 --> 00:06:37,140 with those newly established encrypted IPSec tunnels. 175 00:06:37,140 --> 00:06:39,360 This is done by using IPSec SAs 176 00:06:39,360 --> 00:06:41,250 that were created in IKE phase two. 177 00:06:41,250 --> 00:06:43,920 Now, these packets are going to be encrypted by the sender, 178 00:06:43,920 --> 00:06:46,020 and they're going to be decrypted by the receiver, 179 00:06:46,020 --> 00:06:47,220 and this makes sure everything 180 00:06:47,220 --> 00:06:49,320 is kept confidential and secure. 181 00:06:49,320 --> 00:06:51,690 Now, our fifth and final step of this process is 182 00:06:51,690 --> 00:06:53,160 to terminate the tunnel. 183 00:06:53,160 --> 00:06:55,740 This occurs whenever the IPSec SAs are deleted 184 00:06:55,740 --> 00:06:57,780 by mutual agreement by both peers, 185 00:06:57,780 --> 00:07:00,600 or if the SAs reach their lifetime expiration 186 00:07:00,600 --> 00:07:02,880 and simply time out without being replaced. 187 00:07:02,880 --> 00:07:05,580 When this happens, we need to go and create a new phase one 188 00:07:05,580 --> 00:07:08,310 and phase two key exchange if we want to reestablish 189 00:07:08,310 --> 00:07:10,920 that tunnel and conduct more data transfers. 190 00:07:10,920 --> 00:07:13,230 Now, you may or may not understand the basics 191 00:07:13,230 --> 00:07:15,180 of asymmetric cryptography yet, 192 00:07:15,180 --> 00:07:17,070 so let me take a quick detour 193 00:07:17,070 --> 00:07:19,950 and explain how this whole key exchange thing works. 194 00:07:19,950 --> 00:07:22,590 You may have noticed I kept saying the words Diffie-Hellman. 195 00:07:22,590 --> 00:07:24,810 I kept talking about a Diffie-Hellman exchange. 196 00:07:24,810 --> 00:07:26,940 Well, Diffie and Hellman are basically names 197 00:07:26,940 --> 00:07:28,800 of two computer scientists who came up 198 00:07:28,800 --> 00:07:31,200 with this really brilliant way for two systems 199 00:07:31,200 --> 00:07:32,640 that don't know each other to be able 200 00:07:32,640 --> 00:07:35,430 to exchange a secret key and trust each other. 201 00:07:35,430 --> 00:07:36,630 This process is known 202 00:07:36,630 --> 00:07:39,450 as the Diffie-Hellman Key Exchange named after them. 203 00:07:39,450 --> 00:07:42,090 So in IKE phase one, there's an initial tunnel created 204 00:07:42,090 --> 00:07:43,950 between the two peers, and they're going to begin 205 00:07:43,950 --> 00:07:46,590 to exchange some information to create those IKE SAs, 206 00:07:46,590 --> 00:07:48,150 or security associations, 207 00:07:48,150 --> 00:07:49,860 and then authenticate each other. 208 00:07:49,860 --> 00:07:51,660 Now, in a Diffie-Hellman key exchange, 209 00:07:51,660 --> 00:07:54,660 the two clients, in this case PC1 and PC2, 210 00:07:54,660 --> 00:07:56,640 are going to create their own private key, 211 00:07:56,640 --> 00:07:59,640 and I'm labeling these PRI for private. 212 00:07:59,640 --> 00:08:02,430 From that key, they can use a mathematical algorithm 213 00:08:02,430 --> 00:08:04,680 to calculate a corresponding public key, 214 00:08:04,680 --> 00:08:06,630 and then they can hand that public key 215 00:08:06,630 --> 00:08:09,690 to the other PC to create a key exchange. 216 00:08:09,690 --> 00:08:13,140 Now, PC2 has a private key called PC2 PRI, 217 00:08:13,140 --> 00:08:16,860 and they have a public key for PC1 called PC1 PUB. 218 00:08:16,860 --> 00:08:19,740 PC1 has its private key PC1 PRI, 219 00:08:19,740 --> 00:08:23,040 and a public key for PC2 called PC2 PUB. 220 00:08:23,040 --> 00:08:25,650 Now at this point, each side is going to calculate 221 00:08:25,650 --> 00:08:28,620 a shared secret using the Diffie-Hellman protocol 222 00:08:28,620 --> 00:08:31,500 by using their private key and the other person's public key 223 00:08:31,500 --> 00:08:33,240 and this mathematical algorithm, 224 00:08:33,240 --> 00:08:35,580 they get a Diffie-Hellman's shared key, 225 00:08:35,580 --> 00:08:37,559 which is going to be the same on both sides, 226 00:08:37,559 --> 00:08:40,380 and now they both have the same shared secret. 227 00:08:40,380 --> 00:08:41,990 They can now create a tunnel with it. 228 00:08:41,990 --> 00:08:44,460 At this point, they both agree to the encryption 229 00:08:44,460 --> 00:08:45,630 and the integrity methods, 230 00:08:45,630 --> 00:08:48,000 and they're going to establish their IKE phase two tunnel 231 00:08:48,000 --> 00:08:49,800 using that Diffie-Hellman key. 232 00:08:49,800 --> 00:08:52,830 At this point, they're going to use the IPSec tunnel created, 233 00:08:52,830 --> 00:08:55,290 and that becomes known as a phase two key 234 00:08:55,290 --> 00:08:58,320 that's going to create this IPSec tunnel and secure it. 235 00:08:58,320 --> 00:09:00,510 Once they have this phase two key in use, 236 00:09:00,510 --> 00:09:02,820 they now have encryption and integrity intact 237 00:09:02,820 --> 00:09:04,770 for this tunnel, and it becomes the tunnel 238 00:09:04,770 --> 00:09:07,680 inside of a tunnel, and now we have a secure method 239 00:09:07,680 --> 00:09:09,900 to communicate between the two peers. 240 00:09:09,900 --> 00:09:12,420 Now I know that was a lot, so let me break it down again 241 00:09:12,420 --> 00:09:14,040 into just five steps, and show you 242 00:09:14,040 --> 00:09:15,930 what it looks like in the real world. 243 00:09:15,930 --> 00:09:19,560 First, I have PC1, and they want to send traffic to PC2. 244 00:09:19,560 --> 00:09:22,740 When they do this, router one is going to create an initiation 245 00:09:22,740 --> 00:09:24,450 of an IPSec tunnel. 246 00:09:24,450 --> 00:09:27,210 Second, we're going to see router one and router two, 247 00:09:27,210 --> 00:09:29,610 and they start negotiating the security associations 248 00:09:29,610 --> 00:09:32,640 to form the IPSec IKE phase one tunnel. 249 00:09:32,640 --> 00:09:35,070 This is also known as our ISAKMP tunnel. 250 00:09:35,070 --> 00:09:37,320 Now in step three, the IKE phase two 251 00:09:37,320 --> 00:09:39,150 is going to create this tunnel inside 252 00:09:39,150 --> 00:09:41,850 of the tunnel when it's negotiated and set up. 253 00:09:41,850 --> 00:09:44,250 Now, once that tunnel is established, we can begin 254 00:09:44,250 --> 00:09:46,470 to conduct data transfer in step four, 255 00:09:46,470 --> 00:09:47,730 and the information starts flowing 256 00:09:47,730 --> 00:09:50,340 between PC1 and PC2 securely. 257 00:09:50,340 --> 00:09:52,770 When they're all done with that, we reach step five 258 00:09:52,770 --> 00:09:54,420 and the tunnel is going to be torn down 259 00:09:54,420 --> 00:09:57,540 and the IPSec security associations are going to be deleted. 260 00:09:57,540 --> 00:09:59,640 Now, if you wanted to be able to create another VPN, 261 00:09:59,640 --> 00:10:01,920 you can do that by starting this whole process over 262 00:10:01,920 --> 00:10:04,890 from the beginning and going through those five steps again. 263 00:10:04,890 --> 00:10:06,660 All right, at this point, we've covered 264 00:10:06,660 --> 00:10:08,820 the tunnel establishments a few different times 265 00:10:08,820 --> 00:10:10,080 in a few different ways, 266 00:10:10,080 --> 00:10:12,000 so hopefully it's beginning to make some sense. 267 00:10:12,000 --> 00:10:13,770 The reason I covered this so many times, 268 00:10:13,770 --> 00:10:15,750 in so many different ways is this is an area 269 00:10:15,750 --> 00:10:17,610 that a lot of people struggle with. 270 00:10:17,610 --> 00:10:19,860 Now, to allow the data transfer to happen, 271 00:10:19,860 --> 00:10:21,960 there are two methods that we can use. 272 00:10:21,960 --> 00:10:24,930 These are known as transport mode or tunneling mode. 273 00:10:24,930 --> 00:10:26,550 Now, transport mode is going to use 274 00:10:26,550 --> 00:10:28,470 the packet's original IP header, 275 00:10:28,470 --> 00:10:30,840 and it's used for client-to-site VPNs. 276 00:10:30,840 --> 00:10:32,130 This approach works really well 277 00:10:32,130 --> 00:10:34,350 if you have problems increasing your packet size 278 00:10:34,350 --> 00:10:35,550 because you may end up hitting 279 00:10:35,550 --> 00:10:37,380 a maximum transmitted unit size, 280 00:10:37,380 --> 00:10:39,540 or MTU, inside your network. 281 00:10:39,540 --> 00:10:41,700 Remember by default, the MTU, 282 00:10:41,700 --> 00:10:43,650 or maximum transmission unit size, 283 00:10:43,650 --> 00:10:46,590 is set at 1,500 bytes in most networks. 284 00:10:46,590 --> 00:10:48,480 If you go over 1,500 bytes, 285 00:10:48,480 --> 00:10:50,130 the packet will become fragmented, 286 00:10:50,130 --> 00:10:52,920 and this can cause issues with your VPN's functionality. 287 00:10:52,920 --> 00:10:54,840 If you're using a client-to-site VPN, 288 00:10:54,840 --> 00:10:57,150 I highly recommend you use transport mode 289 00:10:57,150 --> 00:10:59,640 as your IPSec method because it doesn't add 290 00:10:59,640 --> 00:11:01,260 additional padding to your packet 291 00:11:01,260 --> 00:11:03,210 and doesn't increase its size. 292 00:11:03,210 --> 00:11:05,040 Now, on the other hand, if you're setting up 293 00:11:05,040 --> 00:11:07,770 a site-to site-VPN, like having a regional office 294 00:11:07,770 --> 00:11:09,480 connecting back to a main office, 295 00:11:09,480 --> 00:11:11,430 then I would use tunneling mode. 296 00:11:11,430 --> 00:11:14,460 Now, tunneling mode is used to encapsulate the entire packet 297 00:11:14,460 --> 00:11:16,410 and put another header on top of it. 298 00:11:16,410 --> 00:11:18,780 This is going to increase the size of that packet, 299 00:11:18,780 --> 00:11:20,880 and it could go over your MTU. 300 00:11:20,880 --> 00:11:22,410 Now think about it this way. 301 00:11:22,410 --> 00:11:23,550 Let's say you had an envelope, 302 00:11:23,550 --> 00:11:25,260 and you put it inside another envelope 303 00:11:25,260 --> 00:11:27,450 and then wrote an address on it, you readdressed it, 304 00:11:27,450 --> 00:11:29,250 and then you shipped it to somebody else. 305 00:11:29,250 --> 00:11:31,080 This new header is going to have a new source 306 00:11:31,080 --> 00:11:33,750 and destination of the VPN terminating devices 307 00:11:33,750 --> 00:11:35,850 at the different site that it wants to go to. 308 00:11:35,850 --> 00:11:37,440 When it gets to the other site, 309 00:11:37,440 --> 00:11:40,410 the VPN concentrator is going to remove that outer envelope 310 00:11:40,410 --> 00:11:42,480 or that header inside of a network packet, 311 00:11:42,480 --> 00:11:44,700 decrypt the content, and then route it 312 00:11:44,700 --> 00:11:46,560 across their private local area network 313 00:11:46,560 --> 00:11:47,550 just as if it was coming 314 00:11:47,550 --> 00:11:49,650 from an internally connected client. 315 00:11:49,650 --> 00:11:50,880 When using tunneling mode, 316 00:11:50,880 --> 00:11:52,560 you're encapsulating the entire packet 317 00:11:52,560 --> 00:11:55,620 into a new packet, so this is going to increase the size 318 00:11:55,620 --> 00:11:57,750 of your overall packet, and it could go above 319 00:11:57,750 --> 00:12:00,960 that MTU default size of 1,500 bytes. 320 00:12:00,960 --> 00:12:03,780 If you're going to be using a site-to-site VPN, you may need 321 00:12:03,780 --> 00:12:05,910 to allow jumbo frames, which is any frame 322 00:12:05,910 --> 00:12:08,760 above an MTU size of 1,500 bytes. 323 00:12:08,760 --> 00:12:11,070 This way, it'll be properly supported. 324 00:12:11,070 --> 00:12:13,560 Normally, the best way to configure your devices would be 325 00:12:13,560 --> 00:12:16,530 to drop your maximum MTU size on your inner router 326 00:12:16,530 --> 00:12:18,570 to something like 1,400 bytes, 327 00:12:18,570 --> 00:12:20,280 and then connect it to the VPN. 328 00:12:20,280 --> 00:12:23,040 This way, there's enough room to add the extra encapsulation 329 00:12:23,040 --> 00:12:25,020 and the new packet header before transmitting it 330 00:12:25,020 --> 00:12:28,050 out over the public internet inside your VPN tunnel. 331 00:12:28,050 --> 00:12:29,730 If you control the entire network, 332 00:12:29,730 --> 00:12:31,620 you could actually raise your MTU size up 333 00:12:31,620 --> 00:12:34,260 to a maximum of 9,000 bytes if you wanted to, 334 00:12:34,260 --> 00:12:36,960 but this should only be done on your own local area networks 335 00:12:36,960 --> 00:12:38,430 'cause 9,000 byte packets will have 336 00:12:38,430 --> 00:12:40,350 trouble traversing the internet. 337 00:12:40,350 --> 00:12:43,080 Now remember, transport mode is normally going to be used 338 00:12:43,080 --> 00:12:45,750 for client-to-site VPNs, and tunneling mode 339 00:12:45,750 --> 00:12:48,750 is normally going to be used for site-to-site VPNs. 340 00:12:48,750 --> 00:12:50,100 The final thing we need to discuss 341 00:12:50,100 --> 00:12:51,480 in this lesson is the concept 342 00:12:51,480 --> 00:12:53,730 of an authentication header, or AH, 343 00:12:53,730 --> 00:12:55,710 and an encapsulating security payload, 344 00:12:55,710 --> 00:12:58,740 or ESP, within your IPSec protocol. 345 00:12:58,740 --> 00:13:01,140 Now, the AH, or authentication header, is used 346 00:13:01,140 --> 00:13:03,120 to provide connectionless data integrity 347 00:13:03,120 --> 00:13:05,910 and data origin authentication for IP datagrams, 348 00:13:05,910 --> 00:13:08,550 and it provides protection against replay attacks. 349 00:13:08,550 --> 00:13:11,160 Be aware though that the authentication header does not 350 00:13:11,160 --> 00:13:14,310 provide any kind of confidentiality of the data itself. 351 00:13:14,310 --> 00:13:16,500 Instead, the authentication header contains 352 00:13:16,500 --> 00:13:18,480 a cryptographic hash of the data, 353 00:13:18,480 --> 00:13:20,790 and this acts as identification information 354 00:13:20,790 --> 00:13:22,800 to provide the integrity between the sender 355 00:13:22,800 --> 00:13:25,650 and the receiver of each packet being transmitted. 356 00:13:25,650 --> 00:13:27,450 Now, the encapsulating security payload, 357 00:13:27,450 --> 00:13:31,050 or ESP, is used to provide authentication, integrity, 358 00:13:31,050 --> 00:13:33,870 replay protection, and confidentiality of the data. 359 00:13:33,870 --> 00:13:37,380 By using ESP within IPSec, you can rewrite the payload 360 00:13:37,380 --> 00:13:40,050 of the packet inside of an encrypted format. 361 00:13:40,050 --> 00:13:43,200 Now, with ESP, we're only protecting the confidentiality 362 00:13:43,200 --> 00:13:45,540 of the payload contained within the packet, 363 00:13:45,540 --> 00:13:47,490 not the headers themself. 364 00:13:47,490 --> 00:13:49,590 So if you're using transport mode, 365 00:13:49,590 --> 00:13:51,570 such as in a client-to-site VPN, 366 00:13:51,570 --> 00:13:53,370 you can use the authentication header 367 00:13:53,370 --> 00:13:55,590 to provide integrity for your TCP header, 368 00:13:55,590 --> 00:13:57,690 and then you can add the ESP, 369 00:13:57,690 --> 00:13:59,310 encapsulating security payload, 370 00:13:59,310 --> 00:14:02,670 to encrypt the TCP header and the data in the payload. 371 00:14:02,670 --> 00:14:05,670 But this does not encrypt the end-to-end header, 372 00:14:05,670 --> 00:14:08,160 so people outside your organization can see 373 00:14:08,160 --> 00:14:10,740 where the data's coming from and where it's going to. 374 00:14:10,740 --> 00:14:12,270 If you're using the tunneling mode, 375 00:14:12,270 --> 00:14:14,160 such as in a site-to-site VPN, 376 00:14:14,160 --> 00:14:16,677 you can instead use both the authentication header 377 00:14:16,677 --> 00:14:18,540 and the encapsulating security payload 378 00:14:18,540 --> 00:14:21,390 to provide integrity and encryption of that payload, 379 00:14:21,390 --> 00:14:23,370 including the end-to-end header. 380 00:14:23,370 --> 00:14:25,710 In this case, a new IP header is going to be added 381 00:14:25,710 --> 00:14:27,810 to the front of the packet to cover the hops 382 00:14:27,810 --> 00:14:29,760 to the other end of the secure connection. 383 00:14:29,760 --> 00:14:32,250 This means that nobody on the internet can see the source 384 00:14:32,250 --> 00:14:34,950 or destination of the traffic within the organization's 385 00:14:34,950 --> 00:14:37,893 internal networks on either side of this VPN connection.