openvpn-users — OpenVPN users list

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[Simon M. <sim...@in...>]

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

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[David S. <daz...@eu...>]

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

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[Simon M. <sim...@in...>]

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

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[David S. <daz...@eu...>]

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>
> [2]
> <https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/>
> 
> The goal here is to have a system-wide setting for enforcing a stricter
> crypto settings.  This has ties to requirements from enterprise
> customers of RHEL, where there has been request to centrally manage
> this.  And that's happening by pushing out settings to files in
> /etc/crypto-policies/, via whatever tools the enterprise prefer
> (ansible, puppet, chef, etc).  Since Fedora is the "development branch"
> of RHEL, that's how those are related.
> 
> These crypto policies covers everything across multiple SSL/TLS
> libraries (openssl, nss, gnutls) as well as many security relevant
> services and software stacks (krb5, java, libreswan, openssh, libssh).
> 
> The OpenSSL settings for the DEFAULT profile is:
> 
> # cat /usr/share/crypto-policies/DEFAULT/openssl.txt
> @SECLEVEL=2:kEECDH:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK:-kRSA \
>     :-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL    \
>     :!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8

JFTR, the LEGACY profile for OpenSSL is:

# cat /usr/share/crypto-policies/LEGACY/openssl.txt
@SECLEVEL=2:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK \
    :-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL   \
    :!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8

The difference is the addition of `kRSA` in the LEGACY profile.


-- 
kind regards,

David Sommerseth
OpenVPN Inc

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[David S. <daz...@eu...>]

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>
[2]
<https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/>

The goal here is to have a system-wide setting for enforcing a stricter
crypto settings.  This has ties to requirements from enterprise
customers of RHEL, where there has been request to centrally manage
this.  And that's happening by pushing out settings to files in
/etc/crypto-policies/, via whatever tools the enterprise prefer
(ansible, puppet, chef, etc).  Since Fedora is the "development branch"
of RHEL, that's how those are related.

These crypto policies covers everything across multiple SSL/TLS
libraries (openssl, nss, gnutls) as well as many security relevant
services and software stacks (krb5, java, libreswan, openssh, libssh).

The OpenSSL settings for the DEFAULT profile is:

# cat /usr/share/crypto-policies/DEFAULT/openssl.txt
@SECLEVEL=2:kEECDH:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK:-kRSA \
    :-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL    \
    :!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8


-- 
kind regards,

David Sommerseth
OpenVPN Inc

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[Gert D. <ge...@gr...>]

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

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

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[Simon M. <sim...@in...>]

> Hi,
>
> On Thu, Oct 16, 2025 at 01:56:01PM +0200, Simon Matter wrote:
>> I've tried both options but unfortunately they don't make a difference.
>>
>> Is there anything else I can try?
>
> "Look carefully at your certificates" - the error we get back from OpenSSL
> is "certificate verification failed", which could be anything really.
>
> Maybe "openssl verify" can shed some light on it.
>
> (As far as I can see, it's the client that complains, so you need to
> verify the server cert vs. the CA cert that is in the client config)

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.

Simon

[Openvpn-users] (no subject)

[Alireza F. <rad...@gm...>]

curl -X CONNECT 'https://8.8.8.8:853' -H 'Host: 8.8.8.8:853' --http1.1

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[Gert D. <ge...@gr...>]

Hi,

On Thu, Oct 16, 2025 at 01:56:01PM +0200, Simon Matter wrote:
> I've tried both options but unfortunately they don't make a difference.
> 
> Is there anything else I can try?

"Look carefully at your certificates" - the error we get back from OpenSSL
is "certificate verification failed", which could be anything really.

Maybe "openssl verify" can shed some light on it.

(As far as I can see, it's the client that complains, so you need to
verify the server cert vs. the CA cert that is in the client config)

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

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[Simon M. <sim...@in...>]

Hi Gert,

> Hi,
>
> On Thu, Oct 16, 2025 at 11:53:51AM +0200, Simon Matter via Openvpn-users
> wrote:
>> I'm trying to upgrade an old openvpn 2.4 based vpn to 2.7.
>> The old systems do have openssl 1.x while the new systems on AlmaLinux
>> 10
>> will have openssl 3.2.2.
>
> OpenSSL 3.x is much strikter regarding "outdated crypto", so certficates
> based on MD5 or SHA1 hash are refused by default.
>
> Try adding "tls-cert-profile legacy" or "tls-cert-profile insecure" to
> your config and see if that makes it work (this enables SHA1 and MD5
> support).
>
> The error message you see is not the "typical" one, normally it says
> something like "MD too weak" in this case.  But it might still help.
>

I've tried both options but unfortunately they don't make a difference.

Is there anything else I can try?

Simon

Re: [Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[Gert D. <ge...@gr...>]

Hi,

On Thu, Oct 16, 2025 at 11:53:51AM +0200, Simon Matter via Openvpn-users wrote:
> I'm trying to upgrade an old openvpn 2.4 based vpn to 2.7.
> The old systems do have openssl 1.x while the new systems on AlmaLinux 10
> will have openssl 3.2.2.

OpenSSL 3.x is much strikter regarding "outdated crypto", so certficates
based on MD5 or SHA1 hash are refused by default.

Try adding "tls-cert-profile legacy" or "tls-cert-profile insecure" to
your config and see if that makes it work (this enables SHA1 and MD5
support).

The error message you see is not the "typical" one, normally it says
something like "MD too weak" in this case.  But it might still help.

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

[Openvpn-users] Compatibility from openvpn 2.4 to 2.7

[Simon M. <sim...@in...>]

Hi,

I'm trying to upgrade an old openvpn 2.4 based vpn to 2.7.
The old systems do have openssl 1.x while the new systems on AlmaLinux 10
will have openssl 3.2.2.

Trying with a first updated client against the old server gives me the
following error:


Oct 16 09:48:13 gw-06 openvpn[55973]: TCP/UDP: Preserving recently used
remote address: [AF_INET]XX.XX.XX.XX:1194
Oct 16 09:48:13 gw-06 openvpn[55973]: Socket Buffers: R=[212992->212992]
S=[212992->212992]
Oct 16 09:48:13 gw-06 openvpn[55973]: UDPv4 link local: (not bound)
Oct 16 09:48:13 gw-06 openvpn[55973]: UDPv4 link remote:
[AF_INET]XX.XX.XX.XX:1194
Oct 16 09:48:13 gw-06 openvpn[55973]: TLS: Initial packet from
[AF_INET]XX.XX.XX.XX:1194, sid=4c8a20e6 cdc15528
Oct 16 09:48:13 gw-06 openvpn[55973]: VERIFY OK: depth=1, C=CH, ST=BL,
L=Arisdorf, O=Invoca-Systems, CN=Invoca-Systems CA,
ema...@XX...
Oct 16 09:48:13 gw-06 openvpn[55973]: VERIFY ERROR: depth=0,
error=certificate signature failure: C=CH, ST=BL, L=Arisdorf,
O=Invoca-Systems, CN=server, ema...@XX..., serial=1
Oct 16 09:48:13 gw-06 openvpn[55973]: Sent fatal SSL alert: decrypt error
Oct 16 09:48:13 gw-06 openvpn[55973]: OpenSSL: error:0A000086:SSL
routines::certificate verify failed:
Oct 16 09:48:13 gw-06 openvpn[55973]: TLS_ERROR: BIO read
tls_read_plaintext error
Oct 16 09:48:13 gw-06 openvpn[55973]: TLS Error: TLS object -> incoming
plaintext read error
Oct 16 09:48:13 gw-06 openvpn[55973]: TLS Error: TLS handshake failed
Oct 16 09:48:13 gw-06 openvpn[55973]: SIGUSR1[soft,tls-error] received,
process restarting
Oct 16 09:48:13 gw-06 openvpn[55973]: Restart pause, 128 second(s)


I also tried with an openvpn 2.4 build and got similar errors.

Can it be that the new openssl version breaks compatibility with the old
openvpn server? Unfortunately I can not update all systems at the same
time so I'm stuck here.

Any help is much appreciated!
Simon

[Openvpn-users] OpenVPN 2.7_beta3 released

[Yuriy D. <yur...@op...>]

The OpenVPN community project team is proud to release OpenVPN 2.7_beta3.
This is a third beta which includes improvements and bug fixes.

Feature changes since 2.7_beta2:

* improvements on PUSH_UPDATE handling on the server side
* improve "recursive routing checks", prepare the way for a policy-based setup where "packets to VPN server"
  could end up in the tunnel without interfering with OpenVPN operations
* add support for "eoch" data format to DCO on Windows (needs dco-win driver 2.8.0+)
* clean up and remove outdated stuff from COPYING

Important bug fixes since 2.7_beta2:

* bugfixes reconnect and PUSH_UPDATE handling on the client side (notably handling of 
  ifconfig/ifconfig-ipv6/redirect-gateway ipv6 if the server is not always pushing the same address families)

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

[Openvpn-users] HashCalc App

[Alireza F. <rad...@gm...>]

I recommend HashCalc for calculating Hash for Files or Strings

https://play.google.com/store/apps/details?id=com.goyalsoftech.hashcalc

[Openvpn-users] HashCalc App

[Alireza F. <rad...@gm...>]

I recommend HashCalc for calculating Hash for Files or Strings

https://play.google.com/store/apps/details?id=com.goyalsoftech.hashcalc

[Openvpn-users] (no subject)

[Alireza F. <rad...@gm...>]

https://github.com/ReactiveCircus/android-emulator-runner/commit/1dcd0090116d15e7c562f8db72807de5e036a4ed

[Openvpn-users] Security

[Alireza F. <rad...@gm...>]

4

[Openvpn-users] (no subject)

[Alireza F. <rad...@gm...>]

[Openvpn-users] (no subject)

[Alireza F. <rad...@gm...>]

[Openvpn-users] (no subject)

[Alireza F. <rad...@gm...>]

Re: [Openvpn-users] Any way to check client ca.crt expiration date

[Jochen B. <Joc...@bi...>]

On 30.09.25 04:53, Leroy Tennison via Openvpn-users wrote:
> Third point, are you suggesting that we use something different in
> the new ca.crt to distinguish it from the old one and use
> 
> On Monday, September 29, 2025 at 02:49:32 AM CDT, Jochen Bern <joc...@bi...> wrote:
>> You might be able to change the roll-out process so that the new
>> serverCA file and new client certs with some marker (say,
>> OU=ImAlreadyDone) will be installed at the same time, then you could
>> recognize unprepared clients by the missing marker as they auth ... ?

No, I'm trying to suggest a mechanism that might allow you to see *on 
the server side* which clients still don't have the updated CA file, by 
having a mark in the *client* certs.

In the OpenVPN default config, the "identity" of a cert-authenticated 
client essentially is the cert's subject *CN*, but every (re)auth gets 
logged with the full *DN*:

> Sep  7 04:06:33 [...] VERIFY OK: depth=0, CN=Jochen Bern, OU=[...],
>      O=Binect GmbH, L=Weiterstadt, ST=Hessen, C=Deutschland,
>      ema...@bi...

Now suppose that whenever a client gets the new CA certs file installed, 
you *also* replace the client cert with one where the DN contains an 
additional "OU=YupIAlreadyGotIt". (And if you have clients that need a 
new cert but can *not* receive the new CA certs file on the same 
occasion, they still get one *without* that extra marker.) Then you can 
tell *from the server log* which (active) clients still lack the config 
update.

(... I haven't been using EasyRSA for long enough that I can't give you 
instructions on *how* exactly to do all that, though. Matter of fact, 
with that regime, the same info *should* IMHO also be available from the 
CAs' index.txt files ...)

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH

Re: [Openvpn-users] Any way to check client ca.crt expiration date

[Leroy T. <ler...@ve...>]

Thanks for your reply, you mentioned some alternatives I wasn't aware of.  Our configuration pretty much follows the supplied client.conf and server.conf examples as well as easy-rsa so there's one ca file.  I didn't specify how I'd determine the ca.crt file so, for clarification, my plan was to use

    vpnconf=`ps -ef | grep openvpn | grep -o '\-\-config.*conf ' | cut -d' ' -f 2`

followed by

    cacrt=`grep ^ca $vpnconf | cut -d' ' -f2`


followed by (since our standard is to put the client ca.crt in /etc/openvpn and not use full-path for the file)

    expire=`openssl x509 -in /etc/openvpn/$cacrt -noout -enddate`

and use that.

Second, good point about an expired CRL but we don't use client side CRLs

Third point, are you suggesting that we use something different in the new ca.crt to distinguish it from the old one and use

openssl x509 -in </path/to/ca.crt> -noout -subject

to detect non-upgraded clients?

Finally, by design these clients are always connected so we don't face that issue.


On Monday, September 29, 2025 at 02:49:32 AM CDT, Jochen Bern <joc...@bi...> wrote: 

On 29.09.25 04:18, Leroy Tennison via Openvpn-users wrote:
> Other than connecting to the client, finding what ca.crt they
> use and running openssl x509 -in<client ca.crt> -noout -enddate?

a) Just to make sure: The *clients* need the cert of the CA issuing the 
*server* certs, because *that's* the cert they're checking with it.

b) Your OpenSSL command will output the data for the *first* cert found 
in the file. Files - or, for that matter, CApath directories - accepted 
by OpenVPN can contain *several* CA certs. (In the case of a PKI with 
intermediate CAs, they *should* have the entire chains from root to 
server-cert-issuing intermediate.)

c) I still remember the time when, while we evaluated a new platform, we 
found that OpenVPN would also refuse a CA with an expired *CRL*, so you 
might want to check that as well - *if* you're rolling out CRLs to the 
clients.

d) Having that said, I'm not aware of a method to doublecheck any of 
that on the *server* side ...


> My concern is accidentally overlooking a client.


You might be able to change the roll-out process so that the new 
serverCA file and new client certs with some marker (say, 
OU=ImAlreadyDone) will be installed at the same time, then you could 
recognize unprepared clients by the missing marker as they auth ... ?

(Still doesn't catch *dormant* clients, though ...)

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH

_______________________________________________
Openvpn-users mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Any way to check client ca.crt expiration date

[Jochen B. <Joc...@bi...>]

On 29.09.25 04:18, Leroy Tennison via Openvpn-users wrote:
> Other than connecting to the client, finding what ca.crt they
> use and running openssl x509 -in<client ca.crt> -noout -enddate?

a) Just to make sure: The *clients* need the cert of the CA issuing the 
*server* certs, because *that's* the cert they're checking with it.

b) Your OpenSSL command will output the data for the *first* cert found 
in the file. Files - or, for that matter, CApath directories - accepted 
by OpenVPN can contain *several* CA certs. (In the case of a PKI with 
intermediate CAs, they *should* have the entire chains from root to 
server-cert-issuing intermediate.)

c) I still remember the time when, while we evaluated a new platform, we 
found that OpenVPN would also refuse a CA with an expired *CRL*, so you 
might want to check that as well - *if* you're rolling out CRLs to the 
clients.

d) Having that said, I'm not aware of a method to doublecheck any of 
that on the *server* side ...

> My concern is accidentally overlooking a client.

You might be able to change the roll-out process so that the new 
serverCA file and new client certs with some marker (say, 
OU=ImAlreadyDone) will be installed at the same time, then you could 
recognize unprepared clients by the missing marker as they auth ... ?

(Still doesn't catch *dormant* clients, though ...)

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH

[Openvpn-users] Any way to check client ca.crt expiration date

[Leroy T. <ler...@ve...>]

Other than connecting to the client, finding what ca.crt they use and running openssl x509 -in<client ca.crt> -noout -enddate?
The reason I'm asking is that we have a ca.crt which will be expiring in about a year.  I know how to update ca.crt without immediately having to update all clients and how to update all clients (including their own certificates which will expire some time after the ca.crt) and we will be doing that over time.  My concern is accidentally overlooking a client. Thanks for any and all help.

[Openvpn-users] (no subject)

[Alireza F. <rad...@gm...>]

https://github.com/LSPosed/.github/tree/master/profile