WEBVTT

1
00:00.000 --> 00:03.840
In this video, you and I get to put a specific game plan together for our

2
00:03.840 --> 00:08.670
implementation and verification of the distributed firewall functions inside of

3
00:08.670 --> 00:09.000
NSX.

4
00:09.000 --> 00:12.400
So here's what I propose we do. The first step should probably be to go ahead

5
00:12.400 --> 00:15.500
and implement the VMs we're going to use for our testing.

6
00:15.500 --> 00:20.380
And so for those VMs, we'll create one called VM web, one called VM even a one

7
00:20.380 --> 00:25.580
called VM dash DB, and then we'll create two that are odd, odd, an odd B, and

8
00:25.580 --> 00:27.200
we'll put them on those respective hosts.

9
00:27.200 --> 00:31.570
So these three VMs will be on host A and these three VMs will be on host B and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:27.200 --> 00:31.570
So these three VMs will be on host A and these three VMs will be on host B and

10
00:31.570 --> 00:34.100
the network connections will be as shown.

11
00:34.100 --> 00:38.500
Also, because I currently have DHCP services in place here, we should be able

12
00:38.500 --> 00:40.900
to get an IP address dynamically on all these VMs.

13
00:40.900 --> 00:44.380
However, I think it also be good to go ahead and set up a couple of

14
00:44.380 --> 00:46.900
reservations with DHCP for our servers.

15
00:46.900 --> 00:51.300
So for VM dash web, and that's going to be here on the 10 10 network.

16
00:51.300 --> 00:54.700
So my lab environment that VM is going to be a DHCP client by default.

17
00:54.700 --> 00:59.430
So let's set up a reservation and give it the IP address of 10 dot 10 dot 0 dot

18
00:59.430 --> 01:01.400
10 for VM web right there.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

18
00:59.430 --> 01:01.400
10 for VM web right there.

19
01:01.400 --> 01:06.200
And then for VM dash DB, let's give it the IP address on the 10 20 network.

20
01:06.200 --> 01:12.820
So for that VM VM dash DB, let's give it the IP address of 10 dot 20 dot 0 dot

21
01:12.820 --> 01:13.600
20.

22
01:13.600 --> 01:18.310
That'll also be a great opportunity to demonstrate setting up a reservation

23
01:18.310 --> 01:22.100
inside of NSX for a specific VM based on its layer to address.

24
01:22.100 --> 01:26.710
Then for game plan, next, let's go ahead and create some NSX tags and then we

25
01:26.710 --> 01:29.400
can use those tags for our dynamic group membership.

26
01:29.400 --> 01:34.010
So for our NSX tags, let's create one called web tag and we'll create one
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

26
01:29.400 --> 01:34.010
So for our NSX tags, let's create one called web tag and we'll create one

27
01:34.010 --> 01:38.610
called DB tag and let's create one called even tag and we'll create another one

28
01:38.610 --> 01:39.800
called odd tag.

29
01:39.800 --> 01:41.700
Let's also create one called client tag.

30
01:41.700 --> 01:44.800
So when we create the tags, and then as far as which VMs are going to get

31
01:44.800 --> 01:49.590
assigned, which NSX tags, the web server here VM dash web will associate it

32
01:49.590 --> 01:51.300
with the tag of web dash tag.

33
01:51.300 --> 01:56.170
And then the VMs are going to get the even dash tag that be even a and even B

34
01:56.170 --> 02:00.300
and then the odd tag will assign that to VM odd a and odd B.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

34
01:56.170 --> 02:00.300
and then the odd tag will assign that to VM odd a and odd B.

35
02:00.300 --> 02:03.100
We could also create one called servers tag, etc.

36
02:03.100 --> 02:08.120
And then for the client tag, we'll assign that to all four clients VM even a

37
02:08.120 --> 02:09.600
and B and odd a and B.

38
02:09.600 --> 02:12.810
So the cool thing is that once we have these tags associated, we can then

39
02:12.810 --> 02:16.700
dynamically create groups based on looking for and matching on those tags.

40
02:16.700 --> 02:19.650
So our next step would then be to create the security groups and for this

41
02:19.650 --> 02:21.900
discussion, we're going to do that based on tags.

42
02:21.900 --> 02:26.040
And so for the groups, let's go ahead and create several will create one for

43
02:26.040 --> 02:26.900
the database.

44
02:26.900 --> 02:29.840
We'll call that database group and I'm going to actually put the name group

45
02:29.840 --> 02:32.000
here in these groups and the name tag and the tags.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

45
02:29.840 --> 02:32.000
here in these groups and the name tag and the tags.

46
02:32.000 --> 02:34.800
Now, wait, when we see them in the interface, we'll know exactly what they are.

47
02:34.800 --> 02:39.870
So for the security group called DB dash group, it'll include any VMs that have

48
02:39.870 --> 02:41.100
the tag of DB tag.

49
02:41.100 --> 02:44.100
And so when we create the group, we'll specify that's the criteria.

50
02:44.100 --> 02:47.700
It's also created group for web servers. We'll call that web group.

51
02:47.700 --> 02:51.500
Let's also create a group called odd group and one called even group.

52
02:51.500 --> 02:54.460
So for the odd group, we'll be looking for any VMs that have the odd tag

53
02:54.460 --> 02:55.500
associated with them.

54
02:55.500 --> 03:00.100
And for the even group, we'll look for any VMs that have the tag of even tag.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

54
02:55.500 --> 03:00.100
And for the even group, we'll look for any VMs that have the tag of even tag.

55
03:00.100 --> 03:02.900
And just for fun, let's create one more called client group.

56
03:02.900 --> 03:06.290
And then for the client group, the dynamic membership is going to be based on V

57
03:06.290 --> 03:07.700
Ms that have the client tag.

58
03:07.700 --> 03:11.310
So the concept here with the tags and group membership is that we can associate

59
03:11.310 --> 03:12.900
various tags with VMs.

60
03:12.900 --> 03:16.700
And then based on those tags, include those VMs as part of one or more groups.

61
03:16.700 --> 03:20.370
Now up to this point, we really haven't implemented any specific distributed

62
03:20.370 --> 03:22.300
firewall restrictions or controls

63
03:22.300 --> 03:25.700
because the default policy rule says allow everything.

64
03:25.700 --> 03:29.900
So our last step here would then be to go ahead and use the security groups as

65
03:29.900 --> 03:32.300
part of a distributed firewall policy.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

65
03:29.900 --> 03:32.300
part of a distributed firewall policy.

66
03:32.300 --> 03:37.600
So as our last step here, we'll add DFW for distributed firewall policies and

67
03:37.600 --> 03:38.100
rules.

68
03:38.100 --> 03:41.500
And the way the policies and rules work, we create a policy, for example,

69
03:41.500 --> 03:45.240
right here, we'll call it policy C. And then we need that policy, we're going

70
03:45.240 --> 03:46.500
to go ahead and have dot one,

71
03:46.500 --> 03:49.300
dot two, dot three, and these represent rules.

72
03:49.300 --> 03:53.300
So here'd be our policy. And inside the policy, we have individual rules.

73
03:53.300 --> 03:56.940
So instead of a category, those will be processed from top to bottom looking

74
03:56.940 --> 03:57.500
for a match.

75
03:57.500 --> 04:00.700
And once there's a match, it's then going to go ahead and execute the action
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

75
03:57.500 --> 04:00.700
And once there's a match, it's then going to go ahead and execute the action

76
04:00.700 --> 04:04.100
for that, whether it's drop or reject or allow.

77
04:04.100 --> 04:07.990
So far, a game plan will create some policies and rules that are doing matching

78
04:07.990 --> 04:09.100
based on the groups.

79
04:09.100 --> 04:13.300
And then verify we get the expected results here inside of the NSX environment.

80
04:13.300 --> 04:16.110
We can also test that a couple of different ways by initiating those traffic

81
04:16.110 --> 04:18.300
flows that were either permitting or denying.

82
04:18.300 --> 04:23.170
We can also use trace flow to verify whether or not that traffic would make it

83
04:23.170 --> 04:25.500
and if it's dropping or rejecting that traffic,

84
04:25.500 --> 04:29.300
we can also see which device inside of NSX is doing it.

85
04:29.300 --> 04:32.680
And again, just like routing decisions are made as close to the source as
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

85
04:29.300 --> 04:32.680
And again, just like routing decisions are made as close to the source as

86
04:32.680 --> 04:33.300
possible,

87
04:33.300 --> 04:36.820
the implementation of our distributed firewall rules are also implemented as

88
04:36.820 --> 04:38.700
close to the source as possible.

89
04:38.700 --> 04:42.030
So is this machine right here that's trying to access some other resource in

90
04:42.030 --> 04:42.700
the network?

91
04:42.700 --> 04:46.150
And there's a distributed firewall policy rule that says, hey, that is not

92
04:46.150 --> 04:46.900
allowed.

93
04:46.900 --> 04:51.500
It's ESXIA, who's hosting that VM that has a copy of that distributed firewall

94
04:51.500 --> 04:53.900
that's going to be dropping and denying that traffic

95
04:53.900 --> 04:56.100
and not forwarding it out to the external network.

96
04:56.100 --> 05:00.090
So with that game plan in place in our very next video, let's go ahead and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

96
04:56.100 --> 05:00.090
So with that game plan in place in our very next video, let's go ahead and

97
05:00.090 --> 05:03.100
deploy these five VMs that we're going to use

98
05:03.100 --> 05:06.100
for testing and verification of the distributed firewall.

99
05:06.100 --> 05:08.260
I'll see you in the next video in just a moment.