pfSense – OpenVPN Server com Multi-Wan

/ jhonespetter

Quem nunca teve este cenário: uma Matriz com dois links que fecha VPN com as Filiais.

O mundo ideal é ter ativo a redundância para automatizar a troca em caso de uma indisponibilidade no link principal e minimizar o tempo de downtime do serviço. Objetivo aqui não é criar os confs todo da VPN e sim direcionar os pontos pertinentes para que funcione a Multi-Wan no OpenVPN Server, a homologação destas configurações foram feitas no pfSense 2.3.

1 - Cenário

OPENVPN-MULTIWAN2 - NAT

Essa configuração é uma das principais, pois iremos direcionar toda entrada na porta 1194 em ambos links para 127.0.0.1:1194, ou seja, a loopback firewall:

3 - OpenVPN Server

Na interface ao invés de setar a interface WAN1 ou WAN2 setamos a Localhost (127.0.0.1) e a porta utilizada, pois acima fizemos o NAT das duas interfaces direcionando a Localhost:

openvpn1Abaixo o direcionamento da rota:

openvpn2E por fim na parte do Server o Client Specific Override:

openvpn34 - OpenVPN Client

No client so devemos acrescentar em "Custom options" o parâmetro "remote" com o link secundário:

openvpn4 openvpn55 - Confs gerados

server.conf

client.conf

6 - Documentação referências

OpenVPN - https://openvpn.net/index.php/open-source/documentation/howto.html#loadbalance

Implementing a load-balancing/failover configuration

Client
The OpenVPN client configuration can refer to multiple servers for load balancing and failover. For example:

remote server1.mydomain
remote server2.mydomain
remote server3.mydomain

will direct the OpenVPN client to attempt a connection with server1, server2, and server3 in that order. If an existing connection is broken, the OpenVPN client will retry the most recently connected server, and if that fails, will move on to the next server in the list. You can also direct the OpenVPN client to randomize its server list on startup, so that the client load will be probabilistically spread across the server pool.

remote-random

If you would also like DNS resolution failures to cause the OpenVPN client to move to the next server in the list, add the following:

resolv-retry 60

The 60 parameter tells the OpenVPN client to try resolving each remote DNS name for 60 seconds before moving on to the next server in the list.

The server list can also refer to multiple OpenVPN server daemons running on the same machine, each listening for connections on a different port, for example:

remote smp-server1.mydomain 8000
remote smp-server1.mydomain 8001
remote smp-server2.mydomain 8000
remote smp-server2.mydomain 8001

If your servers are multi-processor machines, running multiple OpenVPN daemons on each server can be advantageous from a performance standpoint.

OpenVPN also supports the remote directive referring to a DNS name which has multiple A records in the zone configuration for the domain. In this case, the OpenVPN client will randomly choose one of the A records every time the domain is resolved.

Server
The simplest approach to a load-balanced/failover configuration on the server is to use equivalent configuration files on each server in the cluster, except use a different virtual IP address pool for each server. For example:

server1
server 10.8.0.0 255.255.255.0
server2
server 10.8.1.0 255.255.255.0
server3
server 10.8.2.0 255.255.255.0

pfSense - https://doc.pfsense.org/index.php/Multi-WAN_OpenVPN

OpenVPN Configuration
First, get OpenVPN working as desired on the primary WAN interface. Once it is properly functioning, make a backup just in case.

Bind to Localhost and Setup Port Forwards
The OpenVPN configuration needs to be adjusted so it can be reached from either WAN. The simplest way to do this is by changing the Interface on the VPN connection to be Localhost, and then adding a port forward on each WAN to redirect the OpenVPN port to Localhost (127.0.0.1).

For example: If there are two WANs and the OpenVPN server is running on port 1194, set the Interface to Localhost, then add two port forwards:

WAN1 - UDP, Source *, Destination WAN1 Address port 1194, redirect target 127.0.0.1 port 1194
WAN2 - UDP, Source *, Destination WAN2 Address port 1194, redirect target 127.0.0.1 port 1194

Configure Clients
Clients may be configured to use the second WAN by adding a second remote statement to their configuration, such as:

remote x.x.x.x 1194 udp

Where x.x.x.x is the second WAN IP address or host name.

This process can be automated by using the OpenVPN Client Export package. When exporting a client, in Host Name Resolution choose one of:

Automagic Multi-WAN IPs (port forward targets): Adds a remote statement for each port forward found targeting the interface binding and port used by this VPN, uses the IP address of each WAN as-is.
Automagic Multi-WAN DDNS Hostnames (port forward targets): Like above, but uses the first located Dynamic DNS hostname for a given WAN. If the WAN is a private IP, this may be the better choice.

More than two WAN connections
The same steps can be repeated to add more WAN connections. Add a port forward to any additional WAN. Clients will need an updated configuration file if another WAN is added later.

Aproveitar e documentar fixação IP no tunel:

Now place special configuration files in the ccd subdirectory to define the fixed IP address for each non-Employee VPN client.

ccd/sysadmin1

ifconfig-push 10.8.1.1 10.8.1.2

ccd/contractor1

ifconfig-push 10.8.2.1 10.8.2.2

ccd/contractor2

ifconfig-push 10.8.2.5 10.8.2.6

Each pair of ifconfig-push addresses represent the virtual client and server IP endpoints. They must be taken from successive /30 subnets in order to be compatible with Windows clients and the TAP-Windows driver. Specifically, the last octet in the IP address of each endpoint pair must be taken from this set: