I checked the 'server' options for 'push-route' and 'name-server' and even with these configured as opposed to the openvpn-option configuration entry, it still gives the "Options error" complaint about the push command.

Can you share your config please, with the statement that breaks your config. thx.

Hello,

I have included the requested configs (some portions of configs have been censored for security purposes). I have since rolled back to 1.1.8 for this and other reasons but I can confirm that this configuration works on 1.1.8 but not on 1.2.0.

set interfaces openvpn vtun1 description 'clientvpn'
set interfaces openvpn vtun1 encryption 'aes256'
set interfaces openvpn vtun1 local-port '1194'
set interfaces openvpn vtun1 mode 'server'
set interfaces openvpn vtun1 openvpn-option '--push route x.x.x.0 255.255.255.0'
set interfaces openvpn vtun1 openvpn-option '--push route x.x.x.0 255.255.255.0'
set interfaces openvpn vtun1 openvpn-option '--keepalive 10 120'
set interfaces openvpn vtun1 openvpn-option '--comp-lzo yes'
set interfaces openvpn vtun1 openvpn-option '--auth sha256'
set interfaces openvpn vtun1 openvpn-option '--push dhcp-option DNS x.x.x.4'
set interfaces openvpn vtun1 openvpn-option '--push dhcp-option DNS x.x.x.3'
set interfaces openvpn vtun1 protocol 'tcp-passive'
set interfaces openvpn vtun1 server subnet 'x.x.x.0/24'
set interfaces openvpn vtun1 tls ca-cert-file '/config/auth/ca.crt'
set interfaces openvpn vtun1 tls cert-file '/config/auth/server.crt'
set interfaces openvpn vtun1 tls dh-file '/config/auth/dh2048.pem'
set interfaces openvpn vtun1 tls key-file '/config/auth/server.key'

I went ahead and dug out the other configuration that doesn't work in 1.2.0 either. This is pulled from the config.boot file in the vyos 1.2.0 image i have installed.

openvpn vtun1 {
      description clientvpn
      encryption aes256
      hash sha256
      local-port 1194
      mode server
      protocol tcp-passive
      server {
          name-server x.x.x.4
          name-server x.x.x.3
          push-route x.x.x.0/24
          push-route x.x.x.0/24
          subnet x.x.x.0/24
      }
      tls {
          ca-cert-file /config/auth/ca.crt
          cert-file /config/auth/server.crt
          dh-file /config/auth/dh2048.pem
          key-file /config/auth/server.key
      }
      use-lzo-compression
  }

In T1246#33335, @gmurphy42 wrote:

I went ahead and dug out the other configuration that doesn't work in 1.2.0 either. This is pulled from the config.boot file in the vyos 1.2.0 image i have installed.

openvpn vtun1 {
      description clientvpn
      encryption aes256
      hash sha256
      local-port 1194
      mode server
      protocol tcp-passive
      server {
          name-server x.x.x.4
          name-server x.x.x.3
          push-route x.x.x.0/24
          push-route x.x.x.0/24
          subnet x.x.x.0/24
      }
      tls {
          ca-cert-file /config/auth/ca.crt
          cert-file /config/auth/server.crt
          dh-file /config/auth/dh2048.pem
          key-file /config/auth/server.key
      }
      use-lzo-compression
  }

I think this was fixed in T1259. The original issue about double quotes not being allowed in openvpn-option however still remains

In T1246#33342, @hagbard wrote:

@varesa so 'server push-route x.x.x.0/24' does work for you?
The double quotes are an issue with the parser and I doubt that if will be allowed in the future again.

It works... partially. I just noticed that while it syntactically correct enough that OpenVPN starts, it is actually missing the $variables inside the quotes as the patch changed double quotes to single quotes. That means that instead of --push "dhcp-option DNS 1.1.1.1" or --push "route 192.168.0.0 255.255.255.0" it started with --push "dhcp-option " and --push "route "

I've made a second PR to correct this: https://github.com/vyos/vyatta-openvpn/pull/8 (this belongs to T1259 but it looks like I don't have the power to reopen it)

This time verified more carefully with ps aux | grep openvpn to see that the parameters actually include the variables and also with cat /proc/$(pgrep openvpn)/cmdline | tr '\0' '\n' in order to check the correct quoting

What comes to the quoting of openvpn-option --push "xxx", if we do not want to introduce nested quotes to the parser, maybe we should have a second configuration option dedicated to --push?

Something like set interfaces openvpn vtun0 push-option "my option here" which would then generate a matching command like:
openvpn [...] --push "my option here"

Unless the parser/config structure could work with something like: openvpn-option <some-option> ["optional quoted string"]

Gotcha. I merged your PR.
PLease test with: http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-openvpn/vyatta-openvpn_0.2.60+vyos3+current2_all.deb

What comes to the quoting of openvpn-option --push "xxx", if we do not want to introduce nested quotes to the parser, maybe we should have a second configuration option dedicated to --push?

There is open-vpn server push-route or so available. Sooner or later that backend will be rewritten.

In T1246#33353, @hagbard wrote:

What comes to the quoting of openvpn-option --push "xxx", if we do not want to introduce nested quotes to the parser, maybe we should have a second configuration option dedicated to --push?

There is open-vpn server push-route or so available. Sooner or later that backend will be rewritten.

While pushing routes is available through another config option, not all pushable options are. The first thing that comes to mind is route-ipv6 which I actually got comments about in https://github.com/vyos/vyatta-openvpn/commit/a0d7c07f1ff0b5fe7450d3a13c1365b8e3589725

Something like IPv6 routes should probably be available through server { } just like the ipv4 routes are but it seems like a good idea to still keep the possibility of using some less common options without implementing and keeping each one of the up to date as standalone config options

Yes, I agree it's a good idea. In general, the openvpn package has ipv6 support already, the only missing part is rewriting the vyatta code to enable the user to actually use them.
I think we can close this task here and you may want to open a new request for rewriting the openvpn code, which will happen at one point in the future anyway. Another option would be that you rewrite the backend. I don't use openvpn, so I don't have a lot of experience with it.
Let me know what works for you best.

I should note that this is not my issue/task nor am I personally affected by it. I just pointed out that part of the original issue should be solved by my PR which originated from elsewhere and left my two cents about how to handle the other case here.

This of course doesn't exclude me from working on the parser/config generator further but it's not a high priority for me at this very moment and I'd probably like someone else decide the direction to take with this issue (e.g. what kind of command structure would be the best, what is the goal/basic direction of the rewrite, etc.)

Sorry comment on a resolved ticket, but i'm having the issue that is described in this issue. And i'm not sure how to fix it.

I'm trying to pass arguments to my --route-up script, like this:

set interfaces openvpn vtun0 openvpn-option "--route-up /config/auth/tun_up.sh arg1 arg2"

It doesn't work and openvpn will exit with:

Options error: the --route-up directive should have at most 1 parameter. To pass a list of arguments as one of the parameters, try enclosing them in double quotes ("").

The following doesn't work:

set interfaces openvpn vtun0 openvpn-option "--route-up '/config/auth/tun_up.sh arg1 arg2'"

and will give the error:

Cannot use the single quote (') character in a value string
Value validation failed
Set failed

Is there any solution for this?

Hi yun, please open a new ticket with your issue, and make a reference to this case :)

Sounds like a duplicate of T1632

Please use: set interfaces openvpn vtun0 openvpn-option "--route-up &quot;/config/auth/tun_up.sh arg1 arg2&quot;"

... I know it looks ugly!

Please also use a more recent VyOS build, e.g. 1.3 rolling or https://downloads.vyos.io/snapshot/vyos-1.2-snapshot-2019Q4-amd64.iso

As in rolling the OpenVPN is rewritten to XML/Python the backport is not easily possible, it must be completely reimplemented in the old Perl code thus we should encourage users to migrate to 1.3 rolling to get better testing.