So in this third example of our distributed firewall policies,
we're going to deny Telnet traffic,
which effectively is TCP going to the well-known port of 23,
if it's coming from any of our VMs that are members of the clients group,
going to any VMs that are members of the server group.
And I don't think we have yet created a group called servers,
but there's also many different ways we could implement this.
So we could say traffic from anybody in this group,
going to specific VMs, but for scalability,
we'd probably want to have a group that included those VMs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we'd probably want to have a group that included those VMs.
So as a quick refresher on tags and associating tags with VMs,
and then using those tags as part of group membership,
let's create a new tag called servers.
We'll associate that with our web VM and also our database VM,
and then we'll create a new group that's looking for that respective tag.
And then we'll include that server's group
as part of our security policy rule in the distributive firewall.
So back at the NSX manager, we'll click on inventory on the left.
Let's create a new tag by going to tags,
click on add tag, and we'll call this servers.
And then we'll select virtual machines, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we'll select virtual machines,
and let's go ahead and include VMDB and also VM web
as the two servers we want to receive that tag.
So we'll click on apply and click on save.
And then I don't see it here, so we'll click on refresh,
and there it is right there.
And it's assigned to currently two objects, and that's our two VMs.
So next, let's go to groups and click on add group,
and we'll call this server group.
And for the compute members, we'll click on set there,
and for the criteria, we want to look for a tag WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and for the criteria, we want to look for a tag
that is exactly equal to servers.
So we'll select that servers tag for a match, we'll click on apply,
click on save, and then just to confirm that, for the server group here,
I'm going to click on view members,
just to confirm that our two servers show up there, which they do.
So those two servers have the tag associated with them,
and this group is looking for those tags,
and that's why these two VMs are part of this group.
So we'll click on close,
and now let's include that group information as part of a security policy rule
inside of the distributed firewall.
So to do that, we'll go back to the security tab up on top. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So to do that, we'll go back to the security tab up on top.
Over on the left, we'll click on distributed firewall.
We'll go to our applications category, which we're currently in,
and we'll expand our policy.
Let me also collapse that left hand side to give us a little bit more room,
and we are not using these two rules anymore.
Let me go ahead and select both of those and delete them,
and then click on publish to make sure everything is cleaned up.
Click on refresh there, that looks good,
and let's add a new rule to our policy.
So with our policy selected, we'll click on add rule,
and we'll call this one note-telnet clients to servers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we'll call this one note-telnet clients to servers.
So that's the name of it right there, and for the criteria,
if the source is any VMs that are a member of the group,
all clients, and then we'll click on apply.
So the all clients group is the source,
and for the destination, we'll click on the pencil there,
and the source is going to be server group.
So we'll click on server group, and click on apply.
So there's the destination, and for the actual service based on our plan,
we want to prevent telnet traffic.
So we're going to go ahead and point to TCP with the station port of 23.
So we'll click on the edit in the services column here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll click on the edit in the services column here,
and then we could create our own service,
or we could just do a search up here for telnet and press enter,
and that would show us the objects here regarding that protocol import.
So here is telnet will select that,
and that would match on TCP traffic with a destination port of 23,
regardless of what source port is being used.
So we'll go ahead and click on apply,
and if we want to deny that traffic over here for the action,
we'd want to specify either a drop or reject.
So because we're dropping on telnet traffic, we could do a reject, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So because we're dropping on telnet traffic, we could do a reject,
and that would cause a TCP reset message to be sent back to the clients
from this group who are trying to initiate that conversation.
And before we publish this, let's just verify that telnet
is allowed through the network.
So easy way to do that is go to plan and troubleshoot.
I'm going to say, yes, let's navigate away, go down to traffic analysis,
and then we will create a new trace flow, we'll proceed,
and we want to use TCP to the well-known port of 23.
We use some high-numbered port like 673 as a source,
and then for testing, let's go ahead and test from how about even A, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then for testing, let's go ahead and test from how about even A,
which is one of our client VMs, and let's go to the VMDB server.
So we'll select VMDB as a destination.
So what this is doing is testing whether or not the network will allow
TCP traffic destined to port 23 from this VM to this VM.
So we'll scroll down, click on trace,
and this should be allowed through the network because it's going to hit that
end default rule
of permitting all layer three traffic.
So there's the output, and if we bring up the details,
so it started off on ESXIA, went through distributed firewall rules there, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so it started off on ESXIA, went through distributed firewall rules there,
it got routed from the gateway A up to the tier zero gateway down to the
gateway B,
and then logically shipped over to the tunnel endpoint over at ESXIB,
and then ESXIB did the final delivery.
So that'll work great.
Let's go back to security.
And on the left, we'll go to distributed firewall, and didn't save our changes.
We'll go ahead and recreate that rule again.
So we'll create our policy, add rule, also a note TCP 23, source client,
destination server. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
destination server.
So that'll be the name of our rule.
For the source, we'll select all clients, click on apply,
and for the destination, we'll click on the pencil there,
and that's going to be our server group.
And if we hadn't created that server group,
we also could have just selected the DB group and then the web group.
And if our servers were a member of one of those groups, that would also apply.
So I'm going to go ahead and just take off the DB group there,
and also take off the web group because we have the server group,
and we already confirmed that our two servers are part of that group.
Sounds great. So we'll click on close there, click on apply, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Sounds great. So we'll click on close there, click on apply,
and then for the service, we want to go ahead and use TCP port 23.
So we'll go ahead and search for telnet.
So we'll select telnet, come from the destination TCP port 23, click apply,
and then for the action, let's go ahead and do a reject,
and we'll publish that.
All right, that looks good.
So now that's configured, let's verify this rule,
which has the idea of 407 for our current implementation here.
Let's verify that that rule is going to prevent TCP traffic going to the well
known port of 23,
if it's sourced from any of our clients going to any of our servers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if it's sourced from any of our clients going to any of our servers.
So we'll go to plan and troubleshoot.
On the left, we'll click on traffic analysis,
and we currently have our current test in place.
So let me just do an edit real quick and click on proceed,
and just to verify the details.
So this will be TCP traffic sourced from 6783 going to 23 from VM even A,
which is on ES6IA going over to VM-DB, which is over on segment 20,
and being hosted on ES6IB.
And there's the IP addresses involved, and we'll click on trace. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And there's the IP addresses involved, and we'll click on trace.
So this one should fail, and that's because we have our distributed firewall
with a security policy rule that says deny traffic from the clients group,
going to the servers group if the destination port is TCP port 23.
So here, if we scroll up here and take a look, ES6IA said, yep,
I'm going to go ahead and kill it early.
That traffic came into ES6IA, it went through the logic of the distributed
firewall,
and there's a rule 4074 that said, sorry, that traffic is not allowed,
and it stopped right there. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and it stopped right there.
And so when implementing our security policy rules,
there's lots of different options that we can use to implement it.
So if we go back to security and distributed firewall,
and we added a new rule, for example, click on our policy and click on add rule
,
here for the source and destination, if we clicked on the edit there,
instead of just selecting groups, which is the default tab here,
or clicking here on IP addresses and putting in an IP address or a range
as part of the consideration, we can also specify sources based on other
criteria,
other than just groups or IP addresses.
So over here on the right hand side, where it says filter by name, path, and
more,
if we click there, we can refine our search. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if we click there, we can refine our search.
So if we said, for example, I want to go ahead and search based on virtual
machines.
Now it's showing us all the VMs available.
So if I want to include, for example, VMDB or odd A and so forth,
I could include them specifically as part of the source characteristics for
this rule.
So the actual source and destination information as part of our distributed
firewall rule
isn't restricted to just group membership, but we can also sort based on a lot
of other criteria as well.
So I'm not going to change anything there, so I'll click on cancel. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I'm not going to change anything there, so I'll click on cancel.
So because we're not going to use that rule, I'll go ahead and select it and
click on delete.
So now we've had the opportunity to do three examples of specific security
rules as part
of a distributed firewall in the world of NSX.
[BLANK_AUDIO]