1

I'm in Debian 7.8 Wheezy, and have installed openvpn from the stable repository.

I'd like to set up a system for another user (who does not have high computer literacy) where, if the primary server that I have configured (/path/to/one.ovpn) fails for some reason, I have a backup one (/path/to/two.ovpn) to automatically connect to instead, as a backup.

And maybe I give them ten .ovpn files (e.g. using free community servers from VPN Gate), to try really make sure the user is secured (assuming one of them works), without them having to manually do anything about it.

Is there a way in the default openvpn config, or some third-party GUI compatible with Debian, that can achieve this?

Or perhaps a script? (which I could then set to run at startup.)

Improve this question

3 Answers 3

Reset to default
4

I think the best you can do right now is to set up OpenVPN properly to inform it that there is second server, like this:

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.

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

Improve this answer
2
  • This is useful, but what if one server is TCP and the other is UDP? - the above doesn't seem to allow for that, it's either all servers must be UDP or TCP. Any ideas/suggestions? Commented Oct 27, 2016 at 10:45
  • That's correct, unfortunately no work around I can think of. I'd unify the configs to UDP only though. Commented Oct 31, 2016 at 13:14
0

Not enough rep to comment but I wanted to add that according to this page, it is possible to specify the protocol for each remote entry.

How do I set up my profile for server failover?

You can provide OpenVPN with a list of servers to connect to. On connection failure, OpenVPN will rotate through the list until it finds a responsive server. For example, the following entries in the profile will first try to connect to server A via UDP port 1194, then TCP port 443, then repeat the process with server B. OpenVPN will continue to retry until it successfully connects or hits the Connection Timeout, which can be configured in the Preferences.

remote server-a.example.tld 1194 udp remote server-a.example.tld 443 tcp remote server-b.example.tld 1194 udp remote server-b.example.tld 443 tcp
Improve this answer
0

See <connection> in https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage. This isn't exactly what you're looking for, but it comes close and may be helpful to others.

<connection> Define a client connection profile. Client connection profiles are groups of OpenVPN options that describe how to connect to a given OpenVPN server. Client connection profiles are specified within an OpenVPN configuration file, and each profile is bracketed by <connection> and </connection>. An OpenVPN client will try each connection profile sequentially until it achieves a successful connection.

--remote-random can be used to initially "scramble" the connection list.

Here is an example of connection profile usage:

client dev tun

<connection> remote 198.19.34.56 1194 udp </connection>

<connection> remote 198.19.34.56 443 tcp </connection>

<connection> remote 198.19.34.56 443 tcp http-proxy 192.168.0.8 8080 </connection>

<connection> remote 198.19.36.99 443 tcp http-proxy 192.168.0.8 8080 </connection>

persist-key persist-tun pkcs12 client.p12 remote-cert-tls server verb 3 First we try to connect to a server at 198.19.34.56:1194 using UDP. If that fails, we then try to connect to 198.19.34.56:443 using TCP. If that also fails, then try connecting through an HTTP proxy at 192.168.0.8:8080 to 198.19.34.56:443 using TCP. Finally, try to connect through the same proxy to a server at 198.19.36.99:443 using TCP.

The following OpenVPN options may be used inside of a <connection> block:

bind, connect-retry, connect-retry-max, connect-timeout, explicit-exit-notify, float, fragment, http-proxy, http-proxy-option, link-mtu, local, lport, mssfix, mtu-disc, nobind, port, proto, remote, rport, socks-proxy, tun-mtu and tun-mtu-extra.

A defaulting mechanism exists for specifying options to apply to all profiles. If any of the above options (with the exception of remote ) appear outside of a <connection> block, but in a configuration file which has one or more <connection> blocks, the option setting will be used as a default for <connection> blocks which follow it in the configuration file.

For example, suppose the nobind option were placed in the sample configuration file above, near the top of the file, before the first <connection> block. The effect would be as if nobind were declared in all <connection> blocks below it.

Improve this answer

You must log in to answer this question.