Opened 3 months ago

Last modified 2 months ago

#1481 new Feature Wish

Please support `inactive` in `<connection>`

Reported by: András Korn Owned by:
Priority: minor Milestone:
Component: Configuration Version:
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:


I have several openvpn servers, and a well defined order of preference; I only want to connect to the 2nd or 3rd server if the 1st one is not available.

If I don't specify remote-random, openvpn will try them in the correct order; however, if the first server is not reachable, it will get stuck on the first lower-preference server that is available.

Currently there is no mechanism that would cause openvpn to periodically retry connecting to the first server.

I imagine implementing a mechanism that keeps trying to connect to the first server while retaining the active connection to the 2nd one would be relatively difficult; however, allowing users to specify inactive in lower-preference <connection> blocks would be a poor man's way of doing this.

I realize I can include inactive in the global configuration, but I would like to avoid disconnecting from the primary server if possible; I only want to disconnect from the secondaries.

I can't implement this on the server side, because I only actually have one server instance that has several public IPs (which are on different uplinks).

The next best solution would be to run a script from cron that checks where the running openvpn client is connected; if it's not the preferred server IP, then also checks whether the preferred server is available; and if yes, restarts the client. This feels even kludgier than abusing inactive.

Change History (1)

comment:1 Changed 2 months ago by Gert Döring

I'm not sure if I'm following. OpenVPN configs are read at startup, and not re-read while a connection is established - so even if we permit inactive in a <connection>, it would either "just never connect there", or "not do anything, as configs are not re-read".

As inactive won't solve your issue, indeed, checking from a cron job is what would get the job done (and does not feel very kludgey - you need to have the "check primary server and if it works, initiate the reconnect" somewhere, and OpenVPN inside cannot do it)

Note: See TracTickets for help on using tickets.