Overriding ovpn file options on command line?

[tasket]

I have a project that allows Qubes OS users to drop-in ovpn configs sourced from various VPN service providers. However, there are special requirements to get DNS working after a link goes up.

It works fine if the users' VPN service did not specify their own DNS setup script in the ovpn file. Otherwise, if the file has "up" and "down" set, the --up and --down parameters that my project specifies on the command line are ignored.

This behavior appears to be the opposite of what I'd expect... that command line parameters should override the contents of a config file. Worse, it is inconsistent as there are other openvpn parameters which seem to be overridden by the command line.

How can I ensure that openvpn command line parameters take precedence over ovpn options?


BTW, the VPN guest OS is Debain 9 running openvpn 2.4.0 and the general use case is a PC user connecting to a "public" VPN service.

[tasket]

Bizzarre....

If I run it this way:

Code: Select all

openvpn --config client.ovpn --up myscript.sh

It gives an error (as before) that "providerscript.sh" from the ovpn doesn't exist.

But if I run it this way:

Code: Select all

openvpn --up myscript.sh --config client.ovpn

then it says "Multiple --up scripts defined. The previously configured script is overridden." This means it won't accept myscript.sh from the command line in either case!

[tasket]

Gets weirder....

If I specify --remote as the last argument, openvpn appears to ignore it. If its the first argument, then it overrides the ovpn.

If I specify auth-user-pass badfile in the ovpn, and specify --auth-user-pass goodfile on the command line... it will use the commandline setting.

And I tried it the opposite way, with the badfile on the command line. It uses the command line value always.


QUESTION: Is there a guide to the "multi-faceted" way openvpn prioritizes command line vs ovpn file options?

[tasket]

Its hard to believe how screwed-up OpenVPN's option parser is. Have a look...

Code: Select all

openvpn --config client.ovpn --up /usr/bin/qubes/myscript.sh  # uses ovpn up setting

openvpn --config client.ovpn --up myscript.sh                 # uses ovpn up setting

openvpn --up /usr/bin/qubes/myscript.sh --config client.ovpn  # uses ovpn up setting

openvpn --up myscript.sh --config client.ovpn                 # uses COMMAND LINE up setting!

I find that quite upsetting, don't you?

[ordex]

weird rather than upsetting...what version of OpenVPN are you using? -- edit: you already said it is 2.4.0 --
I normally use "--config X.conf --someoption" to override "someoption" and use the one provided on the command line. I am wondering if the "--up" option has a special treatment.

Still, note that some options allows multiple values. For example 'remote' can be specified multiple times, therefore providing an additional '--remote' on the command line will not override what's provided in the config, but will *append* an additional entry to the list.

What do you exactly get when running:

Code: Select all

openvpn --config client.ovpn --up /usr/bin/qubes/myscript.sh  # uses ovpn up setting

or

Code: Select all

openvpn --config client.ovpn --up myscript.sh                 # uses ovpn up setting

note that the script definitely needs an absolute or relative path, but it won't expand your $PATH

[tasket]

I also use CLI options to override file options, and I think that's the intention of openvpn's authors. But it seems like --up handling is just buggy.

When it comes to relative paths, I've made sure the working directory was already set correctly (I put the script in the same dir as configs) or else I used the --cd option to set it.

What I'll typically get is:

Code: Select all

Options error: --up script fails with 'scriptname.sh': No such file or directory
Options error: Please correct this error.

Further testing reveals that anytime there are multiple --up options and one of the files doesn't exist (which is the intent in my case, to override the setting for a non-existent script) then openvpn will try to use the non-existent one and error out on that. It doesn't matter in what order those --up options are specified or whether they're on the command line or in a file. ...... Plus, it doesn't like absolute paths.

So the only way to resolve this is to _process_ the config file with something like 'sed' to comment-out the up and down lines before running openvpn.

[ordex]

just checked the code: the script existence and accessibility (permissions) are verified exactly when the --up directive is parsed.
This means that the option parser does not get to the second/overriding --up option, but stops at the first "broken" one and exits.

About absolute paths: not sure what problem you are encountering, but I just tested them here and seem to work fine.