Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1001073: network-manager-openvpn: [bullseye] importing ovpn file using GUI results in non-functional VPN (fails due to auth timeout)
99 views
Skip to first unread message
Nicholas D Steeves
Dec 3, 2021, 1:10:04 PM12/3/21
to
Package: network-manager-openvpn
Version: 1.8.12-2
Severity: important
X-Debbugs-Cc: Michael Biebl <bi...@debian.org>, Mike Gabriel <sunw...@debian.org>
Control: tags bullseye upstream fixed-upstream
Dear Michael and Mike,
I'm CCing you because I suspect the Utopia team might not read bugs
sent to pkg-utopia-...@alioth-lists.debian.net...I'm sorry if
that's an unfair assessment, it just feels that way looking at the
bugs for network-manager-openvpn. Mike, apologies if you're not part
of the team--I seem to remember that you were involved in a
Utopia-related tray applet, but maybe not?
I discovered this bug when I upgraded to testing before bullseye's
release, and I'm sorry that I did not report it until now.
With KDE/Plasma, after importing an OpenVPN configuration from an ovpn
config file, using the KDE/Plasma NM gui, the OpenVPN connection fails
after timing out during authentication. Beyond that, there was
nothing useful in the log. A manual CLI OpenVPN connection worked
100% fine. I initially thought that the bug was in the config import
function, so after importing, I manually configured the connection to
the settings that are specified in the ovpn file, and the ones that I
knew would work. Same problem...
The nature of this bug appears to be that network-manager-openvpn does
not pass the configuration defined in the GUI to OpenVPN daemon, thus
the OpenVPN connection fails.
I then created a local bpo of network-manager-openvpn_1.8.16-1, and
installed it, to see if this would solve the problem. It solved the
problem.
The fix for bullseye should cherry-picked from upstream VCS to make
this package usable on Debian stable, because "The Debian Desktop
doesn't work with commercial VPNs" harms Debian's reputation IMHO.
Regards,
Nicholas
Version: 1.8.12-2
Severity: important
X-Debbugs-Cc: Michael Biebl <bi...@debian.org>, Mike Gabriel <sunw...@debian.org>
Control: tags bullseye upstream fixed-upstream
Dear Michael and Mike,
I'm CCing you because I suspect the Utopia team might not read bugs
sent to pkg-utopia-...@alioth-lists.debian.net...I'm sorry if
that's an unfair assessment, it just feels that way looking at the
bugs for network-manager-openvpn. Mike, apologies if you're not part
of the team--I seem to remember that you were involved in a
Utopia-related tray applet, but maybe not?
I discovered this bug when I upgraded to testing before bullseye's
release, and I'm sorry that I did not report it until now.
With KDE/Plasma, after importing an OpenVPN configuration from an ovpn
config file, using the KDE/Plasma NM gui, the OpenVPN connection fails
after timing out during authentication. Beyond that, there was
nothing useful in the log. A manual CLI OpenVPN connection worked
100% fine. I initially thought that the bug was in the config import
function, so after importing, I manually configured the connection to
the settings that are specified in the ovpn file, and the ones that I
knew would work. Same problem...
The nature of this bug appears to be that network-manager-openvpn does
not pass the configuration defined in the GUI to OpenVPN daemon, thus
the OpenVPN connection fails.
I then created a local bpo of network-manager-openvpn_1.8.16-1, and
installed it, to see if this would solve the problem. It solved the
problem.
The fix for bullseye should cherry-picked from upstream VCS to make
this package usable on Debian stable, because "The Debian Desktop
doesn't work with commercial VPNs" harms Debian's reputation IMHO.
Regards,
Nicholas
Michael Biebl
Dec 3, 2021, 1:20:04 PM12/3/21
to
On 03.12.21 19:07, Nicholas D Steeves wrote:
> I then created a local bpo of network-manager-openvpn_1.8.16-1, and
> installed it, to see if this would solve the problem. It solved the
> problem.
>
> The fix for bullseye should cherry-picked from upstream VCS to make
> this package usable on Debian stable, because "The Debian Desktop
> doesn't work with commercial VPNs" harms Debian's reputation IMHO.
Right. Could you run a git bisect to find the commit which we need to
> I then created a local bpo of network-manager-openvpn_1.8.16-1, and
> installed it, to see if this would solve the problem. It solved the
> problem.
>
> The fix for bullseye should cherry-picked from upstream VCS to make
> this package usable on Debian stable, because "The Debian Desktop
> doesn't work with commercial VPNs" harms Debian's reputation IMHO.
cherry-pick=
Uploading a new upstream release 1.8.16 is probably not something the
stable release managers will ack but a targetted fix is more likely to
be accepted.
Regards,
Michael
Nicholas D Steeves
Dec 3, 2021, 2:50:03 PM12/3/21
to
Control: tags -1 bullseye upstream fixed-upstream
[snip]
Looking at the commit history, bisecting will be a waste of time,
because d1942fd from 1.8.16's HEAD^10 (very recent recent) is required
for bullseye's OpenVPN 2.5.x...honestly, without ovpn 2.5.x support,
this package looks RC buggy for bullseye and maybe it just doesn't have
many users? Ie: Maybe most of its more technical users are tracking
sid? My experience is that all less technical users who use a
commercial VPN use the proprietary application furnished by the provider
when they can't get our (and derivatives) network-manager-openvpn to
work properly.
Since 1.8.12, there are 20 relevant commits: 2 security related, 1
definitely needed, 1 needed for at least one well-known commercial VPN
provider, 1 likely needed, 1 nice to have, 1 for being a good netizen,
and the rest I either don't know how to test, or don't have the OpenVPN
knowledge to assess. I've added my annotations with the following
pattern "** ".
commit ab8ad62f0865d98210265327d8274a55c58e8db5
Author: Santiago Gala <sg...@redhat.com>
Date: Fri Sep 24 19:57:48 2021 +0200
helper: set the can-persist flag
OpenVPN is able to persist the connection across link changes and
outages. Set the can-persist flag in the configuration returned to
NetworkManager.
[bgal...@redhat.com: rewrote commit message]
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/40
** this one solves several outstanding bugs in the BTS. I think we want
this one, because users have been asking for it for years, and because
if a laptop loses an unreliable wifi link, the VPN will disconnect, and
then won't reconnect when the link is restored. I think the security
team would support this one.
commit f9286da94dbfa1d585f0dc8d2f57640d467e2193
Author: Beniamino Galvani <bgal...@redhat.com>
Date: Thu Jun 3 18:19:39 2021 +0200
helper: fix parsing of IPv6 configuration
If the server pushes, for example:
ifconfig-ipv6 2001:db8:f00:bebe::1003/64 2001:db8:f00:bebe::1
NetworkManager considers the first argument as the subnet and the
second as the peer, and so it does something equivalent to:
ip addr add dev tun0 2001:db8:f00:bebe::1003/64 peer 2001:db8:f00:bebe::1
which appears in the "ip -6 addr" output as:
inet6 2001:db8:f00:bebe::1003 peer 2001:db8:f00:bebe::1/128 scope global
valid_lft forever preferred_lft forever
Instead, according to 'man openvpn', NM should simply add address
2001:db8:f00:bebe::1003/64 and use the second argument as a fallback
gateway for the routes specified by '--route-ipv6'
** solves other bugs reported in the BTS
commit 3c47520e999d5301eec69838e11ad4053bef4f20
Author: Thomas Haller <tha...@redhat.com>
Date: Mon Jun 7 19:00:45 2021 +0200
service: assume that we run openvpn 2.4 or newer by default
Our version detection might fail or give the wrong result. So change
the code to assume (in case of unknown version) that we run version 2.4
or newer. By now, that should be the common case and we should only assume
to run 2.3 or older if we successfully detected it.
** the absence of this one might cause my bug, but I suspect this one isn't needed, because if it was someone would have filed a grave bug against network-manager-openvpn. Sorry, I'm not sure.
commit d1942fdc94786ea412aadda2bec8f6b9b9005c85
Author: Thomas Haller <tha...@redhat.com>
Date: Mon Jun 7 18:47:56 2021 +0200
service: fix detection of openvpn version
Since 2.5.0, `openvpn --version` no longer exits with
code 1. That broke the version detection.
https://github.com/OpenVPN/openvpn/commit/96ae327add16f06ac8bc28cfbf9ba0abfcc7129c
** This one must be backported
commit 353a521bc08e2c762e7c63d10f8e3233e9442b08
Author: Beniamino Galvani <bgal...@redhat.com>
Date: Fri Feb 19 10:03:41 2021 +0100
helper: ignore IPv4 configuration without an address
This is the same as commit 56bb08f2956e ("helper: ignore IPv6
configuration without an address") but for IPv4.
NetworkManager always rejects configurations without an address, so
ignore them. A configuration without address can be created, for
example, if the server advertises IPv4 routes or domains without an
address.
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/35
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/62
** I'm not sure if this one is needed. Can this information be gathered by introspecting a working connection or from logs?
commit 56bb08f2956e7e394b017344541e1b7ddf46f2b1
Author: Beniamino Galvani <bgal...@redhat.com>
Date: Wed Feb 10 12:01:37 2021 +0100
helper: ignore IPv6 configuration without an address
OpenVPN 2.5.0 started to pass incomplete IPv6 configurations when the
server is not fully configured for IPv6 but has some IPv6
directives. For example, it is enough to add 'push "route-ipv6 ::/0"'
to a IPv4-only setup to trigger this behavior.
As a result, NetworkManager rejects the configuration as invalid and
the connection fails.
Fix this by ignoring IPv6 configurations without an address.
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/issues/64
** I'm not sure what method my commercial ipv6 service uses to block ipv6, but this commit is possibly related. eg: if it pushes some kind of /dev/null ipv6 route.
commit 717a1d41be0b039778b4eb85bca57f9356bb87aa (upstream-vcs/wip/ernestask/tls-crypt-v2-client)
Author: Ernestas Kulik <erne...@baltic.engineering>
Date: Mon Jan 11 17:30:13 2021 +0200
Handle tls-crypt-v2 keys
OpenVPN 2.5.0 adds client-specific tls-crypt keys under the tls-crypt-v2
option, which is currently not supported. This commit adds the necessary
import/export machinery to support it.
** I'm not sure if this is relevant to my bug or not... I use "tls-client"
and "remote-cert-tls server".
commit 34a0c9257aac9ed6e3ac7cdad6f6cc7d8107eef1
Author: Katelyn Schiesser <katelyn....@gmail.com>
Date: Wed Jul 8 11:32:32 2020 -0700
Handle the various pkcs12/cert/key/ca combinations.
OpenVPN allows supplying PKCS#12 client cert/key *or* PEM client cert/key, as
well as a PEM CA cert in either case. When supplying --pkcs12, the args --cert
and --key can not be used. So, you can have one of the following:
- PKCS#12 combined cert/key/ca (one file): --pkcs12
- PKCS#12 combined cert/key/ca with PEM CA: --pkcs12, --ca
- PEM cert/key, PEM CA: --cert, --key, --ca
If a user tries to import an invalid config, they will be met with the appropriate
error message. The editor dialog also enforces the PKCS#12/PEM restrictions.
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/29
** not relevant to my bug, but nice to have.
commit ba6c4bf1b827a1164032e0bf3cef0a72b79b66ae
Author: Thomas Haller <tha...@redhat.com>
Date: Fri Oct 23 15:21:57 2020 +0200
properties: fix string comparison in hash_copy_advanced() wrongly using NM_IN_SET()
CC properties/libnm_vpn_plugin_openvpn_editor_la-nm-openvpn-editor.lo
properties/nm-openvpn-editor.c:2508:6: warning: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) [-Wstring-compare]
if (NM_IN_SET (key, NM_OPENVPN_KEY_HTTP_PROXY_PASSWORD))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./shared/nm-utils/nm-macros-internal.h:531:45: note: expanded from macro 'NM_IN_SET'
#define NM_IN_SET(x, ...) _NM_IN_SET(||, typeof (x), x, __VA_ARGS__)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./shared/nm-utils/nm-macros-internal.h:526:45: note: expanded from macro '_NM_IN_SET'
#define _NM_IN_SET(op, type, x, ...) _NM_IN_SET_EVAL_N(op, type, x, NM_NARG (__VA_ARGS__), __VA_ARGS__)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./shared/nm-utils/nm-macros-internal.h:523:11: note: expanded from macro '_NM_IN_SET_EVAL_N'
!!_NM_IN_SET_EVAL_N2(op, _x, n, __VA_ARGS__); \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./shared/nm-utils/nm-macros-internal.h:515:50: note: expanded from macro '_NM_IN_SET_EVAL_N2'
#define _NM_IN_SET_EVAL_N2(op, _x, n, ...) (_NM_IN_SET_EVAL_##n(op, _x, __VA_ARGS__))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<scratch space>:54:1: note: expanded from here
_NM_IN_SET_EVAL_1
^
./shared/nm-utils/nm-macros-internal.h:498:53: note: expanded from macro '_NM_IN_SET_EVAL_1'
#define _NM_IN_SET_EVAL_1( op, _x, y) (_x == (y))
^ ~~~
** wow...don't you love commit messages like this? I have no clue if this is needed or not.
commit 667113138d3e27cb367e87090955e50885913407
Author: Katelyn Schiesser <katelyn....@gmail.com>
Date: Sat Oct 17 23:30:54 2020 -0700
Accept all valid 'proto' arguments.
OpenVPN allows for a bunch of different args for 'proto', namely 'udp' and 'tcp'
variants that include '4' or '6', and specific to tcp, '-client' suffixes. This
was already defined in shared/util.h; this commit changes the 'proto' check to
also use the 'NMOVPN_PROTCOL_TYPES' array, and adds test for all supported protos.
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/issues/59
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/30
** This one is likely needed!
commit e83b4f89962854f75475ef0fe86f938746c684db
Author: Ralph Benjamin Ruijs <ralph...@ing.com>
Date: Mon Jul 13 22:23:09 2020 +0200
Added option for allow-pull-fqdn
This allows the server to push routes that include DNS-names and not
just ips/networks. OpenVPN will then resolve those names and add the
routes accordingly.
As an example `push route google.com` will result in all traffic to
google.com be redirected over the vpn. The `up` scripts do not need
any special handling as they are passed the resolved options:
route_network_13=ip_1_of_google
route_network_12=ip_2_of_google
Co-authored-by: Florian Apolloner <flo...@apolloner.eu>
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/28
** I think it's likely commercial VPNs are using this. How can I test?
commit 483a04288b2b79e523901c85fba8b82379a323d2
Author: Katelyn Schiesser <katelyn....@gmail.com>
Date: Tue Jul 7 21:17:21 2020 -0700
Add --explicit-exit-notify by default when --proto udp
When using UDP, there is no transport-protocol method to notify the server
that the client has disconnected. For TCP, the socket closing signals the
server to close the peer instance; for UDP, the server must wait for a
configured --ping-exit, --keepalive, or similar to free up the connection.
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/24
** this one seems like a protocol correctness thing that one can't be a good netizens without. Ie: not needed for technical reasons per se, but for social/reputation ones.
commit 29d1e5d7dd730cd9fb985ee559b51db0009824ce
Merge: 93cec82 13080f3
Author: Beniamino Galvani <bgal...@redhat.com>
Date: Tue Jul 7 10:02:56 2020 +0200
merge: branch 'alexforrow/NetworkManager-openvpn-master'
Add remote-random-hostname support.
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/23
[pasted from MR: –remote-random-hostname Prepend a random string
(6 bytes, 12 hex characters) to hostname to prevent DNS
caching. For example, “foo.bar.gov” would be modified to
"<random-chars>.foo.bar.gov".
This change adds an option to the UI, import/export and the
appropriate flag to the OpenVPN executable.]
** this sounds like it potentially closes a CVE
commit 64c9877db25b2f3c3f77e64693dfb25229917cbf
Author: Alex Forrow <al...@forrow.com>
Date: Wed May 27 23:16:08 2020 +0100
support for remote-random-hostname parameter
** I know of at least one popular commercial VPN service that uses this
commit 67d9ebb4f2b58287162284619168224afc04d9e0
Author: Thomas Haller <tha...@redhat.com>
Date: Thu Apr 23 09:47:26 2020 +0200
helper: cleanup parsing foreign_option_* environment variables
There is no need to restrict parsing to 256 variables. Just continue
iterating until we find a variable that is missing.
Also, don't use magical numbers
- tmp += 12; /* strlen ("dhcp-option ") */
+ tmp += NM_STRLEN ("dhcp-option ");
** seems relevant, but sorry, I don't know if it's needed
commit c4ad1b66f090e5a2ae782d7d7067a658587909bd
Merge: 5b038a5 faa15cd
Author: Thomas Haller <tha...@redhat.com>
Date: Mon Mar 30 10:02:44 2020 +0200
merge branch 'EmmanuelP:wip/push-peer-info'
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/20
commit faa15cde7193aecbe955df143cdb7f09be1e56aa
Author: Emmanuel Pacaud <emma...@gnome.org>
Date: Mon Mar 30 08:34:20 2020 +0200
editor: add push-peer-info support
commit e6a415cd5773f3206979f8fc24a669c47a0478f9
Author: Emmanuel Pacaud <emma...@gnome.org>
Date: Mon Mar 30 08:33:19 2020 +0200
import-export: add push-peer-info support
commit cb2134fd4172ae7afda7133710a7ee596e243e85
Author: Emmanuel Pacaud <emma...@gnome.org>
Date: Mon Mar 30 08:29:57 2020 +0200
service: add support for push-peer-info
commit 5b038a581f8c4d529d25be6c0af55e115d2536d2
Author: Emmanuel Pacaud <emma...@gnome.org>
Date: Mon Mar 30 08:57:50 2020 +0200
import-export: fix coding style of compress test
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/21
** Possibly needed to prevent merge conflict with Pacaud's later work.
** Sorry, I don't know OpenVPN well enough to be able to say if this is needed. How can I test?
The remaining commits since 1.8.12 are eiher not relevant, or are
translation-related.
Regards,
Nicholas
[snip]
>> The fix for bullseye should cherry-picked from upstream VCS to make
>> this package usable on Debian stable, because "The Debian Desktop
>> doesn't work with commercial VPNs" harms Debian's reputation IMHO.
>
> Right. Could you run a git bisect to find the commit which we need to
> cherry-pick=
> Uploading a new upstream release 1.8.16 is probably not something the
> stable release managers will ack but a targetted fix is more likely to
> be accepted.
>
Of course, that's why I suggested cherry-picking ;-)
>> this package usable on Debian stable, because "The Debian Desktop
>> doesn't work with commercial VPNs" harms Debian's reputation IMHO.
>
> Right. Could you run a git bisect to find the commit which we need to
> cherry-pick=
> Uploading a new upstream release 1.8.16 is probably not something the
> stable release managers will ack but a targetted fix is more likely to
> be accepted.
>
Looking at the commit history, bisecting will be a waste of time,
because d1942fd from 1.8.16's HEAD^10 (very recent recent) is required
for bullseye's OpenVPN 2.5.x...honestly, without ovpn 2.5.x support,
this package looks RC buggy for bullseye and maybe it just doesn't have
many users? Ie: Maybe most of its more technical users are tracking
sid? My experience is that all less technical users who use a
commercial VPN use the proprietary application furnished by the provider
when they can't get our (and derivatives) network-manager-openvpn to
work properly.
Since 1.8.12, there are 20 relevant commits: 2 security related, 1
definitely needed, 1 needed for at least one well-known commercial VPN
provider, 1 likely needed, 1 nice to have, 1 for being a good netizen,
and the rest I either don't know how to test, or don't have the OpenVPN
knowledge to assess. I've added my annotations with the following
pattern "** ".
commit ab8ad62f0865d98210265327d8274a55c58e8db5
Author: Santiago Gala <sg...@redhat.com>
Date: Fri Sep 24 19:57:48 2021 +0200
helper: set the can-persist flag
OpenVPN is able to persist the connection across link changes and
outages. Set the can-persist flag in the configuration returned to
NetworkManager.
[bgal...@redhat.com: rewrote commit message]
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/40
** this one solves several outstanding bugs in the BTS. I think we want
this one, because users have been asking for it for years, and because
if a laptop loses an unreliable wifi link, the VPN will disconnect, and
then won't reconnect when the link is restored. I think the security
team would support this one.
commit f9286da94dbfa1d585f0dc8d2f57640d467e2193
Author: Beniamino Galvani <bgal...@redhat.com>
Date: Thu Jun 3 18:19:39 2021 +0200
helper: fix parsing of IPv6 configuration
If the server pushes, for example:
ifconfig-ipv6 2001:db8:f00:bebe::1003/64 2001:db8:f00:bebe::1
NetworkManager considers the first argument as the subnet and the
second as the peer, and so it does something equivalent to:
ip addr add dev tun0 2001:db8:f00:bebe::1003/64 peer 2001:db8:f00:bebe::1
which appears in the "ip -6 addr" output as:
inet6 2001:db8:f00:bebe::1003 peer 2001:db8:f00:bebe::1/128 scope global
valid_lft forever preferred_lft forever
Instead, according to 'man openvpn', NM should simply add address
2001:db8:f00:bebe::1003/64 and use the second argument as a fallback
gateway for the routes specified by '--route-ipv6'
** solves other bugs reported in the BTS
commit 3c47520e999d5301eec69838e11ad4053bef4f20
Author: Thomas Haller <tha...@redhat.com>
Date: Mon Jun 7 19:00:45 2021 +0200
service: assume that we run openvpn 2.4 or newer by default
Our version detection might fail or give the wrong result. So change
the code to assume (in case of unknown version) that we run version 2.4
or newer. By now, that should be the common case and we should only assume
to run 2.3 or older if we successfully detected it.
** the absence of this one might cause my bug, but I suspect this one isn't needed, because if it was someone would have filed a grave bug against network-manager-openvpn. Sorry, I'm not sure.
commit d1942fdc94786ea412aadda2bec8f6b9b9005c85
Author: Thomas Haller <tha...@redhat.com>
Date: Mon Jun 7 18:47:56 2021 +0200
service: fix detection of openvpn version
Since 2.5.0, `openvpn --version` no longer exits with
code 1. That broke the version detection.
https://github.com/OpenVPN/openvpn/commit/96ae327add16f06ac8bc28cfbf9ba0abfcc7129c
** This one must be backported
commit 353a521bc08e2c762e7c63d10f8e3233e9442b08
Author: Beniamino Galvani <bgal...@redhat.com>
Date: Fri Feb 19 10:03:41 2021 +0100
helper: ignore IPv4 configuration without an address
This is the same as commit 56bb08f2956e ("helper: ignore IPv6
configuration without an address") but for IPv4.
NetworkManager always rejects configurations without an address, so
ignore them. A configuration without address can be created, for
example, if the server advertises IPv4 routes or domains without an
address.
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/35
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/62
** I'm not sure if this one is needed. Can this information be gathered by introspecting a working connection or from logs?
commit 56bb08f2956e7e394b017344541e1b7ddf46f2b1
Author: Beniamino Galvani <bgal...@redhat.com>
Date: Wed Feb 10 12:01:37 2021 +0100
helper: ignore IPv6 configuration without an address
OpenVPN 2.5.0 started to pass incomplete IPv6 configurations when the
server is not fully configured for IPv6 but has some IPv6
directives. For example, it is enough to add 'push "route-ipv6 ::/0"'
to a IPv4-only setup to trigger this behavior.
As a result, NetworkManager rejects the configuration as invalid and
the connection fails.
Fix this by ignoring IPv6 configurations without an address.
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/issues/64
** I'm not sure what method my commercial ipv6 service uses to block ipv6, but this commit is possibly related. eg: if it pushes some kind of /dev/null ipv6 route.
commit 717a1d41be0b039778b4eb85bca57f9356bb87aa (upstream-vcs/wip/ernestask/tls-crypt-v2-client)
Author: Ernestas Kulik <erne...@baltic.engineering>
Date: Mon Jan 11 17:30:13 2021 +0200
Handle tls-crypt-v2 keys
OpenVPN 2.5.0 adds client-specific tls-crypt keys under the tls-crypt-v2
option, which is currently not supported. This commit adds the necessary
import/export machinery to support it.
** I'm not sure if this is relevant to my bug or not... I use "tls-client"
and "remote-cert-tls server".
commit 34a0c9257aac9ed6e3ac7cdad6f6cc7d8107eef1
Author: Katelyn Schiesser <katelyn....@gmail.com>
Date: Wed Jul 8 11:32:32 2020 -0700
Handle the various pkcs12/cert/key/ca combinations.
OpenVPN allows supplying PKCS#12 client cert/key *or* PEM client cert/key, as
well as a PEM CA cert in either case. When supplying --pkcs12, the args --cert
and --key can not be used. So, you can have one of the following:
- PKCS#12 combined cert/key/ca (one file): --pkcs12
- PKCS#12 combined cert/key/ca with PEM CA: --pkcs12, --ca
- PEM cert/key, PEM CA: --cert, --key, --ca
If a user tries to import an invalid config, they will be met with the appropriate
error message. The editor dialog also enforces the PKCS#12/PEM restrictions.
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/29
** not relevant to my bug, but nice to have.
commit ba6c4bf1b827a1164032e0bf3cef0a72b79b66ae
Author: Thomas Haller <tha...@redhat.com>
Date: Fri Oct 23 15:21:57 2020 +0200
properties: fix string comparison in hash_copy_advanced() wrongly using NM_IN_SET()
CC properties/libnm_vpn_plugin_openvpn_editor_la-nm-openvpn-editor.lo
properties/nm-openvpn-editor.c:2508:6: warning: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) [-Wstring-compare]
if (NM_IN_SET (key, NM_OPENVPN_KEY_HTTP_PROXY_PASSWORD))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./shared/nm-utils/nm-macros-internal.h:531:45: note: expanded from macro 'NM_IN_SET'
#define NM_IN_SET(x, ...) _NM_IN_SET(||, typeof (x), x, __VA_ARGS__)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./shared/nm-utils/nm-macros-internal.h:526:45: note: expanded from macro '_NM_IN_SET'
#define _NM_IN_SET(op, type, x, ...) _NM_IN_SET_EVAL_N(op, type, x, NM_NARG (__VA_ARGS__), __VA_ARGS__)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./shared/nm-utils/nm-macros-internal.h:523:11: note: expanded from macro '_NM_IN_SET_EVAL_N'
!!_NM_IN_SET_EVAL_N2(op, _x, n, __VA_ARGS__); \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./shared/nm-utils/nm-macros-internal.h:515:50: note: expanded from macro '_NM_IN_SET_EVAL_N2'
#define _NM_IN_SET_EVAL_N2(op, _x, n, ...) (_NM_IN_SET_EVAL_##n(op, _x, __VA_ARGS__))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<scratch space>:54:1: note: expanded from here
_NM_IN_SET_EVAL_1
^
./shared/nm-utils/nm-macros-internal.h:498:53: note: expanded from macro '_NM_IN_SET_EVAL_1'
#define _NM_IN_SET_EVAL_1( op, _x, y) (_x == (y))
^ ~~~
** wow...don't you love commit messages like this? I have no clue if this is needed or not.
commit 667113138d3e27cb367e87090955e50885913407
Author: Katelyn Schiesser <katelyn....@gmail.com>
Date: Sat Oct 17 23:30:54 2020 -0700
Accept all valid 'proto' arguments.
OpenVPN allows for a bunch of different args for 'proto', namely 'udp' and 'tcp'
variants that include '4' or '6', and specific to tcp, '-client' suffixes. This
was already defined in shared/util.h; this commit changes the 'proto' check to
also use the 'NMOVPN_PROTCOL_TYPES' array, and adds test for all supported protos.
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/issues/59
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/30
** This one is likely needed!
commit e83b4f89962854f75475ef0fe86f938746c684db
Author: Ralph Benjamin Ruijs <ralph...@ing.com>
Date: Mon Jul 13 22:23:09 2020 +0200
Added option for allow-pull-fqdn
This allows the server to push routes that include DNS-names and not
just ips/networks. OpenVPN will then resolve those names and add the
routes accordingly.
As an example `push route google.com` will result in all traffic to
google.com be redirected over the vpn. The `up` scripts do not need
any special handling as they are passed the resolved options:
route_network_13=ip_1_of_google
route_network_12=ip_2_of_google
Co-authored-by: Florian Apolloner <flo...@apolloner.eu>
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/28
** I think it's likely commercial VPNs are using this. How can I test?
commit 483a04288b2b79e523901c85fba8b82379a323d2
Author: Katelyn Schiesser <katelyn....@gmail.com>
Date: Tue Jul 7 21:17:21 2020 -0700
Add --explicit-exit-notify by default when --proto udp
When using UDP, there is no transport-protocol method to notify the server
that the client has disconnected. For TCP, the socket closing signals the
server to close the peer instance; for UDP, the server must wait for a
configured --ping-exit, --keepalive, or similar to free up the connection.
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/24
** this one seems like a protocol correctness thing that one can't be a good netizens without. Ie: not needed for technical reasons per se, but for social/reputation ones.
commit 29d1e5d7dd730cd9fb985ee559b51db0009824ce
Merge: 93cec82 13080f3
Author: Beniamino Galvani <bgal...@redhat.com>
Date: Tue Jul 7 10:02:56 2020 +0200
merge: branch 'alexforrow/NetworkManager-openvpn-master'
Add remote-random-hostname support.
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/23
[pasted from MR: –remote-random-hostname Prepend a random string
(6 bytes, 12 hex characters) to hostname to prevent DNS
caching. For example, “foo.bar.gov” would be modified to
"<random-chars>.foo.bar.gov".
This change adds an option to the UI, import/export and the
appropriate flag to the OpenVPN executable.]
** this sounds like it potentially closes a CVE
commit 64c9877db25b2f3c3f77e64693dfb25229917cbf
Author: Alex Forrow <al...@forrow.com>
Date: Wed May 27 23:16:08 2020 +0100
support for remote-random-hostname parameter
** I know of at least one popular commercial VPN service that uses this
commit 67d9ebb4f2b58287162284619168224afc04d9e0
Author: Thomas Haller <tha...@redhat.com>
Date: Thu Apr 23 09:47:26 2020 +0200
helper: cleanup parsing foreign_option_* environment variables
There is no need to restrict parsing to 256 variables. Just continue
iterating until we find a variable that is missing.
Also, don't use magical numbers
- tmp += 12; /* strlen ("dhcp-option ") */
+ tmp += NM_STRLEN ("dhcp-option ");
** seems relevant, but sorry, I don't know if it's needed
commit c4ad1b66f090e5a2ae782d7d7067a658587909bd
Merge: 5b038a5 faa15cd
Author: Thomas Haller <tha...@redhat.com>
Date: Mon Mar 30 10:02:44 2020 +0200
merge branch 'EmmanuelP:wip/push-peer-info'
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/20
commit faa15cde7193aecbe955df143cdb7f09be1e56aa
Author: Emmanuel Pacaud <emma...@gnome.org>
Date: Mon Mar 30 08:34:20 2020 +0200
editor: add push-peer-info support
commit e6a415cd5773f3206979f8fc24a669c47a0478f9
Author: Emmanuel Pacaud <emma...@gnome.org>
Date: Mon Mar 30 08:33:19 2020 +0200
import-export: add push-peer-info support
commit cb2134fd4172ae7afda7133710a7ee596e243e85
Author: Emmanuel Pacaud <emma...@gnome.org>
Date: Mon Mar 30 08:29:57 2020 +0200
service: add support for push-peer-info
commit 5b038a581f8c4d529d25be6c0af55e115d2536d2
Author: Emmanuel Pacaud <emma...@gnome.org>
Date: Mon Mar 30 08:57:50 2020 +0200
import-export: fix coding style of compress test
https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/21
** Possibly needed to prevent merge conflict with Pacaud's later work.
** Sorry, I don't know OpenVPN well enough to be able to say if this is needed. How can I test?
The remaining commits since 1.8.12 are eiher not relevant, or are
translation-related.
Regards,
Nicholas
Michael Biebl
Dec 4, 2021, 9:40:03 AM12/4/21
to
Am 03.12.2021 um 20:39 schrieb Nicholas D Steeves:
> Control: tags -1 bullseye upstream fixed-upstream
>
> Michael Biebl <bi...@debian.org> writes:
>> On 03.12.21 19:07, Nicholas D Steeves wrote:
>>
> [snip]
>>> The fix for bullseye should cherry-picked from upstream VCS to make
>>> this package usable on Debian stable, because "The Debian Desktop
>>> doesn't work with commercial VPNs" harms Debian's reputation IMHO.
>>
>> Right. Could you run a git bisect to find the commit which we need to
>> cherry-pick=
>> Uploading a new upstream release 1.8.16 is probably not something the
>> stable release managers will ack but a targetted fix is more likely to
>> be accepted.
>>
>
> Of course, that's why I suggested cherry-picking ;-)
>
> Looking at the commit history, bisecting will be a waste of time,
I'm not reallly looking for a huge list of annotated commit messages
> Control: tags -1 bullseye upstream fixed-upstream
>
> Michael Biebl <bi...@debian.org> writes:
>> On 03.12.21 19:07, Nicholas D Steeves wrote:
>>
> [snip]
>>> The fix for bullseye should cherry-picked from upstream VCS to make
>>> this package usable on Debian stable, because "The Debian Desktop
>>> doesn't work with commercial VPNs" harms Debian's reputation IMHO.
>>
>> Right. Could you run a git bisect to find the commit which we need to
>> cherry-pick=
>> Uploading a new upstream release 1.8.16 is probably not something the
>> stable release managers will ack but a targetted fix is more likely to
>> be accepted.
>>
>
> Of course, that's why I suggested cherry-picking ;-)
>
> Looking at the commit history, bisecting will be a waste of time,
asking questions.
Simply running git bisect and pointing out which commit fixes *this*
particular issue, would be more helpful.
0 new messages