Page MenuHomeVyOS Platform

VyOS 1.2.0 "openvpn-options" configuration does not allow quotes in values
Closed, ResolvedPublicBUG

Description

Attempting to configure a remote access OpenVPN server. Coming from 1.1.8 this configuration worked correctly (openvpn was <2.4.0)

Now with version 2.4.0 of OpenVPN, when you attempt to push a configuration to an OpenVPN client, the openvpn '--push' command only expects one argument. In version 2.3.0 it didn't complain about this, but now it does. The following command (in openvpn) is considered invalid:

--push route 1.2.3.4 255.255.255.255

The following command is the correct command:

--push "route 1.2.3.4 255.255.255.255"

So if you try to apply:

set interface openvpn vtun1 openvpn-option "--push "route 1.2.3.4 255.255.255.255""

It will tell you the configuration path is invalid. If you try to escape out the inner set of quotes, it will give an error stating you cannot use double quotes inside a value string.

I've also tried this with single quotes with the same result. You cannot use single or double quotes within a value string.

The following error shows if you try to add the --push option without the inner set of quotes:

openvpn-vtun1[8025]: Options error: Unrecognized option or missing or extra parameter(s) in [CMD-LINE]:1: push (2.4.0)
openvpn-vtun1[8025]: Use --help for more information.

Details

Version
1.2.0-rolling+201902131655
Is it a breaking change?
Perfectly compatible
Issue type
Bug (incorrect behavior)

Event Timeline

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'
hagbard changed the task status from Open to In progress.Feb 27 2019, 7:07 PM

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
  }
hagbard triaged this task as Normal priority.Feb 27 2019, 8:06 PM
hagbard edited a custom field.

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

hagbard changed the task status from In progress to Needs testing.Feb 27 2019, 8:53 PM

@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.

@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"]

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.

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.)

Thanks, sounds good.

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 :)

syncer changed the task status from Resolved to Unknown Status.Aug 31 2019, 3:06 AM
syncer reassigned this task from hagbard to dmbaturin.
syncer moved this task from Need Triage to Finished on the VyOS 1.3 Equuleus board.
syncer added a subscriber: hagbard.

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.

c-po changed the task status from Unknown Status to Resolved.Feb 16 2020, 12:38 PM
c-po removed a project: VyOS 1.2 Crux (VyOS 1.2.5).
c-po set Is it a breaking change? to Unspecified (possibly destroys the router).
dmbaturin changed Is it a breaking change? from Unspecified (possibly destroys the router) to Perfectly compatible.Sep 29 2021, 1:38 PM
dmbaturin set Issue type to Bug (incorrect behavior).