Opened 17 months ago
Last modified 16 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: | |
Cc: |
Description
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
.
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)