So regarding this scenario,
we probably want to ask a few additional questions to the customer just to make
sure we're on the same sheet of music.
For example, when they talk about clients, we want to make sure we're clear on
who those clients are and what those devices are.
And while we're at it, it wouldn't be a bad idea to clearly identify where the
web servers are and where the database servers are,
and if they intend on growing them.
For example, if in the future they add two more web servers and five more
database servers,
we want to make sure we have a scalable solution where we can just add those
additional servers or they could add the new servers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
additional servers or they could add the new servers.
And as a result, still have the security they want.
Another question we'd want to confirm with them is regarding the connectivity
between the application web servers here and the database servers.
It says here we want to permit TCP 5432 being used by the database service
function.
However, we also may want to confirm if they want to restrict all other traffic
.
So maybe that's the only traffic they want and if they want to deny all other
traffic, we'd also want to make sure we incorporate that as well.
Because remember, at the end of a distributed firewall policy, the rule is by WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Because remember, at the end of a distributed firewall policy, the rule is by
default to allow anything that hasn't been matched earlier in the policies.
So for this one right here, for web server access to database servers, if we
did nothing except take the defaults, that would allow that traffic to go
through.
So let's also presume the customers told us they want to allow this traffic and
nothing else between the web servers and the backend database servers.
So they only want to allow TCP port 5432.
So we're getting tags and groups. Let's start off with tags first.
If we want to identify all the client VMs, we probably want to create a tag WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we want to identify all the client VMs, we probably want to create a tag
called clients.
And I'm going to put clients tag just so we can see that.
And then we can dynamically make a group based on that tag and we can call that
group clients group.
And that way in the future, if we create new VMs, they're gonna be clients when
we create those VMs, we simply associate them with this tag and that will
automatically put them into this dynamic group called clients group.
And for the servers, we have two types. So I'd probably create a web server tag
.
We'll call it web tag for short and also one for database servers, we'll call
it DB tag.
And then create those respective groups as well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then create those respective groups as well.
So over here, we can create a web group and a database group.
And again, the benefit of using the tags and having dynamic membership in these
groups is that if we create, for example, two or three more database servers
or 100 more web servers, if we associate them with a respective tag when they
're created,
then those VMs will automatically be in these groups.
So the distributed firewall rules will apply to those new devices that we've
added to the network.
So then for our distributed firewall and its policies and rules for the clients
to web servers using HTTPS only, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to web servers using HTTPS only,
we can say for the source, if it's the clients group, and it's going to the
destination of the web server group.
And if the service is TCP port 443, which is the well known port for HTTPS,
then we want to go ahead and we want to allow that traffic.
And then for the second entry here, we create a rule that says it's a source is
the group called clients.
And the destination is the group called DB group.
Regardless of service, we could go ahead and we could go ahead and do a drop.
So drop or reject would both be fine.
And that way, as the distributed firewall rules are being processed, they go WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that way, as the distributed firewall rules are being processed, they go
through category by category by category.
And then in each category, their process top down.
So as long as we have a rule in here that says for traffic from clients going
to our database group to drop it,
as long as that appears in our rules before the end, which by default is
permitting all the traffic that would cause that traffic to be denied.
And then for this entry right here for web server traffic, we say if the source
is the group for web servers and the destination is the group for the database
servers.
And the TCP port is 5 4 3 2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the TCP port is 5 4 3 2.
Now, if there's already an object inside of the NSX manager that represents TCP
port 5 4 3 2, we could just use it.
Or if that doesn't exist, we can simply create that on our own and then use it
as part of our rule here.
And if that traffic matches, we want to go ahead and allow it.
And then furthermore, if the customer said we don't want any other traffic
besides this to be permitted between web servers and database servers,
we create yet another rule that says if traffic is from web server group going
to the database server group. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to the database server group.
Regardless of protocol or service, we want to go ahead and drop it.
That would cover everything else that's not TCP port 5 4 3 2 going from our web
servers and those application servers to the back end database servers.
And then to test these and validate these, we could use trace flow to validate
the flows of traffic we expect to be allowed are allowed.
And then also validate that the traffic flows that we expect to be dropped are
dropped.
Also, as a heads up, sometimes there is protocols and ports that are needed for
an application to function that the customer has failed to communicate to us or WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
an application to function that the customer has failed to communicate to us or
that we failed to realize we're also needed.
So another really good step to take would be to test a test environment with
test application servers and test database servers to verify with our security
policy rules in place as part of the distributed firewall to verify that the
application does work.
Because if this needs TCP port 5 4 3 2 between the web server and the back end
database server, but it also needs some other protocol or port to be allowed
and we're not allowing it that would cause the application as a whole not to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we're not allowing it that would cause the application as a whole not to
function as expected.
So again, configure, test, verify and then go through change control and deploy
.
So thanks for joining me in this set of videos and the skill regarding the
distributed firewall in an NSX environment.
And I'll see 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.