All right. So regarding this access for clients up to anywhere at vmware.com,
if they're using HTTPS,
the rule that's been applied is intended to go ahead and stop that traffic.
Why is it still working? So as far as like what could be wrong,
let's take a moment and just think about that together.
Number one, a rule could be disabled.
Or in that rule, we could have the source or destination incorrect,
so I'll say source or destination.
So whether it's based on IP address or group,
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
we'd want to make sure that we're including the right traffic flows
based on source and destination.
As far as the services at layer four,
if we are not pointing to the correct layer for protocols and ports,
that could be causing it not to be matched.
Or if our context profile is incorrect for some reason,
for example, maybe in the context profile,
it's looking for HTTP traffic instead of HTTPS.
Or if the attribute for the fully qualified domain is not correct,
that could also cause a problem causing it not to match.
Or if the action in the rule is set to permit,
that's certainly not going to deny the traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that's certainly not going to deny the traffic.
Or if we don't have the prerequisite in place with the layer seven DNS rule,
that would also cause it not to function.
Now, considering all that, one of the other things we'd want to do is to verify
firsthand
and see whether or not we have a client that actually can
get out to VMware.com using HTTPS.
So let's go to a VM over here on segment 10.
Currently, I have Mint 1 that is up and ready.
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
And let's just verify whether or not Mint 1 can indeed get to VMware.com using
HTTPS.
So let's bring in our client in and let's test it.
So let's go ahead and let's bring up a command prompt.
And let's use curl and verify whether or not we can get there.
So we'll type in curl.
We'll do an I for include header and we'll go to HTTP s colon slash
www.vmware.com.
And sure enough, we are connecting out there.
So we could also go to a browser and verify that works as well.
So we'll open up our browser.
Let's go up to VMware.com and that indeed is working.
It redirected us over to HTTPS. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It redirected us over to HTTPS.
Let me also add that as a bookmark for easy access next time.
So we'll call that bookmark VMware, click on save and click on refresh.
And sure enough, we are going out there.
All right.
So I close the browser and minimize the client.
And also we just took care of question number three.
How would we verify once we fix the problem that they can no longer get out
there?
And two different ways of doing that would be at the CLI with curl
or using a browser to connect to VMware.
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
So the same way we would verify the symptom that is working would also be the
same way
that we would verify after we correct the problem that we have corrected the
problem.
So if the customer really doesn't want anyone to go to VMware.com using HTTPS,
currently we verified that they are.
Let's take a look at the configuration, which also are included as part of the
screenshots
to confirm what the problem is.
So here in the NSX manager, let's go to the security tab up here.
And on the left, we'll go down to distributed firewall.
And here are our rules.
So I'm going to collapse the left hand side.
And let me rearrange these column sizes as well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let me rearrange these column sizes as well.
So here is a policy called FQD and filtering.
And it's here in the applications category.
Let's expand that policy and take a look.
So we have two rules.
Here we have a DNS layer seven inspection,
which is a prerequisite for doing the FQD and filtering.
And let's just verify that that is in place.
Source any destination any for the services is looking just for DNS- UDP,
which is UDP going to port 53.
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
Now, it could be that if the customer is using some other flavor of DNS,
maybe they're using DNS over TLS or DNS over HTTPS.
If they're using those, that would be one reason that this isn't going to match
.
And as a result, that could cause the other rule that's filtering the fully
qualified domain name
to fail.
But in my lab environment, that's exactly what I'm using at layer four.
And then for the context profile, that also looks good.
That says DNS, which is effectively looking at the application layer.
And that's applied to the distributed firewall.
And the action is allowed.
So that rule right there, rule ID 5098, that looks good.
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
So in the event the customer didn't have that prerequisite rule right there,
that would also cause this FQD and inspection rule to not work.
So it looks like that rule is in place.
So let's go down to the rule that's supposed to block HTTPS to VMware.
So that's rule ID 6120 for the source.
It's pointing to 10, zero, zero with an 8-bit mask.
So 10, anything.
So if we look at our topology, that should cover 10, 10 and 10, 20.
If this is their topology, the source IP address for that rule would be okay.
And as we continue on, the destination says any, the service is HTTPS, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And as we continue on, the destination says any, the service is HTTPS,
which basically means TCP going to 443.
So that's the layer four information.
And then for the application layer and the context profile,
we have this context profile right here.
So let's go ahead and click on the pencil icon and take a closer look.
So for the context profile associated with this rule,
let's see which one of these context profiles is applied.
So we'll click on the slider to just show us only the ones that are selected.
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
So this is the one that's currently associated with that rule, VMware, domain,
and HTTPS.
So that's the name of the context profile.
And as far as what's in it, let's click right here to look at its attributes.
So it's matching on the app ID of HTTPS and also the FQDN name of
astro.mvware.
And there is the typo right there that's causing the problem.
So effectively, this would block a client from trying to access mvware.com via
HTTPS.
But as far as VMware.com, it's not going to fly. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But as far as VMware.com, it's not going to fly.
So that's because of the typo there.
So let's go ahead and click on close and let's edit this context profile.
So we'll click on the three dots for the context profile.
We'll click on edit.
Then under attributes, we have two.
We'll click on those two and then we want to modify this one right here.
So for the domain name, we'll click on the three dots, click on edit.
And I don't want mvware.com.
Instead, I want VMware.com and that exists.
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
So if that didn't exist, we just click on the three dots, click on add FQDN.
And then once we've edited in, we can select it.
And now with the spelling correct, let's go ahead and click on add.
And that changes the attribute within this profile.
Then we'll click on apply and then click on save and then click on apply.
So as far as testing to see whether or not that was the problem, let's test.
Let's bring back our client.
And a moment ago, when we did a curl to VMware.com, it worked no problem.
If we hit the up arrow key and do it again.
So now we have a reset.
That's a very good sign.
Let's also bring up a browser. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's also bring up a browser.
And with our browser open, I'm going to go to the bookmark for VMware.
And that is giving us an error.
So on some browsers, if you go to a URL and it's cached, it may still show up.
So at that point, using the CLI, we help you avoid any local cache.
Or if you want to go ahead and just clear the cache in your browser,
or sometimes closing the browser and bring it all the way back up,
that'll do it as well.
But currently here, if we click on try again and try again,
we are now being blocked.
So we should be able to get to anywhere else.
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
So open up a new tab and let's go to fast.com as a speed test.
So the speed test at fast.com is working no problem.
However, trying to connect out to VMware.com is causing us a problem.
And that's because it's matching on this rule right here.
So the hit counts here are going to be aggregated over 15 minutes.
So if we click on the icon here for stats, since the last test I just did,
I waited about 10 to 15 minutes because only after 15 minutes is going to give
us the information.
So based on the last time it did the aggregation over the last 15 minutes,
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
we have a hit count of 10 matches on that rule with a byte count of 18,000
bytes
and change and a packet count of 38.
So we'll go ahead and close that.
And just for grands, if we tried yet another website, let's go ahead
and I've got a bookmark here for Cisco.
That was working no problem.
That's because any of the rules previously I had removed.
And the only rule that we have denying traffic now is this one right here,
denying HTTPS to VMware.
And again, the two ways we could use to verify that from the client perspective
is we could go ahead and use curl at the CLI or we could open up a browser
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
and either way can allow us to verify that our rule is acting as intended.
In this case, blocking HTTPS traffic going to VMware.com.
And actually, one other thing we should just check real quick before we leave
here is
what if we went to a command prompt and we tried to ping, for example, VMware.
com.
So we'll do a ping to www.vmware.com and that confirms that both DNS is working
as well as ICMP.
And because it's not HTTPS, but instead now we're using ICMP,
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
that's why this traffic flow is being allowed because there's no explicit rule
in our distributed firewall policy that is denying it.
So thanks for joining me in this skill as we've upped our game with the
distributed firewall
by now adding to it the option of using a context profile, primarily focused on
what's
really going on at the application layer inside of our client's packets.
So thanks again for joining me and I'll see you soon in another skill.
Until then, I hope this has been informative and I'd like to thank you for
viewing.