WEBVTT

1
00:00.000 --> 00:03.680
In this video, let's take a big picture look at the world of network address

2
00:03.680 --> 00:04.140
translation

3
00:04.140 --> 00:06.060
or as its friends call it, "NAT."

4
00:06.060 --> 00:09.320
There's also a subset of that that's often referred to as "PAT," and we'll talk

5
00:09.320 --> 00:09.600
about

6
00:09.600 --> 00:11.300
all of that right now.

7
00:11.300 --> 00:15.160
So why in the world do we need to do network address translation of any type?

8
00:15.160 --> 00:18.450
Well, let's start off with a very common scenario, and that is we have a VM,

9
00:18.450 --> 00:19.240
for example, right

10
00:19.240 --> 00:23.930
here on the 10100 network that wants to access a server out here on the

11
00:23.930 --> 00:24.740
internet.

12
00:24.740 --> 00:27.790
Maybe it's a Google DNS server or something else that's out on the public

13
00:27.790 --> 00:28.440
internet.

14
00:28.440 --> 00:31.020
So this client, and forwarding to that destination address, would forward it to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

14
00:28.440 --> 00:31.020
So this client, and forwarding to that destination address, would forward it to

15
00:31.020 --> 00:32.520
its default gateway,

16
00:32.520 --> 00:36.200
and then this gateway would make a decision to forward it up to this gateway,

17
00:36.200 --> 00:37.200
and so forth,

18
00:37.200 --> 00:40.800
and so on until it goes to all the layer three routing devices and finally

19
00:40.800 --> 00:42.080
reaches the server.

20
00:42.080 --> 00:43.080
So that's the goal.

21
00:43.080 --> 00:47.860
However, if we are setting a packet from this VM and its source IP address, let

22
00:47.860 --> 00:48.200
me go ahead

23
00:48.200 --> 00:50.720
and put the source address right here in yellow.

24
00:50.720 --> 00:54.790
So I'll say the source address of the IP packet here from VM1, the source would

25
00:54.790 --> 00:58.120
be 10.10.0.10.

26
00:58.120 --> 01:02.740
And this IP address starting with 10 is in the RFC 1918 list of private RFC
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

26
00:58.120 --> 01:02.740
And this IP address starting with 10 is in the RFC 1918 list of private RFC

27
01:02.740 --> 01:04.360
1918 addresses.

28
01:04.360 --> 01:05.800
So the question might be, so what?

29
01:05.800 --> 01:09.010
Well, if we try to forward a packet out and send out through an internet

30
01:09.010 --> 01:10.120
service provider,

31
01:10.120 --> 01:13.140
when they see a source address like this in the 10 address space, they're going

32
01:13.140 --> 01:13.600
to drop

33
01:13.600 --> 01:15.000
it right there.

34
01:15.000 --> 01:18.170
Or let's imagine that they didn't drop it and that packet gets forwarded all

35
01:18.170 --> 01:18.560
the way

36
01:18.560 --> 01:23.360
to this DNS server here at 8888, and it tries to respond back to the 10 network

37
01:23.360 --> 01:23.480
.

38
01:23.480 --> 01:25.860
This server is not going to be able to respond back to the 10 address and have

39
01:25.860 --> 01:26.400
it reach all

40
01:26.400 --> 01:27.720
the way back to this VM.

41
01:27.720 --> 01:31.670
Because again, the 10 address space is a private RFC 1918 address space, and it
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

41
01:27.720 --> 01:31.670
Because again, the 10 address space is a private RFC 1918 address space, and it

42
01:31.670 --> 01:32.560
's not a reachable

43
01:32.560 --> 01:35.120
or routable address on the public internet.

44
01:35.120 --> 01:36.640
So how do we solve that problem?

45
01:36.640 --> 01:38.460
And the answer is we lie.

46
01:38.460 --> 01:42.520
We take this source IP address of 10, 10, 0, 10 that the client's using.

47
01:42.520 --> 01:45.900
And at some point, before we forward it out to our service provider, we swap it

48
01:45.900 --> 01:46.320
out.

49
01:46.320 --> 01:48.400
So let's say we swap it out with these source address.

50
01:48.400 --> 01:51.720
I'll put this in blue to represent a globally routable address.

51
01:51.720 --> 01:57.820
Let's say we swap out this address 10, 10, 0, 10, and we swap it out for 23.1.2

52
01:57.820 --> 01:58.720
.254.

53
01:58.720 --> 02:01.560
So that would also presume by the way that this IP address that we're going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

53
01:58.720 --> 02:01.560
So that would also presume by the way that this IP address that we're going to

54
02:01.560 --> 02:02.040
swap it out

55
02:02.040 --> 02:05.520
with is reachable at our enterprise.

56
02:05.520 --> 02:09.230
So that way when the server gets that request, as he's it came from 2312.254,

57
02:09.230 --> 02:09.720
it can make

58
02:09.720 --> 02:13.770
you route any decision that the internet believes will lead back to one of our

59
02:13.770 --> 02:14.160
routers right

60
02:14.160 --> 02:15.160
here.

61
02:15.160 --> 02:17.520
So here I'm going to call this the pre-net address.

62
02:17.520 --> 02:20.240
And up here, I'll able this as the post-net address.

63
02:20.240 --> 02:23.340
And if we implemented the network address translation right here, this would be

64
02:23.340 --> 02:24.440
our NAT device,

65
02:24.440 --> 02:26.440
the device doing the address translation.

66
02:26.440 --> 02:30.530
And on that initial flow of traffic, when this device right here, tier zero,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

66
02:26.440 --> 02:30.530
And on that initial flow of traffic, when this device right here, tier zero,

67
02:30.530 --> 02:30.840
did that

68
02:30.840 --> 02:34.980
translation because it's swapping out the source address on that initial flow

69
02:34.980 --> 02:35.320
as it goes

70
02:35.320 --> 02:40.520
out to the internet that has a special name and that is source NAT.

71
02:40.520 --> 02:43.360
Or it can be abbreviated as S NAT.

72
02:43.360 --> 02:45.780
Now when we're implementing source NAT, one of those common ways of

73
02:45.780 --> 02:46.480
implementing that

74
02:46.480 --> 02:49.940
on this gateway here is to make it stateful, meaning it's going to remember

75
02:49.940 --> 02:51.000
that translation.

76
02:51.000 --> 02:55.040
And that's also important because when this DNS server responds back to that

77
02:55.040 --> 02:57.720
address 2312.254,

78
02:57.720 --> 03:01.010
this NAT device here, in our case, it's gateway zero, the one that did the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

78
02:57.720 --> 03:01.010
this NAT device here, in our case, it's gateway zero, the one that did the

79
03:01.010 --> 03:02.040
initial translation

80
03:02.040 --> 03:06.190
is also going to do the untranslation and swap out the address it used

81
03:06.190 --> 03:07.200
previously, put

82
03:07.200 --> 03:11.930
back on the real IP address of this VM before it forwards that back down to the

83
03:11.930 --> 03:12.400
VM.

84
03:12.400 --> 03:15.560
So you could say that this NAT device right here is doing translation on the

85
03:15.560 --> 03:16.280
initial flow

86
03:16.280 --> 03:19.480
and untranslation on the return packet.

87
03:19.480 --> 03:23.630
However, it's called source NAT because the initial translation was done on the

88
03:23.630 --> 03:24.160
initial

89
03:24.160 --> 03:27.840
flow traffic, in this case coming from the client, going up to the server.

90
03:27.840 --> 03:30.030
Now another really interesting option we have in the world of address
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

90
03:27.840 --> 03:30.030
Now another really interesting option we have in the world of address

91
03:30.030 --> 03:31.240
translation is called

92
03:31.240 --> 03:33.320
destination NAT.

93
03:33.320 --> 03:35.880
Or as his friends call it, D NAT for short.

94
03:35.880 --> 03:37.840
And let's talk about what that means as well.

95
03:37.840 --> 03:40.650
So let me go ahead and clear up a little bit of my scribbles over here on the

96
03:40.650 --> 03:41.220
right.

97
03:41.220 --> 03:42.220
That looks better.

98
03:42.220 --> 03:45.870
Also, before we draw in when we would use this, let me also give you a spoiler

99
03:45.870 --> 03:47.040
alert that says,

100
03:47.040 --> 03:50.490
you know what, if source NAT is translating the source IP address on the

101
03:50.490 --> 03:51.400
initial flow of

102
03:51.400 --> 03:56.040
traffic going through the gateway, then destination NAT is translating the

103
03:56.040 --> 03:57.200
destination address,

104
03:57.200 --> 04:00.240
again, on that initial flow of traffic through the gateway.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

104
03:57.200 --> 04:00.240
again, on that initial flow of traffic through the gateway.

105
04:00.240 --> 04:01.760
So when exactly would we need this?

106
04:01.760 --> 04:05.620
Let's imagine that we have a server that we're hosting and I'm going to put

107
04:05.620 --> 04:06.240
right here

108
04:06.240 --> 04:07.320
on segment 10.

109
04:07.320 --> 04:08.800
So this is our server.

110
04:08.800 --> 04:12.200
Let's imagine our servers right here at dot 17.

111
04:12.200 --> 04:14.500
So it's at 10, 10, 0, 17.

112
04:14.500 --> 04:17.690
And we want somebody on the public internet, for example, or an external

113
04:17.690 --> 04:18.340
network to be

114
04:18.340 --> 04:20.140
able to reach that IP address.

115
04:20.140 --> 04:23.180
So I'll go ahead and draw here a little device.

116
04:23.180 --> 04:24.380
I'll call this a client.

117
04:24.380 --> 04:27.760
So clients are most of the time going to be using DNS to resolve a name to an

118
04:27.760 --> 04:28.540
IP address.

119
04:28.540 --> 04:32.760
However, this IP address of our server here at 10, 10, 0, 17 is not reachable
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

119
04:28.540 --> 04:32.760
However, this IP address of our server here at 10, 10, 0, 17 is not reachable

120
04:32.760 --> 04:33.300
over the

121
04:33.300 --> 04:34.300
public internet.

122
04:34.300 --> 04:39.350
So we need to have a publicly reachable address that we can map to this private

123
04:39.350 --> 04:40.500
RFC 19 address

124
04:40.500 --> 04:41.980
that the server is actually using.

125
04:41.980 --> 04:42.980
So here's what we could do.

126
04:42.980 --> 04:45.720
We could get a nice address that's reachable that's been assigned to us that we

127
04:45.720 --> 04:46.240
can use.

128
04:46.240 --> 04:49.240
Let's use 23 dot 1 dot 2 dot.

129
04:49.240 --> 04:51.340
And I'm going to use the last octet the same 17.

130
04:51.340 --> 04:54.890
Let's imagine that's the globally routable address on the internet that we want

131
04:54.890 --> 04:55.260
to map

132
04:55.260 --> 04:58.520
to this server on a private network right here.

133
04:58.520 --> 05:00.240
So what we do is we'd pick a device to do it.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

133
04:58.520 --> 05:00.240
So what we do is we'd pick a device to do it.

134
05:00.240 --> 05:04.240
It could be this external router or it could be this gateway as part of NSX.

135
05:04.240 --> 05:07.600
And we say that we want to go ahead and do network address translation.

136
05:07.600 --> 05:08.680
And this will be our net device.

137
05:08.680 --> 05:12.850
Specifically this time, the initial flow of traffic is going to be from clients

138
05:12.850 --> 05:13.040
coming

139
05:13.040 --> 05:16.560
into our network and down to that server going in this direction.

140
05:16.560 --> 05:21.530
And so if a client tries to reach this IP address 23 12 17, we want our net

141
05:21.530 --> 05:22.200
device to

142
05:22.200 --> 05:24.560
swap out that destination address.

143
05:24.560 --> 05:28.340
Hence the term destination at on that initial flow of traffic and swap it out

144
05:28.340 --> 05:29.080
for this address

145
05:29.080 --> 05:30.080
right here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

145
05:29.080 --> 05:30.080
right here.

146
05:30.080 --> 05:34.120
So that's going to be mapped to 10 dot 10 dot 0 dot 17.

147
05:34.120 --> 05:37.640
At which point after swapping out the destination address, it was continued for

148
05:37.640 --> 05:38.440
the packet down

149
05:38.440 --> 05:40.240
to that server who would receive it.

150
05:40.240 --> 05:43.120
And then it would look like from the server perspective that it came from that

151
05:43.120 --> 05:43.480
client

152
05:43.480 --> 05:44.480
on the internet.

153
05:44.480 --> 05:46.760
Then if it was going to respond back, it would respond back.

154
05:46.760 --> 05:49.690
And then as the traffic goes through that net device again, once again, it's

155
05:49.690 --> 05:50.040
going to

156
05:50.040 --> 05:54.400
do an untranslation as it untranslates and continues to forward the packet.

157
05:54.400 --> 05:57.650
So the key takeaway here is that on the initial flow of traffic, what are we

158
05:57.650 --> 05:58.480
swapping out?

159
05:58.480 --> 06:01.480
The source address, which would be source net or on that initial flow of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

159
05:58.480 --> 06:01.480
The source address, which would be source net or on that initial flow of

160
06:01.480 --> 06:02.000
traffic.

161
06:02.000 --> 06:05.280
Are we swapping out the destination address, which would be destination net?

162
06:05.280 --> 06:06.960
And that's what those two terms mean.

163
06:06.960 --> 06:10.680
Now in the event that we are doing a one to one mapping, for example, we're

164
06:10.680 --> 06:11.400
mapping this

165
06:11.400 --> 06:15.870
VM right here to a specific address out on the public internet and it gets to

166
06:15.870 --> 06:16.320
use that

167
06:16.320 --> 06:17.640
single IP address by itself.

168
06:17.640 --> 06:20.710
And then we take this VM right here and we map it to get a different publicly

169
06:20.710 --> 06:21.200
readable

170
06:21.200 --> 06:24.240
address and that's referred to as a one to one mapping.

171
06:24.240 --> 06:27.080
So one address on the inside gets mapped to one address on the outside.

172
06:27.080 --> 06:30.070
For in the case of destination net, one address on the outside gets mapped to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

172
06:27.080 --> 06:30.070
For in the case of destination net, one address on the outside gets mapped to

173
06:30.070 --> 06:30.640
one address

174
06:30.640 --> 06:33.290
on the inside and a different address on the outside, but you map to a

175
06:33.290 --> 06:34.160
different address

176
06:34.160 --> 06:35.160
on the inside.

177
06:35.160 --> 06:37.870
And again, either way, that's referred to as one to one mapping between

178
06:37.870 --> 06:39.280
internal and externally

179
06:39.280 --> 06:40.280
routable addresses.

180
06:40.280 --> 06:44.910
However, there's also the concept of many to one and we've been using this for

181
06:44.910 --> 06:45.440
decades

182
06:45.440 --> 06:48.890
and that's the only reason, by the way, that we haven't run out of IPV for

183
06:48.890 --> 06:49.640
addresses is

184
06:49.640 --> 06:55.310
because we can actually take dozens or hundreds or thousands of internal

185
06:55.310 --> 06:56.680
clients that are

186
06:56.680 --> 07:00.960
using private RFC 19, 18 addresses like the 10 address base and once they do 16
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

186
06:56.680 --> 07:00.960
using private RFC 19, 18 addresses like the 10 address base and once they do 16

187
07:00.960 --> 07:01.440
through

188
07:01.440 --> 07:05.360
31 and so forth and we can map them to a single address before they go out to

189
07:05.360 --> 07:06.200
the internet

190
07:06.200 --> 07:07.520
using source net.

191
07:07.520 --> 07:08.520
So here's an example of that.

192
07:08.520 --> 07:12.320
Let's say we have a publicly readable address of 23.1.2.

193
07:12.320 --> 07:13.320
Are you something different?

194
07:13.320 --> 07:16.850
Let's use 151 as the address that we have that's associated with our

195
07:16.850 --> 07:17.840
organization from

196
07:17.840 --> 07:18.960
an internet perspective.

197
07:18.960 --> 07:22.740
So the entire internet knows that when these are forward packets to this IP

198
07:22.740 --> 07:23.360
address, they're

199
07:23.360 --> 07:25.120
going to forward it back to us.

200
07:25.120 --> 07:27.970
And then we can specify on our net device that we want to go ahead and do

201
07:27.970 --> 07:28.680
source address

202
07:28.680 --> 07:33.670
translation for any clients coming from 10.10 from that address base or from
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

202
07:28.680 --> 07:33.670
translation for any clients coming from 10.10 from that address base or from

203
07:33.670 --> 07:35.000
the 10.20 address

204
07:35.000 --> 07:39.400
base or for that matter, we could also just say 10 anything like that as a rule

205
07:39.400 --> 07:39.880
for our

206
07:39.880 --> 07:43.960
network address translation and then any traffic that is coming through the

207
07:43.960 --> 07:44.680
gateway that's

208
07:44.680 --> 07:49.080
coming from 10 anything in this case with just this rule alone, we could map

209
07:49.080 --> 07:49.440
that to

210
07:49.440 --> 07:52.160
this specific globally readable address.

211
07:52.160 --> 07:56.010
And so when you have that done for multiple inside devices mapping to a single

212
07:56.010 --> 07:56.520
outside

213
07:56.520 --> 08:00.410
address, that's referred to as PAP port address translation because the way the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

213
07:56.520 --> 08:00.410
address, that's referred to as PAP port address translation because the way the

214
08:00.410 --> 08:00.840
gateways

215
08:00.840 --> 08:04.110
keeping track of those differences and the different sessions is by

216
08:04.110 --> 08:05.040
manipulating and

217
08:05.040 --> 08:07.560
modifying the port information layer four.

218
08:07.560 --> 08:11.800
Now it's also interesting to note that not every protocol we use has a port

219
08:11.800 --> 08:12.360
number at

220
08:12.360 --> 08:13.360
layer four.

221
08:13.360 --> 08:18.030
For example, UDP and TCP do, but we have other protocols as well at layer four

222
08:18.030 --> 08:18.080
that

223
08:18.080 --> 08:19.240
don't have ports.

224
08:19.240 --> 08:23.260
However, to make long story short, when we're using the mini one mapping, the

225
08:23.260 --> 08:23.760
gateway is

226
08:23.760 --> 08:27.600
responsible for the tracking and managing of those sessions.

227
08:27.600 --> 08:30.840
So that way when this VM goes up to the internet and gets a response back, it's
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

227
08:27.600 --> 08:30.840
So that way when this VM goes up to the internet and gets a response back, it's

228
08:30.840 --> 08:31.200
coming back

229
08:31.200 --> 08:32.200
to the right device.

230
08:32.200 --> 08:34.780
And when this device right here via one goes up to the internet and response

231
08:34.780 --> 08:35.720
comes back,

232
08:35.720 --> 08:36.880
it comes to the right device.

233
08:36.880 --> 08:39.690
So a source net, which is typically used in this situation like this with

234
08:39.690 --> 08:40.200
clients going

235
08:40.200 --> 08:43.450
out to the internet on that initial flow of traffic, we're swapping out these

236
08:43.450 --> 08:44.160
source private

237
08:44.160 --> 08:46.600
addresses with a globally readable dress.

238
08:46.600 --> 08:49.450
And then when the response comes back, we're doing the untranslation and

239
08:49.450 --> 08:50.760
continuing forwarding

240
08:50.760 --> 08:51.840
down to our clients.

241
08:51.840 --> 08:54.300
It's also important to be aware that anytime we start implementing these

242
08:54.300 --> 08:55.240
network services,

243
08:55.240 --> 08:59.330
including network address translation, we're now invoking a services router

244
08:59.330 --> 09:00.000
function, which
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

245
09:00.000 --> 09:02.840
is going to be implemented on one of our edge notes.

246
09:02.840 --> 09:05.050
And depending on how we want to set up, we could set up our network address

247
09:05.050 --> 09:05.520
translation

248
09:05.520 --> 09:09.320
here at tier zero, which already has a services router from the function of

249
09:09.320 --> 09:10.120
connecting to

250
09:10.120 --> 09:11.360
the external world.

251
09:11.360 --> 09:15.550
And we could also add the services router function here on our tier one gate

252
09:15.550 --> 09:16.120
ways.

253
09:16.120 --> 09:19.580
And as part of that implement that here, if we want to as well, most of the

254
09:19.580 --> 09:20.040
time we're

255
09:20.040 --> 09:23.120
going to be doing our net though, right here at the edge before it goes out to

256
09:23.120 --> 09:23.560
the public

257
09:23.560 --> 09:24.960
or external network.

258
09:24.960 --> 09:28.680
Also another concept regarding that that's important to be aware of is static

259
09:28.680 --> 09:29.960
versus dynamic.

260
09:29.960 --> 09:33.630
With a static translation, we tell the gateway, hey, this translation between
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

260
09:29.960 --> 09:33.630
With a static translation, we tell the gateway, hey, this translation between

261
09:33.630 --> 09:34.040
this address

262
09:34.040 --> 09:37.160
on the inside and this address on the outside should always be in place.

263
09:37.160 --> 09:39.000
It's like a hard coded rule.

264
09:39.000 --> 09:42.690
And the concept of dynamic simply says like a rule that says, hey, if traffic

265
09:42.690 --> 09:43.160
shows up

266
09:43.160 --> 09:46.810
from these subnets, for example, and it's going out to the internet, go ahead

267
09:46.810 --> 09:47.280
and swap

268
09:47.280 --> 09:50.440
it to either this IP address or a range of IP addresses.

269
09:50.440 --> 09:54.450
However, the actual translation isn't created on the net device until that

270
09:54.450 --> 09:55.160
traffic shows

271
09:55.160 --> 09:56.160
up.

272
09:56.160 --> 09:59.830
So that's the concept of static hard coded versus dynamic, just waiting for the

273
09:59.830 --> 10:00.240
traffic
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

273
09:59.830 --> 10:00.240
traffic

274
10:00.240 --> 10:04.160
to show up so it can dynamically on the fly create those translations.

275
10:04.160 --> 10:07.880
So if we are using active standby for the implementation of our gateways, we

276
10:07.880 --> 10:08.280
can set

277
10:08.280 --> 10:11.680
up source net and we can use destination at when needed.

278
10:11.680 --> 10:14.790
Again, D net would be when we have an internal resource that needs to be

279
10:14.790 --> 10:15.360
reached from an

280
10:15.360 --> 10:18.780
external network and source net would be for clients on the inside on their

281
10:18.780 --> 10:19.560
initial flows

282
10:19.560 --> 10:20.560
going out.

283
10:20.560 --> 10:24.060
However, if we are using active active as opposed to active standby, which

284
10:24.060 --> 10:24.560
means that

285
10:24.560 --> 10:28.420
both routers, both gateways, both edge nodes are participating in the actual

286
10:28.420 --> 10:29.040
flow of the

287
10:29.040 --> 10:30.040
data plane.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

287
10:29.040 --> 10:30.040
data plane.

288
10:30.040 --> 10:33.520
At that point, we have yet another option in the world, VMware's NSX for

289
10:33.520 --> 10:34.440
network address

290
10:34.440 --> 10:35.440
translation.

291
10:35.440 --> 10:36.440
And that is called reflexive.

292
10:36.440 --> 10:39.690
And when we choose the option of reflexive, we have our rules in place

293
10:39.690 --> 10:40.480
regarding what

294
10:40.480 --> 10:44.500
can be translated to what however, the actual firewall isn't going to maintain

295
10:44.500 --> 10:44.960
states.

296
10:44.960 --> 10:48.760
That can maintain a net table with all those translations.

297
10:48.760 --> 10:51.880
And that's because either of the gateways, edge one or edge two, because they

298
10:51.880 --> 10:52.360
both could

299
10:52.360 --> 10:53.360
be active.

300
10:53.360 --> 10:56.800
Either one needs to be able to process that translation.

301
10:56.800 --> 11:00.000
So in an active standby scenario, the one active gateway could maintain all
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

302
11:00.000 --> 11:00.480
that state

303
11:00.480 --> 11:01.480
information.

304
11:01.480 --> 11:05.280
However, with active active, we need to be prepared that either of the edges,

305
11:05.280 --> 11:05.440
when there's

306
11:05.440 --> 11:08.680
packets coming in or going out, either of the edges could be involved in that

307
11:08.680 --> 11:09.120
traffic

308
11:09.120 --> 11:10.120
flow.

309
11:10.120 --> 11:13.390
And so reflexive is more like a set of hard coded rules that are in place that

310
11:13.390 --> 11:13.680
can be

311
11:13.680 --> 11:14.680
enforced.

312
11:14.680 --> 11:18.650
However, the firewall's effective and reflexive net are not going to maintain

313
11:18.650 --> 11:19.040
individual

314
11:19.040 --> 11:21.720
state information regarding those translations.

315
11:21.720 --> 11:25.740
Another option that's available in the world of NSX regarding net is no,

316
11:25.740 --> 11:26.800
meaning no source

317
11:26.800 --> 11:28.680
net or no destination net.

318
11:28.680 --> 11:31.970
And the reason for that is because these net rules are going to be in a list
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

318
11:28.680 --> 11:31.970
And the reason for that is because these net rules are going to be in a list

319
11:31.970 --> 11:32.640
and they're

320
11:32.640 --> 11:34.200
processed from top to bottom.

321
11:34.200 --> 11:38.160
So if we have, for example, we want to do address translation for everybody in

322
11:38.160 --> 11:39.160
a subnet,

323
11:39.160 --> 11:43.160
except for one VM, we can make a rule for one VM saying no source net based on

324
11:43.160 --> 11:43.520
that

325
11:43.520 --> 11:46.400
source IP address that we don't want to do translation for.

326
11:46.400 --> 11:47.960
And that way we can do exceptions.

327
11:47.960 --> 11:52.360
So there's no SNAT and no D net that we can use as part of our rules.

328
11:52.360 --> 11:57.630
There also is a net option for NAT 64, which we will be covering in a separate

329
11:57.630 --> 11:58.280
skill as

330
11:58.280 --> 12:00.160
we dive into IPV six.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

330
11:58.280 --> 12:00.160
we dive into IPV six.

331
12:00.160 --> 12:04.840
So for now, we're just going to focus on IPV four and these options with net.

332
12:04.840 --> 12:09.240
So with this overview in mind regarding some of our options regarding address

333
12:09.240 --> 12:10.280
translation,

334
12:10.280 --> 12:14.310
in the next video, let's put a specific game plan together regarding what we

335
12:14.310 --> 12:15.400
want to implement

336
12:15.400 --> 12:19.290
and then we'll follow that plan to configure and verify both source and

337
12:19.290 --> 12:20.720
destination at in

338
12:20.720 --> 12:21.720
our topology.

339
12:21.720 --> 12:24.320
So I'll see you in the next video for that game plan.