Menu
▾
▴
openvpn-users — OpenVPN users list
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
(12) |
Apr
(45) |
May
(34) |
Jun
(50) |
Jul
(39) |
Aug
(39) |
Sep
(29) |
Oct
(28) |
Nov
(30) |
Dec
(28) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(18) |
Feb
(20) |
Mar
(10) |
Apr
(19) |
May
(72) |
Jun
(42) |
Jul
(31) |
Aug
(153) |
Sep
(156) |
Oct
(233) |
Nov
(213) |
Dec
(137) |
| 2004 |
Jan
(255) |
Feb
(292) |
Mar
(449) |
Apr
(241) |
May
(412) |
Jun
(541) |
Jul
(532) |
Aug
(611) |
Sep
(689) |
Oct
(804) |
Nov
(676) |
Dec
(715) |
| 2005 |
Jan
(639) |
Feb
(695) |
Mar
(756) |
Apr
(562) |
May
(497) |
Jun
(424) |
Jul
(394) |
Aug
(427) |
Sep
(390) |
Oct
(418) |
Nov
(387) |
Dec
(494) |
| 2006 |
Jan
(503) |
Feb
(436) |
Mar
(563) |
Apr
(448) |
May
(400) |
Jun
(420) |
Jul
(240) |
Aug
(362) |
Sep
(292) |
Oct
(408) |
Nov
(318) |
Dec
(245) |
| 2007 |
Jan
(330) |
Feb
(241) |
Mar
(259) |
Apr
(216) |
May
(305) |
Jun
(277) |
Jul
(288) |
Aug
(269) |
Sep
(273) |
Oct
(248) |
Nov
(267) |
Dec
(265) |
| 2008 |
Jan
(312) |
Feb
(454) |
Mar
(358) |
Apr
(195) |
May
(352) |
Jun
(305) |
Jul
(233) |
Aug
(385) |
Sep
(441) |
Oct
(325) |
Nov
(301) |
Dec
(329) |
| 2009 |
Jan
(344) |
Feb
(263) |
Mar
(350) |
Apr
(262) |
May
(255) |
Jun
(161) |
Jul
(330) |
Aug
(281) |
Sep
(285) |
Oct
(230) |
Nov
(304) |
Dec
(284) |
| 2010 |
Jan
(353) |
Feb
(260) |
Mar
(357) |
Apr
(403) |
May
(335) |
Jun
(236) |
Jul
(199) |
Aug
(247) |
Sep
(212) |
Oct
(160) |
Nov
(118) |
Dec
(110) |
| 2011 |
Jan
(172) |
Feb
(105) |
Mar
(113) |
Apr
(120) |
May
(124) |
Jun
(88) |
Jul
(94) |
Aug
(63) |
Sep
(78) |
Oct
(42) |
Nov
(137) |
Dec
(90) |
| 2012 |
Jan
(75) |
Feb
(113) |
Mar
(90) |
Apr
(77) |
May
(68) |
Jun
(58) |
Jul
(67) |
Aug
(119) |
Sep
(56) |
Oct
(60) |
Nov
(72) |
Dec
(48) |
| 2013 |
Jan
(78) |
Feb
(93) |
Mar
(114) |
Apr
(79) |
May
(57) |
Jun
(56) |
Jul
(29) |
Aug
(84) |
Sep
(55) |
Oct
(75) |
Nov
(61) |
Dec
(40) |
| 2014 |
Jan
(42) |
Feb
(14) |
Mar
(48) |
Apr
(132) |
May
(96) |
Jun
(58) |
Jul
(90) |
Aug
(116) |
Sep
(88) |
Oct
(69) |
Nov
(97) |
Dec
(93) |
| 2015 |
Jan
(61) |
Feb
(38) |
Mar
(62) |
Apr
(63) |
May
(67) |
Jun
(124) |
Jul
(79) |
Aug
(101) |
Sep
(60) |
Oct
(109) |
Nov
(64) |
Dec
(135) |
| 2016 |
Jan
(107) |
Feb
(83) |
Mar
(90) |
Apr
(78) |
May
(125) |
Jun
(100) |
Jul
(52) |
Aug
(96) |
Sep
(23) |
Oct
(74) |
Nov
(85) |
Dec
(168) |
| 2017 |
Jan
(63) |
Feb
(75) |
Mar
(51) |
Apr
(87) |
May
(48) |
Jun
(135) |
Jul
(90) |
Aug
(72) |
Sep
(38) |
Oct
(54) |
Nov
(102) |
Dec
(42) |
| 2018 |
Jan
(25) |
Feb
(55) |
Mar
(1) |
Apr
(10) |
May
(31) |
Jun
(72) |
Jul
(61) |
Aug
(12) |
Sep
(30) |
Oct
(41) |
Nov
(33) |
Dec
(16) |
| 2019 |
Jan
(19) |
Feb
(26) |
Mar
(72) |
Apr
(32) |
May
(38) |
Jun
(26) |
Jul
(19) |
Aug
(12) |
Sep
(8) |
Oct
(19) |
Nov
(61) |
Dec
(26) |
| 2020 |
Jan
(18) |
Feb
(21) |
Mar
(26) |
Apr
(206) |
May
(59) |
Jun
(18) |
Jul
(64) |
Aug
(28) |
Sep
(22) |
Oct
(15) |
Nov
(22) |
Dec
(21) |
| 2021 |
Jan
(17) |
Feb
(46) |
Mar
(64) |
Apr
(84) |
May
(86) |
Jun
(84) |
Jul
(45) |
Aug
(12) |
Sep
(27) |
Oct
(38) |
Nov
(49) |
Dec
(42) |
| 2022 |
Jan
(37) |
Feb
(55) |
Mar
(35) |
Apr
(31) |
May
(27) |
Jun
(61) |
Jul
(15) |
Aug
(4) |
Sep
(71) |
Oct
(15) |
Nov
(14) |
Dec
(12) |
| 2023 |
Jan
(20) |
Feb
(86) |
Mar
(57) |
Apr
(3) |
May
(7) |
Jun
(28) |
Jul
(105) |
Aug
(189) |
Sep
(33) |
Oct
(63) |
Nov
(40) |
Dec
(71) |
| 2024 |
Jan
(174) |
Feb
(120) |
Mar
(5) |
Apr
(42) |
May
(39) |
Jun
(19) |
Jul
(17) |
Aug
(23) |
Sep
(16) |
Oct
(6) |
Nov
(14) |
Dec
(2) |
| 2025 |
Jan
(1) |
Feb
(11) |
Mar
(19) |
Apr
(6) |
May
(11) |
Jun
(12) |
Jul
(7) |
Aug
(25) |
Sep
(47) |
Oct
(20) |
Nov
(19) |
Dec
(3) |
|
From: Gert D. <ge...@gr...> - 2025-12-12 13:11:09
|
Hi,
On Fri, Nov 28, 2025 at 06:16:29PM +0000, Peter Davis via Openvpn-users wrote:
> I want to know how much bandwidth each client is using. What tool would be useful for this? For example, the following users are connected to my OpenVPN server:
>
> Virtual Address,Common Name,Real Address,Last Ref
> 10.10.0.12,USER1,X.X.X.X:11975,2025-11-28 21:28:41
> 10.10.0.2,USER2,X.X.X.X:55645,2025-11-28 21:28:41
> 10.10.0.7,USER3,X.X.X.X:12564,2025-11-28 21:28:41
> 10.10.0.11,USER4,X.X.X.X:22152,2025-11-28 21:28:34
> 10.10.0.3,USER5,X.X.X.X:58136,2025-11-28 21:28:39
> 10.10.0.8,USER6,X.X.X.X:26612,2025-11-28 21:28:41
>
> I need a program that tells me how much bandwidth the IP address 10.10.0.12 is using, for example.
the stats files have per-client counters, you just need to look in the
right place:
$ cat tap-udp-p2mp/openvpn-status.log
OpenVPN CLIENT LIST
Updated,2025-12-12 14:07:38
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
freebsd-74-amd64,udp6:194.97.140.3:58397,399280,1475352,2025-12-12 05:42:12
freebsd-11-amd64,udp6:[2001:608:0:814::f000:16]:13481,1334688,1339527,2025-12-12 05:42:12
"Bytes Received, Bytes Sent"
OpenVPN does not keep track of per-IP traffic, only per-client. If you
need per-ip and can't map that yourself (or you have a larger client subnet
behind one client, and need more granular statistics) you need to find
a solution for your - unknown to us - operating system that can do such
statistics based on network traffic.
A proper google term could be "find out network traffic by IP".
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 ge...@gr...
|
|
From: Simon M. <sim...@in...> - 2025-12-04 06:33:14
|
Hi, > Hi, > >> The OpenVPN community project team is proud to release OpenVPN 2.7_rc3. >> >> This is the third release candidate for the feature release 2.7.0. >> > > Can one of the developers please add this little patch? > > https://github.com/OpenVPN/openvpn/issues/834 > This patch makes the nice option work when running with systemd. I just want to ask again for it to be included in the 2.7 RC. Thanks, Simon |
|
From: Carsten M. <Car...@at...> - 2025-12-01 14:05:57
|
Hi Selva, Thank you very much for your support. Your solution works great. Charly Von: Selva Nair <sel...@gm...> Gesendet: Donnerstag, 27. November 2025 19:49 An: Carsten Mietzsch <Car...@at...> Cc: ope...@li...; Wilhelm Greiner <Wil...@at...> Betreff: Re: [Openvpn-users] Problem with Athena signed rsa pkcs Hi, > I suspect that the stick simply does not support pss, but we are also unable to get the server to accept the old procedure. The signature algorithm is sha256RSA. > Unfortunately, over 1000 tokens are already in the field and a worldwide replacement is difficult. If the stick does not support PSS, you would normally get an error on the client --- we set the mechanism to CKM_RSS_PKCS_PSS before calling the sign routine in pkcs11-helper. A well behaved token would error out if it gets a signature request with an unsupported mechanism. OpenSSL3.0 prioritizes PSS signatures even for TLS 1.2 but it's not mandatory (unlike TLS1.3). So, if you want to avoid using PSS, you can restrict the signature algorithms in openssl.cnf (doing this only on client or server side should be enough). Here is a snippet of "/etc/ssl/openssl.cnf" showing this: openssl_conf = default_conf [default_conf] ssl_conf = ssl_sect [ssl_sect] system_default = system_default_sect [system_default_sect] SignatureAlgorithms = RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512 # add more algorithms if required Selva On Thu, Nov 27, 2025 at 7:09 AM Carsten Mietzsch via Openvpn-users <ope...@li...<mailto:ope...@li...>> wrote: Hi, We use Athena IDProtect tokens on the client side for pkcs#11 authentication. While the client does not display any errors during the handshake via pkcs, we receive a rejection on the server side: 2025-11-27T08:31:26.281152+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> Sent fatal SSL alert: decrypt error 2025-11-27T08:31:26.281207+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> OpenSSL: error:02000068:rsa routines::bad signature::../crypto/rsa/rsa_pss.c:143:ossl_rsa_verify_PKCS1_PSS_mgf1 2025-11-27T08:31:26.281262+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> OpenSSL: error:1C880004:Provider routines::RSA lib::../providers/implementations/signature/rsa_sig.c:1084:rsa_verify_directly 2025-11-27T08:31:26.281311+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> OpenSSL: error:0A00007B:SSL routines::bad signature::../ssl/statem/statem_lib.c:582:tls_process_cert_verify 2025-11-27T08:31:26.281353+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> TLS_ERROR: BIO read tls_read_plaintext error 2025-11-27T08:31:26.281402+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> TLS Error: TLS object -> incoming plaintext read error 2025-11-27T08:31:26.281719+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> TLS Error: TLS handshake failed 2025-11-27T08:31:26.281766+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> PID packet_id_free 2025-11-27T08:31:26.281806+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> PKCS#11: __pkcs11h_openssl_ex_data_free entered - parent=0x575b0f8c3cc0, ptr=(nil), ad=0x575b0f8c3d50, idx=1, argl=0, argp=0x72efb3a80ac3 2025-11-27T08:31:26.281839+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> PID packet_id_free 2025-11-27T08:31:26.281879+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> PID packet_id_free 2025-11-27T08:31:26.281922+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> TLS: tls_session_init: entry 2025-11-27T08:31:26.281956+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> PID packet_id_init seq_backtrack=64 time_backtrack=15 2025-11-27T08:31:26.281995+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> PID packet_id_init seq_backtrack=64 time_backtrack=15 2025-11-27T08:31:26.282023+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> TLS: tls_session_init: new session object, sid=a9758fd7 30b00b25 2025-11-27T08:31:26.282068+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> TLS: tls_multi_process: i=2 state=S_UNDEF, mysid=00000000 00000000, stored-sid=00000000 00000000, stored-ip=[AF_UNSPEC] 2025-11-27T08:31:26.282113+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> Fatal TLS error (check_tls_errors_co), restarting 2025-11-27T08:31:26.282153+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312<http://192.168.51.159:54312> SIGUSR1[soft,tls-error] received, client-instance restarting 2025-11-27T08:31:26.282196+00:00 sgw02 ovpn-server[87519]: MULTI: multi_close_instance called ovpn is v2.6 and ossl has v3.5.4. We have already tried on both sides to enforce tls-cert-profile legacy and tls 1.2. Forcing ossl to legacy also did not help. I suspect that the stick simply does not support pss, but we are also unable to get the server to accept the old procedure. The signature algorithm is sha256RSA. Unfortunately, over 1000 tokens are already in the field and a worldwide replacement is difficult. Has anyone had any experience with this or have any ideas about what we should check or try? Kind regards, Charly _______________________________________________ Openvpn-users mailing list Ope...@li...<mailto:Ope...@li...> https://lists.sourceforge.net/lists/listinfo/openvpn-users |
|
From: Simon M. <sim...@in...> - 2025-11-29 16:08:57
|
> Hi, > >> The OpenVPN community project team is proud to release OpenVPN 2.7_rc3. >> >> This is the third release candidate for the feature release 2.7.0. >> > > Can one of the developers please add this little patch? > > https://github.com/OpenVPN/openvpn/issues/834 > > It would be much appreciated. The patch is attached to this email. Would be nice if it was considered. Regards, Simon |
|
From: Simon M. <sim...@in...> - 2025-11-29 09:41:14
|
Hi, > The OpenVPN community project team is proud to release OpenVPN 2.7_rc3. > > This is the third release candidate for the feature release 2.7.0. > Can one of the developers please add this little patch? https://github.com/OpenVPN/openvpn/issues/834 It would be much appreciated. Regards, Simon |
|
From: Yuriy D. <yur...@op...> - 2025-11-28 19:44:39
|
The OpenVPN community project team is proud to release OpenVPN 2.7_rc3.
This is the third release candidate for the feature release 2.7.0.
Security fixes:
* CVE-2025-13751: Windows/interactive service: fix bug where the interactive service would error-exit in
certain error conditions instead of just logging the fact and
continuing. After the error-exit, OpenVPN connections will no
longer work until the service is restarted (or the system rebooted).
This can be triggered by any authenticated local user, and has
thus been classified as a "local denial of service" attack.
Important bug fixes since 2.7_rc2:
* Windows/Interactive Service bugfixes:
many small bugfixes to registry-related DNS domain handling
* Windows/Interactive Service: harden service pipe handling
close a small race condition, and add restrictive ACLs
* more type conversion related warnings have been fixed
* --multihome behaviour regarding egress interface selection has been
changed. See Changes.rst and manpage for details.
* cleanup dead code in event handling code (leftover of the multisocket
patch set)
* add new feature, --tls-crypt-v2-max-age n. See Changes.rst and
manpage for details.
* improve documentation to point out the pitfalls of case-insensitive
filesystems and --client-config-dir
* split default gateway query logic in two:
* for --redirect-gateway functionality, query for the gateway towards
the actual IP address of the VPN server connecting to
* for the "net_gateway" special destination for --route, and the
corresponding environment variable, always query for 0.0.0.0 / ::
(this will only make a difference in certain scenarios using a local
proxy, or on a system with multiple interfaces, not using the "default
route" for the VPN connection * see github#890)
* upgrade embedded pkcs11-helper vcpkg + pkcs11-uri patch to 1.31
* CMake / autoconf cleanup wrt unused checks, outdated old-Linux checks,
Windows oddities
* DCO (primarily Linux): improve handling of bulk notifications from
kernel (do not lose notifications, do not crash) (github#900)
More details can be found in the Changes document:
<https://github.com/OpenVPN/openvpn/blob/master/Changes.rst>
Source code and Windows installers can be downloaded from our download page:
<https://openvpn.net/community-downloads/>
Packages for Debian, Ubuntu, Fedora, RHEL, and openSUSE are available in the various
official Community repositories:
<https://community.openvpn.net/Pages/OpenVPN%20software%20repos>
Kind regards,
Yuriy Darnobyt |
|
From: Yuriy D. <yur...@op...> - 2025-11-28 19:41:49
|
The OpenVPN community project team is proud to release OpenVPN 2.6.17. This is a bugfix release containing one security fix. Security fixes: * CVE-2025-13751: Windows/interactive service: fix erroneous exit on error that could be used by a local Windows users to achieve a local denial-of-service Bug fixes: * Windows/interactive service: improve service pipe robustness against file access races (uuid) and access by unauthorized processes (ACL). * upgrade bundled build instruction (vcpkg and patch) for pkcs11-helper to 1.31, fixing a parser bug Windows MSI changes since 2.6.16-I001: * Built against OpenSSL 3.6.0 * Included openvpn-gui updated to 11.59.0.0 * Authorize config before opening the service pipe * Remove dependence on pathcch.dll not in Windows 7 * Included win-dco driver updated to 2.8.0 More details can be found in the Changes document: <https://github.com/OpenVPN/openvpn/blob/release/2.6/Changes.rst> (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: <https://openvpn.net/community/> Debian and Ubuntu packages are available in the official apt repositories: <https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos#DebianUbuntu:UsingOpenVPNaptrepositories> On Red Hat derivatives we recommend using the Fedora Copr repository. <https://copr.fedorainfracloud.org/coprs/g/OpenVPN/openvpn-release-2.6/> Kind regards, Yuriy Darnobyt |
|
From: Peter D. <pet...@pr...> - 2025-11-28 18:16:50
|
Hello, I want to know how much bandwidth each client is using. What tool would be useful for this? For example, the following users are connected to my OpenVPN server: Virtual Address,Common Name,Real Address,Last Ref 10.10.0.12,USER1,X.X.X.X:11975,2025-11-28 21:28:41 10.10.0.2,USER2,X.X.X.X:55645,2025-11-28 21:28:41 10.10.0.7,USER3,X.X.X.X:12564,2025-11-28 21:28:41 10.10.0.11,USER4,X.X.X.X:22152,2025-11-28 21:28:34 10.10.0.3,USER5,X.X.X.X:58136,2025-11-28 21:28:39 10.10.0.8,USER6,X.X.X.X:26612,2025-11-28 21:28:41 I need a program that tells me how much bandwidth the IP address 10.10.0.12 is using, for example. Thank you. |
|
From: Selva N. <sel...@gm...> - 2025-11-27 18:49:56
|
Hi, > I suspect that the stick simply does not support pss, but we are also unable to get the server to accept the old procedure. The signature algorithm is sha256RSA. > Unfortunately, over 1000 tokens are already in the field and a worldwide replacement is difficult. If the stick does not support PSS, you would normally get an error on the client --- we set the mechanism to CKM_RSS_PKCS_PSS before calling the sign routine in pkcs11-helper. A well behaved token would error out if it gets a signature request with an unsupported mechanism. OpenSSL3.0 prioritizes PSS signatures even for TLS 1.2 but it's not mandatory (unlike TLS1.3). So, if you want to avoid using PSS, you can restrict the signature algorithms in openssl.cnf (doing this only on client or server side should be enough). Here is a snippet of "/etc/ssl/openssl.cnf" showing this: openssl_conf = default_conf [default_conf] ssl_conf = ssl_sect [ssl_sect] system_default = system_default_sect [system_default_sect] SignatureAlgorithms = RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512# add more algorithms if required Selva On Thu, Nov 27, 2025 at 7:09 AM Carsten Mietzsch via Openvpn-users < ope...@li...> wrote: > Hi, > > > > We use Athena IDProtect tokens on the client side for pkcs#11 > authentication. While the client does not display any errors during the > handshake via pkcs, we receive a rejection on the server side: > > > > 2025-11-27T08:31:26.281152+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 Sent fatal SSL alert: decrypt error > > 2025-11-27T08:31:26.281207+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 OpenSSL: error:02000068:rsa routines::bad > signature::../crypto/rsa/rsa_pss.c:143:ossl_rsa_verify_PKCS1_PSS_mgf1 > > 2025-11-27T08:31:26.281262+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 OpenSSL: error:1C880004:Provider routines::RSA > lib::../providers/implementations/signature/rsa_sig.c:1084:rsa_verify_directly > > 2025-11-27T08:31:26.281311+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 OpenSSL: error:0A00007B:SSL routines::bad > signature::../ssl/statem/statem_lib.c:582:tls_process_cert_verify > > 2025-11-27T08:31:26.281353+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 TLS_ERROR: BIO read tls_read_plaintext error > > 2025-11-27T08:31:26.281402+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 TLS Error: TLS object -> incoming plaintext read > error > > 2025-11-27T08:31:26.281719+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 TLS Error: TLS handshake failed > > 2025-11-27T08:31:26.281766+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 PID packet_id_free > > 2025-11-27T08:31:26.281806+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 PKCS#11: __pkcs11h_openssl_ex_data_free entered - > parent=0x575b0f8c3cc0, ptr=(nil), ad=0x575b0f8c3d50, idx=1, argl=0, > argp=0x72efb3a80ac3 > > 2025-11-27T08:31:26.281839+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 PID packet_id_free > > 2025-11-27T08:31:26.281879+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 PID packet_id_free > > 2025-11-27T08:31:26.281922+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 TLS: tls_session_init: entry > > 2025-11-27T08:31:26.281956+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 PID packet_id_init seq_backtrack=64 time_backtrack=15 > > 2025-11-27T08:31:26.281995+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 PID packet_id_init seq_backtrack=64 time_backtrack=15 > > 2025-11-27T08:31:26.282023+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 TLS: tls_session_init: new session object, > sid=a9758fd7 30b00b25 > > 2025-11-27T08:31:26.282068+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 TLS: tls_multi_process: i=2 state=S_UNDEF, > mysid=00000000 00000000, stored-sid=00000000 00000000, stored-ip=[AF_UNSPEC] > > 2025-11-27T08:31:26.282113+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 Fatal TLS error (check_tls_errors_co), restarting > > 2025-11-27T08:31:26.282153+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 SIGUSR1[soft,tls-error] received, client-instance > restarting > > 2025-11-27T08:31:26.282196+00:00 sgw02 ovpn-server[87519]: MULTI: > multi_close_instance called > > > > ovpn is v2.6 and ossl has v3.5.4. We have already tried on both sides to > enforce > > tls-cert-profile legacy > > and tls 1.2. > > Forcing ossl to legacy also did not help. > > > > I suspect that the stick simply does not support pss, but we are also > unable to get the server to accept the old procedure. The signature > algorithm is sha256RSA. > > Unfortunately, over 1000 tokens are already in the field and a worldwide > replacement is difficult. > > > > Has anyone had any experience with this or have any ideas about what we > should check or try? > > > > Kind regards, > > > > Charly > _______________________________________________ > Openvpn-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-users > |
|
From: Selva N. <sel...@gm...> - 2025-11-27 17:13:18
|
See https://github.com/OpenVPN/openvpn-gui/issues/789 Though Windows 7 is unsupported, we'll try to unbreak it in 2.6.17 due shortly. Selva On Thu, Nov 27, 2025 at 7:53 AM NederlandsTaalStudent < ned...@gm...> wrote: > Hello! > I've updated from v2.6.15 to v2.6.16 on my win7/64 SP1. > The update instals without any error messages. > However the GUI does not start - it reports a not-found DLL. > > Is this known and intended behaviour? > > Thank you in advance. > _______________________________________________ > Openvpn-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-users > |
|
From: Jan J. K. <jan...@gm...> - 2025-11-27 16:10:55
|
Hi Carsten, On 27/11/2025 14:05, Carsten Mietzsch wrote: > > Unfortunately, I forgot to mention that it worked under Debian 11 with > ovpn 2.4 and ossl 1.1.1w, and it was the update to Deb 13 that caused > the problem. > the certificate looks OK though I cannot fully verify it without the sub-CA and CA you use. Are you loading the certificate from the token itself? I would try debugging this by extracting the certificate and using the token only for the private key. Also, you could try using the pkcs11_engine (or pkcs11_provider) to try to access it using the `openssl` command line tool. HTH, JJK > *Von:*Jan Just Keijser <jan...@gm...> > *Gesendet:* Donnerstag, 27. November 2025 13:19 > *An:* Carsten Mietzsch <Car...@at...>; > ope...@li... > *Cc:* Wilhelm Greiner <Wil...@at...> > *Betreff:* Re: [Openvpn-users] Problem with Athena signed rsa pkcs > > Hi Charly, > > I've dealt with similar stuff in the past - is it possible for you to > extract a certificate from the token and share that here? that will > give some insight into the problem. > > Regards, > > JJK > > > On 27/11/2025 11:34, Carsten Mietzsch via Openvpn-users wrote: > > Hi, > > We use Athena IDProtect tokens on the client side for pkcs#11 > authentication. While the client does not display any errors > during the handshake via pkcs, we receive a rejection on the > server side: > > 2025-11-27T08:31:26.281152+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 Sent fatal SSL alert: decrypt error > > 2025-11-27T08:31:26.281207+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 OpenSSL: error:02000068:rsa routines::bad > signature::../crypto/rsa/rsa_pss.c:143:ossl_rsa_verify_PKCS1_PSS_mgf1 > > 2025-11-27T08:31:26.281262+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 OpenSSL: error:1C880004:Provider > routines::RSA > lib::../providers/implementations/signature/rsa_sig.c:1084:rsa_verify_directly > > 2025-11-27T08:31:26.281311+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 OpenSSL: error:0A00007B:SSL routines::bad > signature::../ssl/statem/statem_lib.c:582:tls_process_cert_verify > > 2025-11-27T08:31:26.281353+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 TLS_ERROR: BIO read tls_read_plaintext error > > 2025-11-27T08:31:26.281402+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 TLS Error: TLS object -> incoming plaintext > read error > > 2025-11-27T08:31:26.281719+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 TLS Error: TLS handshake failed > > 2025-11-27T08:31:26.281766+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 PID packet_id_free > > 2025-11-27T08:31:26.281806+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 PKCS#11: __pkcs11h_openssl_ex_data_free > entered - parent=0x575b0f8c3cc0, ptr=(nil), ad=0x575b0f8c3d50, > idx=1, argl=0, argp=0x72efb3a80ac3 > > 2025-11-27T08:31:26.281839+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 PID packet_id_free > > 2025-11-27T08:31:26.281879+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 PID packet_id_free > > 2025-11-27T08:31:26.281922+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 TLS: tls_session_init: entry > > 2025-11-27T08:31:26.281956+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 PID packet_id_init seq_backtrack=64 > time_backtrack=15 > > 2025-11-27T08:31:26.281995+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 PID packet_id_init seq_backtrack=64 > time_backtrack=15 > > 2025-11-27T08:31:26.282023+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 TLS: tls_session_init: new session object, > sid=a9758fd7 30b00b25 > > 2025-11-27T08:31:26.282068+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 TLS: tls_multi_process: i=2 state=S_UNDEF, > mysid=00000000 00000000, stored-sid=00000000 00000000, > stored-ip=[AF_UNSPEC] > > 2025-11-27T08:31:26.282113+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 Fatal TLS error (check_tls_errors_co), restarting > > 2025-11-27T08:31:26.282153+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 SIGUSR1[soft,tls-error] received, > client-instance restarting > > 2025-11-27T08:31:26.282196+00:00 sgw02 ovpn-server[87519]: MULTI: > multi_close_instance called > > ovpn is v2.6 and ossl has v3.5.4. We have already tried on both > sides to enforce > > tls-cert-profile legacy > > and tls 1.2. > > Forcing ossl to legacy also did not help. > > I suspect that the stick simply does not support pss, but we are > also unable to get the server to accept the old procedure. The > signature algorithm is sha256RSA. > > Unfortunately, over 1000 tokens are already in the field and a > worldwide replacement is difficult. > > Has anyone had any experience with this or have any ideas about > what we should check or try? > > Kind regards, > > Charly > > > > _______________________________________________ > > Openvpn-users mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/openvpn-users > |
|
From: Jan J. K. <jan...@gm...> - 2025-11-27 16:09:00
|
hi, OpenVPN 2.6 is not supported on Windows 7 at all , so I guess you were lucky that it worked up til v2.6.15 ! So, I would argue that the fact that v2.6.15 ran on Windows 7 was NOT intended behaviour ;) cheers, JJK On 27/11/2025 13:51, NederlandsTaalStudent wrote: > Hello! > I've updated from v2.6.15 to v2.6.16 on my win7/64 SP1. > The update instals without any error messages. > However the GUI does not start - it reports a not-found DLL. > > Is this known and intended behaviour? > > |
|
From: Carsten M. <Car...@at...> - 2025-11-27 13:20:32
|
Hi, Unfortunately, I forgot to mention that it worked under Debian 11 with ovpn 2.4 and ossl 1.1.1w, and it was the update to Deb 13 that caused the problem. Von: Jan Just Keijser <jan...@gm...<mailto:jan...@gm...>> Gesendet: Donnerstag, 27. November 2025 13:19 An: Carsten Mietzsch <Car...@at...<mailto:Car...@at...>>; ope...@li...<mailto:ope...@li...> Cc: Wilhelm Greiner <Wil...@at...<mailto:Wil...@at...>> Betreff: Re: [Openvpn-users] Problem with Athena signed rsa pkcs Hi Charly, I've dealt with similar stuff in the past - is it possible for you to extract a certificate from the token and share that here? that will give some insight into the problem. Regards, JJK On 27/11/2025 11:34, Carsten Mietzsch via Openvpn-users wrote: Hi, We use Athena IDProtect tokens on the client side for pkcs#11 authentication. While the client does not display any errors during the handshake via pkcs, we receive a rejection on the server side: 2025-11-27T08:31:26.281152+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 Sent fatal SSL alert: decrypt error 2025-11-27T08:31:26.281207+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 OpenSSL: error:02000068:rsa routines::bad signature::../crypto/rsa/rsa_pss.c:143:ossl_rsa_verify_PKCS1_PSS_mgf1 2025-11-27T08:31:26.281262+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 OpenSSL: error:1C880004:Provider routines::RSA lib::../providers/implementations/signature/rsa_sig.c:1084:rsa_verify_directly 2025-11-27T08:31:26.281311+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 OpenSSL: error:0A00007B:SSL routines::bad signature::../ssl/statem/statem_lib.c:582:tls_process_cert_verify 2025-11-27T08:31:26.281353+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 TLS_ERROR: BIO read tls_read_plaintext error 2025-11-27T08:31:26.281402+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 TLS Error: TLS object -> incoming plaintext read error 2025-11-27T08:31:26.281719+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 TLS Error: TLS handshake failed 2025-11-27T08:31:26.281766+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 PID packet_id_free 2025-11-27T08:31:26.281806+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 PKCS#11: __pkcs11h_openssl_ex_data_free entered - parent=0x575b0f8c3cc0, ptr=(nil), ad=0x575b0f8c3d50, idx=1, argl=0, argp=0x72efb3a80ac3 2025-11-27T08:31:26.281839+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 PID packet_id_free 2025-11-27T08:31:26.281879+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 PID packet_id_free 2025-11-27T08:31:26.281922+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 TLS: tls_session_init: entry 2025-11-27T08:31:26.281956+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 PID packet_id_init seq_backtrack=64 time_backtrack=15 2025-11-27T08:31:26.281995+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 PID packet_id_init seq_backtrack=64 time_backtrack=15 2025-11-27T08:31:26.282023+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 TLS: tls_session_init: new session object, sid=a9758fd7 30b00b25 2025-11-27T08:31:26.282068+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 TLS: tls_multi_process: i=2 state=S_UNDEF, mysid=00000000 00000000, stored-sid=00000000 00000000, stored-ip=[AF_UNSPEC] 2025-11-27T08:31:26.282113+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 Fatal TLS error (check_tls_errors_co), restarting 2025-11-27T08:31:26.282153+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 SIGUSR1[soft,tls-error] received, client-instance restarting 2025-11-27T08:31:26.282196+00:00 sgw02 ovpn-server[87519]: MULTI: multi_close_instance called ovpn is v2.6 and ossl has v3.5.4. We have already tried on both sides to enforce tls-cert-profile legacy and tls 1.2. Forcing ossl to legacy also did not help. I suspect that the stick simply does not support pss, but we are also unable to get the server to accept the old procedure. The signature algorithm is sha256RSA. Unfortunately, over 1000 tokens are already in the field and a worldwide replacement is difficult. Has anyone had any experience with this or have any ideas about what we should check or try? Kind regards, Charly _______________________________________________ Openvpn-users mailing list Ope...@li...<mailto:Ope...@li...> https://lists.sourceforge.net/lists/listinfo/openvpn-users |
|
From: Gert D. <ge...@gr...> - 2025-11-27 13:15:50
|
Hi, On Thu, Nov 27, 2025 at 03:51:03PM +0300, NederlandsTaalStudent wrote: > I've updated from v2.6.15 to v2.6.16 on my win7/64 SP1. > The update instals without any error messages. > However the GUI does not start - it reports a not-found DLL. > > Is this known and intended behaviour? https://github.com/OpenVPN/openvpn-gui/issues/789 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 ge...@gr... |
|
From: NederlandsTaalStudent <ned...@gm...> - 2025-11-27 12:51:26
|
Hello! I've updated from v2.6.15 to v2.6.16 on my win7/64 SP1. The update instals without any error messages. However the GUI does not start - it reports a not-found DLL. Is this known and intended behaviour? Thank you in advance. |
|
From: Jan J. K. <jan...@gm...> - 2025-11-27 12:19:30
|
Hi Charly, I've dealt with similar stuff in the past - is it possible for you to extract a certificate from the token and share that here? that will give some insight into the problem. Regards, JJK On 27/11/2025 11:34, Carsten Mietzsch via Openvpn-users wrote: > > Hi, > > We use Athena IDProtect tokens on the client side for pkcs#11 > authentication. While the client does not display any errors during > the handshake via pkcs, we receive a rejection on the server side: > > 2025-11-27T08:31:26.281152+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 Sent fatal SSL alert: decrypt error > > 2025-11-27T08:31:26.281207+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 OpenSSL: error:02000068:rsa routines::bad > signature::../crypto/rsa/rsa_pss.c:143:ossl_rsa_verify_PKCS1_PSS_mgf1 > > 2025-11-27T08:31:26.281262+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 OpenSSL: error:1C880004:Provider routines::RSA > lib::../providers/implementations/signature/rsa_sig.c:1084:rsa_verify_directly > > 2025-11-27T08:31:26.281311+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 OpenSSL: error:0A00007B:SSL routines::bad > signature::../ssl/statem/statem_lib.c:582:tls_process_cert_verify > > 2025-11-27T08:31:26.281353+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 TLS_ERROR: BIO read tls_read_plaintext error > > 2025-11-27T08:31:26.281402+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 TLS Error: TLS object -> incoming plaintext read > error > > 2025-11-27T08:31:26.281719+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 TLS Error: TLS handshake failed > > 2025-11-27T08:31:26.281766+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 PID packet_id_free > > 2025-11-27T08:31:26.281806+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 PKCS#11: __pkcs11h_openssl_ex_data_free entered - > parent=0x575b0f8c3cc0, ptr=(nil), ad=0x575b0f8c3d50, idx=1, argl=0, > argp=0x72efb3a80ac3 > > 2025-11-27T08:31:26.281839+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 PID packet_id_free > > 2025-11-27T08:31:26.281879+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 PID packet_id_free > > 2025-11-27T08:31:26.281922+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 TLS: tls_session_init: entry > > 2025-11-27T08:31:26.281956+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 PID packet_id_init seq_backtrack=64 time_backtrack=15 > > 2025-11-27T08:31:26.281995+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 PID packet_id_init seq_backtrack=64 time_backtrack=15 > > 2025-11-27T08:31:26.282023+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 TLS: tls_session_init: new session object, > sid=a9758fd7 30b00b25 > > 2025-11-27T08:31:26.282068+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 TLS: tls_multi_process: i=2 state=S_UNDEF, > mysid=00000000 00000000, stored-sid=00000000 00000000, > stored-ip=[AF_UNSPEC] > > 2025-11-27T08:31:26.282113+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 Fatal TLS error (check_tls_errors_co), restarting > > 2025-11-27T08:31:26.282153+00:00 sgw02 ovpn-server[87519]: > 192.168.51.159:54312 SIGUSR1[soft,tls-error] received, client-instance > restarting > > 2025-11-27T08:31:26.282196+00:00 sgw02 ovpn-server[87519]: MULTI: > multi_close_instance called > > ovpn is v2.6 and ossl has v3.5.4. We have already tried on both sides > to enforce > > tls-cert-profile legacy > > and tls 1.2. > > Forcing ossl to legacy also did not help. > > I suspect that the stick simply does not support pss, but we are also > unable to get the server to accept the old procedure. The signature > algorithm is sha256RSA. > > Unfortunately, over 1000 tokens are already in the field and a > worldwide replacement is difficult. > > Has anyone had any experience with this or have any ideas about what > we should check or try? > > Kind regards, > > Charly > > > > _______________________________________________ > Openvpn-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-users |
|
From: Carsten M. <Car...@at...> - 2025-11-27 12:07:39
|
Hi, We use Athena IDProtect tokens on the client side for pkcs#11 authentication. While the client does not display any errors during the handshake via pkcs, we receive a rejection on the server side: 2025-11-27T08:31:26.281152+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 Sent fatal SSL alert: decrypt error 2025-11-27T08:31:26.281207+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 OpenSSL: error:02000068:rsa routines::bad signature::../crypto/rsa/rsa_pss.c:143:ossl_rsa_verify_PKCS1_PSS_mgf1 2025-11-27T08:31:26.281262+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 OpenSSL: error:1C880004:Provider routines::RSA lib::../providers/implementations/signature/rsa_sig.c:1084:rsa_verify_directly 2025-11-27T08:31:26.281311+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 OpenSSL: error:0A00007B:SSL routines::bad signature::../ssl/statem/statem_lib.c:582:tls_process_cert_verify 2025-11-27T08:31:26.281353+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 TLS_ERROR: BIO read tls_read_plaintext error 2025-11-27T08:31:26.281402+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 TLS Error: TLS object -> incoming plaintext read error 2025-11-27T08:31:26.281719+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 TLS Error: TLS handshake failed 2025-11-27T08:31:26.281766+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 PID packet_id_free 2025-11-27T08:31:26.281806+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 PKCS#11: __pkcs11h_openssl_ex_data_free entered - parent=0x575b0f8c3cc0, ptr=(nil), ad=0x575b0f8c3d50, idx=1, argl=0, argp=0x72efb3a80ac3 2025-11-27T08:31:26.281839+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 PID packet_id_free 2025-11-27T08:31:26.281879+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 PID packet_id_free 2025-11-27T08:31:26.281922+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 TLS: tls_session_init: entry 2025-11-27T08:31:26.281956+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 PID packet_id_init seq_backtrack=64 time_backtrack=15 2025-11-27T08:31:26.281995+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 PID packet_id_init seq_backtrack=64 time_backtrack=15 2025-11-27T08:31:26.282023+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 TLS: tls_session_init: new session object, sid=a9758fd7 30b00b25 2025-11-27T08:31:26.282068+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 TLS: tls_multi_process: i=2 state=S_UNDEF, mysid=00000000 00000000, stored-sid=00000000 00000000, stored-ip=[AF_UNSPEC] 2025-11-27T08:31:26.282113+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 Fatal TLS error (check_tls_errors_co), restarting 2025-11-27T08:31:26.282153+00:00 sgw02 ovpn-server[87519]: 192.168.51.159:54312 SIGUSR1[soft,tls-error] received, client-instance restarting 2025-11-27T08:31:26.282196+00:00 sgw02 ovpn-server[87519]: MULTI: multi_close_instance called ovpn is v2.6 and ossl has v3.5.4. We have already tried on both sides to enforce tls-cert-profile legacy and tls 1.2. Forcing ossl to legacy also did not help. I suspect that the stick simply does not support pss, but we are also unable to get the server to accept the old procedure. The signature algorithm is sha256RSA. Unfortunately, over 1000 tokens are already in the field and a worldwide replacement is difficult. Has anyone had any experience with this or have any ideas about what we should check or try? Kind regards, Charly |
|
From: Gert D. <ge...@gr...> - 2025-11-26 21:16:11
|
Hi,
On Wed, Nov 26, 2025 at 08:55:07PM +0100, Giulio wrote:
> Is this the new norm?
I have no idea, but the openvpn-devel@ list might be a better place
to ask this question. Not many developers read the users@ list.
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 ge...@gr...
|
|
From: Giulio <gi...@gm...> - 2025-11-26 19:55:27
|
COPR packages (ie: https://download.copr.fedorainfracloud.org/results/dsommers/openvpn-release-2.6/epel-10-x86_64/09807805-openvpn/openvpn-2.6.16-1.el10.x86_64.rpm) appear to be built against "centos-stream and epel10" instead of "stable rhel/derivatives and epel-10z" (important "z"). ie: https://download.copr.fedorainfracloud.org/results/dsommers/openvpn-release-2.6/epel-10-x86_64/09807805-openvpn/builder-live.log.gz: ... INFO: Start(/var/lib/copr-rpmbuild/workspace/workdir-y8bnl4bk/openvpn/openvpn.spec) Config(centos-stream+epel-10-x86_64) ... Is this the new norm? This could make packages incompatible with systems running stable rhel/derivatives and stable epel-10z. Thanks. |
|
From: Yuriy D. <yur...@op...> - 2025-11-18 18:50:46
|
The OpenVPN community project team is proud to release OpenVPN 2.7_rc2.
This is the second release candidate for the feature release 2.7.0.
Security fixes:
* CVE-2025-12106: IPv6 address parsing: fix buffer overread on invalid input
* CVE-2025-13086: HMAC verification check: fix incorrect memcmp() call
Important bug fixes since 2.7_rc1:
* even more type conversion related warnings have been fixed
* DCO FreeBSD improvements:
* improving debug messages (verb 6)
* implement client-side counter handling
* repair --inactive (and document shortcomings)
* repair handling of DCO disconnection notifications in --client mode
* Windows/Service improvements, hardening, bugfixes
* fix DNS address list generation (if 3 or more --dns addresses in use)
* fix DNS server undo_list
* disallow "stdin" as config name unless user has OpenVPN admin privs
* fix compilation errors with MSVC v19
* iservice: improve validation of config path (pathcc lib)
* [NOTE: this breaks OpenVPN compatibility with Windows 7]
* tapctl: refactor, improve output, change driver default to ovpn-dco
* iservice: when restoring iface metrics, enforce correct ifindex
* improve cmocka unit test assert() handling
* PUSH_UPDATE server: fix reporting of client IPs in ``status`` output after pushing a new IPv4/IPv6 address to client
* AEAD cipher safety margins: fix calculation of AEAD blocks in use (old code would undercount blocks)
* fix invalid pointer creation / memory overread in tls_pre_decrypt
* deprecate ``--opt-verify`` (change into no-op + warning)
More details can be found in the Changes document:
<https://github.com/OpenVPN/openvpn/blob/master/Changes.rst>
Source code and Windows installers can be downloaded from our download page:
<https://openvpn.net/community-downloads/>
Packages for Debian, Ubuntu, Fedora, RHEL, and openSUSE are available in the various
official Community repositories:
<https://community.openvpn.net/Pages/OpenVPN%20software%20repos>
Kind regards,
Yuriy Darnobyt |
|
From: Yuriy D. <yur...@op...> - 2025-11-18 18:47:16
|
The OpenVPN community project team is proud to release OpenVPN 2.6.16. This is a bugfix release containing one security fix. Security fixes: * CVE-2025-13086: Fix memcmp check for the hmac verification in the 3way handshake. This bug renders the HMAC based protection against state exhaustion on receiving spoofed TLS handshake packets in the OpenVPN server inefficient. Bug fixes: * fix invalid pointer creation in tls_pre_decrypt() - technically this is a memory over-read issue, in practice, the compilers optimize it away so no negative effects could be observed. * Windows: in the interactive service, fix the "undo DNS config" handling. * Windows: in the interactive service, disallow using of "stdin" for the config file, unless the caller is authorized OpenVPN Administrator * Windows: in the interactive service, change all netsh calls to use interface index and not interface name - sidesteps all possible attack avenues with special characters in interface names. * Windows: in the interactive service, improve error handling in some "unlikely to happen" paths. * auth plugin/script handling: properly check for errors in creation on $auth_failed_reason_file (arf). * for incoming TCP connections, close-on-exec option was applied to the wrong socket fd, leaking socket FDs to child processes. * sitnl: set close-on-exec flag on netlink socket * ssl_mbedtls: fix missing perf_pop() call (optional performance profiling) Windows MSI changes since 2.6.15-I001: * Built against OpenSSL 3.6.0 * Included openvpn-gui updated to 11.58.0.0 * Check the return value of GetProp() * Make config path check similar to that in interactive service * Escape the type id of password message received from openvpn * Add a message source for event logging * Check correct management daemon path when OpenVPN3 is enabled * Fix OpenVPN3 radio button label size when OVPN3 is enabled * Use GetTempPath() for debug file in plap as well * Migrate all saved plain usernames to encrypted format * Included win-dco driver updated to 2.8.0 More details can be found in the Changes document: <https://github.com/OpenVPN/openvpn/blob/release/2.6/Changes.rst> (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: <https://openvpn.net/community/> Debian and Ubuntu packages are available in the official apt repositories: <https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos#DebianUbuntu:UsingOpenVPNaptrepositories> On Red Hat derivatives we recommend using the Fedora Copr repository. <https://copr.fedorainfracloud.org/coprs/g/OpenVPN/openvpn-release-2.6/> Kind regards, Yuriy Darnobyt |
|
From: Yuriy D. <yur...@op...> - 2025-11-01 07:03:20
|
The OpenVPN community project team is proud to release OpenVPN 2.7_rc1.
This is a first release candidate for the feature release 2.7.0 which includes improvements and bug fixes.
Feature changes since 2.7_beta3:
* add warning for unsupported combination of --push and --tls-server
* add warning for unsupported combination of --reneg-bytes or --reneg-pkts with DCO
* remove perf_push()/perf_pop() infrastructure (because it did not work anymore, and compiler profiling will give
better results today)
* ensure compatibility with OpenSSL 3.6.0 - specifically, do not crash in t_lpback.sh trying to use
new encrypt-then-mac (ETM) ciphers
* improved PUSH_UPDATE server side support, which now handles changes of pushed ifconfig/ifconfig-ipv6 addresses
correctly (send packets to new IP addresses to this client, stop sending packets to the old addresses).
* freshen URLs all over the tree, and change to HTTPS where possible
* on DCO Linux/FreeBSD, add support for clients receiving an IPv4/IPv6 address that is not part of
the --server/--server-ipv6 subnet (= install extra on-interface host routes).
* Windows programs use a new API for path name canonicalization now (PathCchCanonicalizeEx()) which will break building
with MinGW on Ubuntu 22.04 -> Upgrade to 24.04 to make builds work again.
* on Windows, when setting up WINS servers using netsh, use interface index instead of adapter name now
("as for all other netsh calls")
* remove undocumented and unused --memstats feature
Important bug fixes since 2.7_beta3:
* even more type conversion related warnings have been fixed
* more bugfixes related to BYTECOUNT display on the management interface and byte counters on DCO platforms in general
* numerous minibugs reported by ZeroPath AI have been fixed (small memleaks, possible file descriptor leaks,
improved sanity checks, add ASSERT() on function contracts, etc.)
More details can be found in the Changes document:
<https://github.com/OpenVPN/openvpn/blob/master/Changes.rst>
Source code and Windows installers can be downloaded from our download page:
<https://openvpn.net/community-downloads/>
Packages for Debian, Ubuntu, Fedora, RHEL, and openSUSE are available in the various
official Community repositories:
<https://community.openvpn.net/Pages/OpenVPN%20software%20repos>
Kind regards,
Yuriy Darnobyt |
|
From: Simon M. <sim...@in...> - 2025-10-21 09:43:38
|
Hi David, > On 20/10/2025 14:52, Simon Matter wrote: >> While we are at it: the 'nice' option doesn't work because it's not >> allowed. This patch https://github.com/OpenVPN/openvpn/issues/834 makes >> it >> work on RHEL. Could this be integrated in the EPEL RPMs? >> > > Simon, could you post this patch as a git patch to the oepnvpn-devel > mailing list? > Sorry, I'm not a git user. Can you or someone else who works with git provide such a patch, please? Thanks, Simon |
|
From: David S. <daz...@eu...> - 2025-10-21 08:16:35
|
On 20/10/2025 14:52, Simon Matter wrote: > While we are at it: the 'nice' option doesn't work because it's not > allowed. This patch https://github.com/OpenVPN/openvpn/issues/834 makes it > work on RHEL. Could this be integrated in the EPEL RPMs? > Simon, could you post this patch as a git patch to the oepnvpn-devel mailing list? What you have proposed looks good to me. Due to how the openvpn binary works, there are few other alternatives when you try restricting privileges than to grant the CAP_SYS_NICE privilege. -- kind regards, David Sommerseth OpenVPN Inc |
|
From: Simon M. <sim...@in...> - 2025-10-20 12:52:36
|
Hi, > On 20/10/2025 14:03, David Sommerseth via Openvpn-users wrote: >> On 17/10/2025 11:26, Gert Doering wrote: >>> Hi, >>> >>> On Fri, Oct 17, 2025 at 11:19:48AM +0200, Simon Matter wrote: >>>> Looks like "update-crypto-policies --set LEGACY" did the trick to make >>>> it >>>> work. Ar least this makes the errors go away in a test setup. I'll >>>> soon do >>>> it on a production system. >>> >>> Ah, Redhat... "why should we leave decisions to software when we can >>> annoy everbody with a global setting". >>> >>> (I'm not exactly sure how these crypto policies work, but they seem to >>> override the application's request to get "--tls-cert-profile >>> insecure") >>> >>> thanks for reporting back the solution ;-) >> >> For the RPM packaging in Fedora, EPEL and Copr repos, we apply a patch >> which is required [2]. >> >> [1] >> <https://src.fedoraproject.org/rpms/openvpn/blob/rawhide/f/fedora-crypto-policy-compliance.patch> While we are at it: the 'nice' option doesn't work because it's not allowed. This patch https://github.com/OpenVPN/openvpn/issues/834 makes it work on RHEL. Could this be integrated in the EPEL RPMs? Thanks, Simon |
412 messages has been excluded from this view by a project administrator.
