Hypervisor networking using Open vSwitch – Part 3 – Introducing VSX

VLANs allow to introduce network segmentation to our environment. After we make sure the machines sit in separate VLANs, we might want to provide some sort of inter-VLAN routing as well as some sort of a firewall (UTM) that will make sure only desired traffic gets through from VLANs to VLANs.

As an engineer working with CheckPoint daily, it’s a perfect time to introduce VSX. VSX differs from a classic firewall – the VSX device is simply a host to things called VSes – think of them as Docker containers, except they’re firewall instances.

The concept

Okay let’s picture what we’re trying to do:

As you can see, we are going to have three VLANs – VLAN100 that leads to an Internet breakout and two server VLANs – VLAN101 and VLAN102. VSX will essentially be the “router-on-a-stick”. It’s a very simple setup and in real world you would probably be connecting multiple switches to your VSX chassis. However, for this article, this setup should do just fine.

Before we start, we have to make few changes to the setup we ended up with in Hypervisor networking using Open vSwitch – Part 2 – Introducing VLANs. Since we’ve created an internal OVS port for our host to use for inter-VLAN routing we need to remove it in order to allow only our VSX to do the routing for us. In order to delete the internal port, do:

sudo rm /etc/sysconfig/network-scripts/ifcfg-ovsbr0.101
# and then
sudo ovs-vsctl del-port ovsbr0 ovsbr0.101

This basically removes the ovsbr0.101 port and a config file that creates the interface every time system boots or a systemctl restart network command is ran.

Let’s also add an easy way to select the trunk interface in LibVirt.

Run sudo virsh net-edit ovsbr0-network and change it from this:

<network>
  <name>ovsbr0-network</name>
  <uuid>66cf345c-127a-4317-add1-9014d35bc1e1</uuid>
  <forward mode='bridge'/>
  <bridge name='ovsbr0'/>
  <virtualport type='openvswitch'/>
  <portgroup name='vlan-100' default='yes'>
    <vlan>
      <tag id='100'/>
    </vlan>
  </portgroup>
  <portgroup name='vlan-101'>
    <vlan>
      <tag id='101'/>
    </vlan>
  </portgroup>
  <portgroup name='vlan-102'>
    <vlan>
      <tag id='102'/>
    </vlan>
  </portgroup>
</network>

To this:

<network>
  <name>ovsbr0-network</name>
  <uuid>66cf345c-127a-4317-add1-9014d35bc1e1</uuid>
  <forward mode='bridge'/>
  <bridge name='ovsbr0'/>
  <virtualport type='openvswitch'/>
  <portgroup name='vlan-100' default='yes'>
    <vlan>
      <tag id='100'/>
    </vlan>
  </portgroup>
  <portgroup name='vlan-101'>
    <vlan>
      <tag id='101'/>
    </vlan>
  </portgroup>
  <portgroup name='vlan-102'>
    <vlan>
      <tag id='102'/>
    </vlan>
  </portgroup>
  <portgroup name='vlan-all'>
    <vlan trunk='yes'>
      <tag id='100'/>
      <tag id='101'/>
      <tag id='102'/>
    </vlan>
  </portgroup>
</network>

And reload the network with sudo virsh net-destroy ovsbro-network and sudo virsh net-start ovsbro-network so new settings are applied.

Deploy VSX

A VSX gateway starts as a regular gateway until we configure it to be a VSX chassis in SmartConsole. However, in order to administrate it correctly we will need to keep in mind that VSX will requite two things: a management interface and a trunk interface. The trunk interface will contain all the VLANs we will be securing, and the management interface is an interface that’s not a trunk and that will only be used for administration of the chassis. I created the Management Network as a simple Virtual Network (refer to this article and set up the network. Untick the “Enable IPv4 network address space definition” option) and put the CP-MGMT and A-NET-W7 devices on it.

Now create a new virtual machine and when adding interfaces, you should be able to see following:

Select vlan-all. Afterwards add the second NIC in the Management Network and install GAiA.

From the W7 device I accessed the https://10.10.0.2 webpage to configure the gateway. Afterwards add the VSX Gateway by selecting New… > More > Network Object > Gateways and Servers > VSX > Gateway…

Pop in the VSX gateway’s details and press “Next”:

Now pop in the SIC password you set during first time configuration and press “Initialize”.

If the password is right, the Trust State should change from Uninitialized to Trust Established. Now press Next.

Now the creator will ask you which interface is a VLAN Trunk interface. It should be the interface that we assigned to the ovsbr0 network. If you’re unsure which interface it is, look up the interface’s MAC address in Virtual Machine’s properties and find the interface on the VM using ip a s command. Since eth0 is my trunk interface, I will select it and click Next.

Don’t select anything on the screen below. Make sure it is as it’s shown below:

Now select whatever rules are relevant for yourself and press Next.

Bear in mind that if you’re doing this in an environment without implied rules turned on, the box will struggle getting the policy from the management after you press “Next”. It’s because the policy shown on the screenshot above does not allow any edits besides changing objects in “Source” column. Therefore, if implied rules are switched off and above policy is pushed out to the VSX chassis, we will no longer allow traffic on ports like 257, 18191, 18192 and therefore we will lose the ability to push any changes to the chassis.

Don’t panic though. You will have to push that policy anyway. After you do so, however, amend the auto-generated policy and allow management traffic. After the policy is ready, SSH onto chassis and use fw unloadlocal command and push the policy from management. Everything should be OK from then on.

Alright, that’s it! We should see our chassis in the SmartConsole now:

At the moment it doesn’t do much – for it to work we need to add at least one Virtual Switch and a Virtual System that will handle the traffic.

Set up the Virtual Switch

Do you remember how we’ve set up the Open vSwitch on our hypervisor? Here we go again.

VSX might seem confusing to people fresh to CheckPoint but it’s using technology very well known in the Linux world – the interface bridging and virtual switches. So if we want to allow Virtual System 1 access to vlan100 and vlan101, we will need to add two virtual switches – one “plugged” into the vlan100 and one “plugged” into vlan101. We will then attach any number of VSes we want to those switches. Sounds simple? Hope so! Those virtual switches are very basic, there isn’t greater logic to them.

Okay, so let’s start off with two Virtual Switches – one for the vlan 100 (to get to Internet) and one for vlan 101 (to get to one of our VMs).

Go to New… > More > Network Object > Gateways and Servers > VSX > Virtual Switch. It will bring up following dialog window:

I will go with “VS-VLAN100-Internet” as a name and select the “VSX-TEST” chassis as a host and press “Next”.

Now we will be taken to a screen where we select the Virtual Switch interfaces. Press “Add…”. We can now select one of the trunk interfaces (in our case it’s only eth0) and tell the switch what VLAN Tag to use. Basically it creates a 802.1q interface that then gets plugged into the Virtual Switch for the Virtual Systems to use.

After we finish the configuration, the last step is to push out the configuration to the chassis. This might take a while. Redo the same thing again but this time name the switch something like “VS-VLAN101-NET1“, pick eth0 and assign it a 101 VLAN Tag.

SmartConsole will list our chassis now, along with two Virtual Switches.

It’s time to add a virtual system. Go to New… > More > Network Object > Gateways and Servers > VSX > Virtual System. You will get this screen:

Let’s name our VS and select the VSX chassis:

Now we need to add interfaces to the Virtual System. Let’s add some.


Press “Add…” and “Leads to Virtual Switch…”. If you’re wondering why we’re not using the “Regular…” option, here’s the answer – if you use it in one Virtual System, you can no longer use it in any other Virtual System unless you remove it from the one it’s using it first.. Okay, I will first add an interface that leads to VLAN100 (Internet – 192.168.1.0/24):

And then another one to the VS-VLAN101-NET1 switch:

Alright. We should be seeing this now:

Before we proceed it’s worth adding the default route to the “Routes” section. Bear in mind routes in VSX are a bit tricky and you will be generally controlling them from the SmartConsole. Let’s click the “Add Default Route…” button and point it at our Internet breakout (my home router in my case):

Alright. All done!

Press Next and then Finish. The configuration will now be pushed out to the chassis. That’s the end result:

The policy

One of the pros of the VSX is the fact that we can have perfectly separate policies assigned to each VS as they are considered separate gateways. I won’t get in-depth and the policy will be wide open. It’s supposed to only show that the inter-VLAN routing works with VSX doing all the hard work.

Okay, let’s select “Manage policies and layers…” option and create a new policy. Set the VS_NET1_To_Internet gateway as the policy target.

Let’s change the action on the Cleanup Rule from Drop to Accept. Also, change “Track” from None to Log and Install Policy.

Let’s also add a very basic NAT to ensure we can get to the Internet. Because my home router is not aware of the 10.255.255.0/24 network, it will not be able to route traffic back when a reply from a website actually arrives on the router. To get around it, we are going to add following NAT rules:

I created two object: 10.255.255.0/24 network object and a host object pointing at 192.168.1.240 which is essentially the IP address this Virtual System uses to connect to the VS-VLAN100-Internet Virtual Switch. I then used this host object to hide the traffic from 10.255.255.0/24 to anything behind 192.168.1.240. That way, the router will be able to route the traffic back to the Virtual System which will then pass the reply back to our server (10.255.255.50).

After the policy installed, I am now able to ping the VS itself from one of the servers:

And 8.8.8.8:

And the logs in SmartConsole:

Woohooo!

Okay. Let’s now add the VLAN102 to the play.

Head back to the SmartConsole and open the VS_NET1_To_Internet Virtual System and go to New… > More > Network Object > Gateways and Servers > VSX > Virtual Switch. Set it up the same we did it for VLAN101, except change the VLAN tag to 102. Name it VS-VLAN102-NET2.

We now have following devices in our chassis:

However it’s not enough just yet. Let’s open the VS_NET1_To_Internet Virtual System and head to “Topology” section and hit “New” > “Leads to Virtual Switch” to add a new interface:

I will assign it the 172.16.201.1/24 IP address:

Looking good:

Let’s amend the NAT policy now.

Create the net_172.16.201.0_24 network object (172.16.201.0/24) and two extra rules:

Okay. Time to push the policy!

Little test:

Success!

Hopefully this guide helped someone understand basic VSX deployment, as well as how one can use Open vSwitch to work with VSX.

Let me know if something doesn’t make sense or need clarifying and I will get back to you 🙂

Cheers!

Leave a Reply

Your email address will not be published. Required fields are marked *

Navigation