OpenVPN and Multi-WAN

OpenVPN is multi-WAN capable, with some caveats in certain circumstances. This section covers multi-WAN considerations with OpenVPN server and client configurations.

See also

• Multiple WAN Connections

• Routing

• OpenVPN Site-to-Site with Multi-WAN and OSPF

OpenVPN assigned to a Gateway Group

A Gateway Group (Gateway Groups) may be selected as the Interface for an OpenVPN instance. Gateway groups for this purpose must be failover only (one gateway per tier), not load balancing.

Gateway groups can also be set to use a VIP for a specific gateway. When OpenVPN uses a gateway group set this way on a server instance, it will use the interface or VIP of the Tier 1 gateway in the group first. If that gateway goes down, it moves to tier 2, and so on. If the tier 1 gateway comes back up, the VPN will resume operating on that WAN immediately.

When used for a VPN server the server can only be active on one WAN at a time. Some of the other methods described below may be a better fit for most common circumstances, such as needing both WANs usable concurrently with the VPN. When used with OpenVPN clients, the outbound interface will be switched according to the gateway group tiers.

OpenVPN servers and multi-WAN

OpenVPN servers can use any WAN connection, though the methods vary depending on the specifics of a given configuration.

OpenVPN server using TCP

TCP is not the best practice protocol for OpenVPN. However, TCP can make multi-WAN OpenVPN easier to configure when the VPN is using an interface setting of any. OpenVPN servers using TCP will work properly on all WANs where the firewall rules allow the traffic to the OpenVPN server. A firewall rule is required for each WAN interface.

This works because of the connection-oriented nature of TCP. OpenVPN can reply back to the other end with the proper source preserved since it is part of an open connection.

Warning

This method should be considered a last resort. Using a protocol choice which includes multihome works properly for UDP on multiple WANs and is a better alternative. Only use TCP if the other methods are not viable.

OpenVPN server using UDP

OpenVPN servers with UDP are also multi-WAN capable, but with some caveats that aren’t applicable with TCP.

The protocol choice for UDP on IPv4 and IPv6 on all interfaces (multihome) will work properly on all WANs and respond back using the address clients expect.

These other UDP modes in OpenVPN are limited by the connectionless nature of UDP. In these cases, the OpenVPN instance replies back to the client, but the Operating System selects the route and source address based on what the routing table believes is the best path to reach the peer. For non-default WANs, that will not be the correct path or the address the peer used when contacting this VPN.

Multiple Server Method

In certain cases each WAN may require its own OpenVPN server. The server instances may all use the same certificates. Only two parts of the OpenVPN configuration must change:

Tunnel Network

Each server must have a unique Tunnel Network that does not overlap with any other tunnel network or internal subnet.

Interface

Each OpenVPN server must specify a different WAN Interface.

Port forward method

An easier and more flexible option is to bind the OpenVPN server to Localhost or the LAN interface and use port forwards on each WAN to direct the OpenVPN port to the service. This method takes advantage of the reply-to functionality in pf which returns traffic flows back to the proper source via the interface from which the packet originated.

Note

This method requires minor manual intervention when used with the client export package. The Host Name Resolution option must be set to one of the automatic port forward methods otherwise the default export settings would have clients connecting to the wrong address. See OpenVPN Client Export Package for details.

Automatic Failover for Clients

OpenVPN clients can use multiple remote servers. If a client cannot reach the first server, it will attempt a connection to the second server, and so on until it runs out of servers. Then it starts over again.

See also

Additional Servers describes this concept and its configuration in more detail.

This behavior can be used in combination with a multi-WAN OpenVPN server deployment to provide automatic failover for clients. If the OpenVPN servers use IP addresses of 198.51.100.3 and 203.0.113.5 with port 1194, the remote lines in the client configuration file would be:

remote 198.51.100.3 1194 udp
remote 203.0.113.5 1194 udp

For clients configured on pfSense® software, the first remote is set by the Server Host or Address field in the GUI. Additional remote statements must be in the Custom options field.

This method has three notable behaviors that some may find undesirable:

• Clients will take at least 60 seconds to detect a failure and switch to the next server.

  This can be fine-tuned by adjusting the keep alive parameters that the server pushes to clients, but making it too sensitive will also be problematic.

• Any connection failure will cause clients to try the next server, even if it is not a WAN failure.

• Clients will not automatically reconnect to the first server when it recovers.

  Once a client connects to another server it will stay there until it gets disconnected again.

OpenVPN Clients and Multi-WAN

To use an OPT WAN interface, select it as the Interface. OpenVPN clients configured on the firewall will bind to the chosen Interface, but may require a manual static route for the server address to ensure traffic takes the correct path.

If the interface is set to any, the client will automatically follow the system routing table when selecting the interface and IP address it uses when connecting to the server.

Tip

For some cases, using the same gateway group for both the OpenVPN client and the system default route will result in the best failover behavior.