Home / VPN Concentrator / 6WIND Virtual Security Gateway: The VPN Concentrator for Secure Communication
Company infrastructure is distributed in different locations. Whether it is the increasing usage of cloud providers such as AWS or Azure, the multiplication of local decentralized offices, employees hitting the road and working from remote locations or the advent of the Internet of Things (IoT), more and more internal data flows are crossing untrusted communication networks. We can leverage IPsec VPNs to secure these communications using 6WIND vSecGW (Virtual Security Gateway).
In today’s blog post, we’ll see how to easily deploy 6WIND Virtual Security Gateway vRouter as a high-availability IPsec VPN Concentrator cluster sustaining 10k tunnels and 20 Gbps of secured IPsec traffic.
Overview: Use case with 6WIND Virtual Security Gateway vRouter
In this post, we’ll focus on the detailed configuration of 6WIND Virtual Security Gateway vRouter in the following use case:
In this setup, we emulate the connection of a farm of uCPEs to our VPN Concentrator cluster.
An IXIA traffic generator sends traffic in both directions. The packets are ciphered between uCPEs and the VPN Concentrator.
The configuration of 6WIND Virtual Security Gateway nodes involves the following features:
IKE and IPsec synchronization over a dedicated link
Active/Hot Standby high availability for seamless failover
Advanced monitoring with metrics collected and sent to an EMS
The templates take care of all the cryptographic parameters. We only define the local IP address here, allowing connections to this address from any IP address. Note that the address defined here is the virtual IP address of the public VRRP interface built on top of the WAN interface. Additionally, we define the security policies with local and remote traffic selector subnets: initiators are allowed to negotiate the actual subnets protected by the Security Policies as subsets of these subnets.
We must ensure that the same node receives traffic on the LAN and the WAN interfaces and that this node is actually the one active from an IPsec point of view.
That’s why we define that the VRRP interfaces are grouped, thus binding their fate: each state transition of one interface implies the same transition for the other. This ensures that both virtual IP addresses are held by the same node at each time:
This VRRP group notifies the ha-group ha-group1 of each state transition. As we will see in the next paragraph, the IKE/IPsec HA daemon listens to these notifications via the listen-ha-group ha-group1 configuration item. As a result, the IKE daemon of each node is aware of the status of its respective sibling and knows if it should send or receive updates from the other node.
IKE and IPsec
To achieve the high-availability goal, we must keep the standby node synchronized with the active one regarding:
The currently established IPsec VPNs (installed Security Associations and the negotiated secrets)
Their current state (input and output sequence numbers of packets exchanged within a given IPsec VPN)
We enable this synchronization with the following configuration:
We first define the communication channel between both nodes with the local interface and remote- and local-addresses involved in the synchronization channel. Each node has its unique node-id. The configuration of vpnc2 is consequently the following:
This synchronization process ensures that each VPN established on the active node is also propagated to the standby one.
6WIND Virtual Security Gateway collects and sends advanced KPIs to a remote Element Management System (EMS) running InfluxDB, a time series database, which can be displayed by an analytics frontend such as Grafana. More information is at https://github.com/6WIND/supervision-grafana.
The configuration is pretty straight-forward as we only need to enable the KPI retrieval at the system level and to configure the EMS target in the main VRF:
influxdb-output url http://192.168.255.2:8086 database telegraf
Operation and resiliency
Let’s first establish a few IPsec VPNs by starting the traffic. We start the IXIA traffic generator and see that we can reach 18.9 Gbps of clear text traffic. With the overhead induced by the chosen IPsec algorithm this results in 20 Gbps of IPsec traffic between the uCPEs and the VPN concentrator:
We can monitor these IPsec VPNs from the VPN concentrator point of view:
Commands are available to list the established IPsec VPNs, get the total number of VPNs and retrieve the details of a particular one either from its originating IP address or from its originating ID.
We can also check that the traffic exchanged on the WAN interface is encrypted:
The monitoring dashboard available on the EMS provides an overview of the status:
Scaling to 10k VPNs
Let’s now establish 10k additional IPsec VPNs. We can follow the progress on the dashboard:
The 10k VPNs are successfully negotiated while dealing with 20 Gbps of IPsec traffic.
Let’s take a closer look at the initial state of the cluster by comparing the configuration and the status of vpnc1 (left) and vpnc2 (right):
The VRRP interfaces are declared with a higher priority on vpnc1, ensuring that this node becomes master initially. As a consequence, vpnc1 holds both WAN and LAN virtual IP addresses.
We then trigger the failover by simulating a temporary failure of the LAN network connection of vpnc1. Due to the grouping of the VRRP interfaces, vpnc2 takes over both virtual IP addresses:
As both nodes synchronized the IPsec VPN states, vpnc2 could take over the traffic as soon as the failover occurred. From an external point of view, nothing has changed:
LAN and WAN IP addresses have continuously been reachable
The IPsec traffic has been ciphered and deciphered without interruption
The matching dashboard on vpnc1:
And the matching dashboard on vpnc2:
Using 6WIND Virtual Security Gateway vRouter to implement a VPN concentrator solution will bring multiple benefits:
6WIND vRouter can run in any environment including commercial-off-the-shelf (COTS) servers and common virtualization infrastructures
6WIND vRouter management is NETCONF/Yang-based for easy automation
High IPsec throughput scaling with the number of cores allocated
Scales to several thousands of IPsec VPNs with a high establishment rate
Protection mechanisms against DDoS attacks
VRRP and IKE/IPsec High Availability for seamless failover
Advanced monitoring through KPIs exported to an analytics dashboard