So if you had a moment to consider the scenario and identify based on the
screenshots, what you think the problem is, let's compare notes.
One of the first things I would do, first of all, if the customer came to me
and said, "You know what? We have this rule in place and we shouldn't be able
to access HTTP services."
What I'd want to do is verify that that's actually true. I'd want to, you know,
give them the benefit of the doubt and I'd like to see an action.
So the first thing we may want to do is go down to a VM, for example, VM here
on segment 20.
So I currently have a computer here. This is Mint 20 sitting here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I currently have a computer here. This is Mint 20 sitting here.
And I want to verify whether or not I can actually access HTTP services from a
device over here on 1010.
And as of what happened, I had this little web VM here. This is web 10. And its
IP address is NNN.181 on this network segment 1010.0.
So I'd want to verify that that is true, that even with the rules in place that
the clients can get access to see it for myself.
Then we can take a look at what might be incorrectly configured and based on
the screenshots, confirm that together.
So let's go down to this VM right here. This is Mint 20. And let's verify WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's go down to this VM right here. This is Mint 20. And let's verify
whether or not we can access web 10 over here at the IP address of 1010.0181.
So here is Mint 20. That's why I confirm it's on the right subnet. So we can do
an IP address, press enter.
And sure enough, it is at 10.20.0.153. Let's also do a quick ping to test to 10
.10.0.181.
That should be the IP address of our little server over on 10. And let's open
up a browser. We can also do, you know, curl right here with the C URL space WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
up a browser. We can also do, you know, curl right here with the C URL space
dash I and then go to HTTP colon slash slash and 10.10.0.181.
And sure enough, that looks like it is working. So there's the content for the
index study, HTML that the little web servers using and just to confirm that
HTTP is working, even though it shouldn't be.
Let's open up a browser and go to 10.10.0.181. And sure enough, that seems to
be working. So as far as what could the problem be?
Let's make a little list. Number one, maybe we have a rule that's applied to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's make a little list. Number one, maybe we have a rule that's applied to
the gateway here. It should be on gateway B, but maybe it's disabled.
Maybe we have a disabled rule as part of our gateway firewall policy here on
gateway B. Another problem could be that if there's multiple gateways involved,
maybe the rule is applied to the incorrect gateway.
So in this scenario here, if they applied the rule, it said deny HTTP traffic
from 10.20 going to 10.10. If they applied it here or here, it would also block
the traffic because those are in line.
However, if we had another gateway over here, let's call it gateway C, and we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
However, if we had another gateway over here, let's call it gateway C, and we
play that rule here, and that gateway is not in line with the traffic from 10.
20 going over to 10.10.
That would also cause that rule not to be hit. So what else could be the
problem? Another problem could be that on gateway B, if it's deployed as a
distributed router only, and it doesn't have a services component with it,
meaning it's not using the edge nodes.
That would also preclude gateway B if it's not using the edge nodes to prevent
it from being able to enforce any gateway firewall policies. So even though we
can configure them all day and all night, unless we have gateway B associated WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
can configure them all day and all night, unless we have gateway B associated
with an edge cluster, those rules won't be enforced.
So here I'm going to jot down no edges, meaning that this router gateway B is
not associated with the end of our edge nodes, because that would cause a
gateway firewall rule to not be enforced if this gateway wasn't associated with
an edge node.
So in the skill before this walkthrough that we're doing together right now, I
posted a few screenshots regarding some of the configuration here instead of NS
X, let's actually go to the live interface.
And let's just take a peek at the configuration to verify together what we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's just take a peek at the configuration to verify together what we
think is wrong that is currently allowing HTTP traffic from 10.20.0 over to 10.
10.0.
So here in the NSX manager, let's click on security on the left under policy
management will click on gateway firewall. And then because we're focused here
on gateway B, let's use the drop down and take a look at the policies and rules
associated with gateway B.
So currently we have some custom rules here that's fantastic because if we had
placed, for example, the correct policies and rules on a gateway, but not the
right gateway.
Again, that could cause it not to be enforced. So here we have a custom policy WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Again, that could cause it not to be enforced. So here we have a custom policy
called no HTTP policy, and it's associated with this local gateway gateway B.
That's all good.
And then we have a rule and the rule is called no HTTP rule and the idea is 6
123. And this rule is going to match if it's traffic source from 10.20 anything
going to 10.10 anything.
So that part looks good for the source in this nation. And if the services HTTP
, which is TCP going to port 80, which is the well known port for HTTP services.
There's no profile associated with it. So we're only looking basically at the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
There's no profile associated with it. So we're only looking basically at the
layer four protocol for TCP, which should match no problem.
It's applied to our gateway gateway B and the actions rejected. So why isn't
this matching? So we just tested this for mint 20 a moment ago.
So limbering mint 20 back in and click on refresh. And sure enough, it looks
like it's reloading that no problem. And if we try a ping, we can ping that
device.
And the ping is not a problem because it didn't say anything about blocking
ping traffic, but it did want to block HTTP traffic and that is still WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ping traffic, but it did want to block HTTP traffic and that is still
functioning.
So why in the world is that on this page here for the gateway firewall policy
for gateway B, there is this message here and blue says, please associate an
edge cluster to the selected gateway for the firewall to work.
And ignore policy realization effectively, meaning ignore any custom policies
you have here until this gateway gateway B is associated with an edge transport
node.
So that is very likely the reason that this rule is not working. So to fix that
, let's go back to networking. And on the left hand side, we'll expand that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
, let's go back to networking. And on the left hand side, we'll expand that
column and we'll go to our tier one gateways.
And sure enough, gateway B is not associated with any of our edge notes. So if
we look at A over here for a moment, we'll expand that here is showing us that
gateway A is associated with our edge cluster.
But if we collapse that gateway B, if we expand that is not associated with any
edge notes at all. So to change that, we're going to edit gateway B by clicking
on the three dots from the menu clicking on edit.
And then we'll specify that instead of distributed only, we'll do active WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we'll specify that instead of distributed only, we'll do active
standby. And then we'll select the edge cluster. We want the gateway B to be
associated with. We only have one edge cluster that includes edge one and edge
two.
We'll scroll down and click on save and then click on close editing. So now we
go back to security and on the left under policy management, if we click on
gateway firewall and then furthermore, choose the right gateway, which is
gateway B.
You'll notice we still have the same rule in place. So nothing about this rule
has changed since we looked at it last. However, now because gateway B is
associated with the edge nodes as part of the cluster. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
associated with the edge nodes as part of the cluster.
And because the gateway firewall function requires using edge nodes, if that
was the only problem, that rule should now be enforced. So let's go back to
mint 20.
And I'm going to go ahead and close the browser and then we go to the command
line and let's start off with something that won't be cached and that is using
curl. So earlier, oh, there we go. So the connection is now being refused
because of the reject message.
But if we try to do a ping, that's just still work. And if we go to a browser,
let's open up a browser and we'll connect over to our little web server here at WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
let's open up a browser and we'll connect over to our little web server here at
10 dot 10 dot zero dot 181 by putting in that IP address right there.
And survey says, looks like it's coming up, but you know what I think I think
that's cash. So I'm going to go ahead and hit the refresh button. There we go.
It looks better.
So initially, it was just pulling that up from the local cache on the mint 20
computer. And that's one of the other benefits of testing this from the command
line, because it's not caching anything if you use curl.
It's actually going out to that destination every single time. So even though
HTTP is being blocked, other protocols aren't so we use till it to 10 dot 10 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
HTTP is being blocked, other protocols aren't so we use till it to 10 dot 10
dot 0 dot 181 instead of using the well known port for tell net.
We'll use 22, which can see whether or not that ports open and that is being
allowed across the network. We're not getting a reset from that. But if we
tried port 80, let's go and do that.
We'll put in port 80 press enter and boom, we have the connection refused
because we're trying to connect to the port that is matching here in this rule.
Again, that's traffic from 10 20 anything going to 10 10 anything if the
destination port is TCP port 80.
So I have had a lot of fun in this set of videos regarding the gateway firewall WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I have had a lot of fun in this set of videos regarding the gateway firewall
function inside of NSX. And I look forward to seeing you my friend in another
skill very, very soon until then, I hope this has been informative and I'd like
to thank you for viewing.
reviewing.