[Openvpn-devel] OpenVPN 3 Linux v23 released

[David Sommerseth via Openvpn-devel]

OpenVPN 3 Linux v23 (Stable release)

The v23 release is stable release which expands the distribution target
since v22_dev was released.  The goal for this step was to stabilize the
codebase which was migrated to GDBus++ and the new Meson building
system.  The next release (v24) will also be a stable release, with focus
on further stabilisation and less intrusive changes.

The v23 release brings back the OpenVPN 3 AWS-VPC Add-on which was not
ready for the v22_dev release.  This service has also been migrated to
use GDBus++.  The behaviour of this add-on should otherwise be identical
to the service shipped in v21 and older releases.

In addition, a new add-on is included in this release.  The Cloud
Connexa service is being extended with a new functionality, referred to
as Device Posture Checks (DPC).  This feature will enable the VPN server
to request certain checks to be performed on the client side and
reported back to the server.  These checks are restricted to what the
new OpenVPN 3 Device Posture Service (openvpn3-service-devposture)
provides.

This new feature is NOT installed nor enabled by default.  To enable the
client-side functionality, the openvpn3-addon-devposture package must
be installed, the VPN client configuration must be pre-imported and
an Enterprise ID must be assigned to the configuration profile.  That
will allow the server to request Device Posture Checks to be performed.

The currently implemented DPC tests only provides platform information,
like Linux distribution name and version, kernel versions, CPU
architecture and the client's local time.  In future releases, more
tests may be implemented.  More information on available tests and
the declaration of test profiles can be found here:





Known issues:

- openvpn3-service-client may not exit cleanly unless stopped
  via 'openvpn3 session-manage --disconnect' first.  This may
  delay the shutdown process if a VPN session is running when
  the host is being shut down.  A fix is in progress and will
  be prepared for v24.

- Shell completion may list duplicated options in some cases

- openvpn3-admin journal --since has a time zone related issue
  and may not list all log events within the closest hours.


Other changes:

* Improvement: Upgrade to OpenVPN 3 Core Library v3.10.1

This library update provides the functionality to provide the
Device Posture Check functionality in the OpenVPN wire
protocol.  A fix to resolve compilation errors when the
-Wnon-virtual-dtor compiler flag is enabled is included too.


* Bugfix: Report client and version correctly in IV_GUI_VER

The v22_dev release unfortunately changed the format of the
IV_GUI_VER.  It would report: 'openvpn3-linux/v22:dev' when
it should have been 'OpenVPN3/Linux/v22_dev'.  This has
been fixed.


* Bugfix: --tag option not working with config-import or config-manage

A regression bug was introduced in v22_dev which handled the
available tracking of Configuration Manager features incorrectly
and ended up disabling this feature in the openvpn3 config-import
and openvpn3 config-manage commands.  This has been fixed.


* Bugfix: systemd-resolved support rejected IPv6 DNS resolver address

An oversight in the systemd-resolved implementation refused to accept
pushed DNS resolver addresses when it was an IPv6 address.  This has
been fixed and both IPv4 and IPv6 addresses are now fully supported.


* Improvement: Python configuration parser support for 
--connect-retry{,-max}


The Python configuration parser in the openvpn3 module did
not provide a pass-through for --connect-retry and --connect-retry-max
options.  This would result in configuration profiles containing
these options would not function when using the Python based tools
while it would work using the 'openvpn3' command.


Credits
---

Thanks goes to those continuing testing and reporting issues.
A special thanks to Grzegorz Gutowski who provided the fix to
the Python module.  He is also the project lead behind the
openvpn3-indicator project, which provides a tray-icon for
OpenVPN 3 Linux.  If you use a graphical desktop, that's a
project worth checking out!

Many thanks also goes to Razvan Cojocaru who has stepped in providing
many great improvements and done all the work for the Device Posture
support in OpenVPN 3 Linux.  And Lev Stipakov who migrated the
OpenVPN 3 AWS-VPC add-on service to GDBus++


Supported Linux distributions
-

- Debian: 12
- Fedora: 39, 40, Rawhide
- Red Hat Enterprise Linux 8, 9
- Ubuntu: 20.04, 22.04, 24.04

Installation and getting started instructions can be found here:



Debian 11, Red Hat Enterprise Linux 7 and Ubuntu 23.10 are EOL and
is no longer supported.

[Openvpn-devel] OpenVPN 2.6.12 released

[Yuriy Darnobyt]

The OpenVPN community project team is proud to release OpenVPN 2.6.12.

This is a bugfix release.

Bug fixes:

* the fix for CVE-2024-5594 (refuse control channel messages with nonprintable 
characters) was too strict, breaking user
   configurations with AUTH_FAIL messages having trailing CR/NL characters. 
This often happens if the AUTH_FAIL reason
   is set by a script. Strip those before testing the command buffer (github 
​#568). Also, add unit test.
* Http-proxy: fix bug preventing proxy credentials caching (trac #1187)

Windows MSI changes since 2.6.11:

* Built against OpenSSL 3.3.1
* Included openvpn-gui updated to 11.50.0.0
   *Update Italian language (github ​#696)

More details can be found in the Changes document:



(The Changes document also contains a section with work-arounds for
common problems encountered when using OpenVPN with OpenSSL 3)

Source code and Windows installers can be downloaded from our download page:



Debian and Ubuntu packages are available in the official apt repositories:



On Red Hat derivatives we recommend using the Fedora Copr repository.



Kind regards,
Yuriy Darnobyt___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 2.6.11 released

[Frank Lichtenheld]

The OpenVPN community project team is proud to release OpenVPN 2.6.11.

This is a bugfix release containing several security fixes.

Security fixes:

* CVE-2024-4877: Windows: harden interactive service pipe.
  Security scope: a malicious process with "some" elevated privileges
  (SeImpersonatePrivilege) could open the pipe a second time, tricking
  openvn GUI into providing user credentials (tokens), getting full
  access to the account openvpn-gui.exe runs as. (Zeze with TeamT5)
* ​CVE-2024-5594: control channel: refuse control channel messages with
  nonprintable characters in them.
  Security scope: a malicious openvpn peer can send garbage to openvpn
  log, or cause high CPU load. (Reynir Björnsson)
* CVE-2024-28882: only call schedule_exit() once (on a given peer).
  Security scope: an authenticated client can make the server "keep the
  session" even when the server has been told to disconnect this client
  (Reynir Björnsson) 

New features:

* Windows Crypto-API: Implement Windows CA template match for searching
  certificates in windows crypto store.
* Support pre-created DCO interface on FreeBSD (OpenVPN would fail to set
  ifmode p2p/subnet otherwise) 

Bug fixes:

* Fix connect timeout when using SOCKS proxies (trac #328, github ​#267)
* Work around LibreSSL crashing on OpenBSD 7.5 when enumerating ciphers
  (LibreSSL bug, already fixed upstream, but not backported to OpenBSD 7.5,
   see also ​https://github.com/libressl/openbsd/issues/150)
* Add bracket in fingerprint message and do not warn about missing
  verification (github ​#516) 

Documentation:

* Remove "experimental" denotation for --fast-io
* Correctly document ifconfig_* variables passed to scripts
* Documentation: make section levels consistent
* Samples: Update sample configurations (remove compression & old cipher
  settings, add more informative comments) 

Windows MSI changes since 2.6.10:

* For the Windows-specific security fix see above
* Built against OpenSSL 3.3.1
* Included openvpn-gui updated to 11.49.0.0
  * Contains part of the fix for ​CVE-2024-4877

More details can be found in the Changes document:



Source code and Windows installers can be downloaded from our download page:



Debian and Ubuntu packages are available in the official apt repositories:



On Red Hat derivatives we recommend using the Fedora Copr repository.



Regards,
-- 
  Frank Lichtenheld


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 3 Linux v22_dev released

[David Sommerseth via Openvpn-devel]

OpenVPN 3 Linux v22_dev (Limited Release)

This is a limited release primarily targeting Fedora 39 and newer plus
Ubuntu 24.04.  Other Linux distributions shipping glib2 version 2.76
or newer will also benefit from this release.

This release contains a massive re-factoring of the D-Bus integration
layer with glib2.  The glib2 2.76 and newer releases contains several
internal changes which broke the D-Bus implementation layer in
OpenVPN 3 Linux v21 and older releases [1]. To fix this, it was decided
to split out the base D-Bus integration into a new standalone library
which OpenVPN 3 Linux will depend on.  This new project is called
GDBus++.

[1] 

The GDBus++ library makes extended use of multi-threading when
processing D-Bus method calls and implements modern C++17 approaches
when handling requests to registered D-Bus objects.  It has also been
a strong focus on getting rid of as much of various glib2 warnings
which could occasionally appear in prior OpenVPN 3 Linux releases.

There are most likely a still a lot more room for improvements to both
the new GDBus++ and the upgraded OpenVPN 3 Linux code, which is why
this release targets a more limited release scope.

This release has only been through the full QA validation on Fedora 39,
Fedora 40 and Ubuntu 24.04.

That said, this new code can be made available for all the officially
supported RPM distributions by enabling a "development snapshots" repository.
But this repository will also not have the same QA guarantees as the
official stable repositories.

On a development note, this project has now migrated to use Meson [2] as
the build system.  The autoconf/automake build system is now completely
removed.  The Meson build system has turned out to be way simpler to
use and configure than autotools ever was, especially from a developers
point of view.

[2] 


There are unfortunately a few known issues which is targeted for
the coming v23 release:

  - AWS VPC integration is not yet ready, so this add-on is currently
not available in this v22_dev release.  This is targeted for v23.

  - Shell completion may list duplicated options in some cases

  - openvpn3-admin journal --since has a time zone related issue
and may not list all log events within the closest hours.


Other changes worth mentioning with this release:

* Improvement: Upgrade to OpenVPN 3 Core library v3.8.5

  This upgrade contains several bug fixes related to the option
  parser, mostly issues reported by a wide range of users.  In
  addition to incorrect behaviour with the stub compression when
  the --compress option was used.

* Improvement: openvpn3-admin journal --since argument

  The --since argument can now use the keywords 'today' and
  'yesterday'.

* Bug fix: openvpn3-admin log-service would not change some settings

  On some distributions, the --dbus-details and other boolean flags
  was not properly changed when requested.  This has been improved.


Credits
---

Finally, it is needed to give a HUGE THANK YOU to all the community
testers which installed and tested rolling development snapshots during
the development of this release.  Without all this testing, we would
not have the same confidence in this release as we have now.  All your
help and feedback has been really valuable and helpful during this the
development phase.


Supported Linux distributions
-

  - Fedora: 39, 40, Rawhide
  - Ubuntu: 24.04, (amd64, arm64)
  - Red Hat Enterprise Linux 8, 9 (no QA, development snapshot only [3])

Installation and getting started instructions can be found here:

  

The v23 release will also include support for all distributions again,
including Debian 12.  Debian 11, Red Hat Enterprise Linux 7 and
Ubuntu 23.10 will go EOL in just a few days or weeks and will no longer
be supported.


[3] Fedora Copr development snapshots:



--
kind regards,

David Sommerseth
OpenVPN Inc


 Source tarballs ---
* OpenVPN 3 Linux v22_dev

  
  


* GDBus++ v1

  
  

 SHA256 Checksums --

ad8f373814bfbefd12f9824d57badef4535f6c1fde68d2c73d7ee14863547cb6  
openvpn3-linux-22_dev.tar.xz
32af8668130966959319ccd2769146090de5eab73a98612add6a5f9a99ff6921  
openvpn3-linux-22_dev.tar.xz.asc
e53e47f8529109e138d59ff38374818692b6fe26f2fee2d00642bba272e117a3  
gdbuspp-1.tar.xz
eff710210822b8127ec7f2f9b6879ac8150d2c74099c498d4811a2668d7f9670  
gdbuspp-1.tar.xz.asc

--

[Openvpn-devel] OpenVPN 2.6.10 released

[Yuriy Darnobyt]

The OpenVPN community project team is proud to release OpenVPN 2.6.10.

This is a bugfix release containing several security fixes for Windows and 
Windows TAP driver and documentation updates.

Security fixes:

* CVE-2024-27459: Windows: fix a possible stack overflow in the interactive 
service component which might lead to a local privilege escalation.
  Reported-by: Vladimir Tokarev 
* CVE-2024-24974: Windows: disallow access to the interactive service pipe from 
remote computers.
  Reported-by: Vladimir Tokarev 
* CVE-2024-27903: Windows: disallow loading of plugins from untrusted 
installation paths, which could be used to attack openvpn.exe
  via a malicious plugin.  Plugins can now only be loaded from the OpenVPN 
install directory, the Windows system directory, and possibly
  from a directory specified by HKLM\SOFTWARE\OpenVPN\plugin_dir.
  Reported-by: Vladimir Tokarev 
* CVE-2024-1305: Windows TAP driver: Fix potential integer overflow in 
!TapSharedSendPacket.
  Reported-by: Vladimir Tokarev 

User visible changes:

* Update copyright notices to 2024

Bug fixes:

* Windows: if the win-dco driver is used (default) and the GUI requests use of 
a proxy server, the connection would fail.
  Disable DCO in this case.  (Github: #522)
* Compression: minor bugfix in checking option consistency vs. compiled-in 
algorithm support
* systemd unit files: remove obsolete syslog.target

Documentation:

* remove license warnings about mbedTLS linking (README.mbedtls)
* update documentation references in systemd unit files
* sample config files: remove obsolete tls-*.conf files
* document that auth-user-pass may be inlined

Windows MSI changes since 2.6.9:

* For the Windows-specific security fixes see above
* Built against OpenSSL 3.2.1
* Included tap6-windows driver updated to 9.27.0
  * Security fix, see above
* Included ovpn-dco-win driver updated to 1.0.1
  * Ensure we don't pass too large key size to CryptoNG. We do not consider 
this a security issue since the CryptoNG API handles
this gracefully either way.
* Included openvpn-gui updated to 11.48.0.0
  * Position tray tooltip above the taskbar
  * Combine title and message in tray icon tip text
  * Use a custom tooltip window for the tray icon
More details can be found in the Changes document:



(The Changes document also contains a section with work-arounds for
common problems encountered when using OpenVPN with OpenSSL 3)

Source code and Windows installers can be downloaded from our download page:



Debian and Ubuntu packages are available in the official apt repositories:



On Red Hat derivatives we recommend using the Fedora Copr repository.



Kind regards,
Yuriy Darnobyt___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 2.6.9 released

[Frank Lichtenheld]

The OpenVPN community project team is proud to release OpenVPN 2.6.9.

This is a bugfix release containing one security fix for the Windows installer.

Security fixes:

* Windows Installer: fix ​CVE-2023-7235 where installing to a non-default 
directory
  could lead to a local privilege escalation. Reported by Will Dormann. 

New features:

* Add support for building with mbedTLS 3.x.x
* New option --force-tls-key-material-export to only accept clients that can do
  TLS keying material export to generate session keys
  (mostly an internal option to better deal with TLS 1.0 PRF failures).
* Windows: bump vcpkg-ports/pkcs11-helper to 1.30
* Log incoming SSL alerts in easier to understand form and move logging from 
--verb 8
  to --verb 3.
* protocol_dump(): add support for printing --tls-crypt packets 

User visible changes:

* License change is now complete, and all code has been re-licensed under the 
new license
  (still GPLv2, but with new linking exception for Apache2 licensed code).
  See ​COPYING for details. 
  Code that could not be re-licensed has been removed or rewritten.
* The original code for the --tls-export-cert feature has been removed (due to 
the
  re-licensing effort) and rewritten without looking at the original code.
  Feature-compatibility has been tested by other developers, looking at both 
old and
  new code and documentation, so there *should* not be a user-visible change 
here.
* IPv6 route addition/deletion are now logged on the same level (3) as for IPv4.
  Previously IPv6 was always logged at --verb 1.
* Better handling of TLS 1.0 PRF failures in the underlying SSL library (e.g. 
on some
  FIPS builds) - this is now reported on startup, and clients before 2.6.0 that 
can not
  use TLS EKM to generate key material are rejected by the server. Also, error 
messages
  are improved to see what exactly failed. 

Notable bug fixes:

* FreeBSD: for servers with multiple clients, reporting of peer traffic 
statistics would
  fail due to insufficient buffer space (Github: ​#487) 

Windows MSI changes since 2.6.8:

* Security fix, see above
* Built against OpenSSL 3.2.0
* Included openvpn-gui updated to 11.47.0.0
  * Windows GUI: always update tray icon on state change (Github: 
​#openvpn-gui/669)
(for persistent connection profiles, "connecting" state would not show) 

More details can be found in the Changes document:



(The Changes document also contains a section with work-arounds for
common problems encountered when using OpenVPN with OpenSSL 3)

Source code and Windows installers can be downloaded from our download page:



Debian and Ubuntu packages are available in the official apt repositories:



On Red Hat derivatives we recommend using the Fedora Copr repository.



Kind regards,
-- 
  Frank Lichtenheld


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN data channel format using 64bit IV

[Arne Schwabe]

- add protocol-flag aead-packet-format-v2 This signals the client to 
switch to the new data channel format.



And finally have the data channel format. Since this format is 
negotiated like the cipher, there is no need to use another opcode if 
keep the peer id to just 24 bit. But we might want to extend the 
format to have it 8 byte aligned to also allow peer-id to be extended 
in the future.


I'd at least consider to not send the upper 32 bits of the counter over 
the wire. With some simple arithmetic you can detect the counter 
overflow and keep the high bits internal to the application. I'd expect 
such per-packet arithmetic to be much cheaper than transmitting 4 bytes 
extra for each packet.


If you take that approach, you would not even need to change the wire 
format.


Even more, you might not even have to negotiate the option with the 
peer, because the peer will initiate a renegotiation after 0xFF00 
packets if it doesn't support the "implicit long PID". New peers will 
postpone the reneg to 0xFF00 packets.


Even as nice as that sounds, I am not super convinced that we should be 
the "odd protocol" here that takes a different approach than all other 
protocol. All other protocols that I looked at, rather use longer IV 
instead of doing some hidden counter that is not transmitted.


So I would rather err on the safe side here and go for a 8 byte IV instead.

Arne



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Openvpn-users] OpenVPN and outside clients

[Antonio Quartulli]

Hi,

On 03/01/2024 09:14, Peter Davis wrote:

Hello,
I changed the IP address in the client configuration file, but I can't connect 
to the server. I got the following error:

Wed Jan  3 10:32:32 2024 TLS Error: TLS key negotiation failed to occur within 
60 seconds (check your network connectivity)
Wed Jan  3 10:32:32 2024 TLS Error: TLS handshake failed

I checked the OpenVPN log file too, but there was nothing there:
# cat /var/log/openvpn/openvpn.log


This is a clear indication that your connection attempt is not reaching 
the VPN server at all.


This is a problem with whatever is in the middle, i.e. gateway/firewall.

* Have you properly configured the port forwarding on the gateway/firewall?
* Have you allowed the right ports on the gateway/firewall?
* Is there any firewall on the VPN server which may be preventing 
connections from outside the LAN?


Note: this is unrelated to OpenVPN, but just a generic network 
configuration issue.


Regards,

--
Antonio Quartulli


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN data channel format using 64bit IV

[Steffan Karger]

Hi,

I've been just lurking for a while, but you've managed to nerd-snipe me 
in responding.


On 11-12-2023 13:31, Arne Schwabe wrote:
with DCO and possible future hardware assisted OpenVPN acceleration we 
are approaching the point where 32 bit IVs are not cutting it any more.


Agreed. Though to be precise, we use 96-bit IVs in our AEAD mode, which 
include a 32-bit packet counter.



To illustrate the problem, some back of the envelope math here:

If we want to keep the current 3600s renogotiation interval and have a 
safety margin of 30% we have about 3 million packets (2*32 * 0.7) to 
work with. That translates to about 835k packets per second.


Nitpicking, but we currently maintain a reneg threshold at 75% (pid >= 
0xFF00).


With 1300 Byte packets that translates into 8-9 Gbit/s. That is from 
unrealistic any more. Current DCO implementations are already in 
spitting distance to that or might even reach (for a single client 
connection) that if you have extremely fast single core performance CPU.


Agreed. Though it seems to me that with so much processing power and 
network throughput, it wouldn't be much of an issue to renegotiate 
slightly more often.



So I think we need to consider adding 64bit IV now rather than later.


Even considering my remarks above, I do agree it's time.

But, we will also need to make sure that we won't exceed the limits of 
the ciphers we use, which might need additional logic. I don't have time 
right now to dig up all the specifics, but this IRTF draft might serve 
as a good starting point for reading: 
https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-limits-07.html



So the proposal is the following:

- add IV_PACKET_FORMAT_AEAD_V2 flag to the protocol flags. This signal 
that the other side supports the new AEAD data channel packet format 
that supports 64 bit IVs.


I don't think we need to extend this feature to the CBC data channel 
format. I just don't see a use case where people would be able to 
upgrade to a new OpenVPN version to use 64 bit IVs but not to also 
change to use AEAD ciphers.


Ack. Do note that CBC has a random IV per packet, so this doesn't apply 
to the IV in CBC, just the packet counter.


- add protocol-flag aead-packet-format-v2 This signals the client to 
switch to the new data channel format.



And finally have the data channel format. Since this format is 
negotiated like the cipher, there is no need to use another opcode if 
keep the peer id to just 24 bit. But we might want to extend the format 
to have it 8 byte aligned to also allow peer-id to be extended in the 
future.


I'd at least consider to not send the upper 32 bits of the counter over 
the wire. With some simple arithmetic you can detect the counter 
overflow and keep the high bits internal to the application. I'd expect 
such per-packet arithmetic to be much cheaper than transmitting 4 bytes 
extra for each packet.


If you take that approach, you would not even need to change the wire 
format.


Even more, you might not even have to negotiate the option with the 
peer, because the peer will initiate a renegotiation after 0xFF00 
packets if it doesn't support the "implicit long PID". New peers will 
postpone the reneg to 0xFF00 packets.


Regardless of what choice we take, this is a good opportunity to rectify 
the position of the AEAD tag in our packet. Especially for hardware 
implementations it is quite advantageous to have the AEAD at the end of 
the packet instead of the beginning and since we need to have a new data 
format, there is no reason to keep the tag at the start of the packet.


Agreed (as I already stated in 2015: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg09879.html).




So the choice is basically

Variant A:

Bytes

  1  234    5-13  13- (n+13) (n+14) - (n+30)

[OP_CODE_DATA_V2][peerid]   [64 bit IV] [  payload  ][ 16 byte auth tag]


Variant B:

    1    3-8
[OP_CODE_DATA_V3] [ peer-id/padding] [rest identical]


or:

Variant C:

Leave the on-the-wire PID as-is. Just move the auth tag to the end of 
the packet.


variant D:

Keep wire format as-is.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN data channel format using 64bit IV

[Arne Schwabe]

Hey,

with DCO and possible future hardware assisted OpenVPN acceleration we 
are approaching the point where 32 bit IVs are not cutting it any more.



To illustrate the problem, some back of the envelope math here:

If we want to keep the current 3600s renogotiation interval and have a 
safety margin of 30% we have about 3 million packets (2*32 * 0.7) to 
work with. That translates to about 835k packets per second.


With 1300 Byte packets that translates into 8-9 Gbit/s. That is from 
unrealistic any more. Current DCO implementations are already in 
spitting distance to that or might even reach (for a single client 
connection) that if you have extremely fast single core performance CPU.


So I think we need to consider adding 64bit IV now rather than later.

So the proposal is the following:

- add IV_PACKET_FORMAT_AEAD_V2 flag to the protocol flags. This signal 
that the other side supports the new AEAD data channel packet format 
that supports 64 bit IVs.


I don't think we need to extend this feature to the CBC data channel 
format. I just don't see a use case where people would be able to 
upgrade to a new OpenVPN version to use 64 bit IVs but not to also 
change to use AEAD ciphers.


- add protocol-flag aead-packet-format-v2 This signals the client to 
switch to the new data channel format.



And finally have the data channel format. Since this format is 
negotiated like the cipher, there is no need to use another opcode if 
keep the peer id to just 24 bit. But we might want to extend the format 
to have it 8 byte aligned to also allow peer-id to be extended in the 
future.


Regardless of what choice we take, this is a good opportunity to rectify 
the position of the AEAD tag in our packet. Especially for hardware 
implementations it is quite advantageous to have the AEAD at the end of 
the packet instead of the beginning and since we need to have a new data 
format, there is no reason to keep the tag at the start of the packet.



So the choice is basically

Variant A:

Bytes

 1  2345-13  13- (n+13) (n+14) - (n+30)

[OP_CODE_DATA_V2][peerid]   [64 bit IV] [  payload  ][ 16 byte auth tag]


Variant B:

   13-8
[OP_CODE_DATA_V3] [ peer-id/padding] [rest identical]

Arne


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Openvpn-Devel] [PATCH] vcpkg-ports/pkcs11-helper: bump to version 1.30

[Frank Lichtenheld]

On Mon, Dec 04, 2023 at 04:33:45PM +0100, Marc Becker via Openvpn-devel wrote:
> update metadata references for pkcs11-helper v1.30
> remove local patches incorporated in new upstream
> ---
>  .../Fix-build-with-disable-shared.patch   |  48 
>  ...cs11-helper-002-dynamic_loader_flags.patch | 104 --
>  .../vcpkg-ports/pkcs11-helper/portfile.cmake  |   6 +-
>  contrib/vcpkg-ports/pkcs11-helper/vcpkg.json  |   2 +-
>  4 files changed, 3 insertions(+), 157 deletions(-)
>  delete mode 100644 
> contrib/vcpkg-ports/pkcs11-helper/Fix-build-with-disable-shared.patch
>  delete mode 100644 
> contrib/vcpkg-ports/pkcs11-helper/pkcs11-helper-002-dynamic_loader_flags.patch
> 

Changes look reasonable. Build succeeds.

Acked-By: Frank Lichtenheld 

-- 
  Frank Lichtenheld


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [Openvpn-Devel] [PATCH] vcpkg-ports/pkcs11-helper: bump to version 1.30

[Marc Becker via Openvpn-devel]

update metadata references for pkcs11-helper v1.30
remove local patches incorporated in new upstream
---
 .../Fix-build-with-disable-shared.patch   |  48 
 ...cs11-helper-002-dynamic_loader_flags.patch | 104 --
 .../vcpkg-ports/pkcs11-helper/portfile.cmake  |   6 +-
 contrib/vcpkg-ports/pkcs11-helper/vcpkg.json  |   2 +-
 4 files changed, 3 insertions(+), 157 deletions(-)
 delete mode 100644 
contrib/vcpkg-ports/pkcs11-helper/Fix-build-with-disable-shared.patch
 delete mode 100644 
contrib/vcpkg-ports/pkcs11-helper/pkcs11-helper-002-dynamic_loader_flags.patch

diff --git 
a/contrib/vcpkg-ports/pkcs11-helper/Fix-build-with-disable-shared.patch 
b/contrib/vcpkg-ports/pkcs11-helper/Fix-build-with-disable-shared.patch
deleted file mode 100644
index 16fa7042..
--- a/contrib/vcpkg-ports/pkcs11-helper/Fix-build-with-disable-shared.patch
+++ /dev/null
@@ -1,48 +0,0 @@
-From 7171396a151a2edb3474c7a321b7ae4ff7e171fc Mon Sep 17 00:00:00 2001
-From: Frank Lichtenheld 
-Date: Wed, 29 Mar 2023 12:44:44 +0200
-Subject: [PATCH] Allow the build to succeed if configured with
- --disable-shared
-
-Do not try to install a file that does not exist.
-
-Signed-off-by: Frank Lichtenheld 

- configure.ac| 1 +
- lib/Makefile.am | 2 ++
- 2 files changed, 3 insertions(+)
-
-upstream PR: https://github.com/OpenSC/pkcs11-helper/pull/62
-
-diff --git a/configure.ac b/configure.ac
-index a7e9760..f154ae3 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -581,6 +581,7 @@ AC_SUBST([LIBPKCS11_HELPER_LT_AGE])
- AC_SUBST([LIBPKCS11_HELPER_LT_OLDEST])
- AC_SUBST([WIN_LIBPREFIX])
- AC_SUBST([PKCS11H_FEATURES])
-+AM_CONDITIONAL([ENABLE_SHARED], [test "${enable_shared}" = "yes" ])
- AM_CONDITIONAL([WIN32], [test "${WIN32}" = "yes"])
- AM_CONDITIONAL([CYGWIN], [test "${CYGWIN}" = "yes"])
- AM_CONDITIONAL([ENABLE_DOC], [test "${enable_doc}" = "yes"])
-diff --git a/lib/Makefile.am b/lib/Makefile.am
-index 31b928f..3cba32f 100644
 a/lib/Makefile.am
-+++ b/lib/Makefile.am
-@@ -128,10 +128,12 @@ if ENABLE_PKCS11H_TOKEN
- endif
- 
- if WIN32
-+if ENABLE_SHARED
- mylibdir=$(libdir)
- 
mylib_DATA=.libs/@WIN_LIBPREFIX@pkcs11-helper-@libpkcs11_helper_lt_old...@.dll.def
- .libs/@WIN_LIBPREFIX@pkcs11-helper-@libpkcs11_helper_lt_old...@.dll.def:  
libpkcs11-helper.la
- endif
-+endif
- 
- RCCOMPILE = $(RC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
-   $(AM_CPPFLAGS) $(CPPFLAGS)
--- 
-2.34.1
-
diff --git 
a/contrib/vcpkg-ports/pkcs11-helper/pkcs11-helper-002-dynamic_loader_flags.patch
 
b/contrib/vcpkg-ports/pkcs11-helper/pkcs11-helper-002-dynamic_loader_flags.patch
deleted file mode 100644
index 6d674581..
--- 
a/contrib/vcpkg-ports/pkcs11-helper/pkcs11-helper-002-dynamic_loader_flags.patch
+++ /dev/null
@@ -1,104 +0,0 @@
-From 934197611dd1260d17ae0f11ae81c1d2e85612d2 Mon Sep 17 00:00:00 2001
-From: Marc Becker 
-Date: Fri, 22 Jul 2022 10:33:05 +0200
-Subject: [PATCH] core: add provider property for loader flags
-
-support flags for dynamic loader via provider property
-set original values as defaults, use verbatim (user-supplied) value

- include/pkcs11-helper-1.0/pkcs11h-core.h | 11 ++-
- lib/_pkcs11h-core.h  |  2 ++
- lib/pkcs11h-core.c   | 13 +++--
- 3 files changed, 23 insertions(+), 3 deletions(-)
-
-upstream PR: https://github.com/OpenSC/pkcs11-helper/pull/59
-
-diff --git a/include/pkcs11-helper-1.0/pkcs11h-core.h 
b/include/pkcs11-helper-1.0/pkcs11h-core.h
-index 9028c277..56f87718 100644
 a/include/pkcs11-helper-1.0/pkcs11h-core.h
-+++ b/include/pkcs11-helper-1.0/pkcs11h-core.h
-@@ -384,8 +384,17 @@ extern "C" {
-  */
- #define PKCS11H_PROVIDER_PROPERTY_PROVIDER_DESTRUCT_HOOK_DATA 8
- 
-+/**
-+ * @brief Provider loader flags for platform.
-+ * Value type is unsigned.
-+ * Default value is platform dependent:
-+ * win32 -> 0
-+ *dlopen -> RTLD_NOW | RTLD_LOCAL
-+ */
-+#define PKCS11H_PROVIDER_PROPERTY_LOADER_FLAGS 9
-+
- /** @private */
--#define _PKCS11H_PROVIDER_PROPERTY_LAST 9
-+#define _PKCS11H_PROVIDER_PROPERTY_LAST 10
- 
- /** @} */
- 
-diff --git a/lib/_pkcs11h-core.h b/lib/_pkcs11h-core.h
-index f879c0e8..1c02e35d 100644
 a/lib/_pkcs11h-core.h
-+++ b/lib/_pkcs11h-core.h
-@@ -134,6 +134,8 @@ struct _pkcs11h_provider_s {
- #if defined(ENABLE_PKCS11H_SLOTEVENT)
-   _pkcs11h_thread_t slotevent_thread;
- #endif
-+
-+  unsigned loader_flags;
- };
- 
- struct _pkcs11h_session_s {
-diff --git a/lib/pkcs11h-core.c b/lib/pkcs11h-core.c
-index 0bf11e87..409ad9e2 100644
 a/lib/pkcs11h-core.c
-+++ b/lib/pkcs11h-core.c
-@@ -138,6 +138,7 @@ static const char * __pkcs11h_provider_preperty_names[] = {
-   "init_args",
-   "provider_destruct_hook",
-   "provider_destruct_hook_data",
-+  "provider_loader_flags",
-   NULL
- };
- 
-@@ -916,6 +917,10 @@ pkcs11h_registerProvider (
-   reference
-   );
- 
-+#if !defined(_WIN32)
-+  provider->loader_flags = RTLD_NOW | RTLD_LOCAL;

[Openvpn-devel] OpenVPN 2.6.8 released

[Yuriy Darnobyt]

The OpenVPN community project team is proud to release OpenVPN 2.6.8.

This is a small bugfix release fixing a few regressions in 2.6.7 release.

User visible changes:

* Windows: print warning if pushed options require DHCP (e.g. DOMAIN-SEARCH) 
and driver in use does not use DHCP (wintun, dco).

Bug fixes:

* SIGSEGV crash: Do not check key_state buffers that are in S_UNDEF state 
(Github ​#449) - the new sanity check function introduced in 2.6.7 sometimes 
tried to use a NULL pointer after an unsuccessful TLS handshake
* Windows: --dns option did not work when tap-windows6 driver was used, because 
internal flag for "apply DNS option to DHCP server" wasn't set (Github ​#447)
* Windows: fix status/log file permissions, caused by regression after changing 
to CMake build system (Github: ​#454, Trac: ​#1430)
* Windows: fix --chdir failures, also caused by error in CMake build system 
(Github ​#448)

Windows MSI changes since 2.6.7:

* Included openvpn-gui updated to 11.46.0.0

More details can be found in the Changes document:



(The Changes document also contains a section with work-arounds for
common problems encountered when using OpenVPN with OpenSSL 3)

Source code and Windows installers can be downloaded from our download page:



Debian and Ubuntu packages are available in the official apt repositories:



On Red Hat derivatives we recommend using the Fedora Copr repository.



Kind regards,
Yuriy Darnobyt___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.6.7 released

[Dmitry Melekhov]

14.11.2023 11:05, Gert Doering пишет:

Hi,

On Sun, Nov 12, 2023 at 06:08:48PM +, Greg Cox wrote:

Spun this config up, then ran:

iptables -t nat -A PREROUTING -i eth0 -p tcp -m multiport --dports 443,80
-j REDIRECT --to-ports 1194

Within 5 minutes the random web scanners found and segfaulted me.

... your port scanners are definitely better than mine - took more like 5
hours here to crash, but it confirms the current assumptions, ks->state
being S_UNDEF and ks->send_reliable being NULL.

Now, Arne's patch (if (ks->state == S_UNDEF) { continue; }) *should* have
fully fixed this, so I'm a bit surprised that we get "it still crashes"
reports...  will re-test with this setup and see what happens.

gert


I'd like to confirm that after patch and more then 24hours run I have no 
issues.



Thank you!



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.6.7 released

[Gert Doering]

Hi,

On Sun, Nov 12, 2023 at 06:08:48PM +, Greg Cox wrote:
> Spun this config up, then ran:
> 
> iptables -t nat -A PREROUTING -i eth0 -p tcp -m multiport --dports 443,80
> -j REDIRECT --to-ports 1194
> 
> Within 5 minutes the random web scanners found and segfaulted me.

... your port scanners are definitely better than mine - took more like 5
hours here to crash, but it confirms the current assumptions, ks->state
being S_UNDEF and ks->send_reliable being NULL.

Now, Arne's patch (if (ks->state == S_UNDEF) { continue; }) *should* have
fully fixed this, so I'm a bit surprised that we get "it still crashes"
reports...  will re-test with this setup and see what happens.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.6.7 released

[Gert Doering]

Hi,

On Sun, Nov 12, 2023 at 07:22:45PM +0100, Gert Doering wrote:
> (If you feel like debugging a bit more - could you compile an instance
> without optimization, run from gdb, and when it segfaults print all 
> local variables of interest?  i, j, ks, *ks, ks->send_reliable?  We
> got one variable print from Dmitry - thanks! - but the optimizer broke
> printing "ks" things)

Dmitry was able to do this, and has confirmed that ks->send_reliable
is NULL here, because of "half-initialized state" - which can be determined
by checking ks->state first (S_UNDEF = 0 --> send_reliable not yet
initialized).

Thanks for your help, Dmitry and Greg.  Fixed version coming soon...

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.6.7 released

[Greg Cox]

Segfaulting STR:

Rocky9 host, used 2.6.7 from the copr repo.

port 1194
proto tcp-server
dev tun1
ca /etc/openvpn/server/keys/ca.crt
cert /etc/openvpn/server/keys/server.crt
key /etc/openvpn/server/keys/server.key
dh none
tls-groups secp521r1:secp384r1
topology subnet
server 10.50.236.0 255.255.255.0
keepalive 10 120
tls-auth /etc/openvpn/server/keys/ta.key 0
data-ciphers AES-256-GCM
auth SHA512
tls-version-min 1.2
user openvpn
group openvpn
persist-key
persist-tun
log-append /var/log/openvpn/openvpn.log
verb 4
auth-gen-token 0 3600


Spun this config up, then ran:

iptables -t nat -A PREROUTING -i eth0 -p tcp -m multiport --dports 443,80
-j REDIRECT --to-ports 1194

Within 5 minutes the random web scanners found and segfaulted me.

Hope this helps.


On Fri, Nov 10, 2023 at 7:48 PM Gert Doering  wrote:

> Hi,
>
> On Fri, Nov 10, 2023 at 10:51:34AM +0100, Gert Doering wrote:
> > I'll see if I can reproduce this case here and we'll fix it ASAP.
>
> We couldn't reproduce it yet, but we have a crash dump in GH issue #449,
> which hints at the commit cd4d819c99266 getting this double-extra-check
> wrong.
>
> So if you build from git, can you do a checkout of release/2.6, and
> then do "git revert cd4d819c99266", and build from that?  This would
> give you a 2.6.7 "with both CVE fixes, but without the extra safeguard
> check" - which isn't *really* needed, but its intention was "should
> another mistake of sort addressed in the CVE fixes happen again, it
> would get caught" - so double belt and suspenders...
>
> gert
> --
> "If was one thing all people took for granted, was conviction that if you
>  feed honest figures into a computer, honest figures come out. Never
> doubted
>  it myself till I met a computer with a sense of humor."
>  Robert A. Heinlein, The Moon is a Harsh
> Mistress
>
> Gert Doering - Munich, Germany
> g...@greenie.muc.de
> ___________
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.6.7 released

[Gert Doering]

Hi,

On Sun, Nov 12, 2023 at 06:08:48PM +, Greg Cox wrote:
> Spun this config up, then ran:
> 
> iptables -t nat -A PREROUTING -i eth0 -p tcp -m multiport --dports 443,80
> -j REDIRECT --to-ports 1194
> 
> Within 5 minutes the random web scanners found and segfaulted me.

This sounds promising.  Hopefully we can make it crash too with that :-)

(Focus so far was on UDP because that was the first report we got, but if
TCP gets the job done, even better).

Not totally trivial, though... "basic" openssl s_client or just plain
"GET / HTTP/1.0" will just make OpenVPN close the link, not crash...

*keeps trying*


(If you feel like debugging a bit more - could you compile an instance
without optimization, run from gdb, and when it segfaults print all 
local variables of interest?  i, j, ks, *ks, ks->send_reliable?  We
got one variable print from Dmitry - thanks! - but the optimizer broke
printing "ks" things)

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.6.7 released

[Gert Doering]

Hi,

On Fri, Nov 10, 2023 at 10:51:34AM +0100, Gert Doering wrote:
> I'll see if I can reproduce this case here and we'll fix it ASAP.

We couldn't reproduce it yet, but we have a crash dump in GH issue #449,
which hints at the commit cd4d819c99266 getting this double-extra-check
wrong.

So if you build from git, can you do a checkout of release/2.6, and
then do "git revert cd4d819c99266", and build from that?  This would
give you a 2.6.7 "with both CVE fixes, but without the extra safeguard
check" - which isn't *really* needed, but its intention was "should 
another mistake of sort addressed in the CVE fixes happen again, it
would get caught" - so double belt and suspenders...

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.6.7 released

[Gert Doering]

Hi,

On Fri, Nov 10, 2023 at 12:25:22PM +0400, Dmitry Melekhov wrote:
> btw, what I missed, openvpn dies:
> 
> openvpn[11346]: segfault at 0 ip 55e33503f5f3 sp 7fff33642390 error
> 4 in openvpn[55e334fc8000+8f000]
> 
> but only  multipoint udp .

This is bad (but very different from "it stops forwarding", so it should
be much easier to reproduce).  Can you produce a log file with "verb 4" so
it shows what is happening before that?

I'll see if I can reproduce this case here and we'll fix it ASAP.

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.6.7 released

[Dmitry Melekhov]

btw, what I missed, openvpn dies:

openvpn[11346]: segfault at 0 ip 55e33503f5f3 sp 7fff33642390 
error 4 in openvpn[55e334fc8000+8f000]


but only  multipoint udp .



10.11.2023 11:35, Dmitry Melekhov пишет:

10.11.2023 11:23, Gert Doering пишет:

Hi,

On Fri, Nov 10, 2023 at 11:19:58AM +0400, Dmitry Melekhov wrote:

OK, now I know what is broken.

I have so called multihomed server,  and multihomed udp does not work in
2.6.7.

On server with only one external interface everything works OK.

Are you using --multihome in your config?  If not, please add this - UDP
on a server with multiple IP addresses of the same family (v4 or v6) can
not work reliably without --multihome.


yes, sure.

as I said 2.6.6 works OK , and all previous versions since multihomed 
support for udp was introduced.



If it does not work with --multihome, please send logs.



I see nothing strange in logs, server just lost connection, client 
too, then they reconnects.



(There is one multihome-related code change in 2.6.6 -> 2.6.7, but that
should only ever trigger if you use DCO)



I don't use dco, but multihomed udp does not work.



gert








___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.6.7 released

[Dmitry Melekhov]

10.11.2023 11:23, Gert Doering пишет:

Hi,

On Fri, Nov 10, 2023 at 11:19:58AM +0400, Dmitry Melekhov wrote:

OK, now I know what is broken.

I have so called multihomed server,  and multihomed udp does not work in
2.6.7.

On server with only one external interface everything works OK.

Are you using --multihome in your config?  If not, please add this - UDP
on a server with multiple IP addresses of the same family (v4 or v6) can
not work reliably without --multihome.


yes, sure.

as I said 2.6.6 works OK , and all previous versions since multihomed 
support for udp was introduced.




If it does not work with --multihome, please send logs.



I see nothing strange in logs, server just lost connection, client too, 
then they reconnects.



(There is one multihome-related code change in 2.6.6 -> 2.6.7, but that
should only ever trigger if you use DCO)



I don't use dco, but multihomed udp does not work.




gert


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.6.7 released

[Gert Doering]

Hi,

On Fri, Nov 10, 2023 at 11:19:58AM +0400, Dmitry Melekhov wrote:
> OK, now I know what is broken.
> 
> I have so called multihomed server,  and multihomed udp does not work in
> 2.6.7.
> 
> On server with only one external interface everything works OK.

Are you using --multihome in your config?  If not, please add this - UDP
on a server with multiple IP addresses of the same family (v4 or v6) can
not work reliably without --multihome.

If it does not work with --multihome, please send logs.

(There is one multihome-related code change in 2.6.6 -> 2.6.7, but that
should only ever trigger if you use DCO)

gert


-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.6.7 released

[Gert Doering]

Hi,

On Fri, Nov 10, 2023 at 10:21:35AM +0400, Dmitry Melekhov wrote:
> 10.11.2023 00:56, Yuriy Darnobyt ??:
> > The OpenVPN community project team is proud to release OpenVPN 2.6.7.
> 
> something is broken in 2.6.7. it stops passing traffic after several seconds
> after connection when acts as server,

Anything in the logs, when running with --verb 4?  Is this UDP or TCP?  Are
you using --fragment?

I ran the full server side test setup here, and all tests pass - now,
these are only running ~15 seconds per client connect, so might have
overlooked something... just to be sure, I've run a 15-minute ipv4/ipv6
ping test to a UDP server now, and that succeeded just fine.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.6.7 released

[Dmitry Melekhov]

10.11.2023 10:21, Dmitry Melekhov пишет:

10.11.2023 00:56, Yuriy Darnobyt пишет:

The OpenVPN community project team is proud to release OpenVPN 2.6.7.



something is broken in 2.6.7. it stops passing traffic after several 
seconds after connection when acts as server,


so I reverted it back to 2.6.6.

compiled from sources on ubuntu 22.04 with --disable-dco

don't know where is problem, at least now.



OK, now I know what is broken.

I have so called multihomed server,  and multihomed udp does not work in 
2.6.7.


On server with only one external interface everything works OK.


Could you, please, fix this?




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.6.7 released

[Dmitry Melekhov]

10.11.2023 00:56, Yuriy Darnobyt пишет:

The OpenVPN community project team is proud to release OpenVPN 2.6.7.



something is broken in 2.6.7. it stops passing traffic after several 
seconds after connection when acts as server,


so I reverted it back to 2.6.6.

compiled from sources on ubuntu 22.04 with --disable-dco

don't know where is problem, at least now.




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 2.6.7 released

[Yuriy Darnobyt]

The OpenVPN community project team is proud to release OpenVPN 2.6.7.

This is a bugfix release containing security fixes.

Security Fixes:

* CVE-2023-46850 OpenVPN versions between 2.6.0 and 2.6.6 incorrectly use a 
send buffer after
 it has been free()d in some circumstances, causing some free()d memory to be 
sent to the peer.
 All configurations using TLS (e.g. not using --secret) are affected by this 
issue.
 (found while tracking down CVE-2023-46849 / Github #400, #417)
* CVE-2023-46849 OpenVPN versions between 2.6.0 and 2.6.6 incorrectly restore 
--fragment configuration
 in some circumstances, leading to a division by zero when --fragment is used. 
On platforms where
 division by zero is fatal, this will cause an OpenVPN crash.(Github #400, 
#417).

User visible changes:

* DCO: warn if DATA_V1 packets are sent by the other side - this a hard 
incompatibility between
 a 2.6.x client connecting to a 2.4.0-2.4.4 server, and the only fix is to use 
--disable-dco.
* Remove OpenSSL Engine method for loading a key. This had to be removed 
because the original author
 did not agree to relicensing the code with the new linking exception added. 
This was a somewhat
 obsolete feature anyway as it only worked with OpenSSL 1.x, which is 
end-of-support.
* add warning if p2p NCP client connects to a p2mp server - this is a 
combination that used to work
 without cipher negotiation (pre 2.6 on both ends), but would fail in 
non-obvious ways with 2.6 to 2.6.
* add warning to --show-groups that not all supported groups are listed (this is
 due the internal enumeration in OpenSSL being a bit weird, omitting X448 and 
X25519 curves).
* --dns: remove support for exclude-domains argument (this was a new 2.6 option,
 with no backend support implemented yet on any platform, and it turns out that 
 no platform supported it at all - so remove option again)
* warn user if INFO control message too long, do not forward to management 
client
 (safeguard against protocol-violating server implementations)

New features:

* DCO-WIN: get and log driver version (for easier debugging).
* print "peer temporary key details" in TLS handshake
* log OpenSSL errors on failure to set certificate, for example if the 
algorithms used 
 are in acceptable to OpenSSL (misleading message would be printed in cryptoapi 
/ pkcs11 scenarios)
* add CMake build system for MinGW and MSVC builds
* remove old MSVC build system
* improve cmocka unit test building for Windows

Windows MSI changes since 2.6.6:

* Included openvpn-gui updated to 11.45.0.0
   * Add clarity for error on missing management parameter. See GH #657
   * Improve "OpenVPN GUI" tooltip handling See GH #649
* MSIs now use OpenSSL 3.1.4

More details can be found in the Changes document:



(The Changes document also contains a section with work-arounds for
common problems encountered when using OpenVPN with OpenSSL 3)

Source code and Windows installers can be downloaded from our download page:



Debian and Ubuntu packages are available in the official apt repositories:



On Red Hat derivatives we recommend using the Fedora Copr repository.



Kind regards,
Yuriy Darnobyt___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 3 Linux v21 released

[David Sommerseth]

OpenVPN 3 Linux v21 (stable)

This announcement comes a bit delayed as we have spent time ensuring
brand new software package repositories for both .deb and .rpm
packages are working properly.

We have now introduced a set of repositories suitable for production
environments.  These new repositories will only ship stable releases
which has been through a full set of quality assurance testing.
Packages in this repository will primarily focus on packages for
enterprise and long-term support Linux distributions, such as Debian
stable, Red Hat Enterprise Linux and Ubuntu LTS releases.

Fedora Copr repositories will still be used, but will also ship
development and beta releases.  We are also working on establishing
a similar repository for .deb packages too.  The Fedora Copr and the
coming repository for .deb packages will target faster moving Linux
distributions, such as the Fedora and the non-LTS Ubuntu releases.

   *NOTE*   The repository used for .deb packages up to
   *NOTE*   OpenVPN 3 Linux v20 will no longer receive
   *NOTE*   any updates.  You *MUST* setup the new
   *NOTE*   repository for .deb packages to receive the
   *NOTE*   OpenVPN 3 Linux v21 release

The community wiki has been updated with information how to enable
the new repositories, for both .deb and .rpm based distributions:



Over to the OpenVPN 3 Linux v21 details ...

Thais primarily a maintenance release with several minor bug fixes
and some general improvements.

*HOWEVER*, due to issues related to newer glib2 versions on
Arch Linux, Fedora and non-LTS Ubuntu releases, the v21 release
is targeting *only Enterprise/LTS distributions*.  The glib2
integration is going through a large overhaul to work better with
newer versions.  There will come a separate development release
for these distributions once that work has completed.  Details
related to this work can be tracked in this ticket:




* Improvement: Upgrade OpenVPN 3 Core Library to v3.8.2

   This is an upgrade from Core Library 3.7, which provides more
   enhancements and adds support for the newer ovpn-dco-v2 kernel
   module.  This is the same kernel module version OpenVPN 2.6
   supports.


* Bugfix: OpenVPN 3 Linux AWS VPC lacks support for IMDSv2

   mattjbyrd reported the AWS VPC integration was not working with EC2
   instances where IMDSv2 was enforced.  This issue is resolved with
   the OpenVPN 3 Core Library upgrade.

   Details: 


* Bugfix: Python StatusCallback did not work without LogCallback enabled

   Jeremy Fleischman reported an issue related the openvpn3 Python
   module did not work when just setting up a
   SessionManager.StatusCallback() method.  He provided a fix which is
   now included in v21.  Thanks a lot, Jeremy!

   Details:



* Bugfix: openvpn3 config-manage override may not always work

   The openvpn3 config-manage override options would in some cases not work
   due to a programming error related to an internal set_override() method
   and the SetOverride() D-Bus method.  The result was that typically
   string values ended up empty.  Now all the overrides can be configured
   again.


* Bugfix: OpenVPN 3 Python based configuration parser issues

   Several options and --profile-overrides did not work or was completely
   missing, like the dns-scope and allow-compression overrides.  This
   has been improved and the list of overrides should now be up-to-date
   with openvpn3 config-manage.

   The Python based option parser also did not fully support overrides
   with a boolean true/false setting properly.  This has also been
   fixed.


* Improvement: Detect needed host specific settings during package install

   The OpenVPN 3 Linux v20 introduced the openvpn3-admin init-config
   command.  This has been further improved and will now be run
   automatically during the package installation.  This command will
   probe the system for important features on the system, like what
   kind of system logging is in use, what kind of DNS resolver
   approach being available (systemd-resolved, /etc/resolv.conf) as
   well as doing other sanity checks, like if the needed openvpn
   user/group is present, important directories being configured
   correctly and that SELinux based systems have the proper file
   contexts set up.

   The default behaviour is that existing configuration changes done
   will NOT be overwritten.  But if no settings has been set, it will
   generate configurations files better matching the running system.


* Improvements: OpenVPN 3 Log Service

   The OpenVPN 3 Log service (openvpn3-service-logger) made it
   hard to track where Attached: and Detached: log events came
   from.  This does now add a PID reference, which can be traced
   more easily in the logs.

[Openvpn-devel] OpenVPN 2.6.6 released

[Frank Lichtenheld]

The OpenVPN community project team is proud to release OpenVPN 2.6.6.

This is a small bugfix release.

User visible changes:

* OCC exit messages are now logged more visibly. See GH ​#391.
* OpenSSL error messages are now logged with more details
  (for example, when loading a provider fails, which .so was tried, and why did 
it fail).
  See GH ​#361.
* print a more user-friendly message when tls-crypt-v2 client auth fails
* packaging now includes all documentation in the source tarball 

New features:

* set WINS server via interactive service - this adds support for
  "dhcp-option WINS 192.0.2.1" for DCO + wintun interfaces where
  no DHCP server is used. See GH ​#373. 

Windows MSI changes since 2.6.5:

* Included openvpn-gui updated to 11.44.0.0
* MSIs now use OpenSSL 3.1.2 

More details can be found in the Changes document:



(The Changes document also contains a section with work-arounds for
common problems encountered when using OpenVPN with OpenSSL 3)

Source code and Windows installers can be downloaded from our download page:



Debian and Ubuntu packages are available in the official apt repositories:



On Red Hat derivatives we recommend using the Fedora Copr repository.



Kind regards,
-- 
  Frank Lichtenheld


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN Linking Exception - current status report update July

[Arne Schwabe]

Am 15.02.23 um 13:31 schrieb David Sommerseth:


OpenVPN 2.x is licensed under the GNU Public License v2.0 (GPL-2.0). 
This license has served us well in the past and we are not trying to 
change that.  However, changes in licenses of our dependencies put us in 
an unfortunate situation.


Since the last update, we resolved the license approval for a number of 
contributors and are now down to just



Note that the actions for the individual source are my opinion/suggestions.

- Jason A. Donenfeld 

  - Patches to remove possible contribution on mailing list

- James Bottomley 

No response to my license email, however was active this year on 
the mailing list.


* Add unit tests for engine keys
* engine key support

This commits are only relevant for OpenSSL 1.x and we can probably
remove support for this feature again if James does not positively.

- Jérémie Courrèges-Anglas 

   - raised the question if we can keep the OpenSSL license exception
 forever to keep LibreSSL support. I think that is reasonable to just
 keep the outdated exception even if it is just for a handful of
 people using OpenVPN with LibreSSL. When we drafted the mails we
 proposed to remove this because we overlooked LibreSSL.

* Print time_t as long long and suseconds_t as long
probably not trivial.
* Rest of the commits look very small and can probably classified 
as trivial


- Andris Kalnozols 

   Address bounces, could not find any alternative method of contacting
   this person. three commits:

 * extract_x509_extension(): hide status message during normal 
operation.

 * Fix some typos in the man page.

trivial

* Do not upcase x509-username-field for mixed-case arguments.
   non-trivial needs more investigation.


- Mathieu GIANNECCHINI 

   Mail address bounces, could not find an alternative contact.
  --tls-export-cert option only

   One commit having the following feature:

   "--tls-export-cert [directory] : Get peer cert in PEM format and 
store it \n"
   "  in an openvpn temporary file in [directory]. Peer 
cert is \n"
   "  stored before tls-verify script execution and 
deleted after.\n"


We can remove the feature, it seems a corner case. If someone needs
it can still be reimplemented.





Arne


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


_______
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN Linking Exception - current status report

[Frank Lichtenheld]

On Wed, May 17, 2023 at 03:01:38PM +0200, Arne Schwabe wrote:
> Am 15.02.23 um 13:31 schrieb David Sommerseth:
> > 
> > OpenVPN 2.x is licensed under the GNU Public License v2.0 (GPL-2.0).
> > This license has served us well in the past and we are not trying to
> > change that.  However, changes in licenses of our dependencies put us in
> > an unfortunate situation.
> 
> So a good amount of time has passed and we got a lot of positive feedback to
> the license agreement. We got 107 positive responses back contributors
> including a positive one from Fox IT that covers all Fox It employers and a
> positive one from OpenVPN Inc that cover all code that OpenVPN Inc owns. And
> big thanks to everyone who said yes so far.
> 
> 
> With that we are down to a small number of people (10) that are still
> missing acknowledgment.
> 
> 
> Note that the actions for the individual source are my opinion/suggestions.
> 
[...]
> - Josh Cepek 
> 
>   No response at all to my emails. Commits were in 2013 and 2016
> 
>   All seven commits look trivial to me. Need someone else to form an opinion
> if this can be seen as trivial in total or not.
> 

I have reviewed his patches and I agree that they are all individual bug fixes
and are all individually trivial.

Regards,
-- 
  Frank Lichtenheld


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 2.6.5 released

[Frank Lichtenheld]

The OpenVPN community project team is proud to release OpenVPN 2.6.5.

This is a small bugfix release.

User visible changes:

* tapctl (windows): generate driver-specific names (if using tapctl to create
  additional tap/wintun/dco devices, and not using --name).
  See GH ​#337.
* interactive service (windows): do not force target desktop for openvpn.exe
  - this has no impact for normal use, but enables running of OpenVPN in a 
scripted
  way when no user is logged on (for example, via task scheduler).
  See GH ​openvpn-gui#626 

Windows MSI changes since 2.6.4:

* MSIs now use OpenSSL 3.1.1 

Debian/Ubuntu packages in official apt repositories are now available for 
arm64. 

More details can be found in the Changes document:



(The Changes document also contains a section with work-arounds for
common problems encountered when using OpenVPN with OpenSSL 3)

Source code and Windows installers can be downloaded from our download page:



Debian and Ubuntu packages are available in the official apt repositories:



On Red Hat derivatives we recommend using the Fedora Copr repository.



Kind regards,
-- 
  Frank Lichtenheld


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN Linking Exception - current status report

[Arne Schwabe]

Am 15.02.23 um 13:31 schrieb David Sommerseth:


OpenVPN 2.x is licensed under the GNU Public License v2.0 (GPL-2.0). 
This license has served us well in the past and we are not trying to 
change that.  However, changes in licenses of our dependencies put us in 
an unfortunate situation.


So a good amount of time has passed and we got a lot of positive 
feedback to the license agreement. We got 107 positive responses back 
contributors including a positive one from Fox IT that covers all Fox It 
employers and a positive one from OpenVPN Inc that cover all code that 
OpenVPN Inc owns. And big thanks to everyone who said yes so far.



With that we are down to a small number of people (10) that are still 
missing acknowledgment.



Note that the actions for the individual source are my opinion/suggestions.

- Jason A. Donenfeld 

  Has stated to me in a private IRC message that I should bothering him
  about this. Only negative reaction so far.

  * Support fingerprint authentication without CA certificate

  The original v1 patch of this has been significantly rewritten/changed
  by me. We need to check which parts of the v3 patch that of the
  original patch can be still attributed to Jason and rewrite that part
  unless we still get a positive reaction.

- James Bottomley 

   No response to my license email, however was active this year on the 
mailing list.


   * Add unit tests for engine keys
   * engine key support

   This commits are only relevant for OpenSSL 1.x and we can probably
   remove support for this feature again if James does not positively.

- Josh Cepek 

  No response at all to my emails. Commits were in 2013 and 2016

  All seven commits look trivial to me. Need someone else to form an 
opinion if this can be seen as trivial in total or not.



- Guido Vranken 

  No response at all to my emails. Commit are in 2017.

  - 7 smallish commit, not sure if they are trivial. Best to try to
reach this person
  - might be part of some security audit, need to double check if there
are some strings attached to that.

- Jérémie Courrèges-Anglas 

  - raised the question if we can keep the OpenSSL license exception
forever to keep LibreSSL support. I think that is reasonable to just
keep the outdated exception even if it is just for a handful of
people using OpenVPN with LibreSSL. When we drafted the mails we
proposed to remove this because we overlooked LibreSSL.

   * Print time_t as long long and suseconds_t as long
probably not trivial.
   * Rest of the commits look very small and can probably classified as 
   trivial


- Andris Kalnozols 

  Address bounces, could not find any alternative method of contacting
  this person. three commits:

* extract_x509_extension(): hide status message during normal 
operation.

* Fix some typos in the man page.

trivial

   * Do not upcase x509-username-field for mixed-case arguments.
  non-trivial needs more investigation.


- Mathieu GIANNECCHINI 

  Mail address bounces, could not find an alternative contact.
 --tls-export-cert option only

  One commit having the following feature:

  "--tls-export-cert [directory] : Get peer cert in PEM format and 
store it \n"
  "  in an openvpn temporary file in [directory]. Peer 
cert is \n"
  "  stored before tls-verify script execution and 
deleted after.\n"


   We can remove the feature, it seems a corner case. If someone needs
   it can still be reimplemented.

- Holger Kummert 

  Reached out to other ex-Sophos employees, will try to contact him.

  One commit bordering on trivial.


- Markus Koetter 

  Email address bounces, found no alternative contact method. One 
commit in 2011


  Add extv3 X509 field support to --x509-username-field

  Needs --enable-x509-alt-username configure option to be enabled, not
  enabled by default.


- Vasily Kulikov 

  No response so far. Would be probably good to check for alternative
  email address

  One trivial commit and

  * Mac OS X Keychain management client

   contrib/keychain-mcd already removed since it had code quality issues.

   Code for management-external-cert still in OpenVPN, is not trivial



Arne


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 2.6.4 released

[Frank Lichtenheld]

The OpenVPN community project team is proud to release OpenVPN 2.6.4.

This is a small bugfix release.

Note:

* License amendment: all NEW commits fall under a modified license that 
explicitly permits
  linking with Apache2 libraries (mbedTLS, OpenSSL).
  See COPYING for details. Existing code will fall under the new license as 
soon as all
  contributors have agreed to the change - work ongoing.

Feature changes:

* DCO: support kernel-triggered key rotation (avoid IV reuse after 232 packets).
  This is the userland side, accepting a message from kernel, and initiating a
  TLS renegotiation. As of 2.6.4 release, only implemented in FreeBSD kernel. 

Windows MSI changes since 2.6.3:

* Rebuilt included tap-windows driver with the correct version of the old 
Windows 7 driver,
  removing a warning about unsigned driver on Windows 7 installation.
  See GH ​openvpn-build#365. 

More details can be found in the Changes document:



(The Changes document also contains a section with work-arounds for
common problems encountered when using OpenVPN with OpenSSL 3)

Source code and Windows installers can be downloaded from our download page:



Debian and Ubuntu packages are available in the official apt repositories:



On Red Hat derivatives we recommend using the Fedora Copr repository.



Kind regards,
-- 
  Frank Lichtenheld


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Openvpn-users] auth-token-user/auth-token issue with "TLS Auth Error: username attempted to change"

[Arne Schwabe]

Am 05.05.23 um 09:33 schrieb Gert Doering:

Hi,

On Fri, May 05, 2023 at 09:14:03AM +0200, Ralf Hildebrandt via Openvpn-users 
wrote:

May  5 09:06:00 openvpn-gw170-int openvpn-udp[29574]: 
hildeb/10.31.192.115:55334 TLS Auth Error: username attempted to change from 
'hildeb' to 'hildeb::1f047fb6' -- tunnel disabled
May  5 09:06:00 openvpn-gw170-int openvpn-udp[29574]: 
hildeb/10.31.192.115:55334 TLS Auth Error: Auth Username/Password verification 
failed for peer

What do we have to do to make the server accept the the
auth-token-user it pushed to the client?


As of today, there is no way to make it do that.  On initial TLS
authentication, the session is tied hard to the initial username(*),
and changing username on reauthentication is not allowed.

That said, this breaks at least two use cases

  - there was no initial username/password authentication at all - and
you absolutely need auth-token-user here, to make the client actually
send the auth-token back.  It fails, because the server is locked
to "empty username" - I have sent a patch for this, but Arne is not
fully agreeing with me that it's the right thing

  - actually *changing* the auth-token-user from an original username/password
authentication - it runs into the same problem, but this might be
workaroundable by not actually pushing a new "user".  So, question to
you, what is the intention behind changing the username here?


For "my case", I think handling the "username was empty before" case
specially is the easy way forward (even if Arne disagrees), but for
"your case" we'd need to disable the "tie TLS session to username",
which is a no-go for Arne...


So the empty username is problematic since we use the auth-token to 
reauthenticate with that username and then OpenVPN will tell you that 
you have an empty username that is fully authenticated. And I am not 
sure what that would mean in any context. Also if you have no username, 
you either need to track the session in the auth token to ensure that 
you the same user as before or that session could be used with any 
certificate.


For changing the username, that looks simple on the first glance but we 
need to carefully go through our to see where the username is 
used/locked in our code to understand what implications this has.


Arne



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Openvpn-users] auth-token-user/auth-token issue with "TLS Auth Error: username attempted to change"

[Gert Doering]

Hi,

On Fri, May 05, 2023 at 09:14:03AM +0200, Ralf Hildebrandt via Openvpn-users 
wrote:
> May  5 09:06:00 openvpn-gw170-int openvpn-udp[29574]: 
> hildeb/10.31.192.115:55334 TLS Auth Error: username attempted to change from 
> 'hildeb' to 'hildeb::1f047fb6' -- tunnel disabled
> May  5 09:06:00 openvpn-gw170-int openvpn-udp[29574]: 
> hildeb/10.31.192.115:55334 TLS Auth Error: Auth Username/Password 
> verification failed for peer
> 
> What do we have to do to make the server accept the the
> auth-token-user it pushed to the client?

As of today, there is no way to make it do that.  On initial TLS
authentication, the session is tied hard to the initial username(*),
and changing username on reauthentication is not allowed.

That said, this breaks at least two use cases

 - there was no initial username/password authentication at all - and
   you absolutely need auth-token-user here, to make the client actually
   send the auth-token back.  It fails, because the server is locked
   to "empty username" - I have sent a patch for this, but Arne is not
   fully agreeing with me that it's the right thing

 - actually *changing* the auth-token-user from an original username/password
   authentication - it runs into the same problem, but this might be 
   workaroundable by not actually pushing a new "user".  So, question to
   you, what is the intention behind changing the username here?


For "my case", I think handling the "username was empty before" case
specially is the easy way forward (even if Arne disagrees), but for
"your case" we'd need to disable the "tie TLS session to username",
which is a no-go for Arne...

So maybe we need to introduce a new server option

  push-auth-token-user $name

which would be internally converted into

  push "auth-token-user $name"
  + tie $name to the TLS session

Will discuss this with Arne.  Not sure he's reading openvpn-users - so
copying in openvpn-devel.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 2.6.3 released

[Frank Lichtenheld]

The OpenVPN community project team is proud to release OpenVPN 2.6.3.

This is a small bugfix release.

Feature changes:

* Windows: support setting DNS domain in configurations without GUI and DHCP
  (typically wintun or windco drivers), see GH ​openvpn#306. 

Windows MSI changes since 2.6.2:

* Several Windows-specific issues fixed:
  * ensure interactive service stays enabled after silent reinstall,
see GH ​openvpn-build#348, ​openvpn-build#349 and ​openvpn-build#351
  * repair querying install path info for easyrsa-start.bat on some Windows
language versions, see GH ​openvpn-build#352. 
* MSIs are now built against OpenSSL 3.1.0.
* Update included openvpn-gui to 11.41.0.0
  * This update removes the ability to change the password of a private key 
from the GUI.
This was a niche feature which caused a direct dependency of GUI on OpenSSL.
Use openssl.exe directly if you need to edit a private key. 

More details can be found in the Changes document:



(The Changes document also contains a section with work-arounds for
common problems encountered when using OpenVPN with OpenSSL 3)

Source code and Windows installers can be downloaded from our download page:



Debian and Ubuntu packages are available in the official apt repositories:



On Red Hat derivatives we recommend using the Fedora Copr repository.



Kind regards,
-- 
  Frank Lichtenheld


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 2.6.2 released

[Frank Lichtenheld]

The OpenVPN community project team is proud to release OpenVPN 2.6.2.

This is mostly a bugfix release with some improvements.

Feature changes:

* implement byte counter statistics for DCO Linux (p2mp server and client)
* implement byte counter statistics for DCO Windows (client only)
* "--dns server  address ..." now permits up to 8 v4 or v6 addresses

Important note for Linux DCO users:

New control packets flow for data channel offloading on Linux:
2.6.2+ changes the way OpenVPN control packets are handled on Linux when
DCO is active, fixing the lockups observed with 2.6.0/2.6.1 under high client
connect/disconnect activity. This is an INCOMPATIBLE change and therefore an
ovpn-dco kernel module older than v0.2.20230323 (commit ID 726fdfe0fa21) will
not work anymore and must be upgraded. The kernel module was renamed to
"ovpn-dco-v2.ko" in order to highlight this change and ensure that users and
userspace software could easily understand which version is loaded. Attempting
to use the old ovpn-dco with 2.6.2+ will lead to disabling DCO at runtime.

Windows MSI changes since 2.6.1:

* Update included openvpn-gui to 11.39.0.0

More details can be found in the Changes document:



(The Changes document also contains a section with work-arounds for
common problems encountered when using OpenVPN with OpenSSL 3)

Source code and Windows installers can be downloaded from our download page:



Debian and Ubuntu packages are available in the official apt repositories:



On Red Hat derivatives we recommend using the Fedora Copr repository.



Kind regards,
-- 
  Frank Lichtenheld


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 3 Linux v20 released

[David Sommerseth]

OpenVPN 3 Linux v20 (stable)

This is the first stable release of OpenVPN 3 Linux.  This release is
mostly adding minor improvements, a few bug fix and adding two more
helper tools.


* Feature: openvpn3-admin journal

  This is a helper function to retrieve log events from the OpenVPN 3
  Linux stack logging with systemd-journald.  It can be considered a
  lightweight journaldctl tool, which is targetting some of the filters
  useful for OpenVPN 3 Linux.


* Feature: openvpn3-admin init-setup

  This is another helper function to configure OpenVPN 3 Linux in an
  automated fashion based on the current runtime environment.  It will
  ensure proper   state directories are present with the proper
  ownership and access, as well as SELinux context labels if that is
  available.  It will check if the needed user/group accounts is present
  and whether to use systemd-journald and systemd-resolved or not.

  In the next release, this feature will be used in the the packaging
  scripts for Debian/Ubuntu and Fedora/Red Hat Enterprise Linux packaging
  as well.


* Improvement: CR_TEXT based multi-factor authentication support

  Prior releases did not support CR_TEXT/crtext based authentication
  which would result in disconnecting from the server while querying the
  user for the additional credentials.  This new mode is more efficient
  and will keep the connection to the server alive.


* Improvement: Improve behaviour with incorrect private key passphrase

  Prior releases would dump an error message which would not be much
  end-user friendly if the connection failed due to incorrect passphrase
  to the private encryption key needed for the connection.  This has
  been improved and the error handling should be more clear for
  non-technical users.
  


* Improvement: Run resume and restart operations in the background

  Until now, the openvpn3 session-manage --resume and --restart
  operations would run in the foreground, resulting in stopping the VPN
  session if this operation would be interrupted.  These operations can
  typically run in the background.  If a re-authentication would be
  need, the openvpn3 session-auth command is available to complete that
  operation.

  It is also possible to run these operations in the foreground by
  adding the --timeout argument with a value reasonable to wait for this
  operation to complete.


* Improvement: Install openvpn3/constants.h header file

  This adds a header file which contains all the constants used by the
  OpenVPN 3 Linux stack, which is suitable for C programs.  The
  constants listed here is similar to the constants found when importing
  the Python 3 openvpn3.constants module.  These constants are typically
  used in D-Bus signals issued by the OpenVPN 3 Linux stack.


* Bugfix: Don't hardcode use of  --journald in openvpn3-service-logger

  Not all Linux distributions ships with the systemd stack.  Auto-detect
  during build time if systemd support is available or not and fallback
  to syslog if systemd support is lacking.


* Bugfix: Don't hard-fail if systemd-resolved is unreachable

  If openvpn3-service-netcfg could not reach or access the
  systemd-resolved service, it would hard-fail which again would cause
  the VPN session to fail starting.  This has been changed so the VPN
  session will succeed, but it will instead not do the DNS
  configuration.  This situation will be duly logged in the system logs.


* Documentation: Highlight deprecation of openvpn3-autoload

  The openvpn3-autoload feature is being deprecated in favour of using
  the systemd openvpn3-session@.service feature instead.  The
  openvpn3-autoload feature will still be around though, until there is
  a suitable alternative for Linux distributions not capable of using
  the native systemd approach.


* Documentation: Generic overhaul

  Lots of the man pages as well as README.md file has been reviewed and
  updated.  Lots of details has been clarified and the README.md has
  been split up into several files as it has grown quite a lot and some
  of the information would be better to have in other files to avoid
  duplicating the information.

* Code: Coding style

  There exists now a .clang-format coding style definition and all the
  C++ source code and headers should now be using this style.

* Copyright: Switch to SPDX license tags

  To ease the maintenance of copyright blobs, all files with an AGPL
  copyright blob has been switched to the SPDX license tag.


* Source code hosting

  Codeberg has been tested for a little while and I have decided to give
  it more widely use.  As of this release, the main source code hosting
  will be at the codeberg.org instance.  The OpenVPN 3 Linux project
  will in the coming days do a full migration where all issues from
  GitHub will be migrated as best as it can.  The GitHub and GitLab
  instances will still carry a mirror of the git repository, but issue
  tracking will be moved to Codeberg.


Supported Linux distributions
-

[Openvpn-devel] OpenVPN 2.6.1 released

[Frank Lichtenheld]

The OpenVPN community project team is proud to release OpenVPN 2.6.1.

This is mostly a bugfix release with some improvements. 

Feature changes:

* Dynamic TLS Crypt:
  When both peers are OpenVPN 2.6.1+, OpenVPN will dynamically create a 
tls-crypt
  key that is used for renegotiation. This ensure that only the previously
  authenticated peer can do trigger renegotiation and complete renegotiations.
* CryptoAPI (Windows): support issuer name as a selector.
  Certificate selection string can now specify a partial issuer name string as
  "--cryptoapicert ISSUER:" where  is matched as a substring of
  the issuer (CA) name in the certificate. 

Note: configure now enables DCO build by default on FreeBSD and Linux. On Linux
this brings in a new default dependency for libnl-genl (for Linux distributions
that are too old to have a suitable version of the library, use
"configure --disable-dco")

Windows MSI changes since 2.6.0:

* Update included ovpn-dco-win driver to 0.9.2 

More details can be found in the Changes document:



(The Changes document also contains a section with work-arounds for
common problems encountered when using OpenVPN with OpenSSL 3)

Source code and Windows installers can be downloaded from our download page:



Debian and Ubuntu packages are available in the official apt repositories:



On Red Hat derivatives we recommend using the Fedora Copr repository.



Kind regards,
-- 
  Frank Lichtenheld


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.5.9 released

[Matthias Andree]

Am 16.02.23 um 18:52 schrieb Gert Doering:

Hi,

On Thu, Feb 16, 2023 at 08:48:26AM -0500, Jonathan K. Bullard wrote:

On Thu, Feb 16, 2023 at 7:51 AM Frank Lichtenheld  wrote:

The OpenVPN community project team is proud to release OpenVPN 2.5.9. This is
a small bugfix release.

Was this sent a bit early? There is no 2.5.9 tag at
https://github.com/OpenVPN/openvpn/tags.

One day I will learn that it's "git push" *and* "git push --tags".

So the repo was updated, but the tag was missing.  Sorry for that.



I've come to like git push --follow-tags: (quoting the 2.39.2 manpage)
which is a two-in-one for typical release pushes:


--follow-tags
   Push all the refs that would be pushed without this option,
   and also push annotated tags in refs/tags that are missing
   from the remote but are pointing at commit-ish that are
   reachable from the refs being pushed. This can also be
   specified with configuration variable push.followTags. For
   more information, see push.followTags in git-config(1).


This assumes that tags are annotated, but since you've signed it, it's
also annotated.  Note there is a corresponding configuration option, too.

HTH
Matthias



gert



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.5.9 released

[Gert Doering]

Hi,

On Thu, Feb 16, 2023 at 08:48:26AM -0500, Jonathan K. Bullard wrote:
> On Thu, Feb 16, 2023 at 7:51 AM Frank Lichtenheld  
> wrote:
> >
> > The OpenVPN community project team is proud to release OpenVPN 2.5.9. This 
> > is
> > a small bugfix release.
> 
> Was this sent a bit early? There is no 2.5.9 tag at
> https://github.com/OpenVPN/openvpn/tags.

One day I will learn that it's "git push" *and* "git push --tags".

So the repo was updated, but the tag was missing.  Sorry for that.

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.5.9 released

[Jonathan K. Bullard]

On Thu, Feb 16, 2023 at 9:24 AM Arne Schwabe  wrote:
>
> Am 16.02.23 um 14:11 schrieb Jonathan K. Bullard:
> > Not yet seeing anything about 2.5.9 at
> > https://openvpn.net/community-downloads/
> > . (From the New York City
> > metropolitan area.)
> >
> > Maybe caches need updating?
> >
>
> I reached out to our the website team and the statement they gave to
> rely to the community is:
>
> We're working on the Community 2.5.9 release and shall have it updated
> on the website very soon. Thank you for your patience and love to the
> OpenVPN Community and please come back to check our website later today.
>
>
> They also gave me a time of 11:30 am pst, which is about in about 5
> hours from now. And I am not happy with this response either.
>
> Arne

Thanks for the update! And congratulations on, and thanks for, the new release!

Jon


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.5.9 released

[Arne Schwabe]

Am 16.02.23 um 14:11 schrieb Jonathan K. Bullard:
Not yet seeing anything about 2.5.9 at 
https://openvpn.net/community-downloads/ 
. (From the New York City 
metropolitan area.)


Maybe caches need updating?



I reached out to our the website team and the statement they gave to 
rely to the community is:


We're working on the Community 2.5.9 release and shall have it updated 
on the website very soon. Thank you for your patience and love to the 
OpenVPN Community and please come back to check our website later today.



They also gave me a time of 11:30 am pst, which is about in about 5 
hours from now. And I am not happy with this response either.


Arne



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.5.9 released

[Jonathan K. Bullard]

(Sorry for my earlier top-post.)

On Thu, Feb 16, 2023 at 7:51 AM Frank Lichtenheld  wrote:
>
> The OpenVPN community project team is proud to release OpenVPN 2.5.9. This is
> a small bugfix release.
>

Was this sent a bit early? There is no 2.5.9 tag at
https://github.com/OpenVPN/openvpn/tags.

Best regards,

Jon Bullard


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.5.9 released

[Dmitry Melekhov]

16.02.2023 17:11, Jonathan K. Bullard пишет:
Not yet seeing anything about 2.5.9 at 
https://openvpn.net/community-downloads/. (From the New York City 
metropolitan area.)


Maybe caches need updating?


use almost the same url as for 2.5.8 but change version, works for me.




Best regards,

Jon Bullard




On Thu, Feb 16, 2023 at 7:51 AM Frank Lichtenheld 
 wrote:


The OpenVPN community project team is proud to release OpenVPN
2.5.9. This is
a small bugfix release.

The Windows MSI installers are now built against OpenSSL 1.1.1t
which contains
several security fixes.

List of changes in OpenVPN:

<https://github.com/OpenVPN/openvpn/blob/release/2.5/Changes.rst>

Source code and Windows installers can be downloaded from our
download page:

<https://openvpn.net/community-downloads/>

Debian and Ubuntu packages are available in the official apt
repositories:

<https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos>

On Red Hat derivatives we recommend using the Fedora Copr repository.

<https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-release/>

Regards,
-- 
  Frank Lichtenheld



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.5.9 released

[Jonathan K. Bullard]

Not yet seeing anything about 2.5.9 at
https://openvpn.net/community-downloads/. (From the New York City
metropolitan area.)

Maybe caches need updating?

Best regards,

Jon Bullard




On Thu, Feb 16, 2023 at 7:51 AM Frank Lichtenheld 
wrote:

> The OpenVPN community project team is proud to release OpenVPN 2.5.9. This
> is
> a small bugfix release.
>
> The Windows MSI installers are now built against OpenSSL 1.1.1t which
> contains
> several security fixes.
>
> List of changes in OpenVPN:
>
> <https://github.com/OpenVPN/openvpn/blob/release/2.5/Changes.rst>
>
> Source code and Windows installers can be downloaded from our download
> page:
>
> <https://openvpn.net/community-downloads/>
>
> Debian and Ubuntu packages are available in the official apt repositories:
>
> <https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos>
>
> On Red Hat derivatives we recommend using the Fedora Copr repository.
>
> <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-release/>
>
> Regards,
> --
>   Frank Lichtenheld
>
>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 2.5.9 released

[Frank Lichtenheld]

The OpenVPN community project team is proud to release OpenVPN 2.5.9. This is
a small bugfix release.

The Windows MSI installers are now built against OpenSSL 1.1.1t which contains
several security fixes.

List of changes in OpenVPN:



Source code and Windows installers can be downloaded from our download page:



Debian and Ubuntu packages are available in the official apt repositories:



On Red Hat derivatives we recommend using the Fedora Copr repository.



Regards,
-- 
  Frank Lichtenheld


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN Linking Exception

[David Sommerseth]

OpenVPN 2.x is licensed under the GNU Public License v2.0 (GPL-2.0). 
This license has served us well in the past and we are not trying to 
change that.  However, changes in licenses of our dependencies put us in 
an unfortunate situation.


Both mbed TLS and OpenSSL nowadays use the Apache 2.x license (APL-2). 
For the OpenSSL library we have a special exception that allows us 
linking with it.  For newer mbed TLS versions, we cannot do this any more.


The APL-2 allows very liberal use of its source code when including it 
in other program (like BSD license).  Unlike BSD licenses, the APL-2 has 
a few additions that position it better in today's legal landscape.  It 
requires patent grant (in layman terms: you cannot contribute to an 
APL-2 licensed project and later sue someone for using your patents on 
the code you contributed).  This is the most critical aspect where the 
APL-2 is incompatible with GPL-2.0 according to Free Software Foundation 
- .


A short overview of APL-2 and license text can be found here:


The OpenVPN community has discussed these issues with Pamela Chestek
 on the linking exception.  She is a 
renowned open source license legal expert.  Various options for this 
challenge have been studied and evaluated.


What is clear is that we will need a linking exception.  The OpenSSL and
mbed TLS libraries may be considered system libraries on Linux systems 
but cannot be considered as such for distributions of the OpenVPN binary 
on Windows, macOS or Android.



The proposed linking exception for OpenVPN:

In addition, as a special exception, OpenVPN Inc and the
contributors give permission to link the code of this program to
libraries (the "Libraries") licensed under the Apache License
version 2.0 (this work and any linked library the "Combined Work")
and copy and distribute the Combined Work without an obligation to
license the Libraries under the GNU General Public License v2
(GPL-2.0) as required by Section 2 of the GPL-2.0, and without an
obligation to refrain from imposing any additional restrictions in
the Apache License version 2 that are not in the GPL-2.0, as
required by Section 6 of the GPL-2.0.  You must comply with the
GPL-2.0 in all other respects for the Combined Work, including
the obligation to provide source code.  If you modify this file, you
may extend this exception to your version of the file, but you are
not obligated to do so.  If you do not wish to do so, delete this
exception statement from your version.

This exception is the verbatim copy from Pamela Chestek, and the content
in this copy above has been reviewed by her.  There is some legalese
phrases there (in particular related to "Combined work") which may seem 
odd, but this is common practice in legal definitions.


In plain non-legalese English this basically says:

 * The intention for this license exception is to allow OpenVPN to be
   linked against APL-2 licensed libraries, even where the GPL-2.0 and
   APL-2 licenses conflict from a legal perspective.

 * OpenVPN itself will stay GPL-2.0 and the code belonging to the
   OpenVPN project must comply to the GPL-2.0 license.  This is NOT
   dual-licensing of the OpenVPN code base.

 * This license exception DOES NOT require NOR expect a license change
   of the APL-2 based library.  This exception allows using the APL-2
   library as-is.  However, when distributing a compiled OpenVPN binary
   linking against APL-2 libraries ("Combined Work"), the REQUIREMENT is
   that the APL-2 library MUST also be available on similar terms as in
   GPL-2.0, like providing the source code of the library upon request,
   except in the two specific ways mentioned.

 * If the APL-2 based library forbids such linking and distribution,
   this license exception DOES NOT overrule the restriction of the APL-2
   based library.  If the APL-2 library cannot satisfy the requirements
   in this license exception, you CANNOT distribute an OpenVPN binary
   linked with this library.


I hope we can reach an agreement and replace the current OpenSSL linking 
exception with this new exception above.



--
kind regards,

David Sommerseth
OpenVPN Inc



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.6.0 released

[Frank Lichtenheld]

On Fri, Jan 27, 2023 at 08:41:38PM +0100, Matthias Andree wrote:
> Am 25.01.23 um 20:50 schrieb Frank Lichtenheld:
> > The OpenVPN community project team is proud to release OpenVPN 2.6.0.
> > This is the new stable version of OpenVPN with some major new features.
> 
> Hi Frank,
> 
> OpenVPN 2.5.x releases also showed up in .tar.xz format - are there
> plans to provide these (and the detached GnuPG signatures) also for
> OpenVPN 2.6.0?

No, we decided that we see not enough benefit in providing these
differing compressions. The tarball is really not big enough for it
to matter.

Regards,
-- 
  Frank Lichtenheld


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.6.0 released

[Matthias Andree]

Am 25.01.23 um 20:50 schrieb Frank Lichtenheld:

The OpenVPN community project team is proud to release OpenVPN 2.6.0.
This is the new stable version of OpenVPN with some major new features.


Hi Frank,

OpenVPN 2.5.x releases also showed up in .tar.xz format - are there
plans to provide these (and the detached GnuPG signatures) also for
OpenVPN 2.6.0?

Cheers,
Matthias


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.6.0 released

[David Sommerseth]

On 27/01/2023 12:32, André wrote:

Hi,

So download link in Forum Announcement should be corrected?
https://forums.openvpn.net/viewtopic.php?t=35260



Yes, thank you!  Updated!


--
kind regards,

David Sommerseth
OpenVPN Inc




--- Original Message ---
On Friday, January 27th, 2023 at 01:53, David Sommerseth 
 wrote:



On 25/01/2023 20:50, Frank Lichtenheld wrote:
[...snip...]


On Red Hat derivatives we recommend using the Fedora Copr repository.

https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-release/




A slight update here. The repo above will be preserved for OpenVPN 2.5
releases. A new repository for OpenVPN 2.6 has been published:

https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-release-2.6/



--
kind regards,

David Sommerseth
OpenVPN Inc




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel





___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.6.0 released

[André via Openvpn-devel]

Hi,

So download link in Forum Announcement should be corrected?
https://forums.openvpn.net/viewtopic.php?t=35260






Sent with Proton Mail secure email.

--- Original Message ---
On Friday, January 27th, 2023 at 01:53, David Sommerseth 
 wrote:


> On 25/01/2023 20:50, Frank Lichtenheld wrote:
> [...snip...]
> 
> > On Red Hat derivatives we recommend using the Fedora Copr repository.
> > 
> > https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-release/
> 
> 
> 
> A slight update here. The repo above will be preserved for OpenVPN 2.5
> releases. A new repository for OpenVPN 2.6 has been published:
> 
> https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-release-2.6/
> 
> 
> 
> --
> kind regards,
> 
> David Sommerseth
> OpenVPN Inc
> 
> 
> 
> 
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.6.0 released

[David Sommerseth]

On 25/01/2023 20:50, Frank Lichtenheld wrote:
[...snip...]


On Red Hat derivatives we recommend using the Fedora Copr repository.





A slight update here.  The repo above will be preserved for OpenVPN 2.5 
releases.  A new repository for OpenVPN 2.6 has been published:





--
kind regards,

David Sommerseth
OpenVPN Inc




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 2.6.0 released

[Frank Lichtenheld]

The OpenVPN community project team is proud to release OpenVPN 2.6.0.
This is the new stable version of OpenVPN with some major new features.

Changes since RC2:

* Various bugfixes, see 
https://github.com/OpenVPN/openvpn/blob/v2.6.0/Changes.rst

Windows MSI changes since RC2:
* Included openvpn-gui updated to 11.36.0.0. See 
https://github.com/OpenVPN/openvpn-gui/blob/v11.36.0.0/CHANGES.rst.
* DCO driver is now included as a installer module (msm) so that other products 
(like OpenVPN Connect) can share the DCO installation.

Some highlights of 2.6.0 are:

* Data Channel Offload (DCO) kernel acceleration support for Windows, Linux, 
and FreeBSD.
* OpenSSL 3 support, which is now the default on Windows.
* Improved handling of tunnel MTU, including support for pushable MTU.
* Outdated cryptographic algorithms disabled by default, but there are options 
to override
  if necessary.
* Reworked TLS handshake, making OpenVPN immune to replay-packet state 
exhaustion attacks.
* Added --peer-fingerprint mode for a more simplistic certificate setup and 
verification.
* Added Pre-Logon Access Provider support to OpenVPN GUI for Windows.
* Improved protocol negotiation, leading to faster connection setup.

More details can be found in the Changes document:



(The Changes document also contains a section with work-arounds for
common problems encountered when using OpenVPN with OpenSSL 3)

Source code and Windows installers can be downloaded from our download page:



(The Windows installers use OpenSSL 3 now)

(The Community Downloads page on openvpn.net

will probably be updated tomorrow).

Debian and Ubuntu packages are available in the official apt repositories:



On Red Hat derivatives we recommend using the Fedora Copr repository.



Kind regards,
-- 
  Frank Lichtenheld


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Openvpn-users] 2.6rc2 server with DCO and 2.6rc2 client with DCO: not working

[Gert Doering]

Hi,

(copying openvpn-devel, as Arne and Antonio are not reading -users)

On Wed, Jan 18, 2023 at 05:34:51PM +0100, Ralf Hildebrandt via Openvpn-users 
wrote:
> You might have noticed our bug reports regarding capabilities && 2.6rc2.
> The whole point of it all was to test 2.6.x's DCO in our openvpn 
> infrastructure :)

And we appreciate this :-)

> But once we enabled DCO on the server side, things started to go awry - again.
> 
> 2.5.x was not able to connect. 
> So I thought: "Meh, maybe I should use 2.6rc on both cient and server". 
> Said and done.
> 
> Now the server complains:
> =
[..]
> Jan 18 17:16:36 localhost openvpn-udp[50313]: hildeb/10.31.123.139:39440 
> Note: '--allow-compression' is not set to 'no', disabling data channel 
> offload.
> Jan 18 17:16:36 localhost openvpn-udp[50313]: hildeb/10.31.123.139:39440 
> Consider using the '--compress migrate' option.
> Jan 18 17:16:36 localhost openvpn-udp[50313]: hildeb/10.31.123.139:39440 
> MULTI: client has been rejected due to incompatible DCO options

This is a bit surprising.  As you say, it *should* do that for the whole
server, not on a per-client connection.

Is there something related to compression in the main config and/or in
the per-client config (ccd, plugin, ...)?

[..]
> I'm reading this as: The server doesn't like the client based on 
> "incompatible DCO
> options", obviously due to "allow-compression" not being set to "no"
> (which is the default, according to the docs) 

Correct.  This is surprising, and should not happen.

(Sometimes its unavoidable - like, global options *are* compatible with
DCO, and then a per-client config shows up with incompatible options -
and then there is nothing the server can do, as it can not switch to
non-DCO for an individual client.  But see above, should not happen here)

[..]
> allow-compression no
> --- snip ---
> 
> So we clearly set "allow-compression" to "no". And no other compression
> is active (I think).

Indeed!

Anything special config generated by the client-connect script, maybe?


[..]
> 2023-01-18 17:16:37 AUTH: Received control message: AUTH_FAILED
> 2023-01-18 17:16:37 SIGTERM received, sending exit notification to peer

Signalling server->client is limited at this point, but maybe we could
find a way to make this "AUTH_FAILED:server options incompatible with DCO"
or so.  Arne?

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 2.6_rc2 released

[Frank Lichtenheld]

The OpenVPN community project team is proud to release OpenVPN 2.6_rc2.
This is the second release candidate (and the fourth beta release) for
the feature release 2.6.0.

Changes since RC1:

* Add rate limiter for incoming "initial handshake packets",
  enabled by default with a limit of 100 packets per 10 seconds.
  This change makes OpenVPN servers uninteresting as an UDP reflection DDoS 
engine.
* Report CONNECTED,ROUTE_ERROR to management GUI if connection to server 
succeeds
  but not all routes can be installed (Windows and Linux/Netlink only, so far) 
* Various bugfixes, see 
https://github.com/OpenVPN/openvpn/blob/v2.6_rc2/Changes.rst

Windows MSI changes since RC1:
* Included openvpn-gui updated to 11.35.0.0. See 
https://github.com/OpenVPN/openvpn-gui/blob/v11.35.0.0/CHANGES.rst.
  * New feature: Support the CONNECTED,ROUTE_ERROR management message (see 
above) 
* Fix some issues related to upgrading:
  * "Run on logon" option not preserved when updating from 2.5 to 2.6
  * Fix check for running service when upgrading from old NSIS installations 

Debian packages changes since RC1:

* Packages for Debian bookworm are now available. 

Some highlights of 2.6.0 are:

* Data Channel Offload (DCO) kernel acceleration support for Windows, Linux, 
and FreeBSD.
* OpenSSL 3 support.
* Improved handling of tunnel MTU, including support for pushable MTU.
* Reworked TLS handshake, making OpenVPN immune to replay-packet state 
exhaustion attacks.
* Added --peer-fingerprint mode for a more simplistic certificate setup and 
verification.
* Improved protocol negotiation, leading to faster connection setup.

More details can be found in the Changes document:



(The Changes document also contains a section with work-arounds for
common problems encountered when using OpenVPN with OpenSSL 3)

Source code and Windows installers can be downloaded from our download page:



(The Windows installers use OpenSSL 3 now)

Debian and Ubuntu packages are available in the official apt repositories:



(Note that as a Beta release, packages are only available in testing
and release/2.6 repositories, not in stable)

On Red Hat derivatives we recommend using the Fedora Copr repository.




Kind regards,
-- 
  Frank Lichtenheld


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [OpenVPN/openvpn-gui] UI showing green connected status despite not beeing able to create a route (#9)

[Selva Nair]

Hi,

On Mon, Jan 2, 2023 at 5:51 PM Gert Doering  wrote:

> Hi,
>
> On Sat, Dec 31, 2022 at 05:40:49PM +0100, Gert Doering wrote:
> > On Sat, Dec 17, 2022 at 07:09:34PM -0500, Selva Nair wrote:
> > > tldr: Can we get CONNECTED,ERROR instead of CONNECTED,SUCCESS on route
> > > errors?
> >
> > I think this makes sense.  Not sure how complicated it is, and if we
> > can make this before 2.6.0 ("some time in January").
>
> So if I am reading this right, "CONNECTED," is produced
> by management_set_state() -> log_entry_print(), with the "something"
> being transported via "detail" -> "e->string".
>
> "CONNECTED" is only produced by
> init.c::initialization_sequence_completed(),
> and there already is a case for "CONNECTED,ERROR" though I don't understand
> it...
>
> if (flags & ISC_ERRORS)
> {
> detail = "ERROR";
> }
>
> (which will also log "Initialization Sequence Completed *With Errors*",
> but the rest of that branch might be a bit misleading, as it will
> tell systemd "STATUS=Failed")
>
>
> initialization_sequence_completed() is called from init.c::do_up()
> (for client/p2p), forward.c, and mtcp.c/mudp.c (Server).
>
> The "--route-delay" case goes via forward.c::check_add_routes_action(),
> which *can* signal ERROR.  init.c::do_up() does not.
>
> Routes are (if no --route-delay) set up by do_init_tun(), which calls
> do_route().  So adding an "&flags" parameter to that call chain which sets
> ISC_ERROR if a route addition fails might be a viable approach.
>

I was also thinking along these lines. I think we can make add_route()
return a status instead of void, and propagate it back to where it's needed
in check_add_route_action(). Many of those functions that return void can
return an int instead. All real worker functions that set a route :
do_route_service, do_route_ipv6_servuce, do_route_ipapi,
openvpn_execve_check, net_route_v4_add, net_route_v6_add etc.
all return true or false or a status, so it's only their callers that need
to pass it on.

This is assuming "false" or error really means a serious error, not
something
trivial like a route already exists. And, there's the rub... I can't see
how to get
around this on all platforms. On Windows when using service or IPAPI we
can check the error code for ERROR_OBJECT_ALREADY_EXISTS, on Linux
using SITNL already ignores EEXIST, so those two cases are  good to go.
But what to do with openvpn_execve?

I'm tempted to take a short-cut and  implement this only for Windows and
Linux
when using SITNL, and leave others to continue reporting CONNECTED,SUCCESS
on route errors.

That would be easy to do as the only change required is: update netsh calls
used
for ipv6 routes on Windows to use IPAPI (that's an easy change worth doing
anyway).

As for those using route-method = exe on Windows, we may occasionally report
CONNECTED,ERROR even for trivial "route already exists" cases. I think that
is
tolerable as no one should be using route-method=exe. The whole route-method
option should have been deprecated long ago. Same with ip-win32 (just retain
the manual option to please the demons).


> ... and then I found ROUTE_BEFORE_TUN, ROUTE_AFTER_TUN... which adds
> yet another call chain, which is totally irrelevant but would need that
> extra argument as well...


> And, --route-delay, I need to understand better what the code is doing
> there...
>

I haven't looked into this either.

Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [OpenVPN/openvpn-gui] UI showing green connected status despite not beeing able to create a route (#9)

[Gert Doering]

Hi,

On Sat, Dec 31, 2022 at 05:40:49PM +0100, Gert Doering wrote:
> On Sat, Dec 17, 2022 at 07:09:34PM -0500, Selva Nair wrote:
> > tldr: Can we get CONNECTED,ERROR instead of CONNECTED,SUCCESS on route
> > errors?
> 
> I think this makes sense.  Not sure how complicated it is, and if we
> can make this before 2.6.0 ("some time in January").

So if I am reading this right, "CONNECTED," is produced
by management_set_state() -> log_entry_print(), with the "something"
being transported via "detail" -> "e->string".

"CONNECTED" is only produced by init.c::initialization_sequence_completed(),
and there already is a case for "CONNECTED,ERROR" though I don't understand
it...

if (flags & ISC_ERRORS)
{
detail = "ERROR";
}

(which will also log "Initialization Sequence Completed *With Errors*",
but the rest of that branch might be a bit misleading, as it will
tell systemd "STATUS=Failed")


initialization_sequence_completed() is called from init.c::do_up()
(for client/p2p), forward.c, and mtcp.c/mudp.c (Server).

The "--route-delay" case goes via forward.c::check_add_routes_action(),
which *can* signal ERROR.  init.c::do_up() does not.

Routes are (if no --route-delay) set up by do_init_tun(), which calls
do_route().  So adding an "&flags" parameter to that call chain which sets
ISC_ERROR if a route addition fails might be a viable approach.

... and then I found ROUTE_BEFORE_TUN, ROUTE_AFTER_TUN... which adds
yet another call chain, which is totally irrelevant but would need that
extra argument as well...

And, --route-delay, I need to understand better what the code is doing
there...

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [OpenVPN/openvpn-gui] UI showing green connected status despite not beeing able to create a route (#9)

[Gert Doering]

Hi,

On Sat, Dec 17, 2022 at 07:09:34PM -0500, Selva Nair wrote:
> tldr: Can we get CONNECTED,ERROR instead of CONNECTED,SUCCESS on route
> errors?

I think this makes sense.  Not sure how complicated it is, and if we
can make this before 2.6.0 ("some time in January").

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 2.6_rc1 released

[Frank Lichtenheld]

The OpenVPN community project team is proud to release OpenVPN 2.6_rc1.
This is the first release candidate (and the third beta release) for
the feature release 2.6.0.

Changes since Beta 2:

* Officially deprecate NTLMv1 proxy auth method in 2.6. Will be removed in 2.7.
* Support unlimited number of connection entries and remote entries.
* New management commands to enumerate and list remote entries.
* Various bugfixes, see 
https://github.com/OpenVPN/openvpn/blob/v2.6_rc1/Changes.rst

Windows MSI changes since Beta 2:
* Included openvpn-gui updated to 11.34.0.0. See 
https://github.com/OpenVPN/openvpn-gui/blob/v11.34.0.0/CHANGES.rst.
  * New feature: Connections active on exit/logout are now automatically 
restarted in the next session of the GUI
* Windows installers are now built with Visual Studio 17 2022 (previously built 
with VS 16 2019)

Some highlights of 2.6.0 are:

* Data Channel Offload (DCO) kernel acceleration support for Windows, Linux, 
and FreeBSD.
* OpenSSL 3 support.
* Improved handling of tunnel MTU, including support for pushable MTU.
* Reworked TLS handshake, making OpenVPN immune to replay-packet state 
exhaustion attacks.
* Added --peer-fingerprint mode for a more simplistic certificate setup and 
verification.
* Improved protocol negotiation, leading to faster connection setup.

More details can be found in the Changes document:



(The Changes document also contains a section with work-arounds for
common problems encountered when using OpenVPN with OpenSSL 3)

Source code and Windows installers can be downloaded from our download page:



(The Windows installers use OpenSSL 3 now)

Debian and Ubuntu packages are available in the official apt repositories:



(Note that as a Beta release, packages are only available in testing
and release/2.6 repositories, not in stable)

On Red Hat derivatives we recommend using the Fedora Copr repository.




Kind regards,
-- 
  Frank Lichtenheld


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [OpenVPN/openvpn-gui] UI showing green connected status despite not beeing able to create a route (#9)

[Selva Nair]

Hi,

Trying to resurrect this thread, as we still have this deficiency in
OpenVPN core that makes it difficult for UI's to report routing errors.

tldr: Can we get CONNECTED,ERROR instead of CONNECTED,SUCCESS on route
errors?

See also https://github.com/OpenVPN/openvpn-gui/issues/9

On Fri, Jul 6, 2018 at 3:38 PM Jonathan K. Bullard 
wrote:

> Hi,
>
> On Fri, Jul 6, 2018 at 3:24 PM, Selva Nair  wrote:
> >
> > Hi,
> >
> > Copying the devel list as a reminder that "we" have been asking for this
> change for a long time :)
> >
> > On Fri, Jul 6, 2018 at 2:48 PM, Gert Doering 
> wrote:
> >>
> >> Hi,
> >>
> >> On Fri, Jul 06, 2018 at 08:25:02AM -0700, Selva Nair wrote:
> >> > Can we do something about this in openvpn core, so that the GUI can
> be report route errors?
> >>
> >> Currently when we get CONNECTED,SUCCESS we turn the icon green. If we
> get
> >>
> >> CONENCTED,ERROR we keep it amber and the state as "connecting.." even if
> >>
> >> the initialization sequence completes.
> >> >
> >> > So route errors can still be treated as non-fatal but we want to get
> CONNECTED,ERROR in such cases.
>
> +1 to routing errors causing CONNECTED,ERROR (I didn't even know that
> was possible). This confuses many Tunnelblick users.
>
> I'd be happy for routing errors to cause a FATAL error as long as the
> errors weren't caused by "route already exists" or something like
> that. But I assume that's too much trouble.
>
>
> Best regards,
>
> Jon
>

Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 2.6_beta2 released

[Frank Lichtenheld]

The OpenVPN community project team is proud to release OpenVPN 2.6_beta2.
This is the second Beta release for the feature release 2.6.0.

Changes since Beta 1:

* Transport statistics (bytes in/out) for DCO environments.
  Currently only for Windows clients and FreeBSD servers.
  Other platforms will be fixed in next release.
* Various bugfixes, see 
https://github.com/OpenVPN/openvpn/blob/v2.6_beta2/Changes.rst

Windows MSI changes since Beta 1:

* Included openvpn-gui updated to 11.33.0.0. See 
https://github.com/OpenVPN/openvpn-gui/blob/v11.33.0.0/CHANGES.rst
* Update included pkcs11-helper so it can load pkcs11 providers from outside of 
its own install directory.
* Add legacy provider for included OpenSSL so that the workarounds documented 
for old ciphers work on Windows.

Some highlights of 2.6.0 are:

* Data Channel Offload (DCO) kernel acceleration support for Windows, Linux, 
and FreeBSD.
* OpenSSL 3 support.
* Improved handling of tunnel MTU, including support for pushable MTU.
* Reworked TLS handshake, making OpenVPN immune to replay-packet state 
exhaustion attacks.
* Added --peer-fingerprint mode for a more simplistic certificate setup and 
verification.
* Improved protocol negotiation, leading to faster connection setup.

More details can be found in the Changes document:



(The Changes document also contains a section with work-arounds for
common problems encountered when using OpenVPN with OpenSSL 3)

Source code and Windows installers can be downloaded from our download page:



(The Windows installers use OpenSSL 3 now)

Debian and Ubuntu packages are available in the official apt repositories:



(Note that as a Beta release, packages are only available in testing
and release/2.6 repositories, not in stable)

On Red Hat derivatives we recommend using the Fedora Copr repository.




Kind regards,
-- 
  Frank Lichtenheld


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN crash with latest "fix p2p reconnect" patch

[Gert Doering]

Hi,

On Wed, Dec 07, 2022 at 08:56:04AM +0100, Gert Doering wrote:
> the client side tests tested p2p udp (8) before p2p udp TLS (11), so
> never noticed that after running (11), (8) would not work any longer...

More specifically, because I never tested p2p tun (8) on the DCO-enabled
servers ("why would I test this, it just slows down things, --secret won't
do DCO anyway").

But it seems, "p2p --secret" is broken hard in current code - it enables
DCO, and fails when the first client connects...

2022-12-07 09:01:32 us=920037 net_iface_new: add tun3 type ovpn-dco
2022-12-07 09:01:32 us=921045 DCO device tun3 opened
...
2022-12-07 09:02:02 us=527605 Attempting to send data packet while data channel 
offload is in use. Dropping packet
...

start client, send packet:

2022-12-07 09:02:38 us=285472 Peer Connection Initiated with 
[AF_INET6]:::194.97.140.5:18999

Program received signal SIGSEGV, Segmentation fault.
0x5556beaf in addr_set_dco_installed (c=) at dco.c:447
447 ks->remote_addr.dco_installed = true;

(gdb) print ks
$1 = (struct key_state *) 0x5f8

... so whatever "ks" is in here, it's not a valid pointer...


Starting the p2p --secret instance with --disable-dco makes it behave
normally.

Since, I think, the claim is "DCO needs TLS", we just need a patch that
disables DCO for p2p --secret mode...

gert


-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN crash with latest "fix p2p reconnect" patch

[Gert Doering]

Hi,

bad news...

On Thu, Dec 01, 2022 at 12:01:28PM +0100, Arne Schwabe wrote:
> diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
> index 1b418b1bc..958bf0b56 100644
> --- a/src/openvpn/forward.c
> +++ b/src/openvpn/forward.c
> @@ -1174,9 +1174,22 @@ process_incoming_dco(struct context *c)
>  
>  dco_do_read(dco);
>  
> +/* FreeBSD currently sends us removal notifcation with the old peer-id in
> + * p2p mode with the ping timeout reason, so ignore that one to not shout
> + * ourselves in the foot and removing the just established session */
> +if (dco->dco_message_peer_id != c->c2.tls_multi->dco_peer_id)
> +{
> +msg(D_DCO_DEBUG, "%s: received message for mismatching peer-id %d, "
> +"expected %d", __func__, dco->dco_message_peer_id,
> +c->c2.tls_multi->dco_peer_id);
> +return;
> +}

This code works perfectly well for p2p TLS environments, but makes OpenVPN
explode in a scenario that my tests did not trigger properly

 - you have a p2p tun instance with --secret & DCO
 - you have a second p2p DCO instance on the same machine, with TLS
- peers connect and disconnect to the p2p TLS instance

 - the *first* instance receives a DCO message, and explodes...

2022-12-07 08:34:50 us=63605 setsockopt(IPV6_V6ONLY=0)
2022-12-07 08:34:50 us=63826 UDPv6 link local (bound): [AF_INET6][undef]:51204
2022-12-07 08:34:50 us=64015 UDPv6 link remote: [AF_UNSPEC]
2022-12-07 08:35:00 us=977186 Attempting to send data packet while data channel 
offload is in use. Dropping packet

Program received signal SIGSEGV, Segmentation fault.
0x555772b9 in process_incoming_dco (c=0x7fffd460) at forward.c:1180
1180if (dco->dco_message_peer_id != c->c2.tls_multi->dco_peer_id)
(gdb) where
#0  0x555772b9 in process_incoming_dco (c=0x7fffd460)
at forward.c:1180
#1  process_io (c=0x7fffd460) at forward.c:2283
#2  0x5559db4c in tunnel_point_to_point (c=0x7fffd460)
at openvpn.c:94
#3  openvpn_main (argc=2, argv=0x7fffe608) at openvpn.c:311
#4  0x77cbf083 in __libc_start_main (main=0xe500 , 
argc=2, argv=0x7fffe608, init=, fini=, 
rtld_fini=, stack_end=0x7fffe5f8)
at ../csu/libc-start.c:308
#5  0xe53e in _start () at socket.h:1206
(gdb) print *dco
$2 = {nl_sock = 0x55642bd0, nl_cb = 0x5563b310, status = 0, 
  ifmode = __OVPN_MODE_FIRST, ovpn_dco_id = 37, ovpn_dco_mcast_id = 5, 
  ifindex = 27659, dco_packet_in = {capacity = 65536, offset = 0, len = 0, 
data = 0x55643370 ""}, dco_message_type = 0, dco_message_peer_id = -1, 
  dco_del_peer_reason = 0}

(gdb) print c->c2.tls_multi
$3 = (struct tls_multi *) 0x0

 dat.

Bäm.


My tests did not alert me of this, as the sequence of things is

 - build new openvpn binary
 - stop all instances
 - start all instances with new binary
 - run client side tests against all these instances
 - be happy if client side tests succeed

the client side tests tested p2p udp (8) before p2p udp TLS (11), so
never noticed that after running (11), (8) would not work any longer...


One item of obvious confusion - yes, this is --secret and not TLS, and
yes, we use DCO...

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 2.6_beta1 released

[Frank Lichtenheld]

The OpenVPN community project team is proud to release OpenVPN 2.6_beta1.
This is the first Beta release for the feature release 2.6.0.

Some highlights of this release are:

* Data Channel Offload (DCO) kernel acceleration support for Windows, Linux, 
and FreeBSD.
* OpenSSL 3 support.
* Improved handling of tunnel MTU, including support for pushable MTU.
* Reworked TLS handshake, making OpenVPN immune to replay-packet state 
exhaustion attacks.
* Added --peer-fingerprint mode for a more simplistic certificate setup and 
verification.
* Improved protocol negotiation, leading to faster connection setup.

More details can be found in the Changes document:



(The Changes document also contains a section with work-arounds for
common problems encountered when using OpenVPN with OpenSSL 3)

Source code and Windows installers can be downloaded from our download page:



(The Windows installers use OpenSSL 3 now)

Debian and Ubuntu packages are available in the official apt repositories:



(Note that as a Beta release, packages are only available in testing
and release/2.6 repositories, not in stable)

On Red Hat derivatives we recommend using the Fedora Copr repository.




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.5.8 released

[Frank Lichtenheld]

On Wed, Nov 02, 2022 at 10:37:12PM +0100, Frank Lichtenheld wrote:
> Source code and Windows installers can be downloaded from our download page:
> 
> 

A new version of the Windows MSI installer has been released. It fixes the issue
that the original installer contained a openvpn.exe that showed version number
2.5.7 instead of 2.5.8.

As part of the rebuild OpenSSL has been updated to the bugfix release 1.1.1s.

Regards,
-- 
  Frank Lichtenheld


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 2.5.8 released

[Frank Lichtenheld]

The OpenVPN community project team is proud to release OpenVPN 2.5.8. This is
mostly a bugfix release.
However, there were several enhancements of the Windows GUI component:

* OpenVPN 3 support -- the GUI can also work as a user interface for
  the OpenVPN 3 client.
* pkcs11-id-management -- the GUI can list available pkcs11-ids and
  allows the user to select one.
* Persistent connections -- the GUI lists connections started at boot
  by the automatic service and lets the user control them. Interactive
  inputs such as username/password with such connections are possible.

The official APT repositories now contain packages built for Ubuntu 22.10
(kinetic).

List of changes in OpenVPN:



Source code and Windows installers can be downloaded from our download page:



Debian and Ubuntu packages are available in the official apt repositories:



On Red Hat derivatives we recommend using the Fedora Copr repository.




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 3 Linux client - v19 beta released

[David Sommerseth]

Hi,

The OpenVPN 3 Linux v19 (beta) release is now available.

First, thank you to all who have reported issues and as well those
who also contributed with changes.  Your efforts and interest in this
project is highly appreciated.  Please reach out if you have any
questions or wonder about how OpenVPN 3 Linux works or issues related
to using it.

If you have ideas how to make common operations easier with your daily
usage, please get in touch so we can explore those ideas further!

So to the v19 (beta) changes:

This release does another round of improving the logging system,
in addition to bug fixes and other improvements.

* Log system changes

  The net.openvpn.v3.log service has been extended to support logging
  directly to systemd-journald as an alternative to syslog.  The
  default log destination has been changed from syslog to journald.

  Using the systemd-journald as the log destination allows attaching
  more meta data variables to the log events, which can be used when
  querying the journal using journalctl.  These additional meta data
  variables can be observed when using the 'verbose', 'json',
  'json-pretty' or 'export' output modes (journalctl --output)

  The OpenVPN 3 Linux specific meta data variables are prefixed with
  "O3_".  The meta variables OpenVPN 3 Linux may make use of are:

  - O3_LOG_GROUP / O3_LOG_CATEGORY
These are direct mapped to the logging classification described
here: 


  - O3_LOGTAG
This tag is unique per openvpn3-service-* process and will be
changed if the process restarts.  This information has so far
been added to the beginning of the log lines, as the '{tag:}'
prefix.  This prefixing to the log lines can now be removed by
running:

# openvpn3-admin log-service --enable-log-prefix false

The O3_LOGTAG will have the same content as the prefix, without
the '{tag:...}' encapsulation; O3_LOGTAG contains only the plain
identifier.  The log tags currently active can be listed by
running:

# openvpn3-admin log-service --list-subscriptions

  - O3_SENDER, O3_INTERFACE, O3_OBJECT_PATH
These are added if the D-Bus log details are enabled by running:

# openvpn3-admin log-service --dbus-details true

  - O3_SESSION_TOKEN
This is used by the openvpn3-service-client process, where the
session token has the same value as the argument the process
is started with

  To list only these OpenVPN 3 Linux meta variables, run this
  command:

 # journalctl -o verbose --since today \
  
--output-fields=O3_SENDER,O3_INTERFACE,O3_METHOD,O3_OBJECT_PATH,O3_LOGTAG,O3_SESSION_TOKEN,O3_LOG_GROUP,O3_LOG_CATEGORY,MESSAGE
 \
  _PID=$(pidof openvpn3-service-logger)
 
  This query can be extended further to narrow down the log scope.

  To only list client process log events, add this to the line
  above:  O3_LOG_GROUP=Client

* Enhancement: IV_PLAT_VER sent to server
  This field provides OS details of the platform the OpenVPN 3 client
  is running on.  This will contain an arbitrary string provided by
  either the systemd-hostnamed service, or if that is unavailable it
  will extract some more generic information using the uname()
  system function.

  The IV_GUI_VER string has also been slimmed down a bit to only
  provide information about the OpenVPN 3 Linux client alone.  The
  IV_VER will contain information about the OpenVPN 3 Core library
  version which OpenVPN 3 Linux is compiled against.

* Update to OpenVPN 3 Core Library v3.7.1
  This update of the OpenVPN 3 Core library is a maintenance release.
  The changes which touches OpenVPN 3 Linux is related to the ovpn-dco
  kernel module support.  On systems running more VPN sessions in
  parallel with DCO (Data Channel Offload) enabled, the Core library
  could in some situations perform operations on the wrong DCO
  interface.

* Bugfix: Web based authentication with OpenVPN Access Server fix
  When connecting to OpenVPN Access Server configured with web based
  authentication (i.e. SAML), the authentication could fail on
  renegotiations.  The fix currently applied will require to import
  the Access Server profile once again.  This will be improved
  further in the next release.

  

* Bugfix: Python warning with openvpn3-as on Ubuntu 22.04
  When running the openvpn3-as utility on Ubuntu 22.04 it would complain
  about using a deprecated ssl.SSLContext() mode.  This has
  been updated to use the preferred mode.

* Bugfix: openvpn3 command line bash-completion
  The bash-completion support has been changed to avoid adding an
  additional space after file and directory names.


The OpenVPN 3 Linux project is now fully focusing on stabilising the
code for the first stable release.  If the next release will be one
of the last beta releases or a stable release depends on what bugs

[Openvpn-devel] OpenVPN Windows DCO driver

[Lev Stipakov]

Dear all,

The DCO driver for Windows (https://github.com/openvpn/ovpn-dco-win)
implements OpenVPN data channel in kernel, eliminating context switch
and thus noticeably improves performance.

Support for dco-win driver has been merged into openvpn master branch
and openvpn installer:

   x64: 
https://build.openvpn.net/downloads/snapshots/github-actions/openvpn2/openvpn-master-20220825T0959-104e4ef1-amd64.msi

   arm64: 
https://build.openvpn.net/downloads/snapshots/github-actions/openvpn2/openvpn-master-20220825T1004-104e4ef1-arm64.msi

(newer snapshots will also do)

Please give it a try and share your feedback with us. To enable
dco-win driver, add "windows-driver ovpn-dco" to your .ovpn profile.

Known limitations:

 - available for Windows 10 2004 and newer
 - persist-tun support is coming soon
 - only aes-128/192/256-gcm ciphers are supported. chacha20-poly1305
is supported starting from Windows 11
 - compression is not supported (and should not be used anyway)
 - server-side support is missing

DCO Windows driver will be part of 2.6 release which is coming later this year.

-- 
-Lev


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 3 Linux client - v18 beta released

[David Sommerseth]

Hi,

The OpenVPN 3 Linux v18 (beta) release is now available.  This release
consists of a larger overhaul on the logging system with a few
additional bug fixes and other improvements.

* Log system changes

  In prior releases, the backend VPN client (openvpn3-service-client
  processes) sent Log signals (events) to the log service
  (openvpn3-service-logger process).  If a user wanted to receive
  real-time log events, it could easily do so by flipping a boolean
  flag in the VPN session, managed by the session manager
  (openvpn3-service-sessionmgr process).  In this case, the session
  manager would also pick up Log events from the VPN client and
  forward them.

  This architecture had a flaw which meant that if the log forwarding
  in the session manager was enabled for a session, anyone could pick
  up these log events.  And if one of these log listeners turned off
  the log forwarding, this would happen for all other listeners at
  once.  This design also meant that the VPN client process needed to
  send Log events to two different destinations; both the logger and
  the session manager.

  With the change introduced in v18_beta, the VPN client process now
  only sends Log events to the logger service.  When a user wants to
  receive log events now, it needs to call the
  net.openvpn.v3.sessions.LogForward() method setting an enable flag
  instead of flipping the receive_log_events boolean property directly.
  The session manager will now do a proper access control to the caller
  and then tell the log service to forward Log events directly to the
  program wanting to receive Log events.  To disable this forwarding,
  the program just calls the same method and unset the enabling flag.

  This new architecture also allows multiple log forwarders to run in
  parallel without impacting the other listeners.  Each forwarding are
  now handled independently.  And forwarding Log events will no longer
  impact the session manager any more.


* Enhancement: openvpn3-as profiles can be started via systemd

  In v16_beta a new systemd unit file was introduced to make it
  possible to manage VPN sessions via systemd.  With v18_beta
  this integration has been extended to the openvpn3-as utility
  which can download a VPN profile directly from an OpenVPN Access
  Server.

  When run as root, two new options can be used:
  --systemd-start and --owner.

  The first one will instruct openvpn3-as to enable the imported
  configuration profile to be started automatically during boot.

  The --owner takes a username argument, which, when run as root,
  will transfer the ownership of this VPN profile to the given
  username.  When the VPN session is started as root, the session
  will automatically also be owned by the given user.


* Bugfix: openvpn3 session-start with web based authentication

  The instruction guide to help continue with web based authentication
  was misleading and no longer correct.  This has been improved and
  the console now contains the correct instructions.


* Bugfix: Configuration manager could mangle --verify-x509-name

  When importing a configuration file with the --verify-x509-name
  option, it would often be misinterpreted when the import was
  as a persistent configuration profile.

  This has been resolved and the internal on-disk storage format
  for persistent configuration profiles has been upgraded to correctly
  handle this type of option class, with quoted strings.

  

* Bugfix: openvpn3-service-configmgr could segfault

  If the oepnvpn3-service-configmgr could not manage to reach the
  net.openvpn.v3.log service (openvpn3-service-logger), it would
  segfault resulting in a core dump needlessly.  This has been
  resolved by adding proper error handling and gracefully exit
  with a more reasonable error message.
  


* Bugfix: Network Configuration state saving failing silently

  When the Network Configuration service (openvpn3-service-netcfg)
  configuration was to be written to disk and failing, the prior
  implementation ignored any errors happening.  This has been
  improved and the error is now presented to the user if there
  is an error saving the configuration file.


* Bugfix: Python based config parser can now handle legacy algorithms

  The v17_beta release introduced a --enable-legacy-algorithms flag
  to be set on a configuration profile.  This worked fine via the
  openvpn3 config-manage interface, but the Python parser lacked the
  parsing of this option.  This has now been implemented, via the
  --profile-override option.


* Bugfix: Python based config parser did not accept --auth-nocache

  The --auth-nocache is not a feature directly available in OpenVPN 3
  Core library.  But it does not block a configuration file from
  working, so this was put to the internal "ignore list".


* Bugfix: openvpn2 could some times dump spurious error messages

  If CTRL-C was performed during the shutdown phase of a VPN

[Openvpn-devel] OpenVPN 2.5.7 released

[Samuli Seppänen]

The OpenVPN community project team is proud to release OpenVPN 2.5.7. 
This is mostly a bugfix release, but adds limited support for OpenSSL 
3.0. Full support will arrive in OpenVPN 2.6.




Source code and Windows installers can be downloaded from our download page:



Debian and Ubuntu packages are available in the official apt repositories:



On Red Hat derivatives we recommend using the Fedora Copr repository.




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] :openvpn dco connection problem

[Arne Schwabe]

Am 20.04.22 um 10:18 schrieb yuanxun:

Hi

I recently encountered a bug when using the openvpn dco branch. When the 
client connection reaches max_cliants, I reconnect one of the clients, 
and the client will fail to reconnect when it reaches the set number of 
reconnections. At this time, the client state is Not connected, but on 
the management interface, always online.


Can you post logs of the openvpn server? Preferrable with verb 4 at least?

Arne


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] :openvpn dco connection problem

[yuanxun]

Hi

I recently encountered a bug when using the openvpn dco branch. When the
client connection reaches max_cliants, I reconnect one of the clients, and
the client will fail to reconnect when it reaches the set number of
reconnections. At this time, the client state is Not connected, but on the
management interface, always online.

 

 

___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN encryption architecture

[Arne Schwabe]

Am 05.04.22 um 05:10 schrieb Leroy Tennison:
Thanks for your reply, I'm actually looking for something pretty 
high-level like "the server (or client) sends their (whatever key) and 
the client (or server) (creates a session key from it or whatever 
happens) and that is used for encryption."  I am also wondering what the 
client and server keys are used for if not in this process.




High level is that we use a TLS 1.0/TLS 1.1 inspired key exchange in 
older versions and nowadays if both server and client are capable of TLS 
EKM, we use TLS EKM to generate key material for encryption of data 
channel.


The server and client keys are used in the TLS session like with any TLS 
session.


Arne


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN encryption architecture

[Arne Schwabe]

Am 04.04.22 um 22:32 schrieb Leroy Tennison via Openvpn-devel:
Trying to find information on how OpenVPN uses the keys generated for 
the client and server to encrypt traffic and not having any success 
(maybe I'm not searching for the right terms).  Can someone explain or 
point me to a URL explaining how OpenVPN encrypts traffic once 
authentication is successful?  I found the article about authentication 
but it didn't describe the process after authentication.  Thanks for 
your help.




On what level are you looking? Complete protocol specification (some WIP 
but not finished)? Just parts of it? If you are a bit more specific I 
can probably answer your answer.


Arne


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN encryption architecture

[Leroy Tennison via Openvpn-devel]

Trying to find information on how OpenVPN uses the keys generated for the 
client and server to encrypt traffic and not having any success (maybe I'm not 
searching for the right terms).  Can someone explain or point me to a URL 
explaining how OpenVPN encrypts traffic once authentication is successful?  I 
found the article about authentication but it didn't describe the process after 
authentication.  Thanks for your help.___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 2.4.12 released

[Samuli Seppänen]

OpenVPN 2.4.12 was released last week. It will be the last release in 
the 2.4.x series, so we encourage you to migrate to latest 2.5.x release 
if you can.


Source code and Windows installers can be downloaded from our download page:



Linux packages are not provided for this release.


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 2.5.6 released

[Samuli Seppänen]

The OpenVPN community project team is proud to release OpenVPN 2.5.6. 
This is mostly a bugfix release including one security fix ("Disallow 
multiple deferred authentication plug-ins.", CVE: 2022-0547). More 
details are available in Changes.rst:




Source code and Windows installers can be downloaded from our download page:



Debian and Ubuntu packages are available in the official apt repositories:



On Red Hat derivatives we recommend using the Fedora Copr repository.




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN Client 2FA problem with Backslash

[Selva Nair]

Hi Jacob,

On Fri, Mar 11, 2022 at 3:52 AM Jakob Curdes  wrote:

> Hello Selva, hello all,
>
> I have tested the executable in the circumstances described earlier. I
> confirm the problem described (username/password auth succeeds, but second
> auth with 2FA data fails as the backslash in the username is not escaped
> this time) is solved using the binary provided. I also confirmed this in
> issue #483  .
>
> Thank you all for your quick work. This will help us rolling out 2FA to a
> bunch of users!
>
Thanks for testing.

Selva

>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN Client 2FA problem with Backslash

[Jakob Curdes]

Hi,

On Thu, Mar 10, 2022 at 4:23 PM Gert Doering  wrote:

Hi,

On Thu, Mar 10, 2022 at 12:51:51PM -0500, Selva Nair wrote:
> I missed this follow up on the devel list. Please see my reply to
> openvpn-users. If @ doesnt work there is no easy fix short of
patching the
> GUI.

We're planning a 2.5.x release "some time next week" (partly prompted
due to the OpenSSL release on 


tuesday).  So now's a good time for GUI
fixes :-)


See PR 483 

@Jakob Curdes   This could be tested using 
the CI executable here:

https://github.com/OpenVPN/openvpn-gui/suites/5617977743/artifacts/182849130
(for 64 bit Windows). No need to install --- just unzip into a temp 
folder and double click on the included openvpn-gui.exe.


Selva


Hello Selva, hello all,

I have tested the executable in the circumstances described earlier. I 
confirm the problem described (username/password auth succeeds, but 
second auth with 2FA data fails as the backslash in the username is not 
escaped this time) is solved using the binary provided. I also confirmed 
this in issue #483  .


Thank you all for your quick work. This will help us rolling out 2FA to 
a bunch of users!


Regards, Jakob

___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN Client 2FA problem with Backslash

[Selva Nair]

Hi,

On Thu, Mar 10, 2022 at 4:23 PM Gert Doering  wrote:

> Hi,
>
> On Thu, Mar 10, 2022 at 12:51:51PM -0500, Selva Nair wrote:
> > I missed this follow up on the devel list. Please see my reply to
> > openvpn-users. If @ doesnt work there is no easy fix short of patching
> the
> > GUI.
>
> We're planning a 2.5.x release "some time next week" (partly prompted
> due to the OpenSSL release on

tuesday).  So now's a good time for GUI
> fixes :-)
>
>
See PR 483 

@Jakob Curdes   This could be tested using the CI
executable here:
https://github.com/OpenVPN/openvpn-gui/suites/5617977743/artifacts/182849130
(for 64 bit Windows). No need to install --- just unzip into a temp folder
and double click on the included openvpn-gui.exe.

Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN Client 2FA problem with Backslash

[Gert Doering]

Hi,

On Thu, Mar 10, 2022 at 12:51:51PM -0500, Selva Nair wrote:
> I missed this follow up on the devel list. Please see my reply to
> openvpn-users. If @ doesnt work there is no easy fix short of patching the
> GUI.

We're planning a 2.5.x release "some time next week" (partly prompted
due to the OpenSSL release on tuesday).  So now's a good time for GUI
fixes :-)

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN Client 2FA problem with Backslash

[Selva Nair]

Hi,

On Thu, Mar 10, 2022 at 9:15 AM Jakob Curdes  wrote:

> Hello all,
>
> I think I have found a bug in the OpenVPN Windows client , can you help me
> to determine if this is true and how to proceed?
>
> We are trying to implement 2FA for several existing Firebox SSL VPNs
> (which essentially uses OpenVPN on server and client side). The remote
> users all use the Windows OpenVPN client. This works perfectly without 2FA,
> and it works also if you do not need to specify the authentication domain
> on user logon. But for the migration it is necessary to do that as I cannot
> convert all users at once - the domain you enter in the username field is
> then "authpoint" instead of something like "company.private". In the 2FA
> process, the OpenVPN client then opens a text window where you can enter a
> TOTP token or a "p" for a push request. The Backslash is no problem when
> not using 2FA, then the user auth succeeds.
> So it seems in the part for the extra control message handling handles
> backslashes incorrect.
>
> *Typed in Username: authpoint\UserN and corresponding password*
>
> Thu Mar 10 10:35:31 2022 VERIFY OK: depth=0, O=WatchGuard_Technologies,
> OU=Fireware, CN=Fireware SSLVPN Server
> Thu Mar 10 10:35:31 2022 Control Channel: TLSv1.2, cipher TLSv1.2
> ECDHE-RSA-CHACHA20-POLY1305, peer certificate: 2048 bit RSA, signature:
> RSA-SHA256
> Thu Mar 10 10:35:31 2022 [Fireware SSLVPN Server] Peer Connection
> Initiated with [AF_INET]1.2.3.4:443
> Thu Mar 10 10:35:32 2022 MANAGEMENT: >STATE:1646904932,GET_CONFIG,,
> Thu Mar 10 10:35:32 2022 SENT CONTROL [Fireware SSLVPN Server]:
> 'PUSH_REQUEST' (status=1)
> Thu Mar 10 10:35:32 2022 AUTH: Received control message:
> AUTH_FAILED,CRV1:R,E:1796:Yoirtuqeprtiqrew4==:*Type "p" to receive a push
> notification or type your one-time password*
>
>
> *(Typed in "p") *
> Thu Mar 10 10:35:32 2022 SIGUSR1[soft,auth-failure] received, process
> restarting
> Thu Mar 10 10:35:32 2022 MANAGEMENT:
> >STATE:1646904932,RECONNECTING,auth-failure,
> Thu Mar 10 10:35:32 2022 Restart pause, 5 second(s)
> *Thu Mar 10 10:35:40 2022 Previous command sent to management failed:
> ERROR: Options warning: Bad backslash ('\') usage in TCP:0: remember that
> backslashes are treated as shell-escapes and if you need to pass backslash
> characters as part of a Windows filename, you sho*
> Thu Mar 10 10:35:40 2022 MANAGEMENT: CMD 'username "Auth" "
> *authpoint\UserN*"'
> Thu Mar 10 10:35:40 2022 MANAGEMENT: CMD 'password [...]'
>
> This sounds like I need to escape the backslash, but if I do this the auth
> fails completely before the 2FA part comes into the picture.
> Other tricks like forward slashes or "@" do not help here as these are not
> understood by the auth backend in the firebox.
> When using the WatchGuard SSL VPN app this all works (and it has OpenVPN
> inside) but I would like to stick to the OpenVPN clients as all the
> users already have it and know how to handle it.
>

I missed this follow up on the devel list. Please see my reply to
openvpn-users. If @ doesnt work there is no easy fix short of patching the
GUI.

Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN Client 2FA problem with Backslash

[Jakob Curdes]

Hello list, hello Arne,

Am 10.03.2022 um 16:32 schrieb Arne Schwabe:

Am 10.03.22 um 15:14 schrieb Jakob Curdes:
Thu Mar 10 10:35:32 2022 AUTH: Received control message: 
AUTH_FAILED,CRV1:R,E:1796:Yoirtuqeprtiqrew4==:*Type "p" to receive a 
push notification or type your one-time password*


/(Typed in "p")
/
Thu Mar 10 10:35:32 2022 SIGUSR1[soft,auth-failure] received, process 


Where are you typing this in? in the normal cmd.exe terminal that runs 
OpenVPN? because that looks like the client just gives you the 
AUTH_FAILED and then proceeds to connect to the next server.


In a "graphical" popup window of the Windows OpenVPN client which 
appears when the server is configured to do 2FA. The popup window 
displays the text from the above log message "ype "p" to receive a push 
notification or type your one-time password". THe first auth-failed 
seems to be normal, after that the popup is displayed and when all is 
well the auth succeeds in the second round.






restarting
Thu Mar 10 10:35:32 2022 MANAGEMENT: 
 >STATE:1646904932,RECONNECTING,auth-failure,

Thu Mar 10 10:35:32 2022 Restart pause, 5 second(s)
*Thu Mar 10 10:35:40 2022 Previous command sent to management failed: 
ERROR: Options warning: Bad backslash ('\') usage in TCP:0: remember 
that backslashes are treated as shell-escapes and if you need to pass 
backslash characters as part of a Windows filename, you sho*
Thu Mar 10 10:35:40 2022 MANAGEMENT: CMD 'username "Auth" 
"*authpoint\UserN*"'

Thu Mar 10 10:35:40 2022 MANAGEMENT: CMD 'password [...]'

This sounds like I need to escape the backslash, but if I do this the 
auth fails completely before the 2FA part comes into the picture.
Other tricks like forward slashes or "@" do not help here as these 
are not understood by the auth backend in the firebox.
When using the WatchGuard SSL VPN app this all works (and it has 
OpenVPN inside) but I would like to stick to the OpenVPN clients 
as all the users already have it and know how to handle it.


Best regards and thank you for hints,


The new auth-pending method is much easier to implement. With the old 
method you need to part the AUTH_FAILED message and wait until the 
client asks again for the user password on the next connection and 
give the session password/repsonse then.


For the new method, example of implmentating it on Android:

The problem is that I have no control over the method that is used, as I 
cannot freely configure the embedded OpenVPN server in the Firebox.
I think it is just a string handling bug somewhere. On the user list, 
this morning there was a hint to


"I suspect that in manage.c the "parse_line" call does not differentiate 
between file paths (for which \\ is needed) and a "domain\username" call."
which seems to refer to manage.c in the openvpn repository. Does that 
make sense? I looked at the code but my C programming knowledge is limited.


JC




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN Client 2FA problem with Backslash

[Arne Schwabe]

Am 10.03.22 um 15:14 schrieb Jakob Curdes:

Hello all,

I think I have found a bug in the OpenVPN Windows client , can you help 
me to determine if this is true and how to proceed?


We are trying to implement 2FA for several existing Firebox SSL VPNs 
(which essentially uses OpenVPN on server and client side). The remote 
users all use the Windows OpenVPN client. This works perfectly without 
2FA, and it works also if you do not need to specify the authentication 
domain on user logon. But for the migration it is necessary to do that 
as I cannot convert all users at once - the domain you enter in the 
username field is then "authpoint" instead of something like 
"company.private". In the 2FA process, the OpenVPN client then opens a 
text window where you can enter a TOTP token or a "p" for a push 
request. The Backslash is no problem when not using 2FA, then the user 
auth succeeds.
So it seems in the part for the extra control message handling handles 
backslashes incorrect.




Be aware that there is a also a newer 2FA method based on auth-pending 
that addresses many of the shortcoming of the old AUTH_FAILED based method.



/Typed in Username: authpoint\UserN and corresponding password/

Thu Mar 10 10:35:31 2022 VERIFY OK: depth=0, O=WatchGuard_Technologies, 
OU=Fireware, CN=Fireware SSLVPN Server
Thu Mar 10 10:35:31 2022 Control Channel: TLSv1.2, cipher TLSv1.2 
ECDHE-RSA-CHACHA20-POLY1305, peer certificate: 2048 bit RSA, signature: 
RSA-SHA256
Thu Mar 10 10:35:31 2022 [Fireware SSLVPN Server] Peer Connection 
Initiated with [AF_INET]1.2.3.4:443

Thu Mar 10 10:35:32 2022 MANAGEMENT: >STATE:1646904932,GET_CONFIG,,
Thu Mar 10 10:35:32 2022 SENT CONTROL [Fireware SSLVPN Server]: 
'PUSH_REQUEST' (status=1)
Thu Mar 10 10:35:32 2022 AUTH: Received control message: 
AUTH_FAILED,CRV1:R,E:1796:Yoirtuqeprtiqrew4==:*Type "p" to receive a 
push notification or type your one-time password*


/(Typed in "p")
/
Thu Mar 10 10:35:32 2022 SIGUSR1[soft,auth-failure] received, process 


Where are you typing this in? in the normal cmd.exe terminal that runs 
OpenVPN? because that looks like the client just gives you the 
AUTH_FAILED and then proceeds to connect to the next server.



restarting
Thu Mar 10 10:35:32 2022 MANAGEMENT: 
 >STATE:1646904932,RECONNECTING,auth-failure,

Thu Mar 10 10:35:32 2022 Restart pause, 5 second(s)
*Thu Mar 10 10:35:40 2022 Previous command sent to management failed: 
ERROR: Options warning: Bad backslash ('\') usage in TCP:0: remember 
that backslashes are treated as shell-escapes and if you need to pass 
backslash characters as part of a Windows filename, you sho*
Thu Mar 10 10:35:40 2022 MANAGEMENT: CMD 'username "Auth" 
"*authpoint\UserN*"'

Thu Mar 10 10:35:40 2022 MANAGEMENT: CMD 'password [...]'

This sounds like I need to escape the backslash, but if I do this the 
auth fails completely before the 2FA part comes into the picture.
Other tricks like forward slashes or "@" do not help here as these are 
not understood by the auth backend in the firebox.
When using the WatchGuard SSL VPN app this all works (and it has OpenVPN 
inside) but I would like to stick to the OpenVPN clients as all the 
users already have it and know how to handle it.


Best regards and thank you for hints,


The new auth-pending method is much easier to implement. With the old 
method you need to part the AUTH_FAILED message and wait until the 
client asks again for the user password on the next connection and give 
the session password/repsonse then.


For the new method, example of implmentating it on Android:

parsing of the info message:

https://github.com/schwabe/ics-openvpn/blob/97546b9f8b51c0dc60d591b96ae835f00f2b6805/main/src/main/java/de/blinkt/openvpn/core/OpenVPNService.java#L1323


and sending the response:

https://github.com/schwabe/ics-openvpn/blob/97546b9f8b51c0dc60d591b96ae835f00f2b6805/main/src/main/java/de/blinkt/openvpn/core/OpenVpnManagementThread.java#L748


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN Client 2FA problem with Backslash

[Jakob Curdes]

Hello all,

I think I have found a bug in the OpenVPN Windows client , can you help 
me to determine if this is true and how to proceed?


We are trying to implement 2FA for several existing Firebox SSL VPNs 
(which essentially uses OpenVPN on server and client side). The remote 
users all use the Windows OpenVPN client. This works perfectly without 
2FA, and it works also if you do not need to specify the authentication 
domain on user logon. But for the migration it is necessary to do that 
as I cannot convert all users at once - the domain you enter in the 
username field is then "authpoint" instead of something like 
"company.private". In the 2FA process, the OpenVPN client then opens a 
text window where you can enter a TOTP token or a "p" for a push 
request. The Backslash is no problem when not using 2FA, then the user 
auth succeeds.
So it seems in the part for the extra control message handling handles 
backslashes incorrect.


/Typed in Username: authpoint\UserN and corresponding password/

Thu Mar 10 10:35:31 2022 VERIFY OK: depth=0, O=WatchGuard_Technologies, 
OU=Fireware, CN=Fireware SSLVPN Server
Thu Mar 10 10:35:31 2022 Control Channel: TLSv1.2, cipher TLSv1.2 
ECDHE-RSA-CHACHA20-POLY1305, peer certificate: 2048 bit RSA, signature: 
RSA-SHA256
Thu Mar 10 10:35:31 2022 [Fireware SSLVPN Server] Peer Connection 
Initiated with [AF_INET]1.2.3.4:443

Thu Mar 10 10:35:32 2022 MANAGEMENT: >STATE:1646904932,GET_CONFIG,,
Thu Mar 10 10:35:32 2022 SENT CONTROL [Fireware SSLVPN Server]: 
'PUSH_REQUEST' (status=1)
Thu Mar 10 10:35:32 2022 AUTH: Received control message: 
AUTH_FAILED,CRV1:R,E:1796:Yoirtuqeprtiqrew4==:*Type "p" to receive a 
push notification or type your one-time password*


/(Typed in "p")
/
Thu Mar 10 10:35:32 2022 SIGUSR1[soft,auth-failure] received, process 
restarting
Thu Mar 10 10:35:32 2022 MANAGEMENT: 
>STATE:1646904932,RECONNECTING,auth-failure,

Thu Mar 10 10:35:32 2022 Restart pause, 5 second(s)
*Thu Mar 10 10:35:40 2022 Previous command sent to management failed: 
ERROR: Options warning: Bad backslash ('\') usage in TCP:0: remember 
that backslashes are treated as shell-escapes and if you need to pass 
backslash characters as part of a Windows filename, you sho*
Thu Mar 10 10:35:40 2022 MANAGEMENT: CMD 'username "Auth" 
"*authpoint\UserN*"'

Thu Mar 10 10:35:40 2022 MANAGEMENT: CMD 'password [...]'

This sounds like I need to escape the backslash, but if I do this the 
auth fails completely before the 2FA part comes into the picture.
Other tricks like forward slashes or "@" do not help here as these are 
not understood by the auth backend in the firebox.
When using the WatchGuard SSL VPN app this all works (and it has OpenVPN 
inside) but I would like to stick to the OpenVPN clients as all the 
users already have it and know how to handle it.


Best regards and thank you for hints,

Jakob Curdes

___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] openvpn user concurrency

[yuanxun]

Hello!

Considering a metric when using openvpn, what is the user concurrency limit
for a single service process?

Is the concurrency limited by the number of max-clients, or is there a
limit?

 

I haven't figured out how to test it, has anyone done this test?

___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN Data Channel Offload for Windows (Jan 2022)

[Lev Stipakov]

Dear all,

OpenVPN Community would like to present a new technical preview version of
OpenVPN Windows client with Data Channel Offload functionality. This version
includes many bugfixes and improvements since the previous one (May 2021).
It also uses OpenSSL 3.0.1.

The client is built from the openvpn "dco" branch
(https://github.com/openvpn/openvpn/tree/dco)
plus some unmerged patches. The Data Channel Offload kernel driver is built
from https://github.com/openvpn/ovpn-dco-win

The signed installers for x64, x86 and ARM64 could be downloaded from
the link below:

https://build.openvpn.net/downloads/temp/ovpn-dco-win/msi/

Note that DCO functionality requires Windows 10 2004 (Windows Server
2022) or newer.
To enable it, add following options to your ovpn profile:

windows-driver ovpn-dco-win
tun-mtu 1428

If you are interested in what happens inside the driver, you could run TraceView
(https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/traceview)
and
create a new logging session with control GUID
4970F9cf-2c0c-4f11-b1cc-e3a1e9958833.
More information could be found in README.md in ovpn-dco-win repo.

Please give it a try and let us know if you got better performance
compared to tap-windows6.
If you experience any issues with it, please let us know too. Be aware
that this is a technical
preview and not a final release, so use your judgement.

--
-Lev


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.5.5 released

[Gert Doering]

Hi,

On Wed, Dec 15, 2021 at 06:17:01PM +0100, Jan Just Keijser wrote:
> what!  a malformatted Changes.rst file warrants its own CVE code, I 
> would say!
> Let me report it to mitre ;)

We're our own CVE authority now, so mitre has no authority over us!!!

That said, do not let me stop you ;-)

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.5.5 released

[Jan Just Keijser]

On 15/12/21 18:01, Gert Doering wrote:

Hi,

On Wed, Dec 15, 2021 at 04:30:43PM +, tincantech via Openvpn-users wrote:

-BEGIN PGP SIGNED MESSAGE-
It seems only fair to warn the OpenVPN community that Version 2.5.5 has had 
bugs identified.
A new release v2.5.6 is planned for the coming week, or so..

That was a misunderstanding about a comment I made about the planned
change for the release process for 2.5.6, whenever it happens.

The only bugs we *know* about in 2.5.5 is "Changes.rst was malformatted
and talks about openssl.cfg instead of openssl.cnf" - that does not warrant
a new release yet.

what!  a malformatted Changes.rst file warrants its own CVE code, I 
would say!

Let me report it to mitre ;)

JJK



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.5.5 released

[tincantech via Openvpn-devel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Seems I was too hasty here.  OpenVPN 2.5.5 is the current release
and there are no bugs severe enough to warrant a version 2.5.6, at this time.

Sorry for the confusion.

Regards
Richard


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Wednesday, December 15th, 2021 at 16:30, tincantech via Openvpn-users 
 wrote:

> It seems only fair to warn the OpenVPN community that Version 2.5.5 has had 
> bugs identified.
>
> A new release v2.5.6 is planned for the coming week, or so..
>
> Regards
>
> Richard
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
>
> On Wednesday, December 15th, 2021 at 09:30, Samuli Seppänen 
> sam...@openvpn.net wrote:
>
> > The OpenVPN community project team is proud to release OpenVPN 2.5.5.
> >
> > The most notable changes are Windows-related: use of CFG
> >
> > Spectre-mitigations in MSVC builds, bringing back of OpenSSL config
> >
> > loading and several build fixes. More details are available in Changes.rst:
> >
> > https://github.com/OpenVPN/openvpn/blob/release/2.5/Changes.rst
> >
> > Source code and Windows installers can be downloaded from our download page:
> >
> > https://openvpn.net/community-downloads/
> >
> > Debian and Ubuntu packages are available in the official apt repositories:
> >
> > https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos
> >
> > On Red Hat derivatives we recommend using the Fedora Copr repository.
> >
> > https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-release/
> >
> > Openvpn-users mailing list
> >
> > openvpn-us...@lists.sourceforge.net
> >
> > https://lists.sourceforge.net/lists/listinfo/openvpn-users
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAGBQJhuiAeACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ1pDwgAzPtRlmOa5WhGv7Ui7SiKO3kO2GCxpAsQYP4H/GpHLWv3o4GY
2UymApbeXtYu6cjHm4n7fPGyd3302WFmX4/8JkwN4lMmGGNC2mUO8SEYuz1o
mFoBpLhAGI3l/VvGTiEtrIiQBYCwfHURVH8WR5j2lcMvXEqoxaOOIiZpjcN9
uCwPDI8s8ipU1MUGN7DUWHs+6Mp0R+406S9cNKu9J7kpGb+zuYt+y2f37L3Q
gXwETEqDOEm9gXR9eDeZruFXnQSraTvAZm32DUa1JvswCcaWyrynnUHieY12
gx7z0Tw11+Re2OCu5hMgIU97fN1ZNcto/L0eoWB8uNw20Ynoja2tnw==
=7edC
-END PGP SIGNATURE-


publickey - tincantech@protonmail.com - 0x09BC3D44.asc
Description: application/pgp-keys


publickey - tincantech@protonmail.com - 0x09BC3D44.asc.sig
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.5.5 released

[Gert Doering]

Hi,

On Wed, Dec 15, 2021 at 04:30:43PM +, tincantech via Openvpn-users wrote:
> -BEGIN PGP SIGNED MESSAGE-
> It seems only fair to warn the OpenVPN community that Version 2.5.5 has had 
> bugs identified.
> A new release v2.5.6 is planned for the coming week, or so..

That was a misunderstanding about a comment I made about the planned
change for the release process for 2.5.6, whenever it happens.

The only bugs we *know* about in 2.5.5 is "Changes.rst was malformatted
and talks about openssl.cfg instead of openssl.cnf" - that does not warrant
a new release yet.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.5.5 released

[tincantech via Openvpn-devel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It seems only fair to warn the OpenVPN community that Version 2.5.5 has had 
bugs identified.
A new release v2.5.6 is planned for the coming week, or so..

Regards
Richard

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Wednesday, December 15th, 2021 at 09:30, Samuli Seppänen 
 wrote:

> The OpenVPN community project team is proud to release OpenVPN 2.5.5.
>
> The most notable changes are Windows-related: use of CFG
>
> Spectre-mitigations in MSVC builds, bringing back of OpenSSL config
>
> loading and several build fixes. More details are available in Changes.rst:
>
> https://github.com/OpenVPN/openvpn/blob/release/2.5/Changes.rst
>
> Source code and Windows installers can be downloaded from our download page:
>
> https://openvpn.net/community-downloads/
>
> Debian and Ubuntu packages are available in the official apt repositories:
>
> https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos
>
> On Red Hat derivatives we recommend using the Fedora Copr repository.
>
> https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-release/
>
> Openvpn-users mailing list
>
> openvpn-us...@lists.sourceforge.net
>
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAGBQJhuhgkACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ2UVwgAljL4rh7sOEw05+pdAxPREqT9Hrn5owARWcJsWN6CLrf1sR0c
3BjzssUxNNjaubeQZIQe7fqaRlOdE/ikQzCT8H2f9OTQazbK+FYgFZmlwQbj
173E7Ucc1WE4gLgpAy1rArJRiB7ow8AUPqj9xU63JKb5Q8qUTz0tfI7J7NSl
vEZS+nB/zFgsC+OhuPcZvzPXfjmT/4pOHn057jParQBtVw+H8AS+aGjUcKAB
UfQGtuLKHTxZp7FBR4Eh5kr9l/dTbSiRMcoZJAPSN/chs/POolNa/Bbtv6A5
rREVQODLIDrubJhwIweUn3nfburrUd5E+ACVJTCcYJrEi/e/mOHISw==
=n6Vj
-END PGP SIGNATURE-


publickey - tincantech@protonmail.com - 0x09BC3D44.asc
Description: application/pgp-keys


publickey - tincantech@protonmail.com - 0x09BC3D44.asc.sig
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 2.5.5 released

[Samuli Seppänen]

The OpenVPN community project team is proud to release OpenVPN 2.5.5. 
The most notable changes are Windows-related: use of CFG 
Spectre-mitigations in MSVC builds, bringing back of OpenSSL config 
loading and several build fixes. More details are available in Changes.rst:




Source code and Windows installers can be downloaded from our download page:



Debian and Ubuntu packages are available in the official apt repositories:



On Red Hat derivatives we recommend using the Fedora Copr repository.




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 3 Linux client - v17 beta released

[David Sommerseth]

Hi,

The OpenVPN 3 Linux v17 (beta) is now available.  This release consists
mostly of several enhancements of various sizes.

* Behaviour change: Only AEAD ciphers available for data channel by default

  As part of the OpenSSL 3 support, non-AEAD ciphers are no longer enabled
  by default on for the data channel cipher.  That means essentially only
  AES-GCM and, if the TLS library supports it, ChaCha20-Poly1305.

  To restore the previous behaviour, the configuration profile must be
  imported via 'openvpn3 config-import' and then use an override setting:

$ openvpn3 config-manage --enable-legacy-algorithms true \
 --config $CONFIG_NAME
  
* Command line: openvpn3 config-dump


  The openvpn3 config-show command has been deprecated in favour of
  openvpn3 config-dump.  This to avoid ambiguity in behaviour with
  commands supporting --show and to more clearly indicate it is the
  configuration _file_ and not configuration profile being displayed.

* Feature: openvpn3 session-auth command

  This is a new command which can be used to interact with VPN sessions
  requiring interaction related to user authentications.  This is
  useful if the initial connection had not completed properly or that
  the server requires the user to re-authenticate.

* Enhancement: Log level improvements on client log data

  In prior releases, the default log level in the backend process
  was set to 6, which is a debug level.  With this release, the
  default log level is 3.  But this is now more easily configurable.

  - The OpenVPN 3 VPN Client process now parses and respects the
--verb option.

  - The configuration profile can set a log-level override.
  
  - Running VPN sessions can be adjusted on-the-fly using the

the new --log-level option in openvpn3 session-manage.
Changes using this approach are instant.

  - The default log level can also be changed by editing
/usr/share/dbus-1/system-services/net.openvpn.v3.backends.service.
Add the '--client-log-level 6' to the program in the Exec= line to
restore the previous default log level.

* Enhancement: Full support for --static-challenge


  Both the OpenVPN 3 client implementation and Python interface
  has gained full support for the --static-challenge option

* Enhancement: systemd user credential passing

  When starting a VPN session via the openvpn3-session@.service unit
  file, the systemd-ask-password mechanism will be used to retrieve the
  requested user credentials.

* Enhancement: VPN session ownership transfer

  For configuration profiles shared with more users, it is the
  the session owner is the user which started the VPN session.

  With this release, the configuration owner can set the
  --transfer-owner-session flag via openvpn3 config-acl.  This
  will make the configuration profile owner the session owner
  as well, regardless of which user starting the session.  The
  user starting the session will automatically be granted ACL
  entries to manage the session and access the VPN log events.

  This is useful for VPN profiles being started automatically during
  boot via the systemd openvpn3-session@.service unit file.  These
  sessions are typically started as root, but the session owner
  can end up being a different user on the system.  But the user
  need to grant access to the profile for the root user for this
  to work.

* Extend openvpn3-as with an --insecure-certs option

  In v16_beta, the openvpn3-as utility was extended to validate the
  https server certificate of the OpenVPN Access Server.  For servers
  using self-signed certificates or signed by a unknown CA, this tool
  would no longer work.  By using this option, the user instructs this
  tool to ignore such issues.

* Bugfix: Persistent configuration profiles with multiple --remote

  Configuration files containing multiple --remote lines would not
  be preserved correctly in the saved configuration profile; only the
  last entry would be stored.  This has been improved and all entries
  will now be preserved at import time.

  Beware: Configuration profiles will need to be re-imported to
  restore all the --remote entries.

* Bugfix: Fix --tls-crypt-v2 in the Python parser

  In prior releases, configurations started via the Python interface
  would fail with an error if --tls-crypt-v2 was used.  This is now
  fixed.

* Bugfix: Fix Python file loading with spaces in file names

  In prior releases, the configuration parser parsed file names
  containing spaces incorrectly.  This has been improved.

* Bugfix: Non-functional shell completion for config files

  The prior release regressed on shell completion for OpenVPN
  configuration files via the openvpn3 config-import and session-start
  commands.  This has been resolved in this release.

* Distro: Builds on distributions using musl instead of glibc

  Building OpenVPN 3 Linux on Alpine did not work too well as there
  were several aspects not compatible with the d

Re: [Openvpn-devel] [Openvpn-users] NTLMv1, NTLMv2 HTTP proxy support?

[Jan Just Keijser]

Hi Jason,

On 09/11/21 09:37, Jason Haar wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

How about ditching the NTLM and adding HTTPS proxy support instead? ;-)
Does the privacy aspect of talking to proxies "properly" of course (Basic
is fine over HTTPS)

(and accidentally makes openvpn-over-TCP look like real TLS traffic too...)


this was also discussed at the OpenVPN Hackathon last weekend; I have 
code laying around for it

  https://github.com/jjkeijser/connect-proxy/
which allows you to run a separate HTTPS proxy and then connect OpenVPN 
to it using  127.0.0.1:


This needs to be integrated into OpenVPN in some form - I think we 
decided to use the (delayed-then-forgotten) transport obfuscation plugin 
for this. We talked about it a few years ago, but it was never fully 
implemented.


@Gert, list:  who was working on this and who still has the code for the 
transport obfuscation plugin ?  would be a good clean-up project to move 
all proxy (socks, http AND https) code into this plugin.


cheers,

JJK


On 2021-11-07 at 13:55, g...@greenie.muc.de wrote:

Hi Community,

OpenVPN supports HTTP proxies that require NTLM authentication,
supporting NTLMv1 and NTLMv2 protocols.

This is old code, which was written in the dark ages, is not currently
unit/client tested, and uses DES which got deprecated in OpenSSL 3.0.0...

That said, if people still *use* it, we are likely to keep it - otherwise
it might just become lost :-)

So - if you use HTTP proxy in OpenVPN, and that proxy authenticates
against a Windows AD domain, and you use NTLMv1 or NTLMv2 authentication,
please speak up and tell us about your use case!





___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 3 Linux client - v16 beta released

[David Sommerseth]

Hi,

The OpenVPN 3 Linux v16 (beta) is now available.  This release is
mostly a bug-fix release with several known issues resolved
and a few minor feature additions.

Instructions how to install OpenVPN 3 Linux can be found here:


Noticeable changes:

* Bug: Incompatible OCC strings sent to server

  The v15_beta release updated the OpenVPN 3 Core library
  leading to an incompatibility for some users.  This issues
  have now been resolved in a later update of the Core library.

  - OCC strings sent over the wire to the server is now always
prefixed with TCPv4 or UDPv4.


* Bug: DNS caching issues for long-running VPN client sessions

  Before v16_beta, the client would do a DNS lookup before
  connecting and preserve those lookups if --persist-tun was
  used.  This works fine until the configured servers changes
  IP address and no longer is reachable.  Then the client will
  go into a reconnect loop trying to connect, but no other DNS
  lookups would be done.  The Core library has implemented an
  improved approach which will trigger a new DNS lookup in cases
  where it can no longer get a connection established.

  Important related changes:
  
  

NOTE: This is not a perfect solution.  Clients on networks
  utilizing NAT64 is expected to fail when connecting
  to server on an IPv4 address where it changes during
  the runtime of the client.  The best way to resolve
  this is to make the server available via IPv6 as well.

* Bug: Pushed DNS search domains didn't work well

  Several reports indicated that pushing DOMAIN or
  DOMAIN-SEARCH didn't enable them as search domains properly
  when using system-resolved.  This has been fixed by not
  tagging each domain as routing domains.  This may for some
  users change the lookup behaviour so all DNS queries are sent
  to multiple DNS servers instead of just the VPN provided DNS
  server.  We will investigate further how to reduce these
  side-effects when utilizing systemd-resolved.

* Improvement: Do not use connection timeout by default

  Both the 'openvpn3 session-start' and 'openvpn3-autoload'
  had a timeout behaviour where it would stop running if it
  didn't get a connection established within approx. 30 seconds.
  If the server is unavailable or the client is no a network
  with temporarily connection issues, this is a drawback.

  The solution is to remove the current timeout behaviour.  The
  'openvpn3 session-start' command has been extended with a
  --timeout argument which can be used to restore the previous
  behaviour.

* Improvement: openvpn3-as now requires properly signed https server
  certificates.

  Prior versions of openvpn3-as didn't verify the https server
  certificate.  This has now been fixed.

* Improvement: Add better systemd integration for sessions

  This release introduces a Python based systemd integration,
  which will start a pre-imported (openvpn3 config-import)
  configuration profile using the openvpn3-sessions@.service
  unit file.  This can also be used to start connections
  automatically during boot.

  The advantage this has over openvpn3-autoload is that it
  manages VPN sessions on-by-one, while openvpn3-autoload just
  loaded and started everything configured without any real
  session management.  Using the openvpn3-sessions@.service,
  the session status is now also available via 'systemctl' and
  log events are easily found via 'journalctl'.  If a session
  is stopped via 'openvpn3 session-manage', this is also
  reflected in 'systemctl'.

  See the openvpn3-systemd(8) man page for details:
  


  This support is not complete yet, and will be extended
  in coming releases.

* Improvement: Support for the newer WEB_AUTH pending auth method

* Improvement: Extend openvpn3-admin with a sessionmgr-service command.

  This new command currently only supports listing
  all running VPN sessions on the host and list the owner of
  each session as well as the tun/DCO interface in use.

  See the openvpn3-admin-sessionmgr-service(8) man page for
  details.
  


* Improvement: Python based configuration parser updates

  The configuration parser used by openvpn2, openvpn3-autoload
  and the new openvpn3-systemd integration now ignores
  --ncp-ciphers, --data-ciphers and --data-ciphers-fallback

  These options was added in OpenVPN 2.4 and 2.5 as part to
  help migration from prior default ciphers to better ones.
  Connecting to some servers could need a more specific cipher
  to be set.  This is believed not to be needed in OpenVPN 3,
  so instead we just ign

[Openvpn-devel] OpenVPN 2.5.4 released

[Samuli Seppänen]

The OpenVPN community project team is proud to release OpenVPN 2.5.4. 
This release include a number of fixes and small improvements. Windows 
executable and libraries are now built natively on Windows using MSVC, 
not cross-compiled on Linux as with earlier 2.5 releases. Windows 
installers include updated OpenSSL and new OpenVPN GUI. The latter 
includes several improvements, the most important of which is the 
ability to import profiles from URLs where available.


Source code and Windows installers can be downloaded from our download page:



Debian and Ubuntu packages are available in the official apt repositories:



On Red Hat derivatives we recommend using the Fedora Copr repository.



---

Overview of changes since OpenVPN 2.4

  Faster connections

Connections setup is now much faster

  Crypto specific changes

ChaCha20-Poly1305 cipher in the OpenVPN data channel
  Requires OpenSSL 1.1.0 or newer)
Improved TLS 1.3 support when using OpenSSL 1.1.1 or newer
Client-specific tls-crypt keys (--tls-crypt-v2)
Improved Data channel cipher negotiation
Removal of BF-CBC support in default configuration (see below for
possible incompatibilities)

  Server-side improvements

HMAC based auth-token support for seamless reconnects to standalone
  servers or a group of servers.
Asynchronous (deferred) authentication support for auth-pam plugin
Asynchronous (deferred) support for client-connect scripts and
  plugins

  Network-related changes

Support IPv4 configs with /31 netmasks now
802.1q VLAN support on TAP servers
IPv6-only tunnels
New option --block-ipv6 to reject all IPv6 packets (ICMPv6)

  Linux-specific features

VRF support
Netlink integration (OpenVPN no longer needs to execute
  ifconfig/route or ip commands)

Windows-specific features

Wintun driver support, a faster alternative to tap-windows6
Setting tun/tap interface MTU
Setting DHCP search domain
Allow unicode search string in --cryptoapicert option
EasyRSA3, a modern take on OpenVPN CA management
MSI installer

---

Important notices

BF-CBC cipher is no longer the default

Cipher handling for the data channel cipher has been significantly
changed between OpenVPN 2.3/2.4 and v2.5, most notably there are no
"default cipher BF-CBC" anymore because it is no longer considered a
reasonable default. BF-CBC is still available, but it needs to be
explicitly configured now.

For connections between OpenVPN 2.4 and v2.5 clients and servers, both
ends will be able  to negotiate a better cipher than BF-CBC. By default
they will select one of the AES-GCM ciphers, but this can be influenced
using the --data-ciphers setting.

Connections between OpenVPN 2.3 and v2.5 that have no --cipher setting
in the config (= defaulting to BF-CBC and not being negotiation-capable)
must be updated. Unless BF-CBC is included in --data-ciphers or there is
a "--cipher BF-CBC" in the OpenVPN 2.5 config, a v2.5 client or server
will refuse to talk to a v2.3 server or client, because it has no common
data channel cipher and negotiating a cipher is not possible. Generally,
we recommend upgrading such setups to OpenVPN 2.4 or v2.5. If upgrading
is not possible we recommend adding data-ciphers
AES-256-GCM:AES-128-GCM:AES-128-CBC (for v2.5+) or cipher AES-128-CBC
(v2.4.x and older) to the configuration of all clients and servers.

If you really need to use an unsupported OpenVPN 2.3 (or even older)
release and need to stay on BF-CBC (not recommended), the OpenVPN 2.5
based client will need a config file change to re-enable BF-CBC.  But be
warned that BF-CBC and other related weak ciphers will be removed in
coming OpenVPN major releases.

For full details see the Data channel cipher negotiation section on the
man page.

Connectivity to some VPN service provider may break

Connecting with an OpenVPN 2.5 client to at least one commercial VPN
service that
implemented their own cipher negotiation method that always reports back
that it is using BF-CBC to the client is broken in v2.5. This has always
caused warning about mismatch ciphers. We have been in contact with some
service providers and they are looking into it.  This is not something
the OpenVPN community can fix. If your commercial VPN does not work with
a v2.5 client, complain to the VPN service provider.

More details on these new features as well as a list of deprecated
features and user-visible changes are available in Changes.rst:



---

Linux packages are available from




Useful resources

Official documentation:

[Openvpn-devel] OpenVPN 3 Linux client - v15 beta released

[David Sommerseth]

Hi,

The OpenVPN 3 Linux v15 (beta) is now available.  This is primarily
a bugfix release as a few issues appeared soon after the last release.

* Bugfix: 2FA authentication with dynamic challenge protocol

  Servers (most commonly OpenVPN Access Server) deployed with 2FA
  based authentication would fail when the dynamic challenge protocol
  was utilized.  The result would be a client disconnecting with a
  time-out error and in some cases the openvpn3 sessions-list' would
  enlist "ghost" sessions not responding.  This command would also
  wait for a long time before reporting the complete list of sessions
  when such ghost sessions are present.  This is fixed.

  Reported: 

* Bugfix: Fix misbehaviours with --tls-crypt-v2

  This feature has been a known issue for a long time, but newer
  OpenVPN Access Servers now pushes tls-crypt-v2 profiles resulting
  in connections failing with NETWORK_EOF_ERROR errors in the log.
  This is finally fixed.

  Reported: 

* Feature: Added openvpn3-admin variables command

  This "openvpn3-admin variables" command will provide runtime
  information used by openvpn3-linux.  First variable accessible
  is the value reported in the IV_HWADDR field sent to the VPN
  server.  This can be seen using:

 # openvpn3-admin variables --machine-id

Supported Linux distributions:

  - Debian 9 (amd64)
  - Debian 10 (amd64, arm64)
  - CentOS 7 (x86_64)
  - CentOS 8 (x86_64, aarch64)
  - Fedora 33, 34 and Rawhide (x86_64, aarch64, s390x)
  - Red Hat Enterprise Linux 7 (x86_64)
  - Red Hat Enterprise Linux 8 (x86_64, aarch64)
  - Ubuntu 16.04 (amd64)
  - Ubuntu 18.04, 20.04, 20.10 and 21.04 (amd64, arm64)

The arm64 support on selected Debian and Ubuntu releases are
currently considered a tech-preview.

The Data Channel Offload (DCO) tech-preview feature is supported
in these distributions:

  - CentOS 8
  - Fedora 33, 34 and Rawhide
  - Ubuntu 20.04, 20.10 and 21.04
  - Red Hat Enterprise Linux 8

Remember to update the kmod-ovpn-dco package to the latest
available version.

Instructions how to install OpenVPN 3 Linux can be found here:



--
kind regards,

David Sommerseth
OpenVPN Inc


 Source tarballs ---

* OpenVPN 3 Linux v15 beta

  

  


 SHA256 Checksums --

86a29c6cc8bc4dfa15aa913f696e048989ebf682bbc184ae050f61256f87e37f  
openvpn3-linux-15_beta.tar.xz
be0fedded031a135ae2fe82edcac742b5352d17d16648643328b247476953c0f  
openvpn3-linux-15_beta.tar.xz.asc

 git references 

git repositories:



git tag: v15_beta
git commit: 6c9bbc9e10d7c499339c1ac774d1614e8df88573

 Changes from v14 to v15 ---

David Sommerseth (5):
  docs: Update README.md with new DCO and SELinux info
  common: Extend MachineID to provide source information
  ovpn3cli/admin: Add a new 'variables' admin command
  Revert "client/core: Improve fatal exception handling in event()"
  core-ext: Add support for inline --tls-crypt-v2






OpenPGP_signature
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel