WEBVTT 1 00:00.000 --> 00:04.680 So now that we have these two segments associated with our layer 2 VPN service, 2 00:04.680 --> 00:08.150 we should now have the ability to communicate back and forth between these two 3 00:08.150 --> 00:08.440 VMs. 4 00:08.440 --> 00:12.850 In fact, when I left it, I had this VM here trying to ping this VM and vice 5 00:12.850 --> 00:13.440 versa. 6 00:13.440 --> 00:15.640 So let me bring back those remote console windows. 7 00:15.640 --> 00:17.960 So here is the site 4 VM right here, 8 00:17.960 --> 00:20.280 and those pings are flying now, fantastic. 9 00:20.280 --> 00:23.120 Here is the site 3 VM right here, 10 00:23.120 --> 00:24.760 just a little bit on the left-hand side. 11 00:24.760 --> 00:26.640 If we were to capture this traffic, 12 00:26.640 --> 00:30.380 what we would see is traffic going back and forth between these two endpoint IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 12 00:26.640 --> 00:30.380 what we would see is traffic going back and forth between these two endpoint IP 13 00:30.380 --> 00:31.120 addresses, 14 00:31.120 --> 00:36.960 and the payload would be ESP, which is protocol 50, which is used by IPsec. 15 00:36.960 --> 00:38.840 Implying that that traffic is encrypted, 16 00:38.840 --> 00:44.800 so whether we're doing pings or SSH or Telnet or HTTP traffic back and forth, 17 00:44.800 --> 00:48.560 as it goes over the transport network, all that traffic is encrypted. 18 00:48.560 --> 00:53.320 Also, to verify the path to the network, let's go ahead and do a trace, 19 00:53.320 --> 00:55.800 and we can do this from either site 3 or site 4. 20 00:55.800 --> 01:00.440 Let's do a trace just to verify the path and the logic that's being done on a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 20 00:55.800 --> 01:00.440 Let's do a trace just to verify the path and the logic that's being done on a 21 01:00.440 --> 01:00.960 packet, 22 01:00.960 --> 01:03.720 trying to leave this VM as it's going out to this VM. 23 01:03.720 --> 01:07.480 Now, because I have two separate NSX managers, 24 01:07.480 --> 01:10.120 and I don't have an NSX federation set up or anything else, 25 01:10.120 --> 01:13.290 we're not going to have one NSX manager that's going to show us the whole 26 01:13.290 --> 01:13.680 picture. 27 01:13.680 --> 01:15.960 So for our test here from site 3, 28 01:15.960 --> 01:18.560 let's use the trace little feature in the NSX manager, 29 01:18.560 --> 01:23.040 and let's do a trace from this VM here to the IP address 30 01:23.040 --> 01:26.000 that's currently being used by this VM right here. 31 01:26.000 --> 01:28.000 And that'll each show us this half of the story. 32 01:28.000 --> 01:30.760 So let me go ahead and stop my ping there for a moment, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 32 01:28.000 --> 01:30.760 So let me go ahead and stop my ping there for a moment, 33 01:30.760 --> 01:33.680 and then we confirm the IP address on each side. 34 01:33.680 --> 01:38.880 So at site 4 here, the IP address of this VM is 1099.041. 35 01:38.880 --> 01:42.680 So what we'll do in trace flow here at the NSX manager for site 3 36 01:42.680 --> 01:47.200 is that we'll look at traffic from this VM going to that IP address. 37 01:47.200 --> 01:50.320 So here in light mode in the site 3 NSX manager, 38 01:50.320 --> 01:53.000 we'll go to plan and troubleshoot, and on the left, 39 01:53.000 --> 01:55.240 we'll click on traffic analysis. 40 01:55.240 --> 01:58.960 And then we'll click on the get started here in the tile for trace flow. 41 01:58.960 --> 02:01.760 And then here in trace flow, we'll specify the source machine WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 41 01:58.960 --> 02:01.760 And then here in trace flow, we'll specify the source machine 42 02:01.760 --> 02:04.160 is our site 3 red VM, 43 02:04.160 --> 02:06.760 and just to confirm it's IP address, that looks good. 44 02:06.760 --> 02:09.000 And for the destination, which is in the other site, 45 02:09.000 --> 02:10.600 instead of specifying a virtual machine, 46 02:10.600 --> 02:13.720 we'll specify IP address, specify layer 3 only, 47 02:13.720 --> 02:19.440 and we'll specify the IP address of 10.99.0.41, 48 02:19.440 --> 02:23.720 which is the IP address that the VM over at site 3 is currently using. 49 02:23.720 --> 02:26.200 We'll scroll down and we'll click on trace. 50 02:26.200 --> 02:28.840 And then we'll give it a minute to go ahead and run that. 51 02:28.840 --> 02:30.120 All right, and here are the results. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 51 02:28.840 --> 02:30.120 All right, and here are the results. 52 02:30.120 --> 02:35.600 So ESXi Red 1 must be the host that's hosting our little VM at site 3, 53 02:35.600 --> 02:37.600 because that's the host involved here. 54 02:37.600 --> 02:40.800 So it went through the logic of the distributed firewall rules. 55 02:40.800 --> 02:43.840 It did the logical switching through segment 99. 56 02:43.840 --> 02:46.560 It then did the logical distributed routing decisions 57 02:46.560 --> 02:48.720 through the T0 distributed router. 58 02:48.720 --> 02:50.720 And then it handed it off to an edge node. 59 02:50.720 --> 02:53.160 So this is ESXi Red 1. 60 02:53.160 --> 02:55.600 And so there's the tunnel endpoint addresses. 61 02:55.600 --> 02:57.680 And then edge 2 did some processing with it 62 02:57.680 --> 03:00.440 through that logical segment of site 99, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 62 02:57.680 --> 03:00.440 through that logical segment of site 99, 63 03:00.440 --> 03:03.080 including logical processing through the T0 gateway. 64 03:03.080 --> 03:05.760 And then it went through the process of IPsec, 65 03:05.760 --> 03:08.240 which it encrypted traffic and shipped it off 66 03:08.240 --> 03:09.640 to the next device in the path, 67 03:09.640 --> 03:12.880 which would be an edge node over at site 4. 68 03:12.880 --> 03:16.640 So this is showing us from the site 3 perspective, 69 03:16.640 --> 03:18.200 all the logic that's being done. 70 03:18.200 --> 03:20.360 So with the trace flow being used here at site 3, 71 03:20.360 --> 03:22.520 you could identify that first part of the journey 72 03:22.520 --> 03:26.600 from the host that was hosting that VM to the local edge, 73 03:26.600 --> 03:28.600 which then used an IPsec tunnel to forward it 74 03:28.600 --> 03:29.800 to the next top of the path, 75 03:29.800 --> 03:32.120 which was the active edge node here at site 4, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 75 03:29.800 --> 03:32.120 which was the active edge node here at site 4, 76 03:32.120 --> 03:34.360 who would then decrypt it and then forward it down 77 03:34.360 --> 03:36.880 to the tunnel endpoint to the local host, 78 03:36.880 --> 03:38.920 where the traffic would finally then be delivered. 79 03:38.920 --> 03:41.200 Also, just for fun, as we send traffic back and forth 80 03:41.200 --> 03:42.400 between these two VMs, 81 03:42.400 --> 03:45.560 let's also capture the traffic here on the transport network, 82 03:45.560 --> 03:48.400 just to verify that it's ESP protected traffic, 83 03:48.400 --> 03:51.480 going to and from the 23, 1, 230 address 84 03:51.480 --> 03:53.480 and the 24, 1, 240 address, 85 03:53.480 --> 03:55.120 as the IPsec tunnel is used 86 03:55.120 --> 03:56.960 between the two respective edge nodes. 87 03:56.960 --> 03:58.400 So I'm gonna go ahead on the 2VMs 88 03:58.400 --> 04:00.800 and you start up ping back and forth between them. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 88 03:58.400 --> 04:00.800 and you start up ping back and forth between them. 89 04:00.800 --> 04:02.840 And with that running, I'll go to a distributed switch 90 04:02.840 --> 04:04.480 and ask it to do a capture 91 04:04.480 --> 04:07.000 and send it all right here to our management computer. 92 04:07.000 --> 04:09.560 So here is the vSphere client for site 3, 93 04:09.560 --> 04:12.200 that'll work and let's go to the networking tab. 94 04:12.200 --> 04:14.520 We'll go to the distributed switch that my edges are using, 95 04:14.520 --> 04:16.360 and I currently have port marrying set up. 96 04:16.360 --> 04:18.960 It's disabled at the moment, let me just confirm it's settings. 97 04:18.960 --> 04:21.920 So the source is the two edge nodes, 98 04:21.920 --> 04:24.880 fantastic and the destination is my management computer. 99 04:24.880 --> 04:26.840 So we'll edit that and we'll simply say, 100 04:26.840 --> 04:29.280 please start and okay. 101 04:29.280 --> 04:30.480 So now it's capturing that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 101 04:29.280 --> 04:30.480 So now it's capturing that 102 04:30.480 --> 04:32.560 and shipping it over to my management computer. 103 04:32.560 --> 04:34.720 All right, and here we go. 104 04:34.720 --> 04:37.000 So there's a whole bunch of traffic going on. 105 04:37.000 --> 04:39.080 And let's just filter it down with a display filter 106 04:39.080 --> 04:41.280 and say we only wanna see ESP traffic 107 04:41.280 --> 04:44.600 and this represents the ESP traffic currently happening. 108 04:44.600 --> 04:46.600 So if we brought back our clients real quick, 109 04:46.600 --> 04:48.440 it's just to confirm that the ESP traffic 110 04:48.440 --> 04:50.120 is being caused by these clients. 111 04:50.120 --> 04:53.520 Let me go ahead and let me go ahead and stop that for a moment. 112 04:53.520 --> 04:56.000 We'll do a control C at the VM at site 3 113 04:56.000 --> 04:58.440 and a control C, the VM at site 4. 114 04:58.440 --> 05:00.680 You'll notice that the packets have stopped. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 114 04:58.440 --> 05:00.680 You'll notice that the packets have stopped. 115 05:00.680 --> 05:04.120 So if we send traffic back and forth between these two VMs, 116 05:04.120 --> 05:06.280 that traffic is being encrypted and encapsulated 117 05:06.280 --> 05:08.600 by the edge nodes at those respective sites 118 05:08.600 --> 05:10.840 before it's being sent to the peer at the other side. 119 05:10.840 --> 05:12.640 So here in the output, everything up to 120 05:12.640 --> 05:14.680 and including the GRE encapsulation, 121 05:14.680 --> 05:15.880 is just the distributed switch 122 05:15.880 --> 05:18.000 sending it over to my management computer. 123 05:18.000 --> 05:19.080 And then being carried in that 124 05:19.080 --> 05:21.560 is the actual traffic that it got off the wire. 125 05:21.560 --> 05:23.040 There's the IPv4 header. 126 05:23.040 --> 05:24.720 And if we take a look at the details of that 127 05:24.720 --> 05:26.120 and I scooch up a little bit here. 128 05:26.120 --> 05:28.280 In the layer three header, we have the IP addresses 129 05:28.280 --> 05:30.920 for the respective edge nodes that they're using WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 129 05:28.280 --> 05:30.920 for the respective edge nodes that they're using 130 05:30.920 --> 05:34.780 as part of the TR0 gateway at site 4 and 3 respectively. 131 05:34.780 --> 05:37.120 As far as the payload goes, it's protocol 50 132 05:37.120 --> 05:38.360 and then we have the ESP. 133 05:38.360 --> 05:41.520 So behind the scenes, this could be almost anything. 134 05:41.520 --> 05:44.680 It could be HTTPS traffic, SSH traffic, 135 05:44.680 --> 05:46.480 ping traffic, ICB traffic. 136 05:46.480 --> 05:48.200 As that traffic goes over the transport network 137 05:48.200 --> 05:50.880 and is protected by ESP, we really don't know 138 05:50.880 --> 05:53.840 what's in there or what the original IP addresses are 139 05:53.840 --> 05:56.000 because it's all encrypted and protected. 140 05:56.000 --> 05:57.480 Now, because I was capturing data 141 05:57.480 --> 05:59.200 off of the transport network, 142 05:59.200 --> 06:02.160 I'm also capturing traffic as it goes between WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 142 05:59.200 --> 06:02.160 I'm also capturing traffic as it goes between 143 06:02.160 --> 06:06.160 the host tunnel endpoints and the edge tunnel endpoints 144 06:06.160 --> 06:07.240 at site 3. 145 06:07.240 --> 06:09.800 So if we changed our display filter, for example, 146 06:09.800 --> 06:13.760 and said, I want to see ICMP traffic and press Enter, 147 06:13.760 --> 06:14.880 once getting up to this point, 148 06:14.880 --> 06:17.120 it's just the distributed switch saying the traffic 149 06:17.120 --> 06:18.800 over to my management computer. 150 06:18.800 --> 06:21.680 And then the next header here is the IP addresses 151 06:21.680 --> 06:24.720 for my host and edge nodes at site 3. 152 06:24.720 --> 06:26.320 With the layer 4 protocol of UDP, 153 06:26.320 --> 06:29.080 with the well-known port for Geniv, 154 06:29.080 --> 06:31.120 then we have the Geniv information. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 154 06:29.080 --> 06:31.120 then we have the Geniv information. 155 06:31.120 --> 06:34.120 And then within that, we have the original data packets 156 06:34.120 --> 06:34.960 who are being sent. 157 06:34.960 --> 06:38.560 So this case, it's an ICMP message from 1099-041, 158 06:38.560 --> 06:42.200 which is our site for to the virtual machine address 159 06:42.200 --> 06:43.240 at site 3. 160 06:43.240 --> 06:45.520 And if we open up the details for ICMP, 161 06:45.520 --> 06:47.040 it's showing us exactly what this is. 162 06:47.040 --> 06:49.680 So this is a reply to an ICMP ping request. 163 06:49.680 --> 06:52.080 And the reason we can see all of this here unencrypted 164 06:52.080 --> 06:55.320 is because the traffic that's in your traffic being sent. 165 06:55.320 --> 06:58.360 From an edge node at site 3, over to a host at site 3, 166 06:58.360 --> 07:00.200 that traffic isn't encrypted. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 166 06:58.360 --> 07:00.200 that traffic isn't encrypted. 167 07:00.200 --> 07:02.720 However, the traffic that's going between the two sites, 168 07:02.720 --> 07:06.360 from the edge nodes at site 3 and the edge nodes at site 4, 169 07:06.360 --> 07:08.160 that traffic is being encrypted. 170 07:08.160 --> 07:09.840 So once again, if we put a display filter 171 07:09.840 --> 07:12.040 for looking just for ESP traffic, 172 07:12.040 --> 07:14.360 it's going to show us just that encapsulated traffic. 173 07:14.360 --> 07:16.880 And this would be the traffic going between the two sites. 174 07:16.880 --> 07:18.560 And earlier at the active edge node, 175 07:18.560 --> 07:21.600 which was edge 2 at site 4, we use this command. 176 07:21.600 --> 07:23.160 I've timed out due to inactivity. 177 07:23.160 --> 07:26.160 So let me go ahead and reestablish that connection. 178 07:26.160 --> 07:27.960 And let me also go ahead and start generating 179 07:27.960 --> 07:30.240 some additional traffic from the two VMs, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 179 07:27.960 --> 07:30.240 some additional traffic from the two VMs, 180 07:30.240 --> 07:32.160 one at site 3 and one at site 4. 181 07:32.160 --> 07:34.400 And let's go ahead and run that command again. 182 07:34.400 --> 07:37.400 And in the output here, the number of received and sent packets 183 07:37.400 --> 07:39.760 regarding the LTVPN should be increasing. 184 07:39.760 --> 07:41.080 And because the pings are still running, 185 07:41.080 --> 07:43.040 if I hit the upper key and press enter, 186 07:43.040 --> 07:45.320 those numbers should continue to increase. 187 07:45.320 --> 07:47.160 So in conjunction with the LTVPN, 188 07:47.160 --> 07:49.200 we also have our IPsec VPN. 189 07:49.200 --> 07:51.880 So we do a get IPsec VPN. 190 07:51.880 --> 07:53.200 And if we want to take a look at the details 191 07:53.200 --> 07:55.240 for the actual IPsec tunnel itself, 192 07:55.240 --> 07:57.080 we can tack on IPsecSA, 193 07:57.080 --> 08:00.440 which is short for security association and press enter. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 193 07:57.080 --> 08:00.440 which is short for security association and press enter. 194 08:00.440 --> 08:02.240 So there's the command we just issued. 195 08:02.240 --> 08:05.000 Here are the tunnel endpoints between site 4 and site 3. 196 08:05.000 --> 08:06.720 And here's the encryption, hashing 197 08:06.720 --> 08:09.080 and Diffie-Hellman group reusing and combination 198 08:09.080 --> 08:10.480 with our IPsec tunnel.