What Is VPNaaS? VPN as a Service Explained, and How OpenStack Neutron VPNaaS Works in 2026

VPNaaS stands for VPN as a Service: a virtual private network you consume as a service, where a provider runs the gateways and the encryption so you don't buy, rack and patch your own VPN hardware. The acronym has two common meanings. Security vendors use it for a cloud VPN that connects remote staff and branch offices, while in OpenStack it names neutron-vpnaas, the Neutron extension that lets every project build its own IPsec site-to-site tunnels from a virtual router.

Where things stand in October 2026:

• Vendors sell VPNaaS per user or per site; OpenStack VPNaaS is an API your cloud operator may or may not have switched on.
• The OpenStack project is maintained: neutron-vpnaas 29.0.0 shipped with the Hibiscus release on 30 September 2026.
• OpenStack VPNaaS does one job: IPsec tunnels between networks, with a pre-shared key. Laptops and phones need something else.
• Version 29.0.0 removed the OpenSwan drivers and the sha1, md5, des and 3des algorithms. strongSwan and Libreswan remain.
• OVN clouds have been supported since 2024.1 through a separate VPN agent, and each router with VPN there uses one extra public IP.

What is VPNaaS? Definition and meaning

VPNaaS (VPN as a Service) is a VPN that a provider operates for you and that you consume through a subscription or an API. The provider runs the gateways that end the encrypted tunnels; you decide who or what may connect and which networks they reach. You give up some control and gain capacity you never have to plan, patch or replace.

The cloud VPN meaning

In most search results, VPNaaS means a commercial cloud VPN. Employees install a client, sign in through the company's identity provider and connect to the nearest gateway in the provider's network; branch offices point an IPsec or WireGuard tunnel from their router at the same network. Billing is per user or per site, and the VPN concentrator in the server room can go. The catch: traffic is decrypted on gateways you don't run, costs grow with headcount, and a VPN puts a user on a network rather than in front of one application, which is why vendors increasingly bundle zero trust features with it.

The OpenStack meaning

In OpenStack, VPNaaS is an extension of Neutron, the networking service. Once the operator installs neutron-vpnaas, each project can create IPsec site-to-site tunnels from its own virtual router to a remote gateway, through the API, the openstack command line or the Horizon panel from the separate neutron-vpnaas-dashboard plugin. The far end is usually an office firewall, another data centre or another OpenStack region. You still configure each tunnel, but nobody boots, patches or licenses a VPN appliance.

It is not a remote-access VPN for people, and it is not on by default. The Neutron admin guide's VPNaaS chapter has the operator add it as a service plugin and run a database migration before any project can use it.

How is VPNaaS different from a traditional VPN, ZTNA or SASE?

The quickest way to separate these terms is to ask who runs the gateway and what is allowed to connect.

Connecting people? Look at the cloud VPN and ZTNA rows. Connecting an OpenStack network to another site? Read on.

How does OpenStack VPNaaS work?

neutron-vpnaas lives in its own repository and plugs into neutron-server as a service plugin, which stores and validates what projects ask for. An agent on the network side turns that into configuration for an IPsec daemon, strongSwan or Libreswan, and keeps it running. Every tunnel is built from five API objects:

1. An ike policy holds phase 1, where the two gateways authenticate each other: IKE version (v1 or v2), hash, cipher, the Diffie-Hellman group for perfect forward secrecy (PFS) and a lifetime.
2. An ipsec policy covers phase 2, the tunnel that carries your packets: ESP or AH, tunnel or transport mode, and its own hash, cipher and PFS group.
3. A vpn service ties VPN to one router, whose public address becomes the local end of every tunnel. The API reports it, read-only, as external_v4_ip and external_v6_ip.
4. Two endpoint group objects list what sits on each side: local subnets in one, remote CIDRs in the other.
5. An ipsec site connection joins it all to one peer: its address and identity, the pre-shared key, dead peer detection (by default hold, checking every 30 seconds with a 120 second timeout), the MTU, and whether OpenStack may start the negotiation or only answer.

Routing is static: packets enter the tunnel because they match the endpoint groups, and the API has no BGP. Authentication is by pre-shared key only, and the API returns the key to anyone who can read the connection, so be deliberate about project membership.

VPNaaS has stayed inside Neutron. Load balancing, by contrast, left Neutron and is now its own service, Octavia, covered in our article on OpenStack LBaaS with Octavia. Where the VPN agent runs depends on the network back end, which our overview of SDN options in OpenStack, OVS and OVN included, explains.

ML2/OVS: inside the router's namespace

With Open vSwitch, VPN is an extension of the L3 agent. The driver writes the IPsec configuration into the router's network namespace and runs the daemon there, so tunnels leave from the router's own gateway address. The admin guide's settings, strongSwan version:

# as root: add to each file named below, keeping what is already there
# /etc/neutron/neutron.conf (append vpnaas to your existing list)
[DEFAULT]
service_plugins = router,vpnaas

# /etc/neutron/neutron_vpnaas.conf
[service_providers]
service_provider = VPN:strongswan:neutron_vpnaas.services.vpn.service_drivers.ipsec.IPsecVPNDriver:default

# /etc/neutron/l3_agent.ini
[AGENT]
extensions = vpnaas

[vpnagent]
vpn_device_driver = neutron_vpnaas.services.vpn.device_drivers.strongswan_ipsec.StrongSwanDriver

On RHEL-family nodes the guide keeps the same IPsecVPNDriver service provider and sets vpn_device_driver to the LibreSwanDriver class, for Libreswan, instead. Then create the tables, and restart neutron-server and the L3 agents:

# as root, on the controller
neutron-db-manage --subproject neutron-vpnaas upgrade head

It lists the migrations it runs and ends with OK. With Kolla-Ansible, all of this is enable_neutron_vpnaas: true in /etc/kolla/globals.yml, and the Kolla-Ansible networking docs note that on OVS the VPN code runs inside the neutron_l3_agent container.

ML2/OVN: a stand-alone VPN agent

OVN routers are flows in Open vSwitch, not namespaces on a network node, so the L3 agent approach had nowhere to run. Support came in 2024.1 with neutron-vpnaas 24.0.0. The OVN VPNaaS guide says it plainly: "With OVN there is no L3 agent. Instead a stand-alone VPN agent is installed." The operator enables the ovn-vpnaas plugin and runs neutron-ovn-vpn-agent, configured in /etc/neutron/ovn_vpn_agent.ini with the OvnStrongSwanDriver.

The OVN design spec explains the trade-off. The agent gives each VPN router a namespace, linked to the logical router through a tiny 169.254.0.0/30 transit network, with its own external gateway port. The tunnel does not share the router's SNAT address, so every router with VPN uses one more public IP. Kolla-Ansible runs the agent as the neutron_ovn_vpn_agent container.

Is neutron-vpnaas deprecated or still maintained?

It is maintained. neutron-vpnaas belongs to the Neutron stadium, the projects under the Neutron team, and has shipped a release in every recent cycle, most recently 29.0.0 with Hibiscus (2026.2) on 30 September 2026. The deprecation stories come from vendors: Red Hat deprecated VPNaaS in Red Hat OpenStack Platform 11 and, as its RHOSP 12 release notes record, removed it in version 12, back in 2017. Upstream, these are the changes worth knowing, from the neutron-vpnaas release notes:

The 29.0.0 release notes disagree with themselves a little: one note says the weak algorithms were removed, another that the database migration dropping them is still pending. The API reference still names sha1 as the default hash. So never accept defaults. Write the algorithms into every policy, as the example below does, and before upgrading to Hibiscus list every policy with openstack vpn ike policy list and openstack vpn ipsec policy list, which show the hash and cipher of each, and move any still on sha1, md5, des or 3des.

strongSwan or Libreswan?

Use whichever your distribution packages and your deployment tool tests. The admin guide pairs strongSwan with Ubuntu and Libreswan with RHEL and CentOS, and the OVN guide uses strongSwan. Two things are moving. The strongSwan driver still uses the stroke interface, which strongSwan has deprecated, hence the swanctl option coming next release. And Enterprise Linux 10 is rough going: Launchpad bug 2146308 lists six problems on Rocky Linux 10 and CentOS Stream 10, and Kolla-Ansible says OVN VPNaaS is currently not supported on RHEL 10 based distributions. Newer Ubuntu is not safe either: a comment on that bug warns Ubuntu 26.04 may be next, and the swanctl release note says recent Ubuntu and Debian releases ship strongSwan without the stroke plugin. We would keep network nodes on Ubuntu 24.04 LTS with strongSwan, or EL9 with Libreswan, until those reports are closed.

How do you create a site-to-site VPN in OpenStack? A worked example

The setup: a project subnet, 10.0.0.0/24, behind a router with an external gateway, and an office LAN, 192.168.1.0/24, behind a firewall at PEER_PUBLIC_IP. The commands follow the endpoint group method, which the admin guide marks as recommended, plus explicit algorithms using the flags that openstack vpn ike policy create --help lists.

Run them on a machine with the openstack client and your project's credentials loaded (an openrc file or clouds.yaml). The blocks call that Linux account the stack user, after DevStack. Replace the upper-case placeholders.

1. Check that the cloud offers VPNaaS and your client knows the commands:

   # as the stack user
   openstack extension list --network | grep -i vpn
   openstack vpn service list

   Expect a row with the alias vpnaas, then an empty table. No vpnaas row means the operator hasn't enabled it. "Not an openstack command" means an old client: since python-openstackclient 10.2.0 the VPN commands ship in the main client, moved from python-neutronclient.

2. Create the two policies. Both ends must use exactly these values:

   # as the stack user
   openstack vpn ike policy create ikepolicy --ike-version v2 --auth-algorithm sha256 --encryption-algorithm aes-256 --pfs group14
   openstack vpn ipsec policy create ipsecpolicy --auth-algorithm sha256 --encryption-algorithm aes-256 --pfs group14

   Each prints the new policy as a table showing sha256, aes-256 and group14, the 2048-bit MODP group that strongSwan calls modp2048.

3. Confirm the router has an external gateway, then create the VPN service and both endpoint groups:

   # as the stack user
   openstack router show ROUTER_ID -c external_gateway_info
   openstack vpn service create vpn --router ROUTER_ID
   openstack vpn endpoint group create ep_subnet --type subnet --value SUBNET_ID
   openstack vpn endpoint group create ep_cidr --type cidr --value 192.168.1.0/24
   openstack vpn service list --long

   external_gateway_info must list an IP address; if it is empty, set a gateway first. The Ext v4 IP column is the address the office firewall points at (on OVN, not the router's SNAT address). PENDING_CREATE is normal until a connection exists.

4. Generate a key on your own computer with openssl rand -base64 32, send it to the office side over a different channel from the IP addresses, then create the connection:

   # as the stack user
   openstack vpn ipsec site connection create conn --vpnservice vpn --ikepolicy ikepolicy --ipsecpolicy ipsecpolicy --peer-address PEER_PUBLIC_IP --peer-id PEER_PUBLIC_IP --psk 'YOUR_RANDOM_KEY' --local-endpoint-group ep_subnet --peer-endpoint-group ep_cidr
   openstack vpn ipsec site connection show conn

   It starts at PENDING_CREATE and turns ACTIVE once the office side is configured. DOWN means negotiation is failing.

What the other end needs

The office firewall, or a Linux box running strongSwan, mirrors these choices with local and remote swapped:

Alternatives when VPNaaS is missing or not enough

Not every OpenStack cloud enables VPNaaS, and it only covers static IPsec between networks.

The most common alternative is your own gateway: a small instance with WireGuard, in the mainline Linux kernel since version 5.6, or with strongSwan or Libreswan configured by hand. You gain remote-access users, certificates and WireGuard's short configs; you also gain an instance to patch, and two pieces of Neutron plumbing that catch nearly everyone. Port security drops packets whose source isn't the instance's own address, so the gateway's port needs the remote range as an allowed address pair, and the router needs a static route sending that range to the gateway:

# as the stack user
openstack port set --allowed-address ip-address=192.168.1.0/24 GATEWAY_PORT_ID
openstack router set --route destination=192.168.1.0/24,gateway=10.0.0.5 ROUTER_ID

Here 10.0.0.5 is the gateway instance on the project subnet. Open the VPN port in its security group too: UDP 51820 is WireGuard's customary port, while IPsec needs UDP 500 and 4500, plus ESP (IP protocol 50) when nothing does NAT. Our WireGuard setup guide for Debian 13 covers keys, forwarding and the server config, and works the same on an instance.

Two other routes fit narrower cases. A firewall vendor's virtual edition makes sense when the far end is that vendor's hardware, at the cost of a licence. And for fifty people reaching internal tools from home, a cloud VPN or ZTNA product with single sign-on beats any tunnel between networks.

Our rule of thumb: if the operator offers VPNaaS and the other side is a firewall that speaks IKEv2, use VPNaaS. There is nothing to patch, and the tunnel survives instance rebuilds because it lives on the router. Switch to an instance once you need users, certificates or WireGuard.

Why is my OpenStack VPN tunnel down? Troubleshooting

Start with the connection status and the agents, then the logs on both ends:

# as the stack user
openstack vpn ipsec site connection show conn
openstack network agent list

The L3 agent on the router's node (OVS) or the VPN agent (OVN) should show :-) under Alive. On a strongSwan peer, this lists the tunnels that are up:

# as root, on the strongSwan peer
swanctl --list-sas

Empty output means no tunnel (older setups use ipsec statusall). Then match the symptom:

• The peer logs NO_PROPOSAL_CHOSEN: algorithms, IKE version or PFS group differ. A missing modp2048 in esp_proposals is the classic.
• AUTHENTICATION_FAILED means the key or the identities differ. --peer-id must equal the identity the peer sends, which behind NAT is often its private address.
• Stuck at PENDING_CREATE: the agent hosting the router is down or hasn't loaded the VPN extension. On OVN, check that neutron-ovn-vpn-agent runs at all.
• ACTIVE, yet nothing answers. The default security group only admits its own members, so instances need an ingress rule for 192.168.1.0/24. Then check that the peer forwards packets and that the subnets don't overlap.
• Pings work, file transfers hang: MTU. Overlay networks already run below 1500 bytes and IPsec adds headers, so lower --mtu on the connection or clamp TCP MSS on the peer.
• The agent fails after upgrading to 29.0.0 because it still points at an OpenSwan driver. Switch vpn_device_driver to the strongSwan or Libreswan class first.
• Errors about _stackmanager on Libreswan 5.3 or newer: Libreswan dropped that command, and 29.0.0 falls back to start (Launchpad bug 2146535).
• On Rocky Linux 10 or CentOS Stream 10, IKE and ESP come up but the status stays DOWN. Bug 2146308 explains it: the _updown script runs with a stripped PATH and can't find iptables. The report also covers EPEL's binary being named strongswan, not ipsec.

Where an RS Computers VPS fits

RS Computers rents KVM virtual servers in Amsterdam, Prishtina and Dublin: VPS plans with a 1 Gb/s port and VDS plans with a 10 Gb/s port, all on NVMe, each with its own IPv4 and IPv6 address and free weekly backups. The vCPUs are shared. Next to an OpenStack cloud they help in four ways:

• As the far end of a tunnel. Testing VPNaaS needs a peer with a fixed public address, and a VPS Nano (1 vCPU, 1 GB RAM) running strongSwan is enough. For a link carrying backups all day, a VDS gives the encryption more vCPUs and a faster port.
• As a lab. A VDS Medium (8 vCPU, 16 GB RAM) or VDS Large (16 vCPU, 32 GB RAM) can hold a DevStack all-in-one with the VPNaaS plugin. DevStack's docs warn it makes substantial changes to the system, so give it a server of its own.
• As tooling outside the cloud: a bastion, or a monitor checking the services behind the tunnel from another city, as in our guide to monitoring with Uptime Kuma from a second location.
• As the simpler answer. One office and a few servers rarely justify a private cloud; our Proxmox vs OpenStack comparison helps size what you need.

In DevStack, VPNaaS is one line in the [[local|localrc]] section of local.conf, with the branch matching your checkout; strongSwan is the default IPsec package:

# as the stack user: add to the [[local|localrc]] section of ~/devstack/local.conf
enable_plugin neutron-vpnaas https://opendev.org/openstack/neutron-vpnaas stable/2026.2

DevStack's most tested platform is Ubuntu 24.04. The same plans and prices apply in all three cities, as the VPS and VDS plans page shows. To have the setup sized for you, message us on Telegram or email info@rscomputers-ks.com, and we will suggest a plan and quote the setup.

Frequently asked questions

What does VPNaaS stand for?

VPN as a Service, short for Virtual Private Network as a Service: a VPN whose gateways a provider operates for you, either a commercial cloud VPN for remote staff or OpenStack's Neutron extension for site-to-site IPsec tunnels.

Is VPNaaS the same as a cloud VPN?

Usually, yes: vendors use both terms for a hosted VPN that replaces an on-premises concentrator. In OpenStack the term is narrower and means only the Neutron API for IPsec tunnels between networks.

Is VPNaaS the same as ZTNA or SASE?

No. VPNaaS connects a user or site to a network, ZTNA grants access to single applications after checking user and device, and SASE is a bundle that typically includes ZTNA, web filtering, firewalling and SD-WAN, sometimes with VPNaaS inside.

Does OpenStack VPNaaS support OVN?

Yes, since 2024.1 Caracal (neutron-vpnaas 24.0.0). OVN deployments run a stand-alone neutron-ovn-vpn-agent, and each VPN router needs an extra external IP address.

Is neutron-vpnaas deprecated?

Not upstream: 29.0.0 shipped with Hibiscus on 30 September 2026. Red Hat removed it from Red Hat OpenStack Platform 12, and 29.0.0 dropped the OpenSwan drivers, so check what your distribution ships.

What is an endpoint group in OpenStack VPNaaS?

A named list of endpoints of one type, such as subnets or CIDRs. A site connection takes a local group of your subnets and a peer group of remote CIDRs, replacing the older --subnet and --peer-cidr options.

Can I use WireGuard instead of VPNaaS in OpenStack?

Yes, but not through the VPNaaS API, which speaks IPsec only. Run WireGuard on an instance, add the remote range as an allowed address pair on its port, and route that range to the instance on the project router.

Six things to agree with the other side first

Most failed tunnels are mismatches, not bugs. Settle these before anyone types a command:

1. Both public addresses, and whether either side is behind NAT.
2. IKE version and exact proposals in both vocabularies: aes-256, sha256 and group14 in OpenStack are aes256-sha256-modp2048 in strongSwan.
3. The subnets on each side, checked for overlaps.
4. The identity each side sends.
5. How the pre-shared key travels, and who rotates it.
6. Who initiates, and the starting MTU.

Agree on those and the worked example is a short job. Skip them and you will spend the afternoon reading NO_PROPOSAL_CHOSEN in someone else's logs.

← All articles