In this demo,
you will learn how to set up a VyOS platform to enforce
segmentation and segregation by means of VRF.
In the following,
you can see a functional diagram of the scenario we are going to target.
We have three different subnets, each one dedicated to group of endpoint,
namely, user, application, and databases.
The three subnets are terminated with three separate interfaces of VyOS router,
which plays the role of a gateway.
Please note that each subnet is associated to a different VRF,
named after three colors: purple, blue, and green.
Please note that I have detailed here the interface naming and
the IP addressing schema of VyOS interfaces.
As in the previous demo, we have Ethernet 0,
which is our uplink towards the internet.
And finally,
we have a table representing the security policy we need
to deploy over our test infrastructure.
Again, please note that for the sake of clarity,
you have also all details of endpoint IP addressing schema.
In this slide, we have details of how the lab is built.
We have VMWare workstation, which hosts Ubuntu virtual machine, and a
VyOS router, and we have eth0 as uplink interface, and this part is
really identical to our previous demo.
Then we have a container playing the role of user endpoint, which is attached
to VyOS eth1 interface by means of dedicated vmnet0 network.
Then we have another container playing the role of application
endpoint, which is attached to VyOS eth2 interface by means of
dedicated vmnet2 network. And then we have a container playing the
role of database endpoint, which is attached to VyOS eth3 interface by
means of dedicated vmnet3 network.
Please note that if you run this demo on your laptop, virtual machine
interface naming can be different. And now it's time to cast some
configurations by means of VyOS API calls and Python scripts.
We have three scripts, which together ensure proper configuration of a
VyOS router in this scenario. The first script is create_vrf. This is a
very simple script, which creates three virtual routing forwarding
instances named purple, blue, and green, and associates them to a
dedicated instance of VyOS routing table.
We run the script, and we receive back success as a response.
The second script is named configure_interfaces. Proper IP addressing is
provided to interfaces Ethernet 1, 2, and 3. In case you need, I suggest to
refresh IP addressing schema and interface naming by going back to the
diagram at the beginning of this module.
Also, three interfaces are associated to the three VRFs: purple, blue, and green.
We run this script, and we receive back success as a response.
At this point, each subnet sits in a dedicated VRF with no
cross‑talk possibility, but as you know,
we need to allow certain numbers of data flows between
endpoint groups. And here comes the final script, which
does the magic: route leaking.
Let me provide a detailed description.
First line creates a static route entry in purple VRF routing
tables, which says that subnet 172.16.2.0/24, which is the subnet of
application, can be found by means of gateway, which is 172.16.2.2,
which belongs to the blue VRF.
Second line represents the route back; a static route entry is created in
the blue VRF, which says that subnet 172.16.1.0/24 can be found by means
of a gateway, which is 172.16.1.2, which belongs to the purple VRF. These
two lines together allow packets to go back and forth, thus enabling
cross‑VRF leaking between blue and purple VRFs. The next couple of
statements work in the very same way, but the only difference that gateway
for internet destination is 192.168.1.1, which resides in default VRF.
Default VRF means that eth0 interface was not associated with any VRF. And
finally, the last statements install route in VRFs blue and green to allow
communication between databases and applications.
Please note that neither application nor databases have
been provided with default route,
thus preventing communication with public internet. We run this
script, and we receive back success as a response.
The next part is endpoint configuration hosted on Ubuntu virtual machine.
We created three Docker networks with specific IP addressing schema; each
network is in ipvlan mode, and each network is bound to a dedicated
interface, according to our network diagram.
Finally,
we created three Docker containers playing the role of
endpoint users, application, and databases,
each container based on Alpine distribution and bound to
proper network, according our scenario.
Let's confirm that everything works as expected.
Let's open a shell on USER container.
As you can see, we are able to ping application endpoint.
We are not able to communicate with the databases, and we are
able to communicate with the public internet. Now we open a
shell on the application container.
As you can see, we are able to ping a user endpoint.
We are able to communicate with the databases, but our application
is not able to communicate with the public internet. And this fully
demonstrates that we are able to enforce a segmentation and
segregation schema by means of VRFs and a well‑implemented
cross‑VRF leaking route schema.