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