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.
OpenVPN assigned to a Gateway Group¶
A Gateway Group (Gateway Groups) may be selected as the Interface for an OpenVPN instance. Such a gateway group must be configured for failover only, not load balancing. Failover groups only have one gateway per tier. When creating the gateway group, a VIP may also be chosen for use with a specific gateway. When selected for a VPN server, the interface or VIP of the Tier 1 gateway in the group will be used first. If that gateway goes down, it will move 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, this means that the server is only active on one WAN at a time. Some of the other methods described below may be better 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 be used with any WAN connection, though the means of doing so will vary depending on the specifics of a given configuration.
OpenVPN server using TCP¶
TCP is not the preferred protocol for OpenVPN. However, using 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 method should be considered a last resort, and only used if the other methods are not viable.
This works because of the connection-oriented nature of TCP. The OpenVPN can reply back to the other end with the proper source preserved since it is part of an open connection.
OpenVPN server using UDP¶
OpenVPN servers with UDP are also multi-WAN capable, but with some caveats that aren’t applicable with TCP.
These OpenVPN limitations are due to the connectionless nature of UDP. 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 other side. For non-default WANs, that will not be the correct path.
Multiple Server Method¶
In some cases, each WAN must have its own OpenVPN server. The same certificates may be for all the servers. 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.
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 the LAN interface or Localhost and use a port forward from each WAN to direct the OpenVPN port to the service. Using this method the reply-to functionality in pf will ensure that the return traffic flows back to the proper source via the intended interface.
This method requires some 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 leave it attempting to connect to the wrong address. See OpenVPN Client Export Package for details
Automatic Failover for Clients¶
Multiple remote servers can be configured on OpenVPN clients. If the first
server cannot be reached, the second will be used. This can be used in
combination with a multi-WAN OpenVPN server deployment to provide automatic
failover for clients. If the OpenVPN servers are running on IP addresses
198.51.100.3 and 203.0.113.5, both using port 1194, the
remote lines in the
client configuration file will be as follows:
remote 198.51.100.3 1194 udp remote 203.0.113.5 1194 udp
For clients configured on pfSense, the first
remote is configured by the
Server Host or Address* field in the GUI. The second ``remote`` is specified
in the **Advanced field.
This method has three notable behaviors that some may find undesirable:
It will take at least 60 seconds to detect a failure and switch to the next server.
Any connection failure will cause it to try the second server, even if it is not a WAN failure.
It will not “fail-back”. Once a client connects to the second server IP address it will stay there until disconnected.
OpenVPN Clients and Multi-WAN¶
To use an OPT WAN interface, select it as the Interface. OpenVPN clients configured on the firewall will respect the chosen Interface and a static route is added automatically behind the scenes to ensure traffic takes the correct path.
If the interface is instead set to any, the client will follow the system routing table when making the connection to the OpenVPN server. In this case a manual static route will be required to direct traffic to the remote endpoint over the desired WAN.
OpenVPN Site-to-Site with Multi-WAN and OSPF¶
Building upon concepts from earlier in the chapter, it is possible to configure a redundant VPN using a dynamic routing protocol such as OSPF as seen in Figure Example OpenVPN Setup Involving OSPF Across Multiple WANs.
First, setup shared key site-to-site OpenVPN instances on each WAN for the remote sites. Do not fill in the Remote Networks fields on either side, only Tunnel Network addresses.
Setup two servers on the local side, each on a different port. Use two distinct, non-overlapping tunnel networks (e.g.
Setup two clients on the remote firewall, each paired up with one of the above servers, matching the IP addresses and port numbers involved.
Ensure the clients are set for their specific WAN, choose the interface from the drop-down menu, or a CARP VIP that is on one of the WANs being used.
Ensure these OpenVPN connections link up between client and server. The tunnel address on both sides will respond to a ping when they are working correctly. If the tunnels do not establish, see Troubleshooting OpenVPN for suggestions on troubleshooting the connection.
Ensure the OpenVPN firewall rules allow all traffic or at least allow OSPF traffic from a source of the tunnel networks to a destination of any. The destination on the traffic will be a multicast address, which can be used to filter specifically if needed, but there isn’t much to be gained in the way of security if the source is locked down in the rules as the traffic cannot leave that segment.
Once both instances are connected, configure OSPF.
Install the Quagga_OSPF package from System > Packages, Available Packages tab on both firewalls.
Navigate to Services > Quagga OSPFd, Interfaces tab
Add each OpenVPN interface
Set the cost to
10on the primary link and
20on the secondary, and so on
Add the LAN and other internal interfaces as passive interfaces
Navigate to the Global Settings tab
Enter a Master Password. It doesn’t matter what it’s set to, it is used internally for accessing the status daemon.
Set the Router ID to an IP-address-like value, (e.g.
10.3.0.1.) The Router ID is unique on each device, which is why setting it to the LAN IP address of a router is a good practice.
Set the Area ID which is also an IP-address-like value. The Area ID is typically set to
0.0.0.1, but any properly-formatted value may be used. The Area ID is the same for all routers involved in this VPN
Once OSPF has been configured on all routers, they will attempt to form a neighbor relationship.
After OSPF has been setup on both ends the Status tab will show a full peering with each instance on each wan if they connected properly, and the routes obtained via OSPF will be listed. Once that happens, try unplugging/replugging WANs and refreshing the status while running some test traffic across the VPN, such as an ICMP ping.