WEBVTT

00:00:01.340 --> 00:00:02.050
In this demo,

00:00:02.050 --> 00:00:06.260
you will learn how to set up a VyOS platform to enforce

00:00:06.270 --> 00:00:11.000
segmentation and segregation by means of VRF.

00:00:11.000 --> 00:00:13.060
In the following,

00:00:13.060 --> 00:00:17.570
you can see a functional diagram of the scenario we are going to target.

00:00:17.580 --> 00:00:22.580
We have three different subnets, each one dedicated to group of endpoint,

00:00:22.580 --> 00:00:25.680
namely, user, application, and databases.

00:00:25.680 --> 00:00:31.430
The three subnets are terminated with three separate interfaces of VyOS router,

00:00:31.430 --> 00:00:33.750
which plays the role of a gateway.

00:00:34.140 --> 00:00:38.090
Please note that each subnet is associated to a different VRF,

00:00:38.090 --> 00:00:42.070
named after three colors: purple, blue, and green.

00:00:42.080 --> 00:00:45.790
Please note that I have detailed here the interface naming and

00:00:45.790 --> 00:00:49.290
the IP addressing schema of VyOS interfaces.

00:00:49.290 --> 00:00:52.380
As in the previous demo, we have Ethernet 0,

00:00:52.380 --> 00:00:55.150
which is our uplink towards the internet.

00:00:55.440 --> 00:00:55.960
And finally,

00:00:55.960 --> 00:00:59.530
we have a table representing the security policy we need

00:00:59.530 --> 00:01:02.250
to deploy over our test infrastructure.

00:01:02.740 --> 00:01:05.280
Again, please note that for the sake of clarity,

00:01:05.280 --> 00:01:09.850
you have also all details of endpoint IP addressing schema.

00:01:11.940 --> 00:01:15.560
In this slide, we have details of how the lab is built.

00:01:15.740 --> 00:01:21.250
We have VMWare workstation, which hosts Ubuntu virtual machine, and a

00:01:21.250 --> 00:01:26.240
VyOS router, and we have eth0 as uplink interface, and this part is

00:01:26.240 --> 00:01:29.030
really identical to our previous demo.

00:01:29.140 --> 00:01:33.370
Then we have a container playing the role of user endpoint, which is attached

00:01:33.370 --> 00:01:39.810
to VyOS eth1 interface by means of dedicated vmnet0 network.

00:01:39.820 --> 00:01:43.170
Then we have another container playing the role of application

00:01:43.170 --> 00:01:48.910
endpoint, which is attached to VyOS eth2 interface by means of

00:01:48.910 --> 00:01:53.130
dedicated vmnet2 network. And then we have a container playing the

00:01:53.130 --> 00:01:58.970
role of database endpoint, which is attached to VyOS eth3 interface by

00:01:58.970 --> 00:02:02.410
means of dedicated vmnet3 network.

00:02:02.520 --> 00:02:05.970
Please note that if you run this demo on your laptop, virtual machine

00:02:05.970 --> 00:02:10.289
interface naming can be different. And now it's time to cast some

00:02:10.289 --> 00:02:15.350
configurations by means of VyOS API calls and Python scripts.

00:02:19.040 --> 00:02:24.090
We have three scripts, which together ensure proper configuration of a

00:02:24.090 --> 00:02:31.820
VyOS router in this scenario. The first script is create_vrf. This is a

00:02:31.820 --> 00:02:35.790
very simple script, which creates three virtual routing forwarding

00:02:35.790 --> 00:02:41.950
instances named purple, blue, and green, and associates them to a

00:02:41.950 --> 00:02:44.950
dedicated instance of VyOS routing table.

00:02:45.940 --> 00:02:50.190
We run the script, and we receive back success as a response.

00:02:51.040 --> 00:02:56.860
The second script is named configure_interfaces. Proper IP addressing is

00:02:56.860 --> 00:03:03.860
provided to interfaces Ethernet 1, 2, and 3. In case you need, I suggest to

00:03:03.860 --> 00:03:08.900
refresh IP addressing schema and interface naming by going back to the

00:03:08.900 --> 00:03:11.150
diagram at the beginning of this module.

00:03:12.140 --> 00:03:18.350
Also, three interfaces are associated to the three VRFs: purple, blue, and green.

00:03:20.940 --> 00:03:26.180
We run this script, and we receive back success as a response.

00:03:26.180 --> 00:03:32.510
At this point, each subnet sits in a dedicated VRF with no

00:03:32.520 --> 00:03:35.560
cross‑talk possibility, but as you know,

00:03:35.940 --> 00:03:39.100
we need to allow certain numbers of data flows between

00:03:39.100 --> 00:03:43.310
endpoint groups. And here comes the final script, which

00:03:43.310 --> 00:03:45.660
does the magic: route leaking.

00:03:46.340 --> 00:03:48.710
Let me provide a detailed description.

00:03:48.720 --> 00:03:53.080
First line creates a static route entry in purple VRF routing

00:03:53.080 --> 00:04:01.170
tables, which says that subnet 172.16.2.0/24, which is the subnet of

00:04:01.180 --> 00:04:06.950
application, can be found by means of gateway, which is 172.16.2.2,

00:04:06.950 --> 00:04:10.630
which belongs to the blue VRF.

00:04:10.860 --> 00:04:15.780
Second line represents the route back; a static route entry is created in

00:04:15.780 --> 00:04:24.220
the blue VRF, which says that subnet 172.16.1.0/24 can be found by means

00:04:24.220 --> 00:04:31.720
of a gateway, which is 172.16.1.2, which belongs to the purple VRF. These

00:04:31.720 --> 00:04:36.290
two lines together allow packets to go back and forth, thus enabling

00:04:36.300 --> 00:04:42.620
cross‑VRF leaking between blue and purple VRFs. The next couple of

00:04:42.620 --> 00:04:47.000
statements work in the very same way, but the only difference that gateway

00:04:47.220 --> 00:04:55.400
for internet destination is 192.168.1.1, which resides in default VRF.

00:04:55.400 --> 00:05:02.690
Default VRF means that eth0 interface was not associated with any VRF. And

00:05:02.690 --> 00:05:08.130
finally, the last statements install route in VRFs blue and green to allow

00:05:08.130 --> 00:05:11.660
communication between databases and applications.

00:05:12.040 --> 00:05:15.380
Please note that neither application nor databases have

00:05:15.380 --> 00:05:17.560
been provided with default route,

00:05:17.790 --> 00:05:23.370
thus preventing communication with public internet. We run this

00:05:23.370 --> 00:05:26.850
script, and we receive back success as a response.

00:05:28.340 --> 00:05:33.800
The next part is endpoint configuration hosted on Ubuntu virtual machine.

00:05:33.800 --> 00:05:38.840
We created three Docker networks with specific IP addressing schema; each

00:05:38.840 --> 00:05:44.110
network is in ipvlan mode, and each network is bound to a dedicated

00:05:44.110 --> 00:05:47.620
interface, according to our network diagram.

00:05:47.810 --> 00:05:48.380
Finally,

00:05:48.380 --> 00:05:51.630
we created three Docker containers playing the role of

00:05:51.630 --> 00:05:54.450
endpoint users, application, and databases,

00:05:55.440 --> 00:05:59.910
each container based on Alpine distribution and bound to

00:05:59.910 --> 00:06:02.860
proper network, according our scenario.

00:06:03.540 --> 00:06:06.860
Let's confirm that everything works as expected.

00:06:07.540 --> 00:06:09.960
Let's open a shell on USER container.

00:06:10.340 --> 00:06:13.660
As you can see, we are able to ping application endpoint.

00:06:14.340 --> 00:06:18.610
We are not able to communicate with the databases, and we are

00:06:18.610 --> 00:06:22.940
able to communicate with the public internet. Now we open a

00:06:22.940 --> 00:06:25.260
shell on the application container.

00:06:26.140 --> 00:06:29.260
As you can see, we are able to ping a user endpoint.

00:06:29.840 --> 00:06:34.520
We are able to communicate with the databases, but our application

00:06:34.520 --> 00:06:38.350
is not able to communicate with the public internet. And this fully

00:06:38.350 --> 00:06:41.810
demonstrates that we are able to enforce a segmentation and

00:06:41.810 --> 00:06:46.220
segregation schema by means of VRFs and a well‑implemented

00:06:46.220 --> 00:06:49.050
cross‑VRF leaking route schema.