WEBVTT

1
00:00.000 --> 00:03.860
So if you had a moment to consider the scenario and identify based on the

2
00:03.860 --> 00:06.800
screenshots, what you think the problem is, let's compare notes.

3
00:06.800 --> 00:09.840
One of the first things I would do, first of all, if the customer came to me

4
00:09.840 --> 00:13.090
and said, "You know what? We have this rule in place and we shouldn't be able

5
00:13.090 --> 00:14.500
to access HTTP services."

6
00:14.500 --> 00:18.230
What I'd want to do is verify that that's actually true. I'd want to, you know,

7
00:18.230 --> 00:21.400
give them the benefit of the doubt and I'd like to see an action.

8
00:21.400 --> 00:25.720
So the first thing we may want to do is go down to a VM, for example, VM here

9
00:25.720 --> 00:26.800
on segment 20.

10
00:26.800 --> 00:30.800
So I currently have a computer here. This is Mint 20 sitting here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

10
00:26.800 --> 00:30.800
So I currently have a computer here. This is Mint 20 sitting here.

11
00:30.800 --> 00:35.050
And I want to verify whether or not I can actually access HTTP services from a

12
00:35.050 --> 00:37.300
device over here on 1010.

13
00:37.300 --> 00:41.140
And as of what happened, I had this little web VM here. This is web 10. And its

14
00:41.140 --> 00:45.800
IP address is NNN.181 on this network segment 1010.0.

15
00:45.800 --> 00:49.990
So I'd want to verify that that is true, that even with the rules in place that

16
00:49.990 --> 00:52.800
the clients can get access to see it for myself.

17
00:52.800 --> 00:55.880
Then we can take a look at what might be incorrectly configured and based on

18
00:55.880 --> 00:57.800
the screenshots, confirm that together.

19
00:57.800 --> 01:01.960
So let's go down to this VM right here. This is Mint 20. And let's verify
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

19
00:57.800 --> 01:01.960
So let's go down to this VM right here. This is Mint 20. And let's verify

20
01:01.960 --> 01:07.800
whether or not we can access web 10 over here at the IP address of 1010.0181.

21
01:07.800 --> 01:12.610
So here is Mint 20. That's why I confirm it's on the right subnet. So we can do

22
01:12.610 --> 01:13.800
an IP address, press enter.

23
01:13.800 --> 01:20.650
And sure enough, it is at 10.20.0.153. Let's also do a quick ping to test to 10

24
01:20.650 --> 01:22.800
.10.0.181.

25
01:22.800 --> 01:26.270
That should be the IP address of our little server over on 10. And let's open

26
01:26.270 --> 01:31.800
up a browser. We can also do, you know, curl right here with the C URL space
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

26
01:26.270 --> 01:31.800
up a browser. We can also do, you know, curl right here with the C URL space

27
01:31.800 --> 01:37.800
dash I and then go to HTTP colon slash slash and 10.10.0.181.

28
01:37.800 --> 01:38.600
And sure enough, that looks like it is working. So there's the content for the

29
01:38.600 --> 01:46.520
index study, HTML that the little web servers using and just to confirm that

30
01:46.520 --> 01:48.800
HTTP is working, even though it shouldn't be.

31
01:48.800 --> 01:55.180
Let's open up a browser and go to 10.10.0.181. And sure enough, that seems to

32
01:55.180 --> 01:57.800
be working. So as far as what could the problem be?

33
01:57.800 --> 02:02.590
Let's make a little list. Number one, maybe we have a rule that's applied to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

33
01:57.800 --> 02:02.590
Let's make a little list. Number one, maybe we have a rule that's applied to

34
02:02.590 --> 02:06.800
the gateway here. It should be on gateway B, but maybe it's disabled.

35
02:06.800 --> 02:10.080
Maybe we have a disabled rule as part of our gateway firewall policy here on

36
02:10.080 --> 02:13.800
gateway B. Another problem could be that if there's multiple gateways involved,

37
02:13.800 --> 02:16.800
maybe the rule is applied to the incorrect gateway.

38
02:16.800 --> 02:20.340
So in this scenario here, if they applied the rule, it said deny HTTP traffic

39
02:20.340 --> 02:26.090
from 10.20 going to 10.10. If they applied it here or here, it would also block

40
02:26.090 --> 02:28.800
the traffic because those are in line.

41
02:28.800 --> 02:32.240
However, if we had another gateway over here, let's call it gateway C, and we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

41
02:28.800 --> 02:32.240
However, if we had another gateway over here, let's call it gateway C, and we

42
02:32.240 --> 02:35.930
play that rule here, and that gateway is not in line with the traffic from 10.

43
02:35.930 --> 02:37.800
20 going over to 10.10.

44
02:37.800 --> 02:41.110
That would also cause that rule not to be hit. So what else could be the

45
02:41.110 --> 02:45.100
problem? Another problem could be that on gateway B, if it's deployed as a

46
02:45.100 --> 02:48.800
distributed router only, and it doesn't have a services component with it,

47
02:48.800 --> 02:51.800
meaning it's not using the edge nodes.

48
02:51.800 --> 02:55.490
That would also preclude gateway B if it's not using the edge nodes to prevent

49
02:55.490 --> 02:59.600
it from being able to enforce any gateway firewall policies. So even though we

50
02:59.600 --> 03:04.010
can configure them all day and all night, unless we have gateway B associated
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

50
02:59.600 --> 03:04.010
can configure them all day and all night, unless we have gateway B associated

51
03:04.010 --> 03:06.800
with an edge cluster, those rules won't be enforced.

52
03:06.800 --> 03:10.340
So here I'm going to jot down no edges, meaning that this router gateway B is

53
03:10.340 --> 03:13.800
not associated with the end of our edge nodes, because that would cause a

54
03:13.800 --> 03:17.860
gateway firewall rule to not be enforced if this gateway wasn't associated with

55
03:17.860 --> 03:18.800
an edge node.

56
03:18.800 --> 03:22.160
So in the skill before this walkthrough that we're doing together right now, I

57
03:22.160 --> 03:25.590
posted a few screenshots regarding some of the configuration here instead of NS

58
03:25.590 --> 03:27.800
X, let's actually go to the live interface.

59
03:27.800 --> 03:31.290
And let's just take a peek at the configuration to verify together what we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

59
03:27.800 --> 03:31.290
And let's just take a peek at the configuration to verify together what we

60
03:31.290 --> 03:35.930
think is wrong that is currently allowing HTTP traffic from 10.20.0 over to 10.

61
03:35.930 --> 03:36.800
10.0.

62
03:36.800 --> 03:41.050
So here in the NSX manager, let's click on security on the left under policy

63
03:41.050 --> 03:45.210
management will click on gateway firewall. And then because we're focused here

64
03:45.210 --> 03:49.230
on gateway B, let's use the drop down and take a look at the policies and rules

65
03:49.230 --> 03:50.800
associated with gateway B.

66
03:50.800 --> 03:54.720
So currently we have some custom rules here that's fantastic because if we had

67
03:54.720 --> 03:58.780
placed, for example, the correct policies and rules on a gateway, but not the

68
03:58.780 --> 03:59.800
right gateway.

69
03:59.800 --> 04:03.590
Again, that could cause it not to be enforced. So here we have a custom policy
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

69
03:59.800 --> 04:03.590
Again, that could cause it not to be enforced. So here we have a custom policy

70
04:03.590 --> 04:07.850
called no HTTP policy, and it's associated with this local gateway gateway B.

71
04:07.850 --> 04:08.800
That's all good.

72
04:08.800 --> 04:13.690
And then we have a rule and the rule is called no HTTP rule and the idea is 6

73
04:13.690 --> 04:18.060
123. And this rule is going to match if it's traffic source from 10.20 anything

74
04:18.060 --> 04:19.800
going to 10.10 anything.

75
04:19.800 --> 04:24.460
So that part looks good for the source in this nation. And if the services HTTP

76
04:24.460 --> 04:29.800
, which is TCP going to port 80, which is the well known port for HTTP services.

77
04:29.800 --> 04:33.020
There's no profile associated with it. So we're only looking basically at the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

77
04:29.800 --> 04:33.020
There's no profile associated with it. So we're only looking basically at the

78
04:33.020 --> 04:35.800
layer four protocol for TCP, which should match no problem.

79
04:35.800 --> 04:40.590
It's applied to our gateway gateway B and the actions rejected. So why isn't

80
04:40.590 --> 04:43.800
this matching? So we just tested this for mint 20 a moment ago.

81
04:43.800 --> 04:49.030
So limbering mint 20 back in and click on refresh. And sure enough, it looks

82
04:49.030 --> 04:54.030
like it's reloading that no problem. And if we try a ping, we can ping that

83
04:54.030 --> 04:54.800
device.

84
04:54.800 --> 04:57.990
And the ping is not a problem because it didn't say anything about blocking

85
04:57.990 --> 05:00.920
ping traffic, but it did want to block HTTP traffic and that is still
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

85
04:57.990 --> 05:00.920
ping traffic, but it did want to block HTTP traffic and that is still

86
05:00.920 --> 05:01.800
functioning.

87
05:01.800 --> 05:05.870
So why in the world is that on this page here for the gateway firewall policy

88
05:05.870 --> 05:09.780
for gateway B, there is this message here and blue says, please associate an

89
05:09.780 --> 05:12.800
edge cluster to the selected gateway for the firewall to work.

90
05:12.800 --> 05:17.630
And ignore policy realization effectively, meaning ignore any custom policies

91
05:17.630 --> 05:22.310
you have here until this gateway gateway B is associated with an edge transport

92
05:22.310 --> 05:22.800
node.

93
05:22.800 --> 05:27.320
So that is very likely the reason that this rule is not working. So to fix that

94
05:27.320 --> 05:31.570
, let's go back to networking. And on the left hand side, we'll expand that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

94
05:27.320 --> 05:31.570
, let's go back to networking. And on the left hand side, we'll expand that

95
05:31.570 --> 05:33.800
column and we'll go to our tier one gateways.

96
05:33.800 --> 05:37.950
And sure enough, gateway B is not associated with any of our edge notes. So if

97
05:37.950 --> 05:42.210
we look at A over here for a moment, we'll expand that here is showing us that

98
05:42.210 --> 05:44.800
gateway A is associated with our edge cluster.

99
05:44.800 --> 05:49.470
But if we collapse that gateway B, if we expand that is not associated with any

100
05:49.470 --> 05:54.020
edge notes at all. So to change that, we're going to edit gateway B by clicking

101
05:54.020 --> 05:56.800
on the three dots from the menu clicking on edit.

102
05:56.800 --> 06:00.220
And then we'll specify that instead of distributed only, we'll do active
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

102
05:56.800 --> 06:00.220
And then we'll specify that instead of distributed only, we'll do active

103
06:00.220 --> 06:03.920
standby. And then we'll select the edge cluster. We want the gateway B to be

104
06:03.920 --> 06:07.800
associated with. We only have one edge cluster that includes edge one and edge

105
06:07.800 --> 06:07.800
two.

106
06:07.800 --> 06:12.190
We'll scroll down and click on save and then click on close editing. So now we

107
06:12.190 --> 06:15.650
go back to security and on the left under policy management, if we click on

108
06:15.650 --> 06:19.290
gateway firewall and then furthermore, choose the right gateway, which is

109
06:19.290 --> 06:20.800
gateway B.

110
06:20.800 --> 06:24.690
You'll notice we still have the same rule in place. So nothing about this rule

111
06:24.690 --> 06:28.690
has changed since we looked at it last. However, now because gateway B is

112
06:28.690 --> 06:31.800
associated with the edge nodes as part of the cluster.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

112
06:28.690 --> 06:31.800
associated with the edge nodes as part of the cluster.

113
06:31.800 --> 06:35.810
And because the gateway firewall function requires using edge nodes, if that

114
06:35.810 --> 06:39.850
was the only problem, that rule should now be enforced. So let's go back to

115
06:39.850 --> 06:40.800
mint 20.

116
06:40.800 --> 06:43.930
And I'm going to go ahead and close the browser and then we go to the command

117
06:43.930 --> 06:47.260
line and let's start off with something that won't be cached and that is using

118
06:47.260 --> 06:51.210
curl. So earlier, oh, there we go. So the connection is now being refused

119
06:51.210 --> 06:52.800
because of the reject message.

120
06:52.800 --> 06:56.630
But if we try to do a ping, that's just still work. And if we go to a browser,

121
06:56.630 --> 07:00.670
let's open up a browser and we'll connect over to our little web server here at
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

121
06:56.630 --> 07:00.670
let's open up a browser and we'll connect over to our little web server here at

122
07:00.670 --> 07:04.800
10 dot 10 dot zero dot 181 by putting in that IP address right there.

123
07:04.800 --> 07:08.830
And survey says, looks like it's coming up, but you know what I think I think

124
07:08.830 --> 07:12.920
that's cash. So I'm going to go ahead and hit the refresh button. There we go.

125
07:12.920 --> 07:13.800
It looks better.

126
07:13.800 --> 07:17.160
So initially, it was just pulling that up from the local cache on the mint 20

127
07:17.160 --> 07:20.470
computer. And that's one of the other benefits of testing this from the command

128
07:20.470 --> 07:22.800
line, because it's not caching anything if you use curl.

129
07:22.800 --> 07:26.580
It's actually going out to that destination every single time. So even though

130
07:26.580 --> 07:31.020
HTTP is being blocked, other protocols aren't so we use till it to 10 dot 10
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

130
07:26.580 --> 07:31.020
HTTP is being blocked, other protocols aren't so we use till it to 10 dot 10

131
07:31.020 --> 07:33.800
dot 0 dot 181 instead of using the well known port for tell net.

132
07:33.800 --> 07:38.190
We'll use 22, which can see whether or not that ports open and that is being

133
07:38.190 --> 07:41.940
allowed across the network. We're not getting a reset from that. But if we

134
07:41.940 --> 07:42.800
tried port 80, let's go and do that.

135
07:42.800 --> 07:46.700
We'll put in port 80 press enter and boom, we have the connection refused

136
07:46.700 --> 07:50.830
because we're trying to connect to the port that is matching here in this rule.

137
07:50.830 --> 07:54.360
Again, that's traffic from 10 20 anything going to 10 10 anything if the

138
07:54.360 --> 07:57.800
destination port is TCP port 80.

139
07:57.800 --> 08:02.210
So I have had a lot of fun in this set of videos regarding the gateway firewall
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

139
07:57.800 --> 08:02.210
So I have had a lot of fun in this set of videos regarding the gateway firewall

140
08:02.210 --> 08:06.680
function inside of NSX. And I look forward to seeing you my friend in another

141
08:06.680 --> 08:11.610
skill very, very soon until then, I hope this has been informative and I'd like

142
08:11.610 --> 08:12.800
to thank you for viewing.

143
08:12.800 --> 08:14.800
reviewing.