Forwarding VLANs over the Internet

Once the leadership of our organization set the task to include an office in another city in the main corporate network. At the same time, several virtual networks (VLANs) were used inside the corporate network - for telephony, access to the database, equipment management, etc. For some reason, it was not possible to rent a direct channel to forward these VLANs.

Since CentOS 6-based machines acted as external routers in both offices, it was decided to use OpenVPN to transit internal traffic. The initial idea of ​​a separate tunnel for each VLAN was quickly abandoned due to the low scalability of the solution.

The Open vSwitch project came to the rescue - a software switch with VLAN support (IEEE 802.1q).


Virtual network diagram.

OpenVPN Tunnel Configuration

There are a lot of information on setting up OpenVPN on the network and on Habré , so I’ll immediately give the configuration with some comments.


A tap device is used for the ability to transmit ethernet frames.

The bridge.sh script is used to add a network tap device to a virtual switch (ovs). When restarting the OpenVPN daemon, it is necessary to output and re-add the tap device to the switch, without this crutch, traffic from the virtual switch does not arrive at it. This problem has not yet been solved beautifully.
It’s not hard to guess, the tunks parameter describes the ability of a virtual port to transmit tagged traffic of the indicated vlan.

Configure open vSwitch

On most modern distributions, open vSwitch is already present in its entirety. CentOS 6 only has a kernel module. You will have to look for a package with a virtual switch daemon in third-party repositories, or collect it yourself. There is enough information on assembling the package on the network, this process should not cause any difficulties. After installing and starting the daemon, you need to create a virtual switch device. To do this, the ifcfg-ovs0 interface configuration file is created:

DEVICE=ovs0
ONBOOT=yes
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
HOTPLUG=no

which corresponds to the team

ovs-vsctl add-br ovs0

Interface Settings

Configuring virtual switch ports is practically no different from the settings of ordinary system network interfaces. To add the interface to the switch, the ifcfg-eth0.197 interface configuration file is created:

PHYSDEVICE=eth0
DEVICE=eth0.197
ONBOOT=yes
DEVICETYPE=ovs
TYPE=OVSPort
OVS_BRIDGE=ovs0
OVS_OPTIONS="tag=197"
BOOTPROTO=none
HOTPLUG=no

Which corresponds to the command:

ovs-vsctl add-port ovs0 eth0.197

I note that when adding an interface to a virtual switch, the IP address of this interface ceases to be accessible. If necessary, in the north, use the IP address on this VLAN interface, you need to transfer it to the virtual internal port of the switch. The ifcfg-vi197 configuration file in this case will look like this:

DEVICE=vi197
ONBOOT=no
DEVICETYPE=ovs
TYPE=OVSIntPort
BOOTPROTO=static
IPADDR=10.0.120.253
NETMASK=255.255.255.0
OVS_BRIDGE=ovs0
OVS_OPTIONS="tag=197"
HOTPLUG=no
ARPCHECK=no

Which corresponds to the command:

ovs-vsctl add-port ovs0 vi197 tag=197 -- set Interface vi197 type=internal

By analogy, the remaining VLAN interfaces are created.

You can view the current status of the virtual switch ports using the command:

ovs-vsctl show

In my case, the configuration is as follows:

Conclusion

As a result, we get the passage of tagged traffic over an encrypted channel over the Internet.

The solution turned out to be easily scalable, it is easy to add both new VLANs and new remote networks to it.

PS: Instead of OpenVPN, you can use the GRE tunnel built into open vSwitch. There was no time to figure it out yet and I'm not sure about the possibility of encrypting traffic when using it.