So now that we have created our deny ICP traffic from even to odd based on
group membership,
and we've verified that in this video, let's create another rule.
But this time, let's deny SSH traffic, which uses TC port 22.
If it's sourced from any of our clients going to our web server.
And then for testing, we'll use even B, which is right here.
This is going to try to use SSH up to the web server, which is right here.
So here in the NSX manager, before we actually put in that restriction
for SSH traffic, let's verify currently that the default rules would allow that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for SSH traffic, let's verify currently that the default rules would allow that
.
So if we go to plan and troubleshoot on the left, we'll click on traffic
analysis,
and we'll launch trace flow.
So here in trace flow for the source VM, we use the drop down and we're going
to choose even B.
So we'll select that, and then we'll go to the destination.
And for the VM there, we want to select the VM web.
So we'll scroll down and select that.
And then before we click here on trace, we also want to put in the right
protocol.
So by default, it's using ICMP, but we are going to in a moment be denying SSH WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So by default, it's using ICMP, but we are going to in a moment be denying SSH
traffic.
So for the protocol type, instead of ICMP, we'll use TCP.
And then for the port, the well-known port for an SSH session is the server
port of port 22.
And then it's very likely the client's going to source that from some high-
numbered,
currently unused port, which we'll go ahead and put in 6, 7, 8, 3.
So with that in place, we'll scroll down and click on trace.
All right, and here's our results.
Let me go ahead and collapse the left-hand column.
And if we look at the play-by-play and sure enough, even B is being hosted on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if we look at the play-by-play and sure enough, even B is being hosted on
ESX-IB.
That's why ESX-IB here has the initial flow.
So ESX-IB, it went through the distributed firewall, all the rules there by
default,
permitted that traffic.
Then ESX-IB used the tunnel, shipped it over to ESX-I1.
Based on the tunnel endpoint addresses over here, then ESX-I received it.
It logically processed it to the distributed firewall once again,
all the rules there allowed it to go through and that traffic was delivered.
And if we were to have hypothetically captured that traffic, which I did on the
backplane,
the first three rows here are the details for the GRE tunnel where the VMware WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the first three rows here are the details for the GRE tunnel where the VMware
environment shipped
the packets over to my management computer here at 192.168.1.151.
So this is traffic going from ESX-IB based on the tunnel endpoint, over to ESX-
Ia.
Here's the details for the Geniv header.
It's for VNI 68608.608.
It has shown right there.
If we collapse that header, then below that, we have the original payload,
which is the traffic coming from 1010157, which in our topology is the even-B
IP address, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to 101010, and that's the aesthetic binding we set up for the VM-web
server.
And so this is the traffic that was sourced by Traceflow.
So it's actually showing here the source port, which we manually configured of
6783.
That's right here, going to the well-known port for SSH, which is a destination
port of 22.
And then above that, we have the payload of SSH.
So this is courtesy of the NSX environment injecting that into the network as
part of Traceflow.
So now that we've verified that that traffic flow works,
let's go back to our security tab up here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
let's go back to our security tab up here.
On the left, we'll go back down to our distributed firewall.
And let's create a new rule that denies that traffic.
So I'm going to collapse that left-hand side.
And currently we're in the application category.
Here's our policy with our single rule right there.
So let's add a new rule by simply clicking on our policy and clicking on Add
Rule.
And for this new rule, it's going to put it right here before the other one.
So if we wanted to move this, we could just drag and drop it.
Either way, it's great.
So we're going to put it right here as our second rule in our policy.
And for the name, let's go ahead and name this No SSH Clients to Web. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And for the name, let's go ahead and name this No SSH Clients to Web.
That'll be the name of our new rule.
I'm going to scooch that over a little bit so it's a little more readable.
And then for the criteria, we want this criteria to match on any VMs that are
part of the client's group.
So if we click on the pencil here and then we grab this group called All Cl
ients
and just to confirm, we'll click here on View Members.
It can confirm for us at this moment who the members are.
So each of these VMs have the tag that this group is looking for.
And that's why they're all showing up here.
We'll click on Close, click on Apply, and then for the destination, we want the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We'll click on Close, click on Apply, and then for the destination, we want the
destination just to be the VM web server.
So we'll click on the pencil here in the destination column for this rule.
And we're going to scroll down and we're going to pick the group called Web-
Group and click on Apply.
So that's the source, that's the destination, and for the services,
we want to specify TCP port 22.
So we'll click on the pencil and we could here just click on Add Service and
specify TCP port 22,
but they've already got most of the common ports already here.
So if we click here, where it says Filter by Name, Path and More, and then we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we click here, where it says Filter by Name, Path and More, and then we
type in SSH and press Enter.
That's a convenient way of identifying TCP going to port 22.
So we'll click on Apply and then for the action, if we want to deny it, we'll
go ahead and let's do a Reject.
So if somebody tries to from the clients group, if they try to do, for example,
an SSH session,
they're going to time out if they're going to a server in the web group,
they are actually going to go ahead and get a TCP reset canceling the
connection request.
So that's going to be enabled by default once we push it out.
So we'll click on Publish and then right here where it says in progress, we'll WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll click on Publish and then right here where it says in progress, we'll
click on the Refresh Symbol there
and it is ready to go.
So now if we go back to Plan and Troubleshoot and then on the left, we go back
down to Traffic Analysis
and now if we run that same exact test again,
which is TCP traffic with a source of even be going to our web server,
now if we click right here on Retrace and click on Proceed, that's going to be
denied
because it's going to hit the distributed firewall rule and we're not going to
wait until it gets over to ES6IA to do it.
ES6IAB where that traffic is initiated, it's going to be ES6IAB with this copy WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ES6IAB where that traffic is initiated, it's going to be ES6IAB with this copy
of the distributed firewall
that's going to go ahead and drop that traffic.
So if we go down to Play by Play, so sure enough, the traffic was initiated
here on ES6IAB,
then as it tried to go through the distributed firewall, it hit this rule 4073
which killed it
and denied that traffic right there at ES6IAB.
So if we go back to the Security tab and we go back down to a distributed
firewall
and we open up our policy here, and notice that rule right there 4073,
that's the rule that's denying our SSH traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If that traffic was sourced from any VMs, they're members of the All-Clients
group
going to any VMs in the web group.
If the traffic is SSH.
We also verified that's the rule number that we saw in the output.
So we modified this rule right here, we said, "You know what, let's go ahead
and disable it."
So we'll disable it there, we'll click on Publish.
So now that that rule exists, but it's disabled, it's not being used.
Now if we go back to Plan and Troubleshoot and on the left, we go to Traffic
Analysis
and we run this trace again, so I'll click on Retrace with all the same
parameters.
Now it should show as successful. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now it should show as successful.
So sure enough, it started here on ES6IAB, passed the rules in the distributed
firewall,
we shipped over from ES6IAB to ES6IA based on the internal endpoints and also
the names here.
And then ES6IA also because it had no blocking in the distributed firewall
rules,
allowed that traffic to be forwarded and it was delivered.
[BLANK_AUDIO]