Overview #

When you connect to the internet through any Internet provider you don’t doubt that this provider will take all in consideration for ensuring that your connection is secure, but what if you want to connect to a private service? How to ensure that from client to server in public infrastructure the traffic is secure? It is here when VPN services or Virtual Private Network technologies is required. A secure connection is established between both nodes ensuring that no external agent will intercept the traffic obtaining sensible information.

VPN services provide several abilities such as:

Confidentiality: preventing anyone from reading your data. This is implemented with encryption.
Authentication: Verifying that members that create the point-to-point are legitimate devices.
Integrity: verifying that the VPN packet wasn’t changed somehow during transit.
Anti-replay: preventing someone from capturing traffic and resending it, trying to appear as a legitimate device/user.

There are different kinds of implementation in the market-based in privative and open standards, we will focus this article to the open solutions, see below the most relevant.

IPSEC: It has become the standard de facto for the VPN installations on the Internet, it implements a large number of cryptographic algorithms and it has not known major vulnerabilities.
OpenVPN: Very popular but not based in standards, it uses custom security protocols, it supports TLS/SSL with Openssl and a large number of cryptographic algorithms.
L2TP: It is an extension of PPTP, it can use IPSec as the security layer, mostly used in the past by ISPs. Currently, there are better options with better performance.
Wireguard: It is an extremely fast VPN, and extremely easy to install it, it uses the cryptographic algorithms already included in the Linux Kernel, it uses UDP and can be configured in any port.

Scalable VPN environment #

The goal of this article is to describe how to create a load balanced service with high availability setup for VPN services with Relianoid Load Balancer. We focus this article in Wireguard, which uses port 51820 UDP, but it can be extended to other similar solution with another protocol(s) and port(s).

In this article, the configuration of the VPN server is omitted but the following points have to be taken into consideration to scale VPN in high availability successfully:

The VPN server configuration files need to be replicated in all the VPN servers that will be balanced.
VPN clients traffic need to be NATed in the VPN server just to ensure that all the inbound and outbound connections from a APN client go through the same VPN server in the pool.

The following diagram describes the scalable architecture to reach.

1. Two Wireguard servers sharing the same configuration.
2. Each Wireguard server creates the same private network 192.168.2.0/24.
3. Each VPN client will be NATed with the IP of the VPN server where it’s connected.
4. The clients connect to one public IP vpn.company.com via 51820 UDP, this connection will be forwarded to Relianoid (192.168.100.10).
5. Relianoid will load balance the client connections to the available VPN servers and finally, the tunnel will be created against one of the servers.

In this article, we’re going to detail 2 different ways to configure this VPN scalable service with Relianoid: one via Web GUI and another via Command Line Interface.

VPN virtual service configuration with Relianoid #

This section explains how to reach the proper configuration with the command-line interface.

Take into consideration that VPN protocols require Persistence Session abilities in order to ensure that the same client is connected to the same Backend during a period of time even if this client doesn’t generate any traffic.

In order to create the VPN virtual service, a new farm called VPNLB with l4xnat profile listening on 51820 UDP bound to the VPN Virtual IP 192.168.100.10 and sNAT mode, where the firewall will NAT connections from clients with the following command:

zcli farm create -farmname VPNLB -vip 192.168.100.10 -vport 51820 -profile l4xnat

or via web GUI:

Modify the Global Parameters of the farm in order to use UDP protocol, then configure Persistence Session by Source IP and a simple Load Balancing Algorithm by Weight.

zcli farm set VPNLB -protocol udp -nattype nat -persistence srcip -ttl 1800 -algorithm weight

or via web GUI:

Add two Backend Servers 192.168.100.11 and 192.168.100.12 to the already created farm for the VPN load balance service. Port is not needed to be configured as the l4xnat is going to use the same as in the Virtual Port configured.

zcli farm-service-backend add VPNLB default_service -ip 192.168.100.11
zcli farm-service-backend add VPNLB default_service -ip 192.168.100.12

or via web GUI:

In order to select only healthy backends, let’s configure a simple health check for the backends that ensures the port 51820 UDP is available in the backend side. Make a copy of a current generic and pre-loaded health check called check_udp and edit it. We recommend to change the interval field to 21 because each health check uses a timeout of 10 seconds, so 10 seconds * 2 backends + 1 second = 21 seconds.

zcli farmguardian create -copy_from check_udp -name check_udp_vpn
zcli farmguardian set check_udp_vpn -description "VPN check for UDP 51820" -interval 21

or via web GUI:

Finally, add the already created health check called check_udp_vpn to the current farm VPNLB.

zcli farm-service-farmguardian add VPNLB default_service -name check_udp_vpn

DDoS attack mitigation with IPDS module #

VPN services are usually targets of attacks and cybersecurity threats in order to take advantage of the remote connectivity to enter the organization networks.

For that reason, it’s recommendable to complete our scalable VPN service with a security system to protect our organization from external attacks. The current section explains how to use the Relianoid IPDS module and mitigate DDoS attacks for public VPN Services very easily.

Two different protections are detailed in this section that has better results with this kind of service: IP protection via whitelists and connection limits.

Allowing access to the public VPN service from a given whitelist #

The usage of blacklist/whitelist can be used in services where we can ensure that the client list is known, for example, a public VPN service to allow telecommute in an organization of a certain country.

In order to configure a whitelist for Germany and reject traffic from other IP addresses country ranges, please apply the following:

1. Go to IPDS > Blacklist and find there the blacklist geo_ES_Germany. Then Edit this blacklist rule and change the policy field to Allow to be used as whitelist.
2. In the same list go to tab Farms and move the farm VPNLB from the column Available farms to Enable farms.
3. Press the Play icon included in Actions to enable the whitelist.
4. Go to IPDS > Blacklist and find there the blacklist All, go to tab Farms and move the farm VPNLB from column Available farms to Enable farms.
5. Press the Play icon of Actions to enable the blacklist.

With this configuration, one whitelist named geo_ES_Germany already preloaded in Relianoid with all the IP ranges in such country it’s added to the farm VPNLB and additional blacklist named All which the rest of IP addresses is added to the farm, so if the client IP doesn’t match in any range of Germany then it will be dropped.

Allowing access to the public VPN service with connection limits #

In order to apply this kind of DDoS protection is totally recommended to know how our public service works, for example, Wireguard uses only one UDP connection per client. So if we receive several concurrent connections from the same source IP then we can believe that more than one teleworker is connecting behind a NAT which is masquerading the traffic or it could be related to a UDP flood attack. In any case, we can understand than more than 10 connections per source IP is not a legitimated traffic.

In order to configure a limit of concurrent connections per source IP for our VPN virtual service please do the following:

1. Go to IPDS > DoS > Create DoS rule, create a new rule with name limit_per_source_IP and select the Rule type total connection limit per source IP and press Create.
2. In the rule edition form, enter the desired concurrent connections limit in the field Total connections limit per source IP, in our case 10 and press Submit.
3. Go the tab Farms and move the farm VPNLB from column Available farms to Enable farms.

With this configuration, we have limited the number of concurrent connections per source IP to 10, we don’t trust in any client IP which tries to establish more than 10 VPN connections. In case that you can ensure that more than one client is never going to run connections through any public NAT then the limit_per_source_IP could be configured to just 1.

Enjoy your scalable, highly available and secure VPN service with Relianoid!