WEBVTT 1 00:00.000 --> 00:06.160 All right. So regarding this access for clients up to anywhere at vmware.com, 2 00:06.160 --> 00:07.760 if they're using HTTPS, 3 00:07.760 --> 00:12.040 the rule that's been applied is intended to go ahead and stop that traffic. 4 00:12.040 --> 00:15.520 Why is it still working? So as far as like what could be wrong, 5 00:15.520 --> 00:17.600 let's take a moment and just think about that together. 6 00:17.600 --> 00:20.520 Number one, a rule could be disabled. 7 00:20.520 --> 00:25.160 Or in that rule, we could have the source or destination incorrect, 8 00:25.160 --> 00:27.200 so I'll say source or destination. 9 00:27.200 --> 00:29.880 So whether it's based on IP address or group, 10 00:29.880 --> 00:32.240 we'd want to make sure that we're including the right traffic flows WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 10 00:29.880 --> 00:32.240 we'd want to make sure that we're including the right traffic flows 11 00:32.240 --> 00:34.000 based on source and destination. 12 00:34.000 --> 00:36.320 As far as the services at layer four, 13 00:36.320 --> 00:39.840 if we are not pointing to the correct layer for protocols and ports, 14 00:39.840 --> 00:41.920 that could be causing it not to be matched. 15 00:41.920 --> 00:45.040 Or if our context profile is incorrect for some reason, 16 00:45.040 --> 00:47.200 for example, maybe in the context profile, 17 00:47.200 --> 00:51.440 it's looking for HTTP traffic instead of HTTPS. 18 00:51.440 --> 00:54.720 Or if the attribute for the fully qualified domain is not correct, 19 00:54.720 --> 00:57.600 that could also cause a problem causing it not to match. 20 00:57.600 --> 00:59.680 Or if the action in the rule is set to permit, 21 00:59.680 --> 01:01.760 that's certainly not going to deny the traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 21 00:59.680 --> 01:01.760 that's certainly not going to deny the traffic. 22 01:01.760 --> 01:05.920 Or if we don't have the prerequisite in place with the layer seven DNS rule, 23 01:05.920 --> 01:08.320 that would also cause it not to function. 24 01:08.320 --> 01:11.710 Now, considering all that, one of the other things we'd want to do is to verify 25 01:11.710 --> 01:12.560 firsthand 26 01:12.560 --> 01:15.920 and see whether or not we have a client that actually can 27 01:15.920 --> 01:19.040 get out to VMware.com using HTTPS. 28 01:19.040 --> 01:21.760 So let's go to a VM over here on segment 10. 29 01:21.760 --> 01:24.960 Currently, I have Mint 1 that is up and ready. 30 01:24.960 --> 01:30.310 And let's just verify whether or not Mint 1 can indeed get to VMware.com using WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 30 01:24.960 --> 01:30.310 And let's just verify whether or not Mint 1 can indeed get to VMware.com using 31 01:30.310 --> 01:31.200 HTTPS. 32 01:31.200 --> 01:33.440 So let's bring in our client in and let's test it. 33 01:33.440 --> 01:36.160 So let's go ahead and let's bring up a command prompt. 34 01:36.160 --> 01:39.200 And let's use curl and verify whether or not we can get there. 35 01:39.200 --> 01:40.480 So we'll type in curl. 36 01:40.480 --> 01:44.720 We'll do an I for include header and we'll go to HTTP s colon slash 37 01:44.720 --> 01:46.560 www.vmware.com. 38 01:46.560 --> 01:49.280 And sure enough, we are connecting out there. 39 01:49.280 --> 01:53.440 So we could also go to a browser and verify that works as well. 40 01:53.440 --> 01:54.960 So we'll open up our browser. 41 01:54.960 --> 01:59.120 Let's go up to VMware.com and that indeed is working. 42 01:59.120 --> 02:01.040 It redirected us over to HTTPS. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 42 01:59.120 --> 02:01.040 It redirected us over to HTTPS. 43 02:01.040 --> 02:04.720 Let me also add that as a bookmark for easy access next time. 44 02:04.720 --> 02:08.800 So we'll call that bookmark VMware, click on save and click on refresh. 45 02:08.800 --> 02:11.040 And sure enough, we are going out there. 46 02:11.040 --> 02:11.360 All right. 47 02:11.360 --> 02:14.000 So I close the browser and minimize the client. 48 02:14.000 --> 02:16.240 And also we just took care of question number three. 49 02:17.120 --> 02:21.280 How would we verify once we fix the problem that they can no longer get out 50 02:21.280 --> 02:21.440 there? 51 02:21.440 --> 02:24.800 And two different ways of doing that would be at the CLI with curl 52 02:24.800 --> 02:26.960 or using a browser to connect to VMware. 53 02:26.960 --> 02:30.400 So the same way we would verify the symptom that is working would also be the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 53 02:26.960 --> 02:30.400 So the same way we would verify the symptom that is working would also be the 54 02:30.400 --> 02:30.800 same way 55 02:30.800 --> 02:33.880 that we would verify after we correct the problem that we have corrected the 56 02:33.880 --> 02:34.240 problem. 57 02:34.240 --> 02:39.520 So if the customer really doesn't want anyone to go to VMware.com using HTTPS, 58 02:39.520 --> 02:41.360 currently we verified that they are. 59 02:41.360 --> 02:44.960 Let's take a look at the configuration, which also are included as part of the 60 02:44.960 --> 02:45.840 screenshots 61 02:45.840 --> 02:47.840 to confirm what the problem is. 62 02:47.840 --> 02:52.320 So here in the NSX manager, let's go to the security tab up here. 63 02:52.320 --> 02:55.440 And on the left, we'll go down to distributed firewall. 64 02:55.440 --> 02:56.800 And here are our rules. 65 02:56.800 --> 02:58.640 So I'm going to collapse the left hand side. 66 02:58.640 --> 03:01.440 And let me rearrange these column sizes as well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 66 02:58.640 --> 03:01.440 And let me rearrange these column sizes as well. 67 03:01.440 --> 03:04.880 So here is a policy called FQD and filtering. 68 03:04.880 --> 03:07.040 And it's here in the applications category. 69 03:07.040 --> 03:09.600 Let's expand that policy and take a look. 70 03:09.600 --> 03:10.960 So we have two rules. 71 03:10.960 --> 03:13.360 Here we have a DNS layer seven inspection, 72 03:13.360 --> 03:16.880 which is a prerequisite for doing the FQD and filtering. 73 03:16.880 --> 03:19.680 And let's just verify that that is in place. 74 03:19.680 --> 03:24.720 Source any destination any for the services is looking just for DNS- UDP, 75 03:24.720 --> 03:26.880 which is UDP going to port 53. 76 03:26.880 --> 03:30.640 Now, it could be that if the customer is using some other flavor of DNS, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 76 03:26.880 --> 03:30.640 Now, it could be that if the customer is using some other flavor of DNS, 77 03:30.640 --> 03:34.640 maybe they're using DNS over TLS or DNS over HTTPS. 78 03:34.640 --> 03:37.280 If they're using those, that would be one reason that this isn't going to match 79 03:37.280 --> 03:37.280 . 80 03:37.280 --> 03:40.640 And as a result, that could cause the other rule that's filtering the fully 81 03:40.640 --> 03:41.600 qualified domain name 82 03:41.600 --> 03:42.160 to fail. 83 03:42.160 --> 03:45.200 But in my lab environment, that's exactly what I'm using at layer four. 84 03:45.200 --> 03:48.000 And then for the context profile, that also looks good. 85 03:48.000 --> 03:51.600 That says DNS, which is effectively looking at the application layer. 86 03:51.600 --> 03:53.840 And that's applied to the distributed firewall. 87 03:53.840 --> 03:55.520 And the action is allowed. 88 03:55.520 --> 03:59.680 So that rule right there, rule ID 5098, that looks good. 89 03:59.680 --> 04:02.480 So in the event the customer didn't have that prerequisite rule right there, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 89 03:59.680 --> 04:02.480 So in the event the customer didn't have that prerequisite rule right there, 90 04:02.480 --> 04:06.240 that would also cause this FQD and inspection rule to not work. 91 04:06.240 --> 04:08.320 So it looks like that rule is in place. 92 04:08.320 --> 04:13.200 So let's go down to the rule that's supposed to block HTTPS to VMware. 93 04:13.200 --> 04:16.480 So that's rule ID 6120 for the source. 94 04:16.480 --> 04:19.840 It's pointing to 10, zero, zero with an 8-bit mask. 95 04:19.840 --> 04:21.200 So 10, anything. 96 04:21.200 --> 04:25.200 So if we look at our topology, that should cover 10, 10 and 10, 20. 97 04:25.200 --> 04:29.680 If this is their topology, the source IP address for that rule would be okay. 98 04:29.680 --> 04:34.080 And as we continue on, the destination says any, the service is HTTPS, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 98 04:29.680 --> 04:34.080 And as we continue on, the destination says any, the service is HTTPS, 99 04:34.080 --> 04:37.040 which basically means TCP going to 443. 100 04:37.040 --> 04:38.800 So that's the layer four information. 101 04:38.800 --> 04:41.520 And then for the application layer and the context profile, 102 04:41.520 --> 04:44.240 we have this context profile right here. 103 04:44.240 --> 04:48.480 So let's go ahead and click on the pencil icon and take a closer look. 104 04:48.480 --> 04:51.440 So for the context profile associated with this rule, 105 04:51.440 --> 04:54.640 let's see which one of these context profiles is applied. 106 04:54.640 --> 04:57.600 So we'll click on the slider to just show us only the ones that are selected. 107 04:57.600 --> 05:01.550 So this is the one that's currently associated with that rule, VMware, domain, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 107 04:57.600 --> 05:01.550 So this is the one that's currently associated with that rule, VMware, domain, 108 05:01.550 --> 05:02.160 and HTTPS. 109 05:02.160 --> 05:04.880 So that's the name of the context profile. 110 05:04.880 --> 05:08.480 And as far as what's in it, let's click right here to look at its attributes. 111 05:08.480 --> 05:13.680 So it's matching on the app ID of HTTPS and also the FQDN name of 112 05:13.680 --> 05:16.720 astro.mvware. 113 05:16.720 --> 05:20.400 And there is the typo right there that's causing the problem. 114 05:20.400 --> 05:26.960 So effectively, this would block a client from trying to access mvware.com via 115 05:26.960 --> 05:27.760 HTTPS. 116 05:27.760 --> 05:30.880 But as far as VMware.com, it's not going to fly. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 116 05:27.760 --> 05:30.880 But as far as VMware.com, it's not going to fly. 117 05:30.880 --> 05:32.320 So that's because of the typo there. 118 05:32.320 --> 05:36.480 So let's go ahead and click on close and let's edit this context profile. 119 05:36.480 --> 05:39.280 So we'll click on the three dots for the context profile. 120 05:39.280 --> 05:40.400 We'll click on edit. 121 05:40.400 --> 05:42.240 Then under attributes, we have two. 122 05:42.240 --> 05:45.600 We'll click on those two and then we want to modify this one right here. 123 05:45.600 --> 05:50.080 So for the domain name, we'll click on the three dots, click on edit. 124 05:50.080 --> 05:52.880 And I don't want mvware.com. 125 05:52.880 --> 05:56.080 Instead, I want VMware.com and that exists. 126 05:56.080 --> 06:01.040 So if that didn't exist, we just click on the three dots, click on add FQDN. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 126 05:56.080 --> 06:01.040 So if that didn't exist, we just click on the three dots, click on add FQDN. 127 06:01.040 --> 06:03.120 And then once we've edited in, we can select it. 128 06:03.120 --> 06:07.120 And now with the spelling correct, let's go ahead and click on add. 129 06:07.120 --> 06:09.680 And that changes the attribute within this profile. 130 06:09.680 --> 06:14.320 Then we'll click on apply and then click on save and then click on apply. 131 06:14.320 --> 06:18.080 So as far as testing to see whether or not that was the problem, let's test. 132 06:18.080 --> 06:19.600 Let's bring back our client. 133 06:19.600 --> 06:24.640 And a moment ago, when we did a curl to VMware.com, it worked no problem. 134 06:24.640 --> 06:26.560 If we hit the up arrow key and do it again. 135 06:26.560 --> 06:27.600 So now we have a reset. 136 06:27.600 --> 06:29.040 That's a very good sign. 137 06:29.040 --> 06:30.560 Let's also bring up a browser. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 137 06:29.040 --> 06:30.560 Let's also bring up a browser. 138 06:30.880 --> 06:34.720 And with our browser open, I'm going to go to the bookmark for VMware. 139 06:34.720 --> 06:36.080 And that is giving us an error. 140 06:36.080 --> 06:39.840 So on some browsers, if you go to a URL and it's cached, it may still show up. 141 06:39.840 --> 06:44.320 So at that point, using the CLI, we help you avoid any local cache. 142 06:44.320 --> 06:47.120 Or if you want to go ahead and just clear the cache in your browser, 143 06:47.120 --> 06:49.760 or sometimes closing the browser and bring it all the way back up, 144 06:49.760 --> 06:50.560 that'll do it as well. 145 06:50.560 --> 06:53.200 But currently here, if we click on try again and try again, 146 06:53.200 --> 06:54.160 we are now being blocked. 147 06:54.160 --> 06:55.760 So we should be able to get to anywhere else. 148 06:55.760 --> 07:00.160 So open up a new tab and let's go to fast.com as a speed test. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 148 06:55.760 --> 07:00.160 So open up a new tab and let's go to fast.com as a speed test. 149 07:00.160 --> 07:03.680 So the speed test at fast.com is working no problem. 150 07:03.680 --> 07:07.600 However, trying to connect out to VMware.com is causing us a problem. 151 07:07.600 --> 07:10.560 And that's because it's matching on this rule right here. 152 07:10.560 --> 07:13.520 So the hit counts here are going to be aggregated over 15 minutes. 153 07:13.520 --> 07:17.840 So if we click on the icon here for stats, since the last test I just did, 154 07:17.840 --> 07:21.840 I waited about 10 to 15 minutes because only after 15 minutes is going to give 155 07:21.840 --> 07:23.040 us the information. 156 07:23.040 --> 07:26.240 So based on the last time it did the aggregation over the last 15 minutes, 157 07:26.240 --> 07:30.720 we have a hit count of 10 matches on that rule with a byte count of 18,000 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 157 07:26.240 --> 07:30.720 we have a hit count of 10 matches on that rule with a byte count of 18,000 158 07:30.720 --> 07:31.040 bytes 159 07:31.040 --> 07:33.360 and change and a packet count of 38. 160 07:33.360 --> 07:34.640 So we'll go ahead and close that. 161 07:34.640 --> 07:38.240 And just for grands, if we tried yet another website, let's go ahead 162 07:38.240 --> 07:40.480 and I've got a bookmark here for Cisco. 163 07:40.480 --> 07:41.600 That was working no problem. 164 07:41.600 --> 07:44.480 That's because any of the rules previously I had removed. 165 07:44.480 --> 07:47.600 And the only rule that we have denying traffic now is this one right here, 166 07:47.600 --> 07:50.000 denying HTTPS to VMware. 167 07:50.000 --> 07:53.280 And again, the two ways we could use to verify that from the client perspective 168 07:53.280 --> 07:57.920 is we could go ahead and use curl at the CLI or we could open up a browser 169 07:57.920 --> 08:01.920 and either way can allow us to verify that our rule is acting as intended. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 169 07:57.920 --> 08:01.920 and either way can allow us to verify that our rule is acting as intended. 170 08:01.920 --> 08:06.160 In this case, blocking HTTPS traffic going to VMware.com. 171 08:06.160 --> 08:08.880 And actually, one other thing we should just check real quick before we leave 172 08:08.880 --> 08:09.520 here is 173 08:09.520 --> 08:14.250 what if we went to a command prompt and we tried to ping, for example, VMware. 174 08:14.250 --> 08:14.480 com. 175 08:14.480 --> 08:20.560 So we'll do a ping to www.vmware.com and that confirms that both DNS is working 176 08:20.560 --> 08:22.160 as well as ICMP. 177 08:22.160 --> 08:26.560 And because it's not HTTPS, but instead now we're using ICMP, 178 08:26.560 --> 08:30.400 that's why this traffic flow is being allowed because there's no explicit rule WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 178 08:26.560 --> 08:30.400 that's why this traffic flow is being allowed because there's no explicit rule 179 08:30.400 --> 08:33.040 in our distributed firewall policy that is denying it. 180 08:33.040 --> 08:36.450 So thanks for joining me in this skill as we've upped our game with the 181 08:36.450 --> 08:37.520 distributed firewall 182 08:37.520 --> 08:42.560 by now adding to it the option of using a context profile, primarily focused on 183 08:42.560 --> 08:42.880 what's 184 08:42.880 --> 08:47.040 really going on at the application layer inside of our client's packets. 185 08:47.040 --> 08:50.480 So thanks again for joining me and I'll see you soon in another skill. 186 08:50.480 --> 08:54.700 Until then, I hope this has been informative and I'd like to thank you for 187 08:54.700 --> 08:55.440 viewing.