In this video, you and I get to chat about a concept called a gateway firewall.
And one of the first things I'd like to do is compare and contrast it to a
distributed firewall.
So the acronym here would be a DFW for the distributed firewall.
And for a gateway firewall, we just call it a gateway firewall like that.
And in previous skills, we've taken a look at using a distributed firewall and
setting up rules
based on the source and destination, whether it's group membership or IP
addresses and the ports
and protocols involved, and that distributed firewall can control east-west
traffic.
We also had it controlled traffic as it was trying to go out to the internet. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We also had it controlled traffic as it was trying to go out to the internet.
We also did some FQDN filtering.
It was all wonderful. And the beautiful thing about a distributed firewall is
that it's distributed,
meaning all of our transport nodes know about it and they can enforce it.
So if this VM here, VM1 is trying to communicate down here to this VM, let's
call it VM2.
Let's imagine that based on our security policy rules for the distributed
firewall,
that we are either based on source and destination group membership or IP
address or the ports and
protocols in use, let's imagine that the action for our security policy rule WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
protocols in use, let's imagine that the action for our security policy rule
for the distributed
firewall was set to reject or drop that traffic. In that case, when this
traffic is trying to be
sent by this client, host A, who's the competing resource right there, because
as a copy that
distributed firewall can go ahead and enforce that policy and stop that traffic
from ever leaving host
A. So again, the distributed firewall is a set of policies and rules that are
distributed across
our transport nodes so that any one of them can enforce the policy.
So the next logical question is, okay, what is the big difference then between
a distributed firewall
that we looked at previously that can be implemented across the board on all WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that we looked at previously that can be implemented across the board on all
our transport nodes and
a gateway firewall? And here's one of the big differences, even though we still
can with a gateway
firewall implement security policies based on group membership for source and
destination or IP
addresses for source and destination. And we can specify exactly in our rules
what protocols and
ports we want to allow or not allow instead of having it hover and existing
everywhere across
all our transport nodes with a gateway based firewall, we're implementing it
specifically on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
one of our gateways. So let go ahead and remove the DFW component here for a
moment. And let's
imagine we're setting up a gateway firewall and we're implementing it right
here on gateway A.
So in this example, if we set up a gateway firewall right here on gateway A,
and let's imagine we have
this VM here, let's say it's VM three, that's trying to communicate with VM
four, as part of our
security policies and the rules in those policies in a gateway firewall, it's
only traffic that's
trying to be routed through this gateway that's going to be compared against
those rules. So we
could have one set of rules right here on gateway A and a different set of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
could have one set of rules right here on gateway A and a different set of
rules here on the tier
zero gateway zero, and get a third set of rules here on gateway B. And the
rules on each of those
respective gateways is only going to be enforced for traffic if it's trying to
be routed over those
respective gateways. So if we need some centralized rules that are going to be
implemented at the
gateways only, we could modify our gateway firewall policy at the rules we want
and add them to the
correct gateway that we want them to be implemented on, and we're good to go.
There's a couple of
caveats that we want to be aware of as we implement a gateway firewall. Number WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
caveats that we want to be aware of as we implement a gateway firewall. Number
one, if we're
implementing the gateway firewall services behind the scenes for that logical
processing for the
gateway firewall, it's going to be sent up to one of our edge notes. So at the
moment in our
environment, this gateway A and this gateway B, they are set up as distributed
router gateways
only at tier one. And so if we want to implement gateway firewalls at gateway A
or gateway B,
we need to go ahead and tell those two tier one gateways that they should be
associated with
our transport node cluster. Because behind the scenes, what's going to happen WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
our transport node cluster. Because behind the scenes, what's going to happen
is if this VM
here VM one is trying to talk to VM number two, and we have a gateway firewall
and gateway A
behind the scenes host A, because a gateway firewall host A is going to send
the traffic from this
VM over to one of our edge nodes. So it can go ahead and actually implement the
services of that
gateway firewall. So if they distributed firewall, ESXIA, having a copy of that
distributed firewall, get implement that security all on its own. However, if
now we're implementing
a gateway firewall, we are going to need an edge device to actually perform
that logical function WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that logical function
for us. Also in the lab environment, when I deploy these two edge nodes, I
actually specified,
I think the medium size for the deployment and some of the features that we can
implement
on our gateways also depend on the size of our deployment. So for example,
there is some limitation
on a few features. If we use the small option and we have additional features
available,
if we deploy it with the large option, and that boils down to how many CPUs and
how much RAM
each of our transport nodes are using.