Virtual Private Network
TechPreview
The Virtual Private Network as a Service (VPNaaS) extension to the MOSK Networking service (OpenStack Neutron) enables cloud users to extend their private networks securely over the internet to remote sites or devices. Users create and manage encrypted tunnels (such as IPsec) and configure VPN policies (IKE, IPsec) on demand from the same OpenStack interface they use for the rest of their networking without deploying or operating dedicated VPN virtual machines.
Architecture overview
The Virtual Private Network service establishes IPsec tunnels between networks, allowing data to be transferred securely across the public network. Workload traffic that needs to be encrypted is processed by the StrongSwan process running on an OpenStack gateway node and sent over the internet in encrypted form. At the remote gateway, the packets are decrypted and forwarded to the final destination as normal traffic. Encryption and decryption are transparent to cloud workloads. Other traffic passes through the public network unchanged. The VPNaaS service network topology varies depending on the Networking service backend in use.
Networking backend: Open vSwitch
With the Open vSwitch backend, the StrongSwan process runs in the router namespace on the Neutron L3 Agent. That router is directly connected to the private networks whose traffic needs to get protected by the VPN.
The diagram below illustrates a site-to-site VPNaaS network topology using the Open vSwitch backend, where two separate OpenStack clusters act as VPN peers.
Networking backend: Open Virtual Network
With the OVN backend, there are no Neutron L3 Agent services. OVN handles L3
traffic entirely within the OVS br-int (integration bridge) on the compute
hosts, using the host network stack and OpenFlow rules. Dedicated OVN VPN
Agent services perform encryption. The StrongSwan process runs in the VPN
Agent pod. A separate namespace is created for each VPN connection; the
namespace name corresponds to the router ID of the router attached to the
private networks whose traffic is encrypted. The VPN Agent and the router are
connected over the 169.254.0.0/30 network, and encrypted traffic enters the
public network through a dedicated port on the VPN Agent. The router selects
packets that require encryption and sends them to the VPN Agent pod, where
they are encrypted and sent onto the public network. All other traffic reaches
the public network through the router’s public port.
The diagram below illustrates a site-to-site VPNaaS network topology using the Open Virtual Network backend, where two separate OpenStack clusters act as VPN peers.
Networking backend: OpenSDN
OpenSDN, formerly known as Tungsten Fabric, does not support VPNaaS directly.
Enabling VPNaaS in MOSK
The VPNaaS Neutron extension needs to be explicitly enabled in the
OpenStackDeployment custom resource.
To enable the VPNaaS Neutron extension, add the following lines to the
spec:features:neutron:extensions dictionary:
spec:
features:
neutron:
extensions:
vpnaas:
enabled: true