Page MenuHomePhabricator

VyOS 1.2.0 "openvpn-options" configuration does not allow quotes in values
Backport candidate, NormalPublicBUG

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

Difficulty level
Normal (likely a few hours)
Version
1.2.0-rolling+201902131655
Why the issue appeared?
Will be filled on close

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.

hagbard claimed this task.Feb 23 2019, 3:54 PM
hagbard added a comment.EditedFeb 27 2019, 6:41 PM

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 changed Difficulty level from Easy (less than an hour) to Normal (likely a few hours).
varesa added a subscriber: varesa.Feb 27 2019, 8:15 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
  }

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.

varesa added a comment.EditedFeb 28 2019, 10:21 PM

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

hagbard closed this task as Resolved.Feb 28 2019, 10:39 PM

Thanks, sounds good.

yun added a subscriber: yun.May 17 2019, 2:20 PM

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?

runar added a subscriber: runar.May 17 2019, 2:41 PM

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

kHub added a subscriber: kHub.Aug 5 2019, 6:45 PM
syncer reopened this task as Backport candidate.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.
pasik added a subscriber: pasik.Sep 4 2019, 8:07 PM