WEBVTT

1
00:00.000 --> 00:05.060
So now that we have created our deny ICP traffic from even to odd based on

2
00:05.060 --> 00:05.800
group membership,

3
00:05.800 --> 00:09.200
and we've verified that in this video, let's create another rule.

4
00:09.200 --> 00:13.400
But this time, let's deny SSH traffic, which uses TC port 22.

5
00:13.400 --> 00:17.000
If it's sourced from any of our clients going to our web server.

6
00:17.000 --> 00:20.600
And then for testing, we'll use even B, which is right here.

7
00:20.600 --> 00:25.200
This is going to try to use SSH up to the web server, which is right here.

8
00:25.200 --> 00:29.000
So here in the NSX manager, before we actually put in that restriction

9
00:29.000 --> 00:33.930
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

9
00:29.000 --> 00:33.930
for SSH traffic, let's verify currently that the default rules would allow that

10
00:33.930 --> 00:34.000
.

11
00:34.000 --> 00:37.290
So if we go to plan and troubleshoot on the left, we'll click on traffic

12
00:37.290 --> 00:37.800
analysis,

13
00:37.800 --> 00:39.400
and we'll launch trace flow.

14
00:39.400 --> 00:43.400
So here in trace flow for the source VM, we use the drop down and we're going

15
00:43.400 --> 00:44.600
to choose even B.

16
00:44.600 --> 00:48.000
So we'll select that, and then we'll go to the destination.

17
00:48.000 --> 00:51.200
And for the VM there, we want to select the VM web.

18
00:51.200 --> 00:53.200
So we'll scroll down and select that.

19
00:53.200 --> 00:56.440
And then before we click here on trace, we also want to put in the right

20
00:56.440 --> 00:56.800
protocol.

21
00:56.800 --> 01:01.200
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

21
00:56.800 --> 01:01.200
So by default, it's using ICMP, but we are going to in a moment be denying SSH

22
01:01.200 --> 01:01.600
traffic.

23
01:01.600 --> 01:05.800
So for the protocol type, instead of ICMP, we'll use TCP.

24
01:05.800 --> 01:09.700
And then for the port, the well-known port for an SSH session is the server

25
01:09.700 --> 01:10.800
port of port 22.

26
01:10.800 --> 01:14.170
And then it's very likely the client's going to source that from some high-

27
01:14.170 --> 01:14.600
numbered,

28
01:14.600 --> 01:18.800
currently unused port, which we'll go ahead and put in 6, 7, 8, 3.

29
01:18.800 --> 01:22.200
So with that in place, we'll scroll down and click on trace.

30
01:22.200 --> 01:23.400
All right, and here's our results.

31
01:23.400 --> 01:25.200
Let me go ahead and collapse the left-hand column.

32
01:25.200 --> 01:30.250
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

32
01:25.200 --> 01:30.250
And if we look at the play-by-play and sure enough, even B is being hosted on

33
01:30.250 --> 01:31.200
ESX-IB.

34
01:31.200 --> 01:33.400
That's why ESX-IB here has the initial flow.

35
01:33.400 --> 01:37.930
So ESX-IB, it went through the distributed firewall, all the rules there by

36
01:37.930 --> 01:38.400
default,

37
01:38.400 --> 01:39.600
permitted that traffic.

38
01:39.600 --> 01:43.600
Then ESX-IB used the tunnel, shipped it over to ESX-I1.

39
01:43.600 --> 01:47.600
Based on the tunnel endpoint addresses over here, then ESX-I received it.

40
01:47.600 --> 01:50.800
It logically processed it to the distributed firewall once again,

41
01:50.800 --> 01:54.000
all the rules there allowed it to go through and that traffic was delivered.

42
01:54.000 --> 01:57.770
And if we were to have hypothetically captured that traffic, which I did on the

43
01:57.770 --> 01:58.400
backplane,

44
01:58.400 --> 02:03.280
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

44
01:58.400 --> 02:03.280
the first three rows here are the details for the GRE tunnel where the VMware

45
02:03.280 --> 02:04.000
environment shipped

46
02:04.000 --> 02:09.000
the packets over to my management computer here at 192.168.1.151.

47
02:09.000 --> 02:13.690
So this is traffic going from ESX-IB based on the tunnel endpoint, over to ESX-

48
02:13.690 --> 02:14.200
Ia.

49
02:14.200 --> 02:16.200
Here's the details for the Geniv header.

50
02:16.200 --> 02:19.300
It's for VNI 68608.608.

51
02:19.300 --> 02:20.400
It has shown right there.

52
02:20.400 --> 02:23.800
If we collapse that header, then below that, we have the original payload,

53
02:23.800 --> 02:29.000
which is the traffic coming from 1010157, which in our topology is the even-B

54
02:29.000 --> 02:30.000
IP address,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

55
02:30.000 --> 02:34.540
going to 101010, and that's the aesthetic binding we set up for the VM-web

56
02:34.540 --> 02:35.200
server.

57
02:35.200 --> 02:37.800
And so this is the traffic that was sourced by Traceflow.

58
02:37.800 --> 02:41.940
So it's actually showing here the source port, which we manually configured of

59
02:41.940 --> 02:43.000
6783.

60
02:43.000 --> 02:47.540
That's right here, going to the well-known port for SSH, which is a destination

61
02:47.540 --> 02:48.600
port of 22.

62
02:48.600 --> 02:51.000
And then above that, we have the payload of SSH.

63
02:51.000 --> 02:55.130
So this is courtesy of the NSX environment injecting that into the network as

64
02:55.130 --> 02:56.400
part of Traceflow.

65
02:56.400 --> 02:59.200
So now that we've verified that that traffic flow works,

66
02:59.200 --> 03:01.200
let's go back to our security tab up here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

66
02:59.200 --> 03:01.200
let's go back to our security tab up here.

67
03:01.200 --> 03:03.600
On the left, we'll go back down to our distributed firewall.

68
03:03.600 --> 03:06.000
And let's create a new rule that denies that traffic.

69
03:06.000 --> 03:07.800
So I'm going to collapse that left-hand side.

70
03:07.800 --> 03:10.000
And currently we're in the application category.

71
03:10.000 --> 03:13.200
Here's our policy with our single rule right there.

72
03:13.200 --> 03:16.710
So let's add a new rule by simply clicking on our policy and clicking on Add

73
03:16.710 --> 03:17.000
Rule.

74
03:17.000 --> 03:19.600
And for this new rule, it's going to put it right here before the other one.

75
03:19.600 --> 03:21.800
So if we wanted to move this, we could just drag and drop it.

76
03:21.800 --> 03:22.600
Either way, it's great.

77
03:22.600 --> 03:27.000
So we're going to put it right here as our second rule in our policy.

78
03:27.000 --> 03:32.800
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

78
03:27.000 --> 03:32.800
And for the name, let's go ahead and name this No SSH Clients to Web.

79
03:32.800 --> 03:34.400
That'll be the name of our new rule.

80
03:34.400 --> 03:36.800
I'm going to scooch that over a little bit so it's a little more readable.

81
03:36.800 --> 03:41.250
And then for the criteria, we want this criteria to match on any VMs that are

82
03:41.250 --> 03:43.200
part of the client's group.

83
03:43.200 --> 03:46.830
So if we click on the pencil here and then we grab this group called All Cl

84
03:46.830 --> 03:47.200
ients

85
03:47.200 --> 03:49.600
and just to confirm, we'll click here on View Members.

86
03:49.600 --> 03:52.400
It can confirm for us at this moment who the members are.

87
03:52.400 --> 03:56.200
So each of these VMs have the tag that this group is looking for.

88
03:56.200 --> 03:57.400
And that's why they're all showing up here.

89
03:57.400 --> 04:01.630
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

89
03:57.400 --> 04:01.630
We'll click on Close, click on Apply, and then for the destination, we want the

90
04:01.630 --> 04:04.000
destination just to be the VM web server.

91
04:04.000 --> 04:07.400
So we'll click on the pencil here in the destination column for this rule.

92
04:07.400 --> 04:10.460
And we're going to scroll down and we're going to pick the group called Web-

93
04:10.460 --> 04:12.400
Group and click on Apply.

94
04:12.400 --> 04:16.000
So that's the source, that's the destination, and for the services,

95
04:16.000 --> 04:19.000
we want to specify TCP port 22.

96
04:19.000 --> 04:22.280
So we'll click on the pencil and we could here just click on Add Service and

97
04:22.280 --> 04:24.200
specify TCP port 22,

98
04:24.200 --> 04:27.000
but they've already got most of the common ports already here.

99
04:27.000 --> 04:30.950
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

99
04:27.000 --> 04:30.950
So if we click here, where it says Filter by Name, Path and More, and then we

100
04:30.950 --> 04:32.800
type in SSH and press Enter.

101
04:32.800 --> 04:37.400
That's a convenient way of identifying TCP going to port 22.

102
04:37.400 --> 04:41.160
So we'll click on Apply and then for the action, if we want to deny it, we'll

103
04:41.160 --> 04:43.000
go ahead and let's do a Reject.

104
04:43.000 --> 04:47.200
So if somebody tries to from the clients group, if they try to do, for example,

105
04:47.200 --> 04:48.400
an SSH session,

106
04:48.400 --> 04:51.400
they're going to time out if they're going to a server in the web group,

107
04:51.400 --> 04:54.430
they are actually going to go ahead and get a TCP reset canceling the

108
04:54.430 --> 04:55.600
connection request.

109
04:55.600 --> 04:58.600
So that's going to be enabled by default once we push it out.

110
04:58.600 --> 05:01.460
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

110
04:58.600 --> 05:01.460
So we'll click on Publish and then right here where it says in progress, we'll

111
05:01.460 --> 05:03.000
click on the Refresh Symbol there

112
05:03.000 --> 05:04.600
and it is ready to go.

113
05:04.600 --> 05:08.330
So now if we go back to Plan and Troubleshoot and then on the left, we go back

114
05:08.330 --> 05:09.800
down to Traffic Analysis

115
05:09.800 --> 05:12.800
and now if we run that same exact test again,

116
05:12.800 --> 05:17.400
which is TCP traffic with a source of even be going to our web server,

117
05:17.400 --> 05:21.580
now if we click right here on Retrace and click on Proceed, that's going to be

118
05:21.580 --> 05:22.000
denied

119
05:22.000 --> 05:25.010
because it's going to hit the distributed firewall rule and we're not going to

120
05:25.010 --> 05:27.200
wait until it gets over to ES6IA to do it.

121
05:27.200 --> 05:31.400
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

121
05:27.200 --> 05:31.400
ES6IAB where that traffic is initiated, it's going to be ES6IAB with this copy

122
05:31.400 --> 05:32.800
of the distributed firewall

123
05:32.800 --> 05:35.000
that's going to go ahead and drop that traffic.

124
05:35.000 --> 05:39.370
So if we go down to Play by Play, so sure enough, the traffic was initiated

125
05:39.370 --> 05:40.400
here on ES6IAB,

126
05:40.400 --> 05:45.110
then as it tried to go through the distributed firewall, it hit this rule 4073

127
05:45.110 --> 05:46.000
which killed it

128
05:46.000 --> 05:49.200
and denied that traffic right there at ES6IAB.

129
05:49.200 --> 05:52.640
So if we go back to the Security tab and we go back down to a distributed

130
05:52.640 --> 05:53.200
firewall

131
05:53.200 --> 05:57.400
and we open up our policy here, and notice that rule right there 4073,

132
05:57.400 --> 06:00.000
that's the rule that's denying our SSH traffic.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

133
06:00.000 --> 06:04.300
If that traffic was sourced from any VMs, they're members of the All-Clients

134
06:04.300 --> 06:04.600
group

135
06:04.600 --> 06:06.800
going to any VMs in the web group.

136
06:06.800 --> 06:08.800
If the traffic is SSH.

137
06:08.800 --> 06:11.800
We also verified that's the rule number that we saw in the output.

138
06:11.800 --> 06:14.200
So we modified this rule right here, we said, "You know what, let's go ahead

139
06:14.200 --> 06:15.200
and disable it."

140
06:15.200 --> 06:17.800
So we'll disable it there, we'll click on Publish.

141
06:17.800 --> 06:21.200
So now that that rule exists, but it's disabled, it's not being used.

142
06:21.200 --> 06:24.600
Now if we go back to Plan and Troubleshoot and on the left, we go to Traffic

143
06:24.600 --> 06:25.200
Analysis

144
06:25.200 --> 06:28.390
and we run this trace again, so I'll click on Retrace with all the same

145
06:28.390 --> 06:29.000
parameters.

146
06:29.000 --> 06:31.200
Now it should show as successful.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

146
06:29.000 --> 06:31.200
Now it should show as successful.

147
06:31.200 --> 06:35.480
So sure enough, it started here on ES6IAB, passed the rules in the distributed

148
06:35.480 --> 06:36.000
firewall,

149
06:36.000 --> 06:40.100
we shipped over from ES6IAB to ES6IA based on the internal endpoints and also

150
06:40.100 --> 06:41.000
the names here.

151
06:41.000 --> 06:44.800
And then ES6IA also because it had no blocking in the distributed firewall

152
06:44.800 --> 06:44.800
rules,

153
06:44.800 --> 06:47.200
allowed that traffic to be forwarded and it was delivered.

154
06:47.200 --> 06:56.200
[BLANK_AUDIO]