In this video, you and I get to put a specific game plan together for our
implementation and verification of the distributed firewall functions inside of
NSX.
So here's what I propose we do. The first step should probably be to go ahead
and implement the VMs we're going to use for our testing.
And so for those VMs, we'll create one called VM web, one called VM even a one
called VM dash DB, and then we'll create two that are odd, odd, an odd B, and
we'll put them on those respective hosts.
So these three VMs will be on host A and these three VMs will be on host B and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So these three VMs will be on host A and these three VMs will be on host B and
the network connections will be as shown.
Also, because I currently have DHCP services in place here, we should be able
to get an IP address dynamically on all these VMs.
However, I think it also be good to go ahead and set up a couple of
reservations with DHCP for our servers.
So for VM dash web, and that's going to be here on the 10 10 network.
So my lab environment that VM is going to be a DHCP client by default.
So let's set up a reservation and give it the IP address of 10 dot 10 dot 0 dot
10 for VM web right there. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
10 for VM web right there.
And then for VM dash DB, let's give it the IP address on the 10 20 network.
So for that VM VM dash DB, let's give it the IP address of 10 dot 20 dot 0 dot
20.
That'll also be a great opportunity to demonstrate setting up a reservation
inside of NSX for a specific VM based on its layer to address.
Then for game plan, next, let's go ahead and create some NSX tags and then we
can use those tags for our dynamic group membership.
So for our NSX tags, let's create one called web tag and we'll create one WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So for our NSX tags, let's create one called web tag and we'll create one
called DB tag and let's create one called even tag and we'll create another one
called odd tag.
Let's also create one called client tag.
So when we create the tags, and then as far as which VMs are going to get
assigned, which NSX tags, the web server here VM dash web will associate it
with the tag of web dash tag.
And then the VMs are going to get the even dash tag that be even a and even B
and then the odd tag will assign that to VM odd a and odd B. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then the odd tag will assign that to VM odd a and odd B.
We could also create one called servers tag, etc.
And then for the client tag, we'll assign that to all four clients VM even a
and B and odd a and B.
So the cool thing is that once we have these tags associated, we can then
dynamically create groups based on looking for and matching on those tags.
So our next step would then be to create the security groups and for this
discussion, we're going to do that based on tags.
And so for the groups, let's go ahead and create several will create one for
the database.
We'll call that database group and I'm going to actually put the name group
here in these groups and the name tag and the tags. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here in these groups and the name tag and the tags.
Now, wait, when we see them in the interface, we'll know exactly what they are.
So for the security group called DB dash group, it'll include any VMs that have
the tag of DB tag.
And so when we create the group, we'll specify that's the criteria.
It's also created group for web servers. We'll call that web group.
Let's also create a group called odd group and one called even group.
So for the odd group, we'll be looking for any VMs that have the odd tag
associated with them.
And for the even group, we'll look for any VMs that have the tag of even tag. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And for the even group, we'll look for any VMs that have the tag of even tag.
And just for fun, let's create one more called client group.
And then for the client group, the dynamic membership is going to be based on V
Ms that have the client tag.
So the concept here with the tags and group membership is that we can associate
various tags with VMs.
And then based on those tags, include those VMs as part of one or more groups.
Now up to this point, we really haven't implemented any specific distributed
firewall restrictions or controls
because the default policy rule says allow everything.
So our last step here would then be to go ahead and use the security groups as
part of a distributed firewall policy. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
part of a distributed firewall policy.
So as our last step here, we'll add DFW for distributed firewall policies and
rules.
And the way the policies and rules work, we create a policy, for example,
right here, we'll call it policy C. And then we need that policy, we're going
to go ahead and have dot one,
dot two, dot three, and these represent rules.
So here'd be our policy. And inside the policy, we have individual rules.
So instead of a category, those will be processed from top to bottom looking
for a match.
And once there's a match, it's then going to go ahead and execute the action WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And once there's a match, it's then going to go ahead and execute the action
for that, whether it's drop or reject or allow.
So far, a game plan will create some policies and rules that are doing matching
based on the groups.
And then verify we get the expected results here inside of the NSX environment.
We can also test that a couple of different ways by initiating those traffic
flows that were either permitting or denying.
We can also use trace flow to verify whether or not that traffic would make it
and if it's dropping or rejecting that traffic,
we can also see which device inside of NSX is doing it.
And again, just like routing decisions are made as close to the source as WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And again, just like routing decisions are made as close to the source as
possible,
the implementation of our distributed firewall rules are also implemented as
close to the source as possible.
So is this machine right here that's trying to access some other resource in
the network?
And there's a distributed firewall policy rule that says, hey, that is not
allowed.
It's ESXIA, who's hosting that VM that has a copy of that distributed firewall
that's going to be dropping and denying that traffic
and not forwarding it out to the external network.
So with that game plan in place in our very next video, let's go ahead and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So with that game plan in place in our very next video, let's go ahead and
deploy these five VMs that we're going to use
for testing and verification of the distributed firewall.
I'll see you in the next video in just a moment.