So in this video, we're going to implement another gateway firewall, but this
time we're going to do it on the Gateway A, one of our Tier 1 firewalls.
So to implement the actual gateway firewall function on a gateway, that gateway
has to be leveraging the services of our edge transport nodes.
So as a prerequisite step, before we implement the gateway firewall here on
Gateway A, we also need to tell it that we want to use the edge transport nodes
.
So here in the NSX manager, if we went to networking and on the left-hand side,
let's take a peek at our topology by clicking right here on network topology.
And let's double click here on our Tier 1 gateway. This is Gateway A. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's double click here on our Tier 1 gateway. This is Gateway A.
So we'll double click and then we'll show us what's going on behind the scenes
with it.
So here up on top, it's showing us the gateway is connected to, which is being
supported by the two edge nodes.
And currently, if we zoom in a little bit, Edge 1 is active and Edge 2 is
standby.
And we scroll down though, down to the Gateway A, notice that it's not using
Edge 1 or Edge 2 for any services.
And that's because when we deploy these two gateways, these two Tier 1 gateways
, originally,
we deployed them as a distributed gateway only and not using any edge services. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we deployed them as a distributed gateway only and not using any edge services.
So as it currently sits, if we went over to Gateway A, in fact, let's just do
it for a moment.
We went to security on the left-hand side. We went to Gateway firewall.
And then for the gateway, we use the dropdown and choose Gateway A.
It's giving us a warning message saying you can configure policies and rules on
this gateway A,
but because it's not yet associated with any edge nodes, they're not going to
work.
That's the little message right here is indicating.
So to fix that, let's go ahead and associate Gateway A with our edge nodes. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So to fix that, let's go ahead and associate Gateway A with our edge nodes.
And a simple way of doing that is by clicking here on networking, going down to
under connectivity,
clicking on Tier 1 gateways.
So there's our Tier 1 Gateway A. We'll click on the three dots to edit it from
the menu.
We'll click on edit.
And then right here on the HA mode, instead of saying distributed only,
we're going to say, you know what?
We want to use active standby.
And at which point it'll say, hey, which cluster do you want to use?
So by making the Gateway A active standby and then choosing the cluster,
we've just met the requirements of associating the Gateway A with the edge WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we've just met the requirements of associating the Gateway A with the edge
nodes.
Then once we click on save here, so let's do that, we'll click on save and we
'll scroll down,
click on close editing, and then we'll collapse that.
Now notice that Gateway A is HA mode of active standby and Gateway B is still
set up as distributed only.
Also behind the scenes because we just activated active standby for Gateway A,
we now also logically have a services router in NSX for Gateway A and Gateway B
,
which is still only a distributed router, wouldn't have that services router
component.
In fact, let's go to the CLI on one of our edge nodes and take a look at WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In fact, let's go to the CLI on one of our edge nodes and take a look at
Gateway A and Gateway B.
So this is edge 1 if we do a get gateways just like that.
It's going to show us the gateways and also their VRFs and check this out for
Gateway A.
Here is the distributed router function for Gateway A and there is the services
router function for Gateway A
because we associated it with the edge nodes and for Gateway B, there's the
distributed router.
However, there's no services router function for Gateway B because we haven't
associated Gateway B with the edge nodes.
So if we want to do the same treatment there, we could go ahead to Gateway B, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we want to do the same treatment there, we could go ahead to Gateway B,
click on the three dots from the menu, click on edit.
Then instead of saying distributed only, we could say active standby and then
pick our cluster or edge cluster
and then scroll down, click on save and then click on close editing.
So I'll collapse that as well.
So now they're both using active standby, leveraging the resources of our edge
nodes.
So if we went back to the CLI here on edge 1, for example, hit the up arrow key
for get gateways,
now, bada bing, ba-da-boom.
We now also have a services router component for Gateway B.
So now with the edge nodes associated with each of our tier 1 gateways, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now with the edge nodes associated with each of our tier 1 gateways,
we could now, if we wanted to, create Gateway Firewalls on either one of them.
And based on our plan, we want to implement a Gateway firewall right here on
Gateway A.
And as part of our policy that we're going to create on this Gateway A,
we're going to specify that we want one of our rules to say no ICB echo request
if the source is coming from 10 10 and the destination is going to 10 20.
And those are the IP addresses associated with our two segments.
So let's head over to the NSX manager and we'll create our Gateway Firewall
rules and policies WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
rules and policies
right here on Gateway A.
So to do that, let's go to the security tab up here on top and on the left,
we'll click on another policy management Gateway firewall once again.
So we currently have this Gateway policy here on Gateway 0.
And we included two rules in it, one that's permitting HTTP
and one that's denying everything else if it's going to the address of our
little web server.
So if we want to implement customized Gateway firewall rules here on Gateway A,
from the dropdown, we select Gateway A.
So we'll choose Gateway A.
So it only has its defaults in place. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So it only has its defaults in place.
So we'll click on add policy.
We'll call it our Gateway A policy.
And then we'll add a rule to that by clicking on add rule.
And based on what we want to accomplish, we can go ahead and click on the
pencil there
and go to IP addresses, a traffic source from 10.10.0, anything.
So we'll put 10 10.0/24, which means matching on the first 24 bits there.
Click on apply and for the destination, we'll go ahead and click on the pencil
for that column for that rule.
And we'll specify for IP addresses, the 10.20.0.0/24 and click on apply. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we'll specify for IP addresses, the 10.20.0.0/24 and click on apply.
And let's go ahead and call this new rule, no ICMP echo requests.
And then for the service, we want to go ahead and match on ICMP echo requests.
So we're here for these services.
We'll go ahead and click on the pencil and let's go ahead and see what they
currently have for ICMP.
So in the filter, I'm going to go ahead and type in ICMP press center and we
have several.
So we could just block all ICMP traffic, but that would include probably more
than what we want to do for our specific lab task. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
than what we want to do for our specific lab task.
So let's go ahead and choose this right here.
ICMP echo request right there because that's literally what we want to stop.
So with ICMP echo request selected, we'll click on apply.
And now here's this rule is going to say, once we click on publish, if traffic
is sourced from 10, 10, 0, anything and going to 10, 20, 0, anything.
And the actual service is an ICMP echo request, then it's going to go ahead and
permit it.
So I'm going to go ahead and change that because we want to go ahead and drop
that traffic.
So we'll click on drop there because it's not going to match on a TCP flow. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll click on drop there because it's not going to match on a TCP flow.
It doesn't matter if you put reject there because there's no possibility of a
TCP reset if the initial traffic is ICMP.
Also notice right here, it's just reminding us this is applied to our tier one
gateway A and that's because when we started configuring this new policy and
the respective rule, we had selected the gateway A up here.
So before we publish this out, let's just do a quick verification that we can
indeed ping between 10, 10 and 10, 20.
And again, that's going to begin with an ICMP echo request. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And again, that's going to begin with an ICMP echo request.
So in our topology, let me just bring up mint 10 and let's try to ping the
interface here connected to segment 20.
That's going to be 10, 20.0.1 on Gateway B. And before we apply this rule that
denies the echo request, that should work.
No problem.
So let's bring in mint 10 and that is this machine right here.
And let's do a ping to 10.20.0.1.
And that is the logical interface address right here for Gateway B and press WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that is the logical interface address right here for Gateway B and press
enter and that is working.
No problem whatsoever.
However, if we activate this rule by clicking on publish and then try that
again.
Now is that traffic is trying to be sent that ICMP echo request between 10, 10
and 10, 20.
Now with this rule currently active, which is running on our gateway A when it
sees an echo request source from 10, 10, 0, anything going to 10, 20, 0,
anything.
It should go ahead and drop it as that traffic is trying to be routed over
Gateway A.
In fact, let's go ahead and test that.
So let's do a quick test before the ping worked and now we'll go ahead and do a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's do a quick test before the ping worked and now we'll go ahead and do a
ping again and it is failing.
So let that run for a second or two.
We'll do a control C indicates that six packets were sent and zero responded to
.
So we have a hundred percent packet loss again.
That's because of the rule.
So now with this rule in place, we're not able to do an ICMP echo request from
10, 10 over to 10, 20.
However, if we don't want to mint 20, for example, and we try to do a ping
request over to mint 10 because it'd be coming from 10, 20, 0 going to 10, 10,
0, that wouldn't match that rule. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
0, that wouldn't match that rule.
And that traffic flow should be allowed.
So let's head over to mint 20 for a moment and just verify that as well.
So here is mint 20 right here.
This confirm it's IP address with the I have to config or IP address.
Either way, it'll be great.
So it's IP addresses 10 dot 20 dot 0 dot 153 and let's do a ping over to this
interface address right here.
On gateway, which is 10 dot 10 dot 0 dot 1 and press enter that works.
And we could also ping this little web server here, which is at 10 dot 10 dot 0 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we could also ping this little web server here, which is at 10 dot 10 dot 0
dot 181.
So we had the upper key and change that last octet to 181 press enter.
That's working great as well.
And that's working because we did the initial echo request.
There was nothing filtering or denying that traffic.
And then when these devices responded back, which is also going through our
gateway a that response traffic coming back because it wasn't an ICMP echo
request didn't match the rule again.
And was allowed by default.
We could also verify that with trace flow.
So if we go to plan and troubleshoot and click on the left on traffic analysis
and then in the trace flow tile here, click on get started. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then in the trace flow tile here, click on get started.
If we want to confirm the ICMP echo request starting over here at mint 10, for
example, we can select that.
So there's mint 10 on the left.
If we scroll down, there's its IP address for the destination.
Let's go ahead and choose mint 20.
There's its IP address and then we'll scroll down and by default, it's going to
be using ICMP.
And so the initial packet flow is going to look like an echo request.
That's what's going to generate for this trace flow and we'll click on trace.
And here in the bottom part where it says observations, let me scroll up a
little bit there.
If we click on dropped, it'll show us where it was dropped.
So it was dropped by firewall rule ID 6122 and it was dropped by edge to. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So it was dropped by firewall rule ID 6122 and it was dropped by edge to.
So if we go back to security and on the left, if we go down to our gateway
firewall and we look at our gateway firewall on gateway a and we expand the
rules, check it out.
There's our rule denying ICMP echo request and the rule ID is 6122 exactly what
we saw in the results of our trace flow.
Also, if we expand this and look at all the traffic here, let me give us a
little more room.
So here in the traffic flow showing that the traffic started here on ESXIB and
that's because mint 10 is being hosted on ESXIB. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that's because mint 10 is being hosted on ESXIB.
It went through the logical distributed firewall.
There was no rules present in the distributed firewall to stop the traffic.
So that traffic logically crossed over segment 10 and then logically got routed
to our gateway gateway a and notice it didn't get dropped right here.
And that's because ESXIB for that gateway a functionality is using the edge
notes.
So this is where ESXIB said, you know what, I need to forward it to the active
edge node and based on the destination over here, it's centered over to edge to
which has the IP address of 4444 for its tunnel endpoint. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which has the IP address of 4444 for its tunnel endpoint.
So then edge to receives it and as it's largely being forwarded now by edge to
to the gateway firewall, it's matching on the rule rule 6122 and that's so the
traffic is being dropped.
This is also a great time to point out that because it's a gateway firewall
running, for example, this case on gateway a and not a distributed firewall.
That's the reason that host B right off the gate didn't deny the traffic
because host B does not have a copy of that services router that is being
enforced and implemented by the transport nodes, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
enforced and implemented by the transport nodes,
which allows us to have the gateway firewall here on gateway a.
Now, one of the questions might be, well, why did host B send it over to edge
to and not edge one?
And it's very likely because gateway a is currently being supported with the
active role being played here on edge to for gateway a and is being backed up
in a standby role here on edge one.
So we can also verify that by looking at the topology for gateway a to verify
the edge to is the active router for gateway a.
So to do that, we'll go to the networking tab on the left, we'll click on
network topology and then for gateway a, which is right here, we'll zoom in to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
network topology and then for gateway a, which is right here, we'll zoom in to
make it bigger.
So if we hover over two services, we have gateway firewall rules that are
present and we also have DHP services there.
So we double click on gateway a, it'll show us the details for the fabric
behind the scenes.
So here at the bottom is gateway a if we zoom in, there's our tier zero gateway
and sure enough, edge to is the active node and edge one is the standby.
And that's why I host B said the traffic over to edge to so edge to could make
the decision and process the gateway firewall role right here on gateway a and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the decision and process the gateway firewall role right here on gateway a and
it's kind of cool because it looks like they're divvying up the
responsibilities.
So for gateway a edge to is active.
And if we scroll up here and take a look at the gateway zero up here on gateway
zero, it's edge one that's active.
So they're taking different responsibilities based on different gateways and
that was just the default behavior.
I didn't do anything to influence which one would be active in either case.
So let's check our work. We updated our topology verified we had full
connectivity.
Then we set up a gateway firewall on tier zero, permitting only inbound HTTP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Then we set up a gateway firewall on tier zero, permitting only inbound HTTP
traffic going to this web server.
And the next we created right here on gateway a gateway based firewall, which
was denying initial ICMP request source from 10 10 if they're trying to go to
10 20.
Then once we applied that policy and rule here on the gateway a, we then
verified that from the client machines and we also verified it with trace flow.