WEBVTT

1
00:00.000 --> 00:03.120
So in this video, we're going to implement another gateway firewall, but this

2
00:03.120 --> 00:06.500
time we're going to do it on the Gateway A, one of our Tier 1 firewalls.

3
00:06.500 --> 00:10.560
So to implement the actual gateway firewall function on a gateway, that gateway

4
00:10.560 --> 00:14.000
has to be leveraging the services of our edge transport nodes.

5
00:14.000 --> 00:18.080
So as a prerequisite step, before we implement the gateway firewall here on

6
00:18.080 --> 00:22.050
Gateway A, we also need to tell it that we want to use the edge transport nodes

7
00:22.050 --> 00:22.300
.

8
00:22.300 --> 00:26.000
So here in the NSX manager, if we went to networking and on the left-hand side,

9
00:26.000 --> 00:29.800
let's take a peek at our topology by clicking right here on network topology.

10
00:29.800 --> 00:33.800
And let's double click here on our Tier 1 gateway. This is Gateway A.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

10
00:29.800 --> 00:33.800
And let's double click here on our Tier 1 gateway. This is Gateway A.

11
00:33.800 --> 00:36.360
So we'll double click and then we'll show us what's going on behind the scenes

12
00:36.360 --> 00:36.800
with it.

13
00:36.800 --> 00:40.570
So here up on top, it's showing us the gateway is connected to, which is being

14
00:40.570 --> 00:42.500
supported by the two edge nodes.

15
00:42.500 --> 00:46.710
And currently, if we zoom in a little bit, Edge 1 is active and Edge 2 is

16
00:46.710 --> 00:47.300
standby.

17
00:47.300 --> 00:52.070
And we scroll down though, down to the Gateway A, notice that it's not using

18
00:52.070 --> 00:54.600
Edge 1 or Edge 2 for any services.

19
00:54.600 --> 00:58.100
And that's because when we deploy these two gateways, these two Tier 1 gateways

20
00:58.100 --> 00:58.800
, originally,

21
00:58.800 --> 01:04.300
we deployed them as a distributed gateway only and not using any edge services.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

21
00:58.800 --> 01:04.300
we deployed them as a distributed gateway only and not using any edge services.

22
01:04.300 --> 01:07.160
So as it currently sits, if we went over to Gateway A, in fact, let's just do

23
01:07.160 --> 01:07.800
it for a moment.

24
01:07.800 --> 01:11.500
We went to security on the left-hand side. We went to Gateway firewall.

25
01:11.500 --> 01:15.100
And then for the gateway, we use the dropdown and choose Gateway A.

26
01:15.100 --> 01:18.620
It's giving us a warning message saying you can configure policies and rules on

27
01:18.620 --> 01:19.600
this gateway A,

28
01:19.600 --> 01:23.490
but because it's not yet associated with any edge nodes, they're not going to

29
01:23.490 --> 01:23.900
work.

30
01:23.900 --> 01:26.200
That's the little message right here is indicating.

31
01:26.200 --> 01:30.900
So to fix that, let's go ahead and associate Gateway A with our edge nodes.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

31
01:26.200 --> 01:30.900
So to fix that, let's go ahead and associate Gateway A with our edge nodes.

32
01:30.900 --> 01:34.740
And a simple way of doing that is by clicking here on networking, going down to

33
01:34.740 --> 01:35.700
under connectivity,

34
01:35.700 --> 01:37.600
clicking on Tier 1 gateways.

35
01:37.600 --> 01:41.790
So there's our Tier 1 Gateway A. We'll click on the three dots to edit it from

36
01:41.790 --> 01:42.100
the menu.

37
01:42.100 --> 01:43.100
We'll click on edit.

38
01:43.100 --> 01:46.900
And then right here on the HA mode, instead of saying distributed only,

39
01:46.900 --> 01:47.900
we're going to say, you know what?

40
01:47.900 --> 01:49.500
We want to use active standby.

41
01:49.500 --> 01:52.400
And at which point it'll say, hey, which cluster do you want to use?

42
01:52.400 --> 01:57.300
So by making the Gateway A active standby and then choosing the cluster,

43
01:57.300 --> 02:01.460
we've just met the requirements of associating the Gateway A with the edge
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

43
01:57.300 --> 02:01.460
we've just met the requirements of associating the Gateway A with the edge

44
02:01.460 --> 02:01.900
nodes.

45
02:01.900 --> 02:04.780
Then once we click on save here, so let's do that, we'll click on save and we

46
02:04.780 --> 02:05.500
'll scroll down,

47
02:05.500 --> 02:08.000
click on close editing, and then we'll collapse that.

48
02:08.000 --> 02:13.000
Now notice that Gateway A is HA mode of active standby and Gateway B is still

49
02:13.000 --> 02:14.600
set up as distributed only.

50
02:14.600 --> 02:19.100
Also behind the scenes because we just activated active standby for Gateway A,

51
02:19.100 --> 02:24.480
we now also logically have a services router in NSX for Gateway A and Gateway B

52
02:24.480 --> 02:24.600
,

53
02:24.600 --> 02:27.760
which is still only a distributed router, wouldn't have that services router

54
02:27.760 --> 02:28.300
component.

55
02:28.300 --> 02:32.420
In fact, let's go to the CLI on one of our edge nodes and take a look at
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

55
02:28.300 --> 02:32.420
In fact, let's go to the CLI on one of our edge nodes and take a look at

56
02:32.420 --> 02:34.300
Gateway A and Gateway B.

57
02:34.300 --> 02:37.500
So this is edge 1 if we do a get gateways just like that.

58
02:37.500 --> 02:40.980
It's going to show us the gateways and also their VRFs and check this out for

59
02:40.980 --> 02:42.000
Gateway A.

60
02:42.000 --> 02:46.600
Here is the distributed router function for Gateway A and there is the services

61
02:46.600 --> 02:47.900
router function for Gateway A

62
02:47.900 --> 02:52.620
because we associated it with the edge nodes and for Gateway B, there's the

63
02:52.620 --> 02:53.400
distributed router.

64
02:53.400 --> 02:56.860
However, there's no services router function for Gateway B because we haven't

65
02:56.860 --> 02:59.700
associated Gateway B with the edge nodes.

66
02:59.700 --> 03:03.200
So if we want to do the same treatment there, we could go ahead to Gateway B,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

66
02:59.700 --> 03:03.200
So if we want to do the same treatment there, we could go ahead to Gateway B,

67
03:03.200 --> 03:05.700
click on the three dots from the menu, click on edit.

68
03:05.700 --> 03:09.100
Then instead of saying distributed only, we could say active standby and then

69
03:09.100 --> 03:11.000
pick our cluster or edge cluster

70
03:11.000 --> 03:14.700
and then scroll down, click on save and then click on close editing.

71
03:14.700 --> 03:15.800
So I'll collapse that as well.

72
03:15.800 --> 03:19.370
So now they're both using active standby, leveraging the resources of our edge

73
03:19.370 --> 03:19.800
nodes.

74
03:19.800 --> 03:23.140
So if we went back to the CLI here on edge 1, for example, hit the up arrow key

75
03:23.140 --> 03:24.000
for get gateways,

76
03:24.000 --> 03:25.300
now, bada bing, ba-da-boom.

77
03:25.300 --> 03:28.900
We now also have a services router component for Gateway B.

78
03:28.900 --> 03:31.900
So now with the edge nodes associated with each of our tier 1 gateways,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

78
03:28.900 --> 03:31.900
So now with the edge nodes associated with each of our tier 1 gateways,

79
03:31.900 --> 03:36.200
we could now, if we wanted to, create Gateway Firewalls on either one of them.

80
03:36.200 --> 03:39.620
And based on our plan, we want to implement a Gateway firewall right here on

81
03:39.620 --> 03:40.200
Gateway A.

82
03:40.200 --> 03:43.800
And as part of our policy that we're going to create on this Gateway A,

83
03:43.800 --> 03:48.400
we're going to specify that we want one of our rules to say no ICB echo request

84
03:48.400 --> 03:52.800
if the source is coming from 10 10 and the destination is going to 10 20.

85
03:52.800 --> 03:55.500
And those are the IP addresses associated with our two segments.

86
03:55.500 --> 03:59.100
So let's head over to the NSX manager and we'll create our Gateway Firewall

87
03:59.100 --> 04:00.500
rules and policies
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

87
03:59.100 --> 04:00.500
rules and policies

88
04:00.500 --> 04:01.800
right here on Gateway A.

89
04:01.800 --> 04:05.800
So to do that, let's go to the security tab up here on top and on the left,

90
04:05.800 --> 04:09.300
we'll click on another policy management Gateway firewall once again.

91
04:09.300 --> 04:13.300
So we currently have this Gateway policy here on Gateway 0.

92
04:13.300 --> 04:16.600
And we included two rules in it, one that's permitting HTTP

93
04:16.600 --> 04:20.120
and one that's denying everything else if it's going to the address of our

94
04:20.120 --> 04:21.100
little web server.

95
04:21.100 --> 04:25.100
So if we want to implement customized Gateway firewall rules here on Gateway A,

96
04:25.100 --> 04:27.600
from the dropdown, we select Gateway A.

97
04:27.600 --> 04:29.200
So we'll choose Gateway A.

98
04:29.200 --> 04:31.200
So it only has its defaults in place.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

98
04:29.200 --> 04:31.200
So it only has its defaults in place.

99
04:31.200 --> 04:33.000
So we'll click on add policy.

100
04:33.000 --> 04:35.300
We'll call it our Gateway A policy.

101
04:35.300 --> 04:38.100
And then we'll add a rule to that by clicking on add rule.

102
04:38.100 --> 04:41.410
And based on what we want to accomplish, we can go ahead and click on the

103
04:41.410 --> 04:42.000
pencil there

104
04:42.000 --> 04:46.500
and go to IP addresses, a traffic source from 10.10.0, anything.

105
04:46.500 --> 04:50.900
So we'll put 10 10.0/24, which means matching on the first 24 bits there.

106
04:50.900 --> 04:54.300
Click on apply and for the destination, we'll go ahead and click on the pencil

107
04:54.300 --> 04:55.700
for that column for that rule.

108
04:55.700 --> 05:02.100
And we'll specify for IP addresses, the 10.20.0.0/24 and click on apply.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

108
04:55.700 --> 05:02.100
And we'll specify for IP addresses, the 10.20.0.0/24 and click on apply.

109
05:02.100 --> 05:08.500
And let's go ahead and call this new rule, no ICMP echo requests.

110
05:08.500 --> 05:12.200
And then for the service, we want to go ahead and match on ICMP echo requests.

111
05:12.200 --> 05:13.800
So we're here for these services.

112
05:13.800 --> 05:16.880
We'll go ahead and click on the pencil and let's go ahead and see what they

113
05:16.880 --> 05:18.800
currently have for ICMP.

114
05:18.800 --> 05:22.970
So in the filter, I'm going to go ahead and type in ICMP press center and we

115
05:22.970 --> 05:23.800
have several.

116
05:23.800 --> 05:27.900
So we could just block all ICMP traffic, but that would include probably more

117
05:27.900 --> 05:30.500
than what we want to do for our specific lab task.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

117
05:27.900 --> 05:30.500
than what we want to do for our specific lab task.

118
05:30.500 --> 05:32.600
So let's go ahead and choose this right here.

119
05:32.600 --> 05:37.300
ICMP echo request right there because that's literally what we want to stop.

120
05:37.300 --> 05:41.200
So with ICMP echo request selected, we'll click on apply.

121
05:41.200 --> 05:45.040
And now here's this rule is going to say, once we click on publish, if traffic

122
05:45.040 --> 05:49.200
is sourced from 10, 10, 0, anything and going to 10, 20, 0, anything.

123
05:49.200 --> 05:54.400
And the actual service is an ICMP echo request, then it's going to go ahead and

124
05:54.400 --> 05:55.100
permit it.

125
05:55.100 --> 05:58.810
So I'm going to go ahead and change that because we want to go ahead and drop

126
05:58.810 --> 05:59.600
that traffic.

127
05:59.600 --> 06:03.800
So we'll click on drop there because it's not going to match on a TCP flow.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

127
05:59.600 --> 06:03.800
So we'll click on drop there because it's not going to match on a TCP flow.

128
06:03.800 --> 06:07.180
It doesn't matter if you put reject there because there's no possibility of a

129
06:07.180 --> 06:09.800
TCP reset if the initial traffic is ICMP.

130
06:09.800 --> 06:14.500
Also notice right here, it's just reminding us this is applied to our tier one

131
06:14.500 --> 06:18.300
gateway A and that's because when we started configuring this new policy and

132
06:18.300 --> 06:21.300
the respective rule, we had selected the gateway A up here.

133
06:21.300 --> 06:25.780
So before we publish this out, let's just do a quick verification that we can

134
06:25.780 --> 06:28.700
indeed ping between 10, 10 and 10, 20.

135
06:28.700 --> 06:31.800
And again, that's going to begin with an ICMP echo request.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

135
06:28.700 --> 06:31.800
And again, that's going to begin with an ICMP echo request.

136
06:31.800 --> 06:36.610
So in our topology, let me just bring up mint 10 and let's try to ping the

137
06:36.610 --> 06:39.300
interface here connected to segment 20.

138
06:39.300 --> 06:44.310
That's going to be 10, 20.0.1 on Gateway B. And before we apply this rule that

139
06:44.310 --> 06:46.500
denies the echo request, that should work.

140
06:46.500 --> 06:47.300
No problem.

141
06:47.300 --> 06:52.300
So let's bring in mint 10 and that is this machine right here.

142
06:52.300 --> 06:56.200
And let's do a ping to 10.20.0.1.

143
06:56.200 --> 07:00.470
And that is the logical interface address right here for Gateway B and press
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

143
06:56.200 --> 07:00.470
And that is the logical interface address right here for Gateway B and press

144
07:00.470 --> 07:02.200
enter and that is working.

145
07:02.200 --> 07:03.700
No problem whatsoever.

146
07:03.700 --> 07:07.370
However, if we activate this rule by clicking on publish and then try that

147
07:07.370 --> 07:07.900
again.

148
07:07.900 --> 07:11.870
Now is that traffic is trying to be sent that ICMP echo request between 10, 10

149
07:11.870 --> 07:13.100
and 10, 20.

150
07:13.100 --> 07:17.840
Now with this rule currently active, which is running on our gateway A when it

151
07:17.840 --> 07:21.920
sees an echo request source from 10, 10, 0, anything going to 10, 20, 0,

152
07:21.920 --> 07:22.300
anything.

153
07:22.300 --> 07:26.250
It should go ahead and drop it as that traffic is trying to be routed over

154
07:26.250 --> 07:27.000
Gateway A.

155
07:27.000 --> 07:29.100
In fact, let's go ahead and test that.

156
07:29.100 --> 07:32.420
So let's do a quick test before the ping worked and now we'll go ahead and do a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

156
07:29.100 --> 07:32.420
So let's do a quick test before the ping worked and now we'll go ahead and do a

157
07:32.420 --> 07:35.800
ping again and it is failing.

158
07:35.800 --> 07:37.400
So let that run for a second or two.

159
07:37.400 --> 07:42.120
We'll do a control C indicates that six packets were sent and zero responded to

160
07:42.120 --> 07:42.300
.

161
07:42.300 --> 07:44.100
So we have a hundred percent packet loss again.

162
07:44.100 --> 07:45.200
That's because of the rule.

163
07:45.200 --> 07:48.790
So now with this rule in place, we're not able to do an ICMP echo request from

164
07:48.790 --> 07:50.600
10, 10 over to 10, 20.

165
07:50.600 --> 07:53.820
However, if we don't want to mint 20, for example, and we try to do a ping

166
07:53.820 --> 07:58.400
request over to mint 10 because it'd be coming from 10, 20, 0 going to 10, 10,

167
07:58.400 --> 08:00.100
0, that wouldn't match that rule.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

167
07:58.400 --> 08:00.100
0, that wouldn't match that rule.

168
08:00.100 --> 08:01.800
And that traffic flow should be allowed.

169
08:01.800 --> 08:04.900
So let's head over to mint 20 for a moment and just verify that as well.

170
08:04.900 --> 08:07.800
So here is mint 20 right here.

171
08:07.800 --> 08:12.200
This confirm it's IP address with the I have to config or IP address.

172
08:12.200 --> 08:13.200
Either way, it'll be great.

173
08:13.200 --> 08:18.370
So it's IP addresses 10 dot 20 dot 0 dot 153 and let's do a ping over to this

174
08:18.370 --> 08:20.200
interface address right here.

175
08:20.200 --> 08:26.000
On gateway, which is 10 dot 10 dot 0 dot 1 and press enter that works.

176
08:26.000 --> 08:30.130
And we could also ping this little web server here, which is at 10 dot 10 dot 0
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

176
08:26.000 --> 08:30.130
And we could also ping this little web server here, which is at 10 dot 10 dot 0

177
08:30.130 --> 08:31.100
dot 181.

178
08:31.100 --> 08:35.000
So we had the upper key and change that last octet to 181 press enter.

179
08:35.000 --> 08:36.600
That's working great as well.

180
08:36.600 --> 08:39.100
And that's working because we did the initial echo request.

181
08:39.100 --> 08:41.300
There was nothing filtering or denying that traffic.

182
08:41.300 --> 08:43.880
And then when these devices responded back, which is also going through our

183
08:43.880 --> 08:47.700
gateway a that response traffic coming back because it wasn't an ICMP echo

184
08:47.700 --> 08:49.500
request didn't match the rule again.

185
08:49.500 --> 08:51.200
And was allowed by default.

186
08:51.200 --> 08:53.100
We could also verify that with trace flow.

187
08:53.100 --> 08:57.470
So if we go to plan and troubleshoot and click on the left on traffic analysis

188
08:57.470 --> 09:00.300
and then in the trace flow tile here, click on get started.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

188
08:57.470 --> 09:00.300
and then in the trace flow tile here, click on get started.

189
09:00.300 --> 09:04.120
If we want to confirm the ICMP echo request starting over here at mint 10, for

190
09:04.120 --> 09:05.300
example, we can select that.

191
09:05.300 --> 09:07.000
So there's mint 10 on the left.

192
09:07.000 --> 09:10.600
If we scroll down, there's its IP address for the destination.

193
09:10.600 --> 09:12.100
Let's go ahead and choose mint 20.

194
09:12.100 --> 09:15.590
There's its IP address and then we'll scroll down and by default, it's going to

195
09:15.590 --> 09:16.200
be using ICMP.

196
09:16.200 --> 09:19.400
And so the initial packet flow is going to look like an echo request.

197
09:19.400 --> 09:22.600
That's what's going to generate for this trace flow and we'll click on trace.

198
09:22.600 --> 09:25.180
And here in the bottom part where it says observations, let me scroll up a

199
09:25.180 --> 09:26.000
little bit there.

200
09:26.000 --> 09:28.500
If we click on dropped, it'll show us where it was dropped.

201
09:28.500 --> 09:33.900
So it was dropped by firewall rule ID 6122 and it was dropped by edge to.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

201
09:28.500 --> 09:33.900
So it was dropped by firewall rule ID 6122 and it was dropped by edge to.

202
09:33.900 --> 09:37.660
So if we go back to security and on the left, if we go down to our gateway

203
09:37.660 --> 09:41.840
firewall and we look at our gateway firewall on gateway a and we expand the

204
09:41.840 --> 09:43.000
rules, check it out.

205
09:43.000 --> 09:48.700
There's our rule denying ICMP echo request and the rule ID is 6122 exactly what

206
09:48.700 --> 09:51.000
we saw in the results of our trace flow.

207
09:51.000 --> 09:53.900
Also, if we expand this and look at all the traffic here, let me give us a

208
09:53.900 --> 09:54.800
little more room.

209
09:54.800 --> 09:58.200
So here in the traffic flow showing that the traffic started here on ESXIB and

210
09:58.200 --> 10:01.400
that's because mint 10 is being hosted on ESXIB.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

210
09:58.200 --> 10:01.400
that's because mint 10 is being hosted on ESXIB.

211
10:01.400 --> 10:03.900
It went through the logical distributed firewall.

212
10:03.900 --> 10:07.500
There was no rules present in the distributed firewall to stop the traffic.

213
10:07.500 --> 10:12.180
So that traffic logically crossed over segment 10 and then logically got routed

214
10:12.180 --> 10:15.900
to our gateway gateway a and notice it didn't get dropped right here.

215
10:15.900 --> 10:20.350
And that's because ESXIB for that gateway a functionality is using the edge

216
10:20.350 --> 10:21.000
notes.

217
10:21.000 --> 10:25.220
So this is where ESXIB said, you know what, I need to forward it to the active

218
10:25.220 --> 10:29.450
edge node and based on the destination over here, it's centered over to edge to

219
10:29.450 --> 10:32.800
which has the IP address of 4444 for its tunnel endpoint.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

219
10:29.450 --> 10:32.800
which has the IP address of 4444 for its tunnel endpoint.

220
10:32.800 --> 10:37.630
So then edge to receives it and as it's largely being forwarded now by edge to

221
10:37.630 --> 10:42.440
to the gateway firewall, it's matching on the rule rule 6122 and that's so the

222
10:42.440 --> 10:43.600
traffic is being dropped.

223
10:43.600 --> 10:46.670
This is also a great time to point out that because it's a gateway firewall

224
10:46.670 --> 10:50.600
running, for example, this case on gateway a and not a distributed firewall.

225
10:50.600 --> 10:55.280
That's the reason that host B right off the gate didn't deny the traffic

226
10:55.280 --> 10:58.830
because host B does not have a copy of that services router that is being

227
10:58.830 --> 11:01.400
enforced and implemented by the transport nodes,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

227
10:58.830 --> 11:01.400
enforced and implemented by the transport nodes,

228
11:01.400 --> 11:04.400
which allows us to have the gateway firewall here on gateway a.

229
11:04.400 --> 11:08.240
Now, one of the questions might be, well, why did host B send it over to edge

230
11:08.240 --> 11:09.400
to and not edge one?

231
11:09.400 --> 11:13.410
And it's very likely because gateway a is currently being supported with the

232
11:13.410 --> 11:17.340
active role being played here on edge to for gateway a and is being backed up

233
11:17.340 --> 11:19.400
in a standby role here on edge one.

234
11:19.400 --> 11:23.550
So we can also verify that by looking at the topology for gateway a to verify

235
11:23.550 --> 11:26.400
the edge to is the active router for gateway a.

236
11:26.400 --> 11:29.450
So to do that, we'll go to the networking tab on the left, we'll click on

237
11:29.450 --> 11:32.850
network topology and then for gateway a, which is right here, we'll zoom in to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

237
11:29.450 --> 11:32.850
network topology and then for gateway a, which is right here, we'll zoom in to

238
11:32.850 --> 11:33.400
make it bigger.

239
11:33.400 --> 11:37.610
So if we hover over two services, we have gateway firewall rules that are

240
11:37.610 --> 11:40.400
present and we also have DHP services there.

241
11:40.400 --> 11:43.420
So we double click on gateway a, it'll show us the details for the fabric

242
11:43.420 --> 11:44.400
behind the scenes.

243
11:44.400 --> 11:48.360
So here at the bottom is gateway a if we zoom in, there's our tier zero gateway

244
11:48.360 --> 11:53.400
and sure enough, edge to is the active node and edge one is the standby.

245
11:53.400 --> 11:57.320
And that's why I host B said the traffic over to edge to so edge to could make

246
11:57.320 --> 12:01.540
the decision and process the gateway firewall role right here on gateway a and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

246
11:57.320 --> 12:01.540
the decision and process the gateway firewall role right here on gateway a and

247
12:01.540 --> 12:04.400
it's kind of cool because it looks like they're divvying up the

248
12:04.400 --> 12:04.400
responsibilities.

249
12:04.400 --> 12:07.400
So for gateway a edge to is active.

250
12:07.400 --> 12:11.900
And if we scroll up here and take a look at the gateway zero up here on gateway

251
12:11.900 --> 12:14.400
zero, it's edge one that's active.

252
12:14.400 --> 12:17.750
So they're taking different responsibilities based on different gateways and

253
12:17.750 --> 12:19.400
that was just the default behavior.

254
12:19.400 --> 12:22.400
I didn't do anything to influence which one would be active in either case.

255
12:22.400 --> 12:25.500
So let's check our work. We updated our topology verified we had full

256
12:25.500 --> 12:26.400
connectivity.

257
12:26.400 --> 12:31.230
Then we set up a gateway firewall on tier zero, permitting only inbound HTTP
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

257
12:26.400 --> 12:31.230
Then we set up a gateway firewall on tier zero, permitting only inbound HTTP

258
12:31.230 --> 12:33.400
traffic going to this web server.

259
12:33.400 --> 12:37.850
And the next we created right here on gateway a gateway based firewall, which

260
12:37.850 --> 12:41.650
was denying initial ICMP request source from 10 10 if they're trying to go to

261
12:41.650 --> 12:42.400
10 20.

262
12:42.400 --> 12:46.100
Then once we applied that policy and rule here on the gateway a, we then

263
12:46.100 --> 12:51.400
verified that from the client machines and we also verified it with trace flow.