WEBVTT 1 00:00.000 --> 00:04.190 For our discussion regarding an IPsec site site tunnel that involves an NSX 2 00:04.190 --> 00:04.720 environment, 3 00:04.720 --> 00:08.560 let's imagine we have two sites. So over here on the left we have site A, and 4 00:08.560 --> 00:08.720 that's 5 00:08.720 --> 00:12.480 beyond done, we have site B over here. So on the left with our NSX environment, 6 00:12.480 --> 00:13.680 here is a segment 7 00:13.680 --> 00:17.410 with a VM connected to it. And over here on the right, we're not using NSX, we 8 00:17.410 --> 00:18.080 just have a 9 00:18.080 --> 00:21.760 traditional router, which is connected to a network segment. And then we have a 10 00:21.760 --> 00:22.640 computer over here 11 00:22.640 --> 00:25.730 as well. So perhaps this physical router is routing for a virtualized 12 00:25.730 --> 00:27.360 environment, and that's why 13 00:27.360 --> 00:31.620 there's also a VM over here on this site. In either case, this is a T0 router WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 13 00:27.360 --> 00:31.620 there's also a VM over here on this site. In either case, this is a T0 router 14 00:31.620 --> 00:33.040 over here at site A, 15 00:33.040 --> 00:36.720 and this is a physical router over here at site B. And they both have 16 00:36.720 --> 00:38.480 connectivity to the internet 17 00:38.480 --> 00:42.960 through a service provider. So if we wanted to provide connectivity between 18 00:42.960 --> 00:43.360 this segment, 19 00:43.360 --> 00:47.600 the 10330 network address space that we're using here, and the 1080 address 20 00:47.600 --> 00:48.240 space for using over 21 00:48.240 --> 00:52.220 here, there's a few problems with that. Number one, unless we do NAT, to send 22 00:52.220 --> 00:53.440 that traffic out, 23 00:53.440 --> 00:57.300 the internet's not going to forward it because these are RFC 1918 private 24 00:57.300 --> 00:58.080 address spaces. 25 00:58.080 --> 01:01.510 Or even if we did NAT, we have to do double NAT, where we're doing source now WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 25 00:58.080 --> 01:01.510 Or even if we did NAT, we have to do double NAT, where we're doing source now 26 01:01.510 --> 01:02.560 on this end and 27 01:02.560 --> 01:06.680 destination out over here. Once again, because we have RFC 1918 addresses, let 28 01:06.680 --> 01:07.760 's assume just for 29 01:07.760 --> 01:12.460 discussion that we're doing all the NAT required, we still don't want to just 30 01:12.460 --> 01:13.760 send packets back and 31 01:13.760 --> 01:17.360 forth over the internet if they're not encrypted. Because an eavesdropper who's 32 01:17.360 --> 01:18.080 looking at those 33 01:18.080 --> 01:21.140 packets, if they see that traffic going back and forth, and they can capture 34 01:21.140 --> 01:21.760 that traffic, 35 01:21.760 --> 01:26.280 they also, if it's not encrypted traffic, have access to the plain text context 36 01:26.280 --> 01:27.200 of the payloads. 37 01:27.200 --> 01:31.120 So if we want connectivity between this network segment over here and this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 37 01:27.200 --> 01:31.120 So if we want connectivity between this network segment over here and this 38 01:31.120 --> 01:31.840 network segment over 39 01:31.840 --> 01:35.770 here, and we want to send that data over a public or an untrusted network, and 40 01:35.770 --> 01:36.560 we don't want to do 41 01:36.560 --> 01:41.310 a whole bunch of games with NAT, what we can do is implement an IPsec site to 42 01:41.310 --> 01:42.640 site VPN tunnel. 43 01:42.640 --> 01:46.960 And when talking about IPsec VPN tunnels in general, there's two types. There's 44 01:46.960 --> 01:47.920 the site to site where 45 01:47.920 --> 01:51.870 we're building a tunnel between, for example, site A and site B, and there's 46 01:51.870 --> 01:52.560 also an option for 47 01:52.560 --> 01:56.660 something called a remote access VPN tunnel. And a situation like that would be 48 01:56.660 --> 01:57.040 a user, 49 01:57.040 --> 02:01.220 maybe at their home or a coffee shop, and they're building a VPN tunnel into WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 49 01:57.040 --> 02:01.220 maybe at their home or a coffee shop, and they're building a VPN tunnel into 50 02:01.220 --> 02:02.080 headquarters. Maybe 51 02:02.080 --> 02:06.720 we're here to site A or they're building a VPN from their PC over here to site 52 02:06.720 --> 02:07.440 B. And that's 53 02:07.440 --> 02:12.390 an example of a remote access VPN tunnel. And now that we've mentioned that 54 02:12.390 --> 02:13.520 that type of tunnel 55 02:13.520 --> 02:17.300 exists, let's go ahead and clear that off, because our focus in this set of 56 02:17.300 --> 02:18.560 videos is going to be a 57 02:18.560 --> 02:22.880 site to site tunnel using an NSX gateway. So logically, the tunnel would look 58 02:22.880 --> 02:23.680 like this. It 59 02:23.680 --> 02:28.150 looks like a tunnel that goes from site A from this gateway here over to this 60 02:28.150 --> 02:29.680 physical router at site 61 02:29.680 --> 02:34.810 B at site A, that's an NSX gateway, who then take the traffic, encrypt it, and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 61 02:29.680 --> 02:34.810 B at site A, that's an NSX gateway, who then take the traffic, encrypt it, and 62 02:34.810 --> 02:35.680 then ship it 63 02:35.680 --> 02:39.320 logically through the tunnel, which the transport network is going through the 64 02:39.320 --> 02:40.400 internet. But because 65 02:40.400 --> 02:43.900 we're encrypting that traffic, anybody who eavesdrops on the traffic and sees 66 02:43.900 --> 02:44.880 it won't be able to make 67 02:44.880 --> 02:48.520 sense of it because they don't have the correct keys to correctly unlock or 68 02:48.520 --> 02:49.520 decrypt the data. 69 02:49.520 --> 02:53.080 And then when that traffic is received here at the other side of the IP, site 70 02:53.080 --> 02:53.920 site tunnel, 71 02:53.920 --> 02:57.600 this device would decrypt that traffic, and then forward it, assuming it was 72 02:57.600 --> 02:58.080 going to this 73 02:58.080 --> 03:00.720 destination right here. And then for the response, the similar thing would WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 73 02:58.080 --> 03:00.720 destination right here. And then for the response, the similar thing would 74 03:00.720 --> 03:01.120 happen, 75 03:01.120 --> 03:05.030 the traffic would go from this VM here up to this gateway, who would then 76 03:05.030 --> 03:06.000 encrypt it, ship it 77 03:06.000 --> 03:09.780 over to the IPsec tunnel, once again, using the internet as a transport network 78 03:09.780 --> 03:10.400 , and then the 79 03:10.400 --> 03:13.930 receiving side would decrypt it and then forward it down to the client. And 80 03:13.930 --> 03:14.960 there's a couple different 81 03:14.960 --> 03:19.560 flavors and varieties of IPsec that we could use. We could use one flavor 82 03:19.560 --> 03:21.360 called Ike, and Ike is an 83 03:21.360 --> 03:26.280 acronym for internet key exchange, version one, or we could use Ike version two 84 03:26.280 --> 03:27.120 . And whether we're 85 03:27.120 --> 03:30.710 using Ike version one or Ike version two for the implementation of our IPsec WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 85 03:27.120 --> 03:30.710 using Ike version one or Ike version two for the implementation of our IPsec 86 03:30.710 --> 03:31.680 site, site tunnel, 87 03:31.680 --> 03:36.270 there's actually more than just one tunnel, regardless of which one of these 88 03:36.270 --> 03:37.440 options we use. 89 03:37.440 --> 03:40.560 At the end of the day, when we set up an IPsec tunnel, whether we're using Ike 90 03:40.560 --> 03:41.280 version one or 91 03:41.280 --> 03:45.290 Ike version two, we're going to have a tunnel that's used to carry the actual 92 03:45.290 --> 03:46.480 data. So for example, 93 03:46.480 --> 03:50.050 a device over here, I'll call this device left, this VM here. If they're saying 94 03:50.050 --> 03:50.800 traffic over to 95 03:50.800 --> 03:54.270 this device over here at the right, I'll call that device right. That traffic, 96 03:54.270 --> 03:54.720 if we're using 97 03:54.720 --> 03:58.010 IPsec as it goes between the two sites, is going to be encrypted and shipped 98 03:58.010 --> 03:58.960 over what's known as 99 03:58.960 --> 04:04.450 this IPsec tunnel. Now, based on the flavor of Ike that we're using, this could WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 99 03:58.960 --> 04:04.450 this IPsec tunnel. Now, based on the flavor of Ike that we're using, this could 100 04:04.450 --> 04:05.680 be called the child 101 04:05.680 --> 04:11.000 SA, SA is a acronym for security association, or it could be called the Ike 102 04:11.000 --> 04:12.240 phase two tunnel. 103 04:12.240 --> 04:16.000 But in either case, the IPsec actual tunnel itself is the tunnel that's 104 04:16.000 --> 04:17.440 carrying the actual user 105 04:17.440 --> 04:22.400 traffic. However, there is one more tunnel involved in an IPsec session between 106 04:22.400 --> 04:23.120 the gateway over here 107 04:23.120 --> 04:25.950 on the left and the gateway over here on the right. And that is a tunnel I'd 108 04:25.950 --> 04:27.360 like to refer to as the 109 04:27.360 --> 04:31.630 control tunnel. And we can think of the control tunnel as a special purpose WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 109 04:27.360 --> 04:31.630 control tunnel. And we can think of the control tunnel as a special purpose 110 04:31.630 --> 04:32.880 tunnel or path that 111 04:32.880 --> 04:36.900 can be used when this device on the left needs to communicate directly with 112 04:36.900 --> 04:38.320 this device on the right, 113 04:38.320 --> 04:42.320 the two ends of the IPsec tunnel. And based on the flavor of Ike that we're 114 04:42.320 --> 04:43.920 using, this could be called 115 04:43.920 --> 04:48.410 the Ike phase one tunnel, or it could be called the Ike tunnel. But again, 116 04:48.410 --> 04:49.680 regardless of which flavor 117 04:49.680 --> 04:53.380 we're using, we're going to have two tunnels at the end of the day, one for the 118 04:53.380 --> 04:54.400 two endpoints to 119 04:54.400 --> 04:57.850 negotiate and communicate directly with each other. And the IPsec tunnel being 120 04:57.850 --> 04:59.280 used to carry the actual 121 04:59.280 --> 05:03.120 data traffic from the devices who are sitting traffic back and forth over the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 121 04:59.280 --> 05:03.120 data traffic from the devices who are sitting traffic back and forth over the 122 05:03.120 --> 05:04.000 tunnel. And even 123 05:04.000 --> 05:08.570 though logically that's how the traffic flows, the two tunnels are terminated 124 05:08.570 --> 05:09.440 at the endpoints 125 05:09.440 --> 05:13.780 of the IPsec VPN tunnel. So this Ike phase one or Ike control tunnel would 126 05:13.780 --> 05:15.520 terminate here at the 127 05:15.520 --> 05:19.560 gateway at site A and so would the IPsec tunnel. And over at site B would be 128 05:19.560 --> 05:20.720 this router as the 129 05:20.720 --> 05:24.190 termination point for both these tunnels as well. However, when users send 130 05:24.190 --> 05:24.960 traffic, then these 131 05:24.960 --> 05:28.450 you go through the tunnel, the actual gateways will use the IPsec tunnel for 132 05:28.450 --> 05:29.600 that user traffic. 133 05:29.600 --> 05:32.640 All right, let me clean that up just a little bit. I'd also like to identify WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 133 05:29.600 --> 05:32.640 All right, let me clean that up just a little bit. I'd also like to identify 134 05:32.640 --> 05:33.600 these tunnels with a 135 05:33.600 --> 05:37.900 letter I'll call this control tunnel, the Ike phase one or Ike parent tunnel. 136 05:37.900 --> 05:39.440 Let's call that tunnel A 137 05:39.440 --> 05:43.040 and we'll call the actual IPsec tunnel. We'll call that tunnel B. Now both of 138 05:43.040 --> 05:44.000 these tunnels 139 05:44.000 --> 05:48.760 have to be negotiated and set up between the endpoints. And again, the end 140 05:48.760 --> 05:49.680 points for the IPsec 141 05:49.680 --> 05:53.180 tunnel for a site site tunnel is going to be the gateway here and the router 142 05:53.180 --> 05:53.920 over here. 143 05:53.920 --> 05:57.770 So for the control tunnel, there's a really cool way to help remember many of 144 05:57.770 --> 05:58.560 the details they 145 05:58.560 --> 06:03.010 have to negotiate and agree on if they want to go ahead and form that control WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 145 05:58.560 --> 06:03.010 have to negotiate and agree on if they want to go ahead and form that control 146 06:03.010 --> 06:04.160 tunnel between them. 147 06:04.160 --> 06:07.860 And a great way to think about the details that these two peers on the site 148 06:07.860 --> 06:08.640 site VPN tunnel, 149 06:08.640 --> 06:11.420 when they set up this control tunnel, the great way to remember a lot of the 150 06:11.420 --> 06:12.080 details they have to 151 06:12.080 --> 06:17.100 set up is using this term of haggle, like they have to haggle to agree on these 152 06:17.100 --> 06:18.080 certain parameters. 153 06:18.080 --> 06:21.740 And that's also going to remind us of many of those parameters, including they 154 06:21.740 --> 06:22.720 need to agree 155 06:22.720 --> 06:27.200 on the encryption algorithm that they want to use. So today in modern networks, 156 06:27.200 --> 06:27.520 we're going to be 157 06:27.520 --> 06:31.150 using some flavor of AES, the advanced encryption standard, but they have to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 157 06:27.520 --> 06:31.150 using some flavor of AES, the advanced encryption standard, but they have to 158 06:31.150 --> 06:32.560 agree. If for example, 159 06:32.560 --> 06:36.510 this site over here supports only one flavor of AES and the other side supports 160 06:36.510 --> 06:37.200 only a different 161 06:37.200 --> 06:40.320 flavor. They're never going to agree. And as a result, they won't set up that 162 06:40.320 --> 06:41.040 initial control 163 06:41.040 --> 06:45.290 tunnel. Another element they need to agree on is the authentication that they 164 06:45.290 --> 06:46.240 are who they say 165 06:46.240 --> 06:50.010 they are. And for the authentication, think of it like these two sides of the 166 06:50.010 --> 06:50.720 VPN tunnel, 167 06:50.720 --> 06:54.480 how are they going to prove who they are? Now the two main ways of doing it are 168 06:54.480 --> 06:55.600 a pre shared key. 169 06:55.600 --> 06:59.410 And that's basically where you just plug in a value like a password on this 170 06:59.410 --> 07:00.160 side and you do the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 170 06:59.410 --> 07:00.160 side and you do the 171 07:00.160 --> 07:03.990 same thing on that side and they match it's great. Another option is use 172 07:03.990 --> 07:05.440 digital certificates for 173 07:05.440 --> 07:09.040 the authentication. So they need to agree on how they're going to authenticate. 174 07:09.040 --> 07:09.760 And then secondly, 175 07:09.760 --> 07:13.900 they also need to perform the actual authentication using the method they agree 176 07:13.900 --> 07:14.720 to. Another element 177 07:14.720 --> 07:18.160 they need to agree to is the lifetime. Now when it comes to lifetime, which is 178 07:18.160 --> 07:19.360 done in seconds, 179 07:19.360 --> 07:22.840 that's one of the parameters where if they're not exactly the same on both 180 07:22.840 --> 07:23.840 sides for the actual 181 07:23.840 --> 07:28.080 first initial control tunnel here, they can negotiate down to the one that has 182 07:28.080 --> 07:29.600 the lesser time. So this 183 07:29.600 --> 07:34.020 guy set for like 86,000 seconds and this guy set for 20,000 seconds, they can WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 183 07:29.600 --> 07:34.020 guy set for like 86,000 seconds and this guy set for 20,000 seconds, they can 184 07:34.020 --> 07:35.200 agree on that 20,000 185 07:35.200 --> 07:38.440 seconds and keep moving forward. So at the end of the day, they're going to 186 07:38.440 --> 07:39.520 come to an agreement on 187 07:39.520 --> 07:43.660 what that lifetime is. And then once that lifetime is about to expire, they can 188 07:43.660 --> 07:44.560 go ahead and negotiate 189 07:44.560 --> 07:48.080 a new tunnel and build the tunnel again. Another element that they need to 190 07:48.080 --> 07:48.960 agree on for this 191 07:48.960 --> 07:54.400 initial tunnel is the hashing hashing is a great method of validating data 192 07:54.400 --> 07:56.480 integrity. So on building 193 07:56.480 --> 08:00.400 this tunnel, if one side says, you know what, we can use shop 256 only. And the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 193 07:56.480 --> 08:00.400 this tunnel, if one side says, you know what, we can use shop 256 only. And the 194 08:00.400 --> 08:01.280 other side says, 195 08:01.280 --> 08:05.280 we can do shop 512 only. That's going to be a problem. They need to agree on 196 08:05.280 --> 08:07.440 what hashing algorithm 197 08:07.440 --> 08:11.080 can be supported, because then they're going to start using that for this 198 08:11.080 --> 08:12.320 tunnel to do data 199 08:12.320 --> 08:15.840 integrity on the packets going back and forth. And last but not least, for the 200 08:15.840 --> 08:16.880 encryption algorithm, 201 08:16.880 --> 08:20.400 we need some keying material that can be used to lock and unlock the data 202 08:20.400 --> 08:21.360 respectively. 203 08:21.360 --> 08:25.800 And that keying material is developed through a process called Diffie-Hellman. 204 08:25.800 --> 08:26.560 And so the G 205 08:26.560 --> 08:30.930 here is for a group. And I'll put in parentheses, DH for Diffie-Hellman group. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 205 08:26.560 --> 08:30.930 here is for a group. And I'll put in parentheses, DH for Diffie-Hellman group. 206 08:30.930 --> 08:31.680 And the Diffie-Hellman 207 08:31.680 --> 08:35.690 group is done with numbers. For example, there's group five and group 14, and 208 08:35.690 --> 08:37.040 there's several others, 209 08:37.040 --> 08:40.560 and they need to agree on which Diffie-Hellman group they're going to run. So 210 08:40.560 --> 08:40.960 even though it's 211 08:40.960 --> 08:46.050 a big, longer story, at the end of the day, Diffie-Hellman allows these two 212 08:46.050 --> 08:47.680 devices over a public 213 08:47.680 --> 08:52.900 untrusted network to go ahead and calculate a shared secret key that they can 214 08:52.900 --> 08:53.680 both use for 215 08:53.680 --> 08:56.480 the encryption. And at the same time, anybody who's listening to that 216 08:56.480 --> 08:57.440 conversation back and 217 08:57.440 --> 09:00.950 forth as they're running Diffie-Hellman, they won't come up with that final key WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 217 08:57.440 --> 09:00.950 forth as they're running Diffie-Hellman, they won't come up with that final key 218 09:00.950 --> 09:02.320 . So that key or that 219 09:02.320 --> 09:06.370 keying material to be more specific is to be used with the encryption algorithm 220 09:06.370 --> 09:07.120 . So even though 221 09:07.120 --> 09:11.260 the encryption algorithm is an open standard, AES, for example, because these 222 09:11.260 --> 09:11.840 two peers have 223 09:11.840 --> 09:16.150 negotiated and set up special key materials using that algorithm to lock and 224 09:16.150 --> 09:17.360 unlock the data, 225 09:17.360 --> 09:22.160 anybody on the internet, even if they know we're using AES 128 or AES 256, etc 226 09:22.160 --> 09:22.960 ., because they 227 09:22.960 --> 09:26.260 don't have the keying material that only these two endpoints have, they won't 228 09:26.260 --> 09:27.040 be able to decrypt 229 09:27.040 --> 09:31.000 or unlock the encrypted payload. And as a result, our data can be sent back and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 229 09:27.040 --> 09:31.000 or unlock the encrypted payload. And as a result, our data can be sent back and 230 09:31.000 --> 09:31.360 forth, 231 09:31.360 --> 09:35.850 and it can be kept secure. So all of that, my friend, was the negotiation for 232 09:35.850 --> 09:36.480 the initial 233 09:36.480 --> 09:41.600 control tunnel between these two endpoints of the IPsec tunnel. And if the 234 09:41.600 --> 09:42.800 control tunnel is built 235 09:42.800 --> 09:46.600 and set up the Ike tunnel here, they can then proceed to set up the actual IP 236 09:46.600 --> 09:47.520 sec tunnel as well. 237 09:47.520 --> 09:52.000 So I'll put that as tunnel B here, and I'll put that here in pink. So they also 238 09:52.000 --> 09:52.320 are going to 239 09:52.320 --> 09:56.380 negotiate several parameters for the actual IPsec tunnel itself. They're going 240 09:56.380 --> 09:57.120 to negotiate 241 09:57.120 --> 10:00.560 encryption. For example, what type of encryption do we want to use for this IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 241 09:57.120 --> 10:00.560 encryption. For example, what type of encryption do we want to use for this IP 242 10:00.560 --> 10:02.160 sec tunnel? So up here 243 10:02.160 --> 10:07.360 for the encryption, if we used AES 128, we could use AES 128 here as well, or 244 10:07.360 --> 10:08.160 we could use something 245 10:08.160 --> 10:11.850 different because they don't have to be the exact same algorithms for each of 246 10:11.850 --> 10:12.560 the tunnels, 247 10:12.560 --> 10:16.610 because at the end of the day, they are two separate and distinct tunnels. This 248 10:16.610 --> 10:17.440 is the initial Ike 249 10:17.440 --> 10:22.630 tunnel here in green. And then this is the IPsec tunnel or the child tunnel 250 10:22.630 --> 10:24.160 here in pink. And in Ike 251 10:24.160 --> 10:27.350 version two, which referred to as the child tunnel, because you can think of it 252 10:27.350 --> 10:28.160 like a child that 253 10:28.160 --> 10:32.710 was built or developed using the actual initial tunnel, the Ike tunnel up here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 253 10:28.160 --> 10:32.710 was built or developed using the actual initial tunnel, the Ike tunnel up here. 254 10:32.710 --> 10:33.360 But in either case, 255 10:33.360 --> 10:37.390 it's also still called the IPsec tunnel. So for that IPsec tunnel, we need to 256 10:37.390 --> 10:38.400 negotiate the 257 10:38.400 --> 10:41.860 encryption we're going to use on that IPsec tunnel. We need to agree on the 258 10:41.860 --> 10:43.120 lifetime for that IPsec 259 10:43.120 --> 10:46.470 tunnel. And the reason we have lifetimes for tunnels is because if we'd have to 260 10:46.470 --> 10:47.360 tunnel up for 261 10:47.360 --> 10:51.730 years and years, the same exact tunnel using the same exact keys, there's more 262 10:51.730 --> 10:52.800 of an opportunity 263 10:52.800 --> 10:57.360 for that to be compromised. So by creating a new tunnel, for example, every day 264 10:57.360 --> 10:58.160 up here for the 265 10:58.160 --> 11:02.030 control tunnel, and then maybe every hour here for the IPsec tunnel, as we're WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 265 10:58.160 --> 11:02.030 control tunnel, and then maybe every hour here for the IPsec tunnel, as we're 266 11:02.030 --> 11:02.960 phasing out the old 267 11:02.960 --> 11:06.530 tunnels and bringing in new tunnels. And if we're using new keying material 268 11:06.530 --> 11:07.600 every time we do that, 269 11:07.600 --> 11:11.120 that makes those tunnels more secure. Another element we'd want to negotiate 270 11:11.120 --> 11:11.520 here for the 271 11:11.520 --> 11:15.600 IPsec tunnel is the hashing algorithm that we're going to be using. Oftentimes, 272 11:15.600 --> 11:16.080 that's referred to 273 11:16.080 --> 11:20.230 as an HMac for hash message authentication code, which has the main purpose 274 11:20.230 --> 11:21.040 here to go ahead and 275 11:21.040 --> 11:24.780 new data integrity for each and every packet being sent. There's also an option 276 11:24.780 --> 11:24.960 for the 277 11:24.960 --> 11:30.710 IPsec tunnel to do what's called PFS, which is perfect forward secrecy. And WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 277 11:24.960 --> 11:30.710 IPsec tunnel to do what's called PFS, which is perfect forward secrecy. And 278 11:30.710 --> 11:31.520 when that's used as 279 11:31.520 --> 11:35.860 part of the IPsec tunnel, it's going to go ahead and rerun Diffie Hellman once 280 11:35.860 --> 11:37.040 again and create a 281 11:37.040 --> 11:41.360 separate set of keying material to be used for the actual IPsec tunnel. So 282 11:41.360 --> 11:42.480 using perfect forward 283 11:42.480 --> 11:46.680 secrecy on the IPsec tunnel isn't required, but it is additional and better 284 11:46.680 --> 11:48.160 security than not using 285 11:48.160 --> 11:51.230 it at all. All right. And there's one other concept I want to share with you 286 11:51.230 --> 11:51.840 regarding 287 11:51.840 --> 11:55.810 IPsec site to site tunnels. And that is how they are implemented. One of the 288 11:55.810 --> 11:57.520 options is a policy-based 289 11:57.520 --> 12:01.820 tunnel with a policy-based tunnel. Think of it like rules where this gateway WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 289 11:57.520 --> 12:01.820 tunnel with a policy-based tunnel. Think of it like rules where this gateway 290 12:01.820 --> 12:03.200 receives a packet from 291 12:03.200 --> 12:09.640 1033-0 and it's destined for 1080 and based on that policy in the rules that 292 12:09.640 --> 12:10.480 trains this gateway 293 12:10.480 --> 12:13.420 to go ahead and encrypt it, ship it through the tunnel, where it's received at 294 12:13.420 --> 12:14.160 the other side, 295 12:14.160 --> 12:17.560 who decrypts it and then forwards it down to the destination. And that's policy 296 12:17.560 --> 12:18.320 -based. Now, 297 12:18.320 --> 12:22.480 the other option is route-based. And with route-based, think of it like a 298 12:22.480 --> 12:24.560 logical network that exists 299 12:24.560 --> 12:28.590 between, for example, this gateway here at site A and this router here at site 300 12:28.590 --> 12:29.200 B. And actually, 301 12:29.200 --> 12:34.900 let me redraw that right here, because any traffic that goes over that logical WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 301 12:29.200 --> 12:34.900 let me redraw that right here, because any traffic that goes over that logical 302 12:34.900 --> 12:35.840 network segment, 303 12:35.840 --> 12:40.160 because this route-based will go ahead and automatically be encrypted with IP 304 12:40.160 --> 12:41.040 sec using the 305 12:41.040 --> 12:45.150 IPsec tunnel. And the benefit of route-based is that we can add additional 306 12:45.150 --> 12:46.560 networks and use dynamic 307 12:46.560 --> 12:50.960 routing protocols like BGP to advertise additional routes and reachability 308 12:50.960 --> 12:52.560 through network. And as 309 12:52.560 --> 12:56.470 our dynamic routing changes, any traffic that's being sent over the logical 310 12:56.470 --> 12:57.760 segment between site A 311 12:57.760 --> 13:01.900 and site B will automatically be encrypted with IPsec. Whereas with policy- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 311 12:57.760 --> 13:01.900 and site B will automatically be encrypted with IPsec. Whereas with policy- 312 13:01.900 --> 13:02.800 based, we'd have to 313 13:02.800 --> 13:07.890 specify, okay, traffic from 1033-0 going to 1080, go ahead and encrypt that. 314 13:07.890 --> 13:09.520 And vice versa over here 315 13:09.520 --> 13:13.920 from the site B perspective. Any traffic from 1080, 0 going specifically to 10 316 13:13.920 --> 13:14.720 33-0, 317 13:14.720 --> 13:18.080 go ahead and encrypt that. And then if we added additional networks, we'd have 318 13:18.080 --> 13:18.960 to modify our 319 13:18.960 --> 13:22.800 configuration in our IPsec. Then go ahead and tell it to also include that, 320 13:22.800 --> 13:23.920 again, if we're doing 321 13:23.920 --> 13:28.750 policy-based IPsec tunnels. Now, because there are several options in setting 322 13:28.750 --> 13:29.680 up an IPsec site, 323 13:29.680 --> 13:33.720 site VPN tunnel, to help keep us out of the weeds, let's do this. In the next WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 323 13:29.680 --> 13:33.720 site VPN tunnel, to help keep us out of the weeds, let's do this. In the next 324 13:33.720 --> 13:34.560 video, let's put a 325 13:34.560 --> 13:39.010 specific game plan together on what we intend to do, including which protocols 326 13:39.010 --> 13:40.000 we're going to use 327 13:40.000 --> 13:44.020 for the initial tunnel, as well as the IPsec tunnel. We'll identify the IP 328 13:44.020 --> 13:45.680 addresses between our tier 329 13:45.680 --> 13:49.760 zero gateway and the external router. And then with that game plan in place, we 330 13:49.760 --> 13:50.640 can then proceed 331 13:50.640 --> 13:55.000 to do the implementation and verification step by step of an IPsec tunnel 332 13:55.000 --> 13:56.800 between an NSX gateway, 333 13:56.800 --> 14:00.940 a tier zero gateway in our topology, and an external third-party router. So if WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 333 13:56.800 --> 14:00.940 a tier zero gateway in our topology, and an external third-party router. So if 334 14:00.940 --> 14:01.760 you're ready, 335 14:01.760 --> 14:05.120 I'm ready and I'll see you in the next video for the game plan.