Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1421241 - Options error: Unrecognized option or missing or extra parameter(s) in [CMD-LINE]:1: tls-remote (2.4.0)
Summary: Options error: Unrecognized option or missing or extra parameter(s) in [CMD-L...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager-openvpn
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1421499 1421592 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-10 17:21 UTC by Kamil Páral
Modified: 2017-03-02 01:21 UTC (History)
17 users (show)

Fixed In Version: NetworkManager-openvpn-1.2.8-2.fc25
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-02 01:21:29 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 776045 0 Normal RESOLVED Unrecognized option or missing or extra parameter(s) in [CMD-LINE]:1: tls-remote (2.4_rc1) 2020-09-07 13:35:21 UTC

Description Kamil Páral 2017-02-10 17:21:46 UTC
Description of problem:
After upgrading from openvpn-2.3.14-1.fc25.x86_64 to 2.4.0-1.fc25.x86_64, I can no longer connect to my corporate VPN. Journal says:

Feb 10 18:16:54 dryad NetworkManager[917]: <info>  [1486747014.5447] audit: op="connection-activate" uuid="5777c2b4-defc-46f1-9858-2b850d51587c" name="Brno (BRQ)" pid=1764 uid=1000 result="success"
Feb 10 18:16:54 dryad NetworkManager[917]: <info>  [1486747014.5511] vpn-connection[0x561bc50a0160,5777c2b4-defc-46f1-9858-2b850d51587c,"Brno (BRQ)",0]: Started the VPN service, PID 2461
Feb 10 18:16:54 dryad NetworkManager[917]: <info>  [1486747014.5606] vpn-connection[0x561bc50a0160,5777c2b4-defc-46f1-9858-2b850d51587c,"Brno (BRQ)",0]: Saw the service appear; activating connection
Feb 10 18:17:01 dryad NetworkManager[917]: <info>  [1486747021.0090] keyfile: update /etc/NetworkManager/system-connections/BRQ.ovpn (5777c2b4-defc-46f1-9858-2b850d51587c,"Brno (BRQ)")
Feb 10 18:17:01 dryad NetworkManager[917]: <info>  [1486747021.0196] vpn-connection[0x561bc50a0160,5777c2b4-defc-46f1-9858-2b850d51587c,"Brno (BRQ)",0]: VPN plugin: state changed: starting (3)
Feb 10 18:17:01 dryad NetworkManager[917]: <info>  [1486747021.0197] vpn-connection[0x561bc50a0160,5777c2b4-defc-46f1-9858-2b850d51587c,"Brno (BRQ)",0]: VPN connection: (ConnectInteractive) reply received
Feb 10 18:17:01 dryad NetworkManager[917]: Options error: Unrecognized option or missing or extra parameter(s) in [CMD-LINE]:1: tls-remote (2.4.0)
Feb 10 18:17:01 dryad NetworkManager[917]: Use --help for more information.
Feb 10 18:17:01 dryad NetworkManager[917]: <warn>  [1486747021.0291] vpn-connection[0x561bc50a0160,5777c2b4-defc-46f1-9858-2b850d51587c,"Brno (BRQ)",0]: VPN plugin: failed: connect-failed (1)
Feb 10 18:17:01 dryad NetworkManager[917]: <warn>  [1486747021.0294] vpn-connection[0x561bc50a0160,5777c2b4-defc-46f1-9858-2b850d51587c,"Brno (BRQ)",0]: VPN plugin: failed: connect-failed (1)
Feb 10 18:17:01 dryad NetworkManager[917]: <info>  [1486747021.0294] vpn-connection[0x561bc50a0160,5777c2b4-defc-46f1-9858-2b850d51587c,"Brno (BRQ)",0]: VPN plugin: state changed: stopping (5)
Feb 10 18:17:01 dryad NetworkManager[917]: <info>  [1486747021.0294] vpn-connection[0x561bc50a0160,5777c2b4-defc-46f1-9858-2b850d51587c,"Brno (BRQ)",0]: VPN plugin: state changed: stopped (6)
Feb 10 18:17:01 dryad NetworkManager[917]: <info>  [1486747021.0303] vpn-connection[0x561bc50a0160,5777c2b4-defc-46f1-9858-2b850d51587c,"Brno (BRQ)",0]: VPN plugin: state change reason: unknown (0)
Feb 10 18:17:01 dryad NetworkManager[917]: <info>  [1486747021.0313] vpn-connection[0x561bc50a0160,5777c2b4-defc-46f1-9858-2b850d51587c,"Brno (BRQ)",0]: VPN service disappeared


Version-Release number of selected component (if applicable):
openvpn-2.4.0-1.fc25.x86_64

How reproducible:
always

Steps to Reproduce:
1. try to active vpn in gnome
2. type in password
3. see "vpn activation failed" message immediately after confirming

Comment 1 Gwyn Ciesla 2017-02-10 17:36:14 UTC
I'm updating NetworkManager-openvpn, see if this build helps when it's done.

https://koji.fedoraproject.org/koji/taskinfo?taskID=17729210

Comment 2 David Sommerseth 2017-02-10 17:47:00 UTC
Dan Williams (dcwb) should already have received a heads-up about these potential issues in late november/early december 2016 regarding this issue.  I understood they already had fixed this.

--tls-remote have been deprecated since v2.3.0 (released January 2013) and already at that point had the much improved replacement in-place since that time.  The syntax of --verify-x509-name is different, but more flexible and supports UTF-8 characters properly.  See the man page for more information.

For the record, I am running NetworkManager-openvpn-1.2.6-1.el7.x86_64 (Scientific Linux 7.3) ... and I see it uses --verify-x509-name instead of --tls-remote.

Comment 3 Thomas Haller 2017-02-10 18:48:32 UTC
Recent versions of the plugin support --verify-x509-name.

Since openvpn removed an option, NetworkManager-openvpn can do nothing here automatically.


Maybe the GUI should now be updated to make it more obvious that tls-remote is defunct. But in the end, there is no solution and users are forced to modify their existing configurations.

upstream: https://bugzilla.gnome.org/show_bug.cgi?id=776045

Comment 4 Thomas Haller 2017-02-13 08:58:38 UTC
*** Bug 1421499 has been marked as a duplicate of this bug. ***

Comment 5 Thomas Haller 2017-02-13 08:59:56 UTC
*** Bug 1421592 has been marked as a duplicate of this bug. ***

Comment 6 David Sommerseth 2017-02-13 09:30:12 UTC
The nm-openvpn plug-in could disable the --tls-remote variant in the UI and in existing configuration convert it to the new syntax.

IIRC ... the eqvivalent of

      --tls-remote host.example.com 

should be

      --verify-x509-name host.example.com name

The 'name' type should match against the CN field of the X.509 subject.

The only difference here compared against --tls-remote is that there are no character replacements, where some less used characters (typically outside a-z, A-Z and 0-9) are changed to _ (underscore).  I believe the majority of users uses normal hostnames in the server CN, so this could ease the migration.

Further the plug-in could issue a warning if --tls-remote is used and an underscore is found in the match value.

Comment 7 Thomas Haller 2017-02-13 10:10:22 UTC
(In reply to David Sommerseth from comment #6)
> The nm-openvpn plug-in could disable the --tls-remote variant in the UI and
> in existing configuration convert it to the new syntax.

yes, the nm-connection-editor UI should be improved to strongly discourage the tls-remote option, possibly with a warning that it might make your connection non-working.

The upstream bug is still open to improve here, but these changes only make the issue more discoverable to the user. The user is still required to manually fix the connection.


> IIRC ... the eqvivalent of
> 
>       --tls-remote host.example.com 
> 
> should be
> 
>       --verify-x509-name host.example.com name
> 
> The 'name' type should match against the CN field of the X.509 subject.
> 
> The only difference here compared against --tls-remote is that there are no
> character replacements, where some less used characters (typically outside
> a-z, A-Z and 0-9) are changed to _ (underscore).  I believe the majority of
> users uses normal hostnames in the server CN, so this could ease the
> migration.

... so it's not really equivalent :)

Apparently it was desired by openvpn 2.4 to break configurations with --tls-remoted, otherwise it could just have kept the option. Which raises the question why the nm-openvpn should behave any different here.

But yes, probably this should be done. A user just doesn't care for the reasons his configuration breaks. (as always: patches welcome).


> Further the plug-in could issue a warning if --tls-remote is used and an
> underscore is found in the match value.

Comment 9 David Sommerseth 2017-02-13 10:30:37 UTC
(In reply to Thomas Haller from comment #7)
> (In reply to David Sommerseth from comment #6)
[...snip...]
> > The only difference here compared against --tls-remote is that there are no
> > character replacements, where some less used characters (typically outside
> > a-z, A-Z and 0-9) are changed to _ (underscore).  I believe the majority of
> > users uses normal hostnames in the server CN, so this could ease the
> > migration.
> 
> ... so it's not really equivalent :)

Fair point :)

> Apparently it was desired by openvpn 2.4 to break configurations with
> --tls-remoted, otherwise it could just have kept the option. Which raises
> the question why the nm-openvpn should behave any different here.

To be fair, the --tls-remote feature was deprecated officially in OpenVPN v2.3.1, released March 27, 2013 (just re-checked commit logs - we removed it in v2.3.0 and introduced a compatibility wrapper in v2.3.1).  And it has been labelled with "DEPRECATED" in the man page since that release, even saying "It will be removed in either in OpenVPN v2.4 or v2.5".  Plus we also reminded people about this being removed all back to v2.4_beta1 (released Nov 17, 2016).  I also got in touch with Dan Williams around the same time, to ensure nm-openvpn would be able to tackle this situation.

But in retrospect, we could probably have made even more noise about this.  This is something we need to discuss in the OpenVPN developers community.

With that said, OpenVPN v2.4 carries 240+ configuration options.  So we do need to remove deprecated features from time to time; we already have way too many options.  But on the other hand, we do feel that giving a few years of adoption time is fairly generous.

> But yes, probably this should be done. A user just doesn't care for the
> reasons his configuration breaks. (as always: patches welcome).

:)  Yeah, users just want things to work.

Comment 10 Thomas Haller 2017-02-13 13:33:42 UTC
(In reply to Thomas Haller from comment #7)
> But yes, probably this should be done. A user just doesn't care for the
> reasons his configuration breaks. (as always: patches welcome).

patches for review on upstream bug:

https://bugzilla.gnome.org/show_bug.cgi?id=776045#c3

Comment 11 David Sommerseth 2017-02-13 16:28:47 UTC
I have only glared at the code, and I do not have too much experience inside the nm-openvpn plug-in source code and no build setup for NetworkManager stuff.  But this looks like a very reasonable approach.  When there is an EL7 build available, I can definitely test this for you (currently running Scientific Linux 7.3 x86_64, which is a RHEL 7.3 clone).

Just one comment to a sentence in your commit message:
"[...} or ever worse, that it wronlgy accepts a server that should be rejected."

I don't dare to say this is completely wrong, but I really struggle to imagine a way this could be abused.

A typical attack vector would be a MITM attack, where the client connects to a different server without being aware of it.  For this to work out, the server must provide to the client a server certificate signed by the same CA as the real OpenVPN server, otherwise OpenVPN will reject the server regardless.  So just here it will be a big challenge.  Secondly, the CN field of the certificate the MITM server provides need to consider a remapping which is not happening.  Such an attack scenario sounds more like to be of more academic interest than a realistic attack vector.  But I might overlook something.

On the other side, you are right that some servers which provides a value typically *not* being a normal host name in the CN field might get the connection rejected.  So if the CN value is "VPN Server (1)", the old remapping would end up with "VPN_Server__1_" (which would be the value used with --tls-remote).  But with a typical normal host name, this should not be an issue at all.

And to be honest, the --tls-remote feature worked poorly in use cases where the CN was not a typical host name.  Just mix in UTF-8 and other "national characters" and you're got a challenge.  These are some of the areas --verify-x509-name tries to fix.

Comment 12 Thomas Haller 2017-02-13 23:32:06 UTC
(In reply to David Sommerseth from comment #11)

I think a false-positive of rejecting a server that would have been accepted by --tls-remote is acceptable. The user really should fix the configuration.

I would be more concerned about a scenario where tls-remove would have rejected the server, but the verify-x509-name workaround doesn't.
If you say, "I really struggle to imagine a way this could be abused", that is a good thing, although I am not 100% sure that such a case cannot happen (and neither you "dare to say"). That's why I'd leave that remark there.

Comment 13 Peter Gervase 2017-02-15 12:44:54 UTC
As a workaround, I rpm -Uvh --oldpackage openvpn-2.3.12-1.fc26.x86_64.rpm NetworkManager-openvpn-1.2.6-1.fc26.x86_64.rpm NetworkManager-openvpn-gnome-1.2.6-1.fc26.x86_64.rpm
from:
https://koji.fedoraproject.org/koji/buildinfo?buildID=793933
https://koji.fedoraproject.org/koji/buildinfo?buildID=806543
and I'm now able to get back in my corporate vpn.

Comment 15 Kamil Páral 2017-02-15 13:44:30 UTC
(In reply to Peter Gervase from comment #13)
> As a workaround, I rpm -Uvh --oldpackage openvpn-2.3.12-1.fc26.x86_64.rpm

If you installed the "broken" openvpn package and need to downgrade immediately, the easiest way to do that is "sudo dnf distro-sync --disablerepo=updates-testing" (you might specify just those packages you want to downgrade).

Comment 16 Stephen Gallagher 2017-02-27 12:51:44 UTC
(In reply to Thomas Haller from comment #14)
> Workaround merged upstream:
> https://git.gnome.org/browse/network-manager-openvpn/commit/
> ?id=37d6dc4c521ebce71313e9ea757f90cd7eefc7d2

It has been twelve days since this fix went upstream. If there isn't an imminent upstream release, can we please get a downstream build with this patch ASAP? Those of us on Rawhide really need this working again...

Comment 17 Thomas Haller 2017-02-27 15:06:30 UTC
(In reply to Stephen Gallagher from comment #16)
> (In reply to Thomas Haller from comment #14)
> > Workaround merged upstream:
> > https://git.gnome.org/browse/network-manager-openvpn/commit/
> > ?id=37d6dc4c521ebce71313e9ea757f90cd7eefc7d2
> 
> It has been twelve days since this fix went upstream. If there isn't an
> imminent upstream release, can we please get a downstream build with this
> patch ASAP? Those of us on Rawhide really need this working again...

btw, you can also fix your configuration not to use the deprecated option. That is what "openvpn" wants you to do.

But sure, I agree a rawhide build should be done.

Comment 18 Fedora Update System 2017-02-27 17:21:29 UTC
NetworkManager-openvpn-1.2.8-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-3870a93455

Comment 19 Fedora Update System 2017-03-01 02:53:15 UTC
NetworkManager-openvpn-1.2.8-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-3870a93455

Comment 20 Fedora Update System 2017-03-02 01:21:29 UTC
NetworkManager-openvpn-1.2.8-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.