openvpn-users — OpenVPN users list

Re: [Openvpn-users] How do I choose a specific Server Certificate?

[tincantech <tin...@pr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

To generate a client certificate for a specific client name, you’re on the right track with the commands you mentioned. Here's the step-by-step process, including generating and signing the client's certificate, and how to associate it with a specific certificate for your OpenVPN server.
1. Ensure You're in the Easy-RSA Directory:

Make sure you’re inside the Easy-RSA directory (i.e., /etc/openvpn/easy-rsa/).

cd /etc/openvpn/easy-rsa

2. Generate a Client Key Request:

You’ll need to generate the certificate signing request (CSR) for the client. This creates a private key and a public key request (which will later be signed by the CA).

Replace client_name with the actual name you want to assign to your client.

./easyrsa gen-req client_name nopass

    client_name can be anything you prefer (e.g., client1, client_alice, etc.).

    nopass means the key won’t be password-protected. If you want a password on the key, omit nopass.

This will create the following files:

    pki/private/client_name.key (private key for the client).

    pki/reqs/client_name.req (CSR file).

3. Sign the Client Request with the CA:

Once the CSR is generated, you need to sign it using the server's certificate authority (CA). This will create the client certificate.

./easyrsa sign-req client client_name

    You will be prompted to confirm that you want to sign the request. Type yes to approve it.

This will generate a signed certificate for the client:

    pki/issued/client_name.crt (signed client certificate).

4. Distribute the Client Certificate and Key:

You need to transfer the following files to your client machine (or distribute them securely):

    pki/private/client_name.key (private key).

    pki/issued/client_name.crt (signed client certificate).

    pki/ca.crt (CA certificate, if not already done).

Optionally, if you're using ta.key for TLS authentication, you'll also need to provide that key to the client (if you haven't already).
5. Optional: Generate Client Configuration File

On the client machine, you’ll need to create a configuration file for OpenVPN (typically client.ovpn). A sample configuration would look like this:

client
dev tun
proto udp
remote <your-server-ip> <port>
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client_name.crt
key client_name.key
tls-auth ta.key 1
cipher AES-256-CBC
verb 3

Make sure to:

    Replace <your-server-ip> with the IP address or domain of your OpenVPN server.

    Include the necessary certificate and key files on the client machine (client_name.crt, client_name.key, ca.crt, ta.key).

Additional Considerations:

    Revocation: If you ever need to revoke a client certificate, you can use Easy-RSA’s revoke command. The client certificate will then no longer be valid.

    Example:

    ./easyrsa revoke client_name
    ./easyrsa gen-crl
    cp pki/crl.pem /etc/openvpn/

    Then, ensure OpenVPN is configured to use the CRL file (crl-verify /etc/openvpn/crl.pem).

    Client Directory Structure: When deploying certificates to clients, keep the structure organized to prevent mixing up the different files (e.g., each client in a separate directory with the correct certs and keys).

Once you’ve done this, your client should be ready to connect to your OpenVPN server!

-- 



Sent with Proton Mail secure email.

On Saturday, 12 July 2025 at 10:52, Peter Davis via Openvpn-users <ope...@li...> wrote:

> Hello,
> I used the following commands to generate the Server Certificate:
> 
> # cp -r /usr/share/easy-rsa /etc/openvpn/
> # cd /etc/openvpn/easy-rsa
> # mv vars.example vars
> 
> # nano vars
> 
> export KEY_COUNTRY="US"
> export KEY_PROVINCE="CA"
> export KEY_CITY="NY"
> export KEY_ORG="MyName"
> export KEY_EMAIL="ad...@ex..."
> export KEY_OU="OpenVPN"
> 
> # ./easyrsa init-pki
> # ./easyrsa build-ca nopass
> # ./easyrsa gen-req server nopass
> # ./easyrsa sign-req server server
> # ./easyrsa gen-dh
> # openvpn --genkey secret ta.key
> 
> Then I edited the vars file with the new contents and issued the above commands to generate the new certificate. Then I created a directory for each certificate in the /etc/openvpn directory and moved the following files to the corresponding directory:
> 
> # cp ta.key /etc/openvpn/DIRECTORY_NAME
> # cp pki/ca.crt /etc/openvpn/DIRECTORY_NAME
> # cp pki/private/SERVER_NAME.key /etc/openvpn/DIRECTORY_NAME
> # cp pki/issued/SERVER_NAME.crt /etc/openvpn/DIRECTORY_NAME
> # cp pki/dh.pem /etc/openvpn/DIRECTORY_NAME
> 
> Now I want to generate keys for clients using the following commands:
> 
> # ./easyrsa gen-req client_name nopass
> # ./easyrsa sign-req client client_name
> 
> 
> How do I generate my client for a specific certificate?
> 
> 
> Thank you.
> 
> 
> _______________________________________________
> Openvpn-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsC5BAEBCgBtBYJockg8CZBPl5z2a5C4nUUUAAAAAAAcACBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3Jn2NQBQXc0OPuHrAxNWx/kUfePLG+9bdpFmoyO
T2viEQIWIQQJvD1EZ6ONcnnFVVVPl5z2a5C4nQAA/68H/R3qEGUHUH6iUCwm
661mr0NVGb77GIpfxEV8zgnYq2FiTXtSP1etWu0DZhH/cmYiCDOE4Nm7KRkQ
l1HRtuZNeeYpNzz1hcOp/fJDLxZ5R1t4qHiYOhVHG3Ih1ORMzJIIQO3XoRjM
LhGmqWdddANwkuJeZ94GgXgEE7AIw+xYWMvUm1dkH9OClPyU3FTBGdxvLxOl
uin48Uuq8zeVvt7Xtrb/XYXxZKDV7bd3VJzYlFvhJdWw6jvwN5xuaan+NyAi
OEefW7xFFBF0ZTHaCyYIWZaPAB9OsqWf1flI40gatz3AZp9stI0efie8PrE+
P2STR4FDishYuLRUMcZhHuDWRmU=
=JpCe
-----END PGP SIGNATURE-----

[Openvpn-users] How do I choose a specific Server Certificate?

[Peter D. <pet...@pr...>]

Hello,
I used the following commands to generate the Server Certificate:

# cp -r /usr/share/easy-rsa /etc/openvpn/
# cd /etc/openvpn/easy-rsa
# mv vars.example vars

# nano vars

export KEY_COUNTRY="US"
export KEY_PROVINCE="CA"
export KEY_CITY="NY"
export KEY_ORG="MyName"
export KEY_EMAIL="ad...@ex..."
export KEY_OU="OpenVPN"

# ./easyrsa init-pki
# ./easyrsa build-ca nopass
# ./easyrsa gen-req server nopass                        
# ./easyrsa sign-req server server
# ./easyrsa gen-dh
# openvpn --genkey secret ta.key

Then I edited the vars file with the new contents and issued the above commands to generate the new certificate. Then I created a directory for each certificate in the /etc/openvpn directory and moved the following files to the corresponding directory:

# cp ta.key /etc/openvpn/DIRECTORY_NAME
# cp pki/ca.crt /etc/openvpn/DIRECTORY_NAME
# cp pki/private/SERVER_NAME.key /etc/openvpn/DIRECTORY_NAME
# cp pki/issued/SERVER_NAME.crt /etc/openvpn/DIRECTORY_NAME
# cp pki/dh.pem /etc/openvpn/DIRECTORY_NAME

Now I want to generate keys for clients using the following commands:

# ./easyrsa gen-req client_name nopass
# ./easyrsa sign-req client client_name


How do I generate my client for a specific certificate?


Thank you.

Re: [Openvpn-users] Security Update not showing up to patch

[Rui S. <rs...@ru...>]

Hi Gert,

On Sat, Jun 28, 2025 at 4:56 PM Gert Doering <ge...@gr...> wrote:

> So, I think we on the openvpn-users@ list might not be able to provide
> meaningful advice here.
>
I'm sure you cannot. I've sent this to the wrong mailing list.
My apologies for the noise!

Regards,
-- 
Rui Santos
Veni, Vidi, Linux

Re: [Openvpn-users] Security Update not showing up to patch

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

Hi,

On Sat, Jun 28, 2025 at 01:33:18PM +0100, Rui Santos wrote:
> I'm trying to mitigate this vulnerability:
> https://www.suse.com/support/update/announcement/2025/suse-su-202501737-1/

... which seems to be about "gstreamer-plugins-bad"... which I hope
is not using OpenVPN in any way...

So, I think we on the openvpn-users@ list might not be able to provide
meaningful advice here.

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] Security Update not showing up to patch

[Rui S. <rs...@ru...>]

Hi all,

I'm trying to mitigate this vulnerability:
https://www.suse.com/support/update/announcement/2025/suse-su-202501737-1/

However, it doesn't appear either on YaST nor on zypper patch.
Maybe I'm doing something wrong?

These are the repositories I have enabled:
# zypper lr --show-enabled-only
Repository priorities are without effect. All enabled repositories
share the same priority.

#  | Alias                 | Name
                   | Enabled | GPG Check | Refresh
---+-----------------------+--------------------------------------------------------------+---------+-----------+--------
 1 | devel_tools_scm       | Software configuration management (15.7)
                   | Yes     | (r ) Yes  | Yes
 4 | repo-backports-update | Update repository of openSUSE Backports
                   | Yes     | (r ) Yes  | Yes
 9 | repo-non-oss          | Non-OSS Repository
                   | Yes     | (r ) Yes  | Yes
10 | repo-openh264         | Open H.264 Codec (openSUSE Leap)
                   | Yes     | (r ) Yes  | Yes
11 | repo-oss              | Main Repository
                   | Yes     | (r ) Yes  | Yes
13 | repo-sle-update       | Update repository with updates from SUSE
Linux Enterprise 15 | Yes     | (r ) Yes  | Yes
15 | repo-update           | Main Update Repository
                   | Yes     | (r ) Yes  | Yes
16 | repo-update-non-oss   | Update Repository (Non-Oss)
                   | Yes     | (r ) Yes  | Yes
17 | server_monitoring     | Server Monitoring Software (15.6)
                   | Yes     | (r ) Yes  | Yes

Am I missing anything?

Regards,
-- 
Rui Santos
Veni, Vidi, Linux

[Openvpn-users] Android DNS double connect bug

[shadowbladeee <sha...@pr...>]

Hello List,

I am using version 3.7.1 on Android 13, even tho I have noticed this behavior in earlier versions as well.

The VPN server running on a Debian box, it pushes the default route and DNS servers to Android.

This DNS server is a dnsmasq on that server which routes the requests (local ones with .lan extension) to the local DNS server, the rest to public servers. 

I noticed that many times after connecting this just don't work, the lan addresses stay unresolvable, I reconnect again and DNS works (until next reconnect).

Anyone seen this behavior? Any workaround for it?
I would be ok using dnsmasq on Android directly or even hosts file but sadly this cannot be done on unrooted phone :/

Thanks

Re: [Openvpn-users] IPv6 Routing Issue Behind OpenVPN on OpenBSD with ISP-Delegated /64

[Marc S. <sch...@al...>]

Hello,

On Tue, Jun 24, 2025 at 09:33:52AM +0000, michael.davis303 via Openvpn-users wrote:
> ping6: sendmsg: Permission denied (even with doas used)

No recent experience with *BSD, but on Linux, you get that kind of behaviour
with firewall rules, AFAIR.

Re: [Openvpn-users] IPv6 Routing Issue Behind OpenVPN on OpenBSD with ISP-Delegated /64

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

Hi,

On Tue, Jun 24, 2025 at 09:33:52AM +0000, michael.davis303 via Openvpn-users wrote:
> ping6: sendmsg: Permission denied (even with doas used)

This tends to be a firewall issue... (on the machine that sends the ping)

Are you permitting outbound IPv6?  Can you share "pfctl -s rules"?

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] IPv6 Routing Issue Behind OpenVPN on OpenBSD with ISP-Delegated /64

[michael.davis303 <mic...@pr...>]

Hi everyone,

I'm running an OpenVPN server on OpenBSD where clients connect over IPv4 and are assigned IPv6 addresses (IPv6-in-IPv4 tunnel). My ISP delegates a full /64 range (aaaa:bbbb:cccc:dddd::/64), but only the address configured at boot via autoconf (aaaa:bbbb:cccc:dddd:92::1/64) is actually routed to the server — effectively as a /128.
I'd like to assign IPv6 addresses from the /64 to OpenVPN clients. The OpenVPN config looks like this:

server-ipv6 aaaa:bbbb:cccc:dddd:93::/112
push "route-ipv6 aaaa:bbbb:cccc:dddd::/64"
push "route-ipv6 2000::/3"

> net.inet6.ip6.forwarding=1 is enabled.
> pf isn't blocking anything (pflog0 shows no drops).
> When VPN is up and tun0 is active, clients properly get assigned an address from  aaaa:bbbb:cccc:dddd:93::/112 and with it can ping6 the server’s VPN gateway (aaaa:bbbb:cccc:dddd:93::1) and host IP (aaaa:bbbb:cccc:dddd:92::1) — but can't reach anything beyond.
> tcpdump on tun0 shows clients’ echo requests leaving, but no replies ever return.
> From the server itself, trying to ping6 -S aaaa:bbbb:cccc:dddd:93::1 google.com fails with:

ping6: sendmsg: Permission denied (even with doas used)

This seems like a routing issue — possibly because the server’s upstream isn’t routing the rest of the /64 to the host, just the boot-assigned /128.

Has anyone dealt with a similar setup? Any advice or workarounds — such as using NDP proxying, static routing tricks, or other ways to get the full prefix routed behind OpenVPN?

Thank you very much in advance for your answers.

Best regards,
Michael,

[Openvpn-users] OpenVPN 2.7_alpha2 released

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

The OpenVPN community project team is proud to release OpenVPN 2.7_alpha2.
This is the second Alpha release for the feature release 2.7.0.
As the Alpha name implies this is an early release build, this is not intended 
for production use.

This release include security fix for CVE-2025-50054

Highlights of this release include:
* Multi-socket support for servers -- Handle multiple addresses/ports/protocols 
within one server
* Improved Client support for DNS options
* Client implementations for Linux/BSD, included with the default install
* New client implementation for Windows, adding support for features like split 
DNS and DNSSEC
* Architectural improvements on Windows
* The block-local flag is now enforced with WFP filters
* Windows network adapters are now generated on demand
* Windows automatic service now runs as an unprivileged user
* Support for server mode in win-dco driver
Note: Support for the wintun driver has been removed. win-dco is now the 
default, tap-windows6 is the fallback solution for use-cases not covered by win-dco.
* Improved data channel
* Enforcement of AES-GCM usage limit
* Epoch data keys and packet format
* Support for new upstream DCO Linux kernel module
* This release supports the new ovpn DCO Linux kernel module which will be 
available in future upstream Linux kernel releases. Backports of the new module 
to current kernels are available via the ovpn-backports project.
* TLS 1.3 support with bleeding-edge mbedTLS versions

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

Re: [Openvpn-users] OpenVPN Forums broken

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

Hi,

On Mon, Jun 16, 2025 at 04:23:35PM +0100, Vincents Lists via Openvpn-users wrote:
> For the past few weeks the "new" OpenVPN forums ( [ https://forums-new.openvpn.net/ | https://forums-new.openvpn.net/ ] ) have been overrun by Call-Girl spam, and it is impossible to actually reach any of the forums/messages. 
> 
> Is there a plan to get it cleaned up? 
> 
> If not, can the old forum ( [ https://forums.openvpn.net/ | https://forums.openvpn.net/ ] ) be reinstated until such time as the new one can be cleaned/hardened/relaunched. 

My understanding is that we found a new volunteer to do a new "new forum"
(so the existing "forums-new" will be removed completely, and a new
"forums-new" with the old content will be created), and "this will happen
in the next weeks".

It's not me, and I am not the one who does server and software maintenance,
so I have no more definite information - except "we hear you, and yes,
it took to long"

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] OpenVPN Forums broken

[Vincents L. <vin...@it...>]

Hi, 

For the past few weeks the "new" OpenVPN forums ( [ https://forums-new.openvpn.net/ | https://forums-new.openvpn.net/ ] ) have been overrun by Call-Girl spam, and it is impossible to actually reach any of the forums/messages. 

Is there a plan to get it cleaned up? 

If not, can the old forum ( [ https://forums.openvpn.net/ | https://forums.openvpn.net/ ] ) be reinstated until such time as the new one can be cleaned/hardened/relaunched. 

Thanks 
Vincent 


IT Solutions Email Disclaimer - This e-mail and any files transmitted with it contain information which may be confidential and which may also be privileged and is intended solely for the use of the individual or entity to whom it is addressed.  Unless you are the intended recipient you may not copy or use it, or disclose it to anyone else.  Any opinions expressed are that of the individual and not necessarily that of IT Solutions Ltd. If you have received this e-mail in error please notify the sender by return. For further information on IT Solutions visit https://www.itsolutions.ie

Re: [Openvpn-users] OpenVPN Client and auto reconnect

[Alex K <rig...@gm...>]

I would try this option:  --connect-retry n

Perhaps set it to a small value or 1?

On Tue, Jun 10, 2025 at 9:34 PM NKP - A. Weitekamp via Openvpn-users <
ope...@li...> wrote:

> Hello everyone!
>
> I have a question. We're using OpenVPN Connect 3.7.2 (4253) on Windows and
> would like to disable auto reconnection when the connection is lost.
>
> We use 2FA and have the following problem: If the connection drops
> briefly, the VPN client repeatedly attempts to establish a connection. The
> user doesn't see this in the background, and the firewall then blocks the
> numerous connection attempts.
>
>
>
> The VPN client may simply not be able to reconnect. Is there a solution?
>
>
>
> Thanks for your help!
>
>
>
> weite
>
>
> _______________________________________________
> Openvpn-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
>

[Openvpn-users] OpenVPN Client and auto reconnect

[NKP - A. W. <wei...@nk...>]

Hello everyone!
I have a question. We're using OpenVPN Connect 3.7.2 (4253) on Windows and would like to disable auto reconnection when the connection is lost.
We use 2FA and have the following problem: If the connection drops briefly, the VPN client repeatedly attempts to establish a connection. The user doesn't see this in the background, and the firewall then blocks the numerous connection attempts.

The VPN client may simply not be able to reconnect. Is there a solution?

Thanks for your help!

weite

[Openvpn-users] OpenVPN 2.7_alpha1 released

[Frank L. <fr...@li...>]

The OpenVPN community project team is proud to release OpenVPN 2.7_alpha1.
This is the first Alpha release for the feature release 2.7.0.
As the "Alpha" name implies this is an early release build, this is not intended
for production use.

Highlights of this release include:
* Multi-socket support for servers -- Handle multiple addresses/ports/protocols
  within one server
* Improved Client support for DNS options
  * Client implementations for Linux/BSD, included with the default install
  * New client implementation for Windows, adding support for features like split
    DNS and DNSSEC
* Architectural improvements on Windows
  * The block-local flag is now enforced with WFP filters
  * Windows network adapters are now generated on demand
  * Windows automatic service now runs as an unprivileged user
  * Support for server mode in win-dco driver
  * Note: Support for the wintun driver has been removed.
    win-dco is now the default, tap-windows6 is the fallback solution for
    use-cases not covered by win-dco.
* Improved data channel
  * Enforcement of AES-GCM usage limit
  * Epoch data keys and packet format
* Support for new upstream DCO Linux kernel module
  * This release supports the new ovpn DCO Linux kernel module which will be
    available in future upstream Linux kernel releases. Backports of the new
    module to current kernels are available via the ovpn-backports project.

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>

Regards,
-- 
  Frank Lichtenheld

[Openvpn-users] OpenVPN 3 Linux v24.1 released

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

OpenVPN 3 Linux v24 (Bugfix/security release)

The v24.1 release is a small security and bugfix release.

* Security: CVE-2025-3908 - openvpn3-admin init-config follows symlink
  Wolfgang Frisch from the SUSE security team reach out and
  notified us of a potential issue with the openvpn3-admin init-config
  command following symlinks when creating needed directories.  This
  has been resolved and this command will no longer follow symlinks
  and will insist the user running this command to setup these
  directories manually with the correct ownership and privileges.

* Bugfix: openvpn3 session-manage --log-level can crash the Session Manager
  When changing the log-level for an on-going VPN session to an invalid
  log-level value, the Session Manager process would fail and stop
  running due to an uncaught exception.  The result would not affect
  the currently on-going VPN sessions, but none of those sessions could
  be managed via the session manager any more.  This has been fixed and
  the Session Manager will now reply to the caller with an error message
  instead.  This issue was reported by Wolfgang Frisch from the SUSE
  security team.

* Bugfix: Control character injection via command line arguments
  All the command line arguments would pass on ASCII control characters
  which could be used to inject misleading information into logs.  Since
  none of the entry points of user data need ASCII control characters
  except newline characters a few places, these characters are now
  removed.  This issue was reported by Wolfgang Frisch from the SUSE
  security team.

* Bugfix: openvpn3-service-backendstart crash during shutdown
  Occasionally the openvpn3-service-backendstart helper service could
  crash during it's shutdown phase.  This was due to an uncaught
  exception.  This has been resolved.

* Bugfix: VPN session failing to start without org.freedesktop.hostname1
  The current client code expected the org.freedesktop.hostname1
  (systemd-hostnamed) service to be available.  On systems without
  systemd, this would result in the client using a longer time to wait
  for this service to appear before continuing.  Meanwhile, the Session
  Manager would also not receive a response in time from this client
  process, thus considering it unresponsive and stopping the VPN session
  instead.  This has been resolved by querying the master D-Bus service
  if the org.freedesktop.hostname1 service is available or not and just
  continue without it, if it is unavailable.

* Build fix: Meson clean-up
  Newer Meson versions had several minor complaints about the build
  configuration.  These issues should now be resolved and Meson should
  no longer report any warnings.

* Build fix: GCC-15 related build issues
  The GCC-15 compiler now starts to complain about more issues which was
  not raised by prior compiler versions with the same compiler flags.
  Issues raised by GCC-15 are now fixed.


Known issues:

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


Credits
-------
Wolfgang Frisch from the SUSE security team for their bug
and security reports.


Supported Linux distributions
-----------------------------

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

Red Hat Enterprise Linux 10 is in tech preview.

Installation and getting started instructions can be found here:

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


--
kind regards,

David Sommerseth
OpenVPN Inc


---- Source tarballs ---------------------------------------------------
* OpenVPN 3 Linux v24.1

  <https://swupdate.openvpn.net/community/releases/openvpn3-linux-24.1.tar.xz>
  <https://swupdate.openvpn.net/community/releases/openvpn3-linux-24.1.tar.xz.asc>

---- SHA256 Checksums --------------------------------------------------

7a85a6247f481a4eb998b79721a7ae87c27f43fea54d09d7cafc86c59cc94ded  openvpn3-linux-24.1.tar.xz.asc
c0e5db2cea4e9f2118b81425d3833b85821c515b72a53e21479c7a1f24d4bef0  openvpn3-linux-24.1.tar.xz

---- git references ----------------------------------------------------

git repositories:

 - OpenVPN 3 Linux
   <https://codeberg.org/OpenVPN/openvpn3-linux> (PRIMARY)
   <https://gitlab.com/openvpn/openvpn3-linux>   (code-only mirror)
   <https://github.com/OpenVPN/openvpn3-linux>   (code-only mirror)

   git tag: v24.1
   git commit: 8bba2a15088bd0ef9c2f18ff29186e890a010add

---- Changes from v24 to v24.1 --------------------------------------

David Sommerseth (31):
      build: Misc cleanup in Meson build scripts
      build: Fix incorrect default value assignment for create_statedir option
      common: Refactor Configuration::File to use std::filesystem
      ovpn3cli/init-config: Refactor file/directory handling to use std::filesystem
      ovpn3cli/init-config: Don't follow symlinks setting up state/configs dirs
      sessionmgr: Catch incorrect log level requests in Session object
      build: Fix minor meson complaint in addons/aws
      build: Improve OpenVPN 3 Core library version extraction
      events/log: Refactor Events::Log()
      events/log: Simplify Events::Log::str() methods
      events/log: Implement character filter in Events::Log
      log: Extend LogSender with a Debug_wnl() method
      log/core: Enable multi-line logging via the Core D-Bus logger
      log/journal: Don't filter newlines from journald entries
      log: Preserve the newlines in the log when openvpn3-service-log starts
      tests: Add --allow-newline to logservice1 send subcommand
      common/cmdargparser: Minor code cleanup in RegisterParsedArgs::register_option()
      common/cmdargparser: Filter out ASCII control characters from command line
      common: Merge and move string ctrl char sanitizing to a shared function
      log: Filter strings coming via D-Bus calls
      sessionmgr/client: Filter reason string to Pause D-Bus method call
      common: Filter input value to RequiresQueue::UpdateEntry()
      tests/request-queue: Remove unused local function
      configmgr/test: Add tests for control chars in various configuration profiles
      configmgr: Remove control characters from various user input via D-Bus
      netcfg: Remove control characters from the D-Bus method inputs
      log: Add missing cstdint header in logmetadata.hpp
      common: Check if org.freedesktop.hostname1 is available in PlatformInfo
      client: Handle exceptions in ~BackendStarterSrv
      build: Allow version tags to contain dots and minor version digits
      configmgr/proxy: Ignore minor version number in feature check

--------------------------------------------------------------------

Re: [Openvpn-users] Permission Error with systemd

[Stefanie L. (Febas) <ste...@pe...>]

On 5/15/25 16:46, David Sommerseth wrote:
> On 15/05/2025 15:30, Stefanie Leisestreichler (Febas) wrote:
>> On 5/15/25 14:48, David Sommerseth wrote:
> [...snip...]
>>>
>>> Not when starting via systemd.  In this case, when the `User=openvpn` is
>>> set in the service unit file, systemd will drop to that user and set the
>>> requested capabilities before executing the binary in ExecStart=.
>>>
>>> But due to OpenVPN 2.x allowing a lot to happen before it normally drops
>>> privileges, a lot of additional capabilities was needed to grant to it -
>>> otherwise a lot of configurations didn't work as intended.
>>>
>>>
>> So when I get you right user openvpn in combination with systemd has a
>> lot more rights than nobody ever had...
> 
> Not quite so.
> 
> When starting OpenVPN without systemd, it must be started as root to
> have all the needed privileges.  When openvpn has completed the
> initialization, it will drop to the user given in openvpn configuration
> along with lesser set of capabilities.  During this initialization
> phase, the openvpn process has full root access and capabilities.
> 
> When starting OpenVPN with systemd, the openvpn process will be started
> as the openvpn user with a reduced set of capabilities.  The reduced set
> of capabilities is still quite comprehensive, but it is still a bit less
> than when starting directly as root.
> 
> The difference is basically that starting it via systemd, the openvpn
> process and most of the script hooks and plugins will never have the
> full root privileges, even in the early stages.  After the
> initialization phase has completed, the systemd approach will have
> basically the same set of capabilities enabled.  In the source code,
> platform_user_group_set() is the function handling this.
> 
> It should be possible to narrow down the needed capabilities even more
> in the systemd case, but that will require some refactoring to detect it
> being started more restricted and drop the steps of reducing its
> capability set.  And it would need some additional helper service for
> the script hooks to work well without needing to be re-written as well.
> 
> 

Thanks for your time and background info.

Re: [Openvpn-users] Permission Error with systemd

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

On 15/05/2025 15:30, Stefanie Leisestreichler (Febas) wrote:
> On 5/15/25 14:48, David Sommerseth wrote:
[...snip...]
>>
>> Not when starting via systemd.  In this case, when the `User=openvpn` is
>> set in the service unit file, systemd will drop to that user and set the
>> requested capabilities before executing the binary in ExecStart=.
>>
>> But due to OpenVPN 2.x allowing a lot to happen before it normally drops
>> privileges, a lot of additional capabilities was needed to grant to it -
>> otherwise a lot of configurations didn't work as intended.
>>
>>
> So when I get you right user openvpn in combination with systemd has a
> lot more rights than nobody ever had...

Not quite so.

When starting OpenVPN without systemd, it must be started as root to
have all the needed privileges.  When openvpn has completed the
initialization, it will drop to the user given in openvpn configuration
along with lesser set of capabilities.  During this initialization
phase, the openvpn process has full root access and capabilities.

When starting OpenVPN with systemd, the openvpn process will be started
as the openvpn user with a reduced set of capabilities.  The reduced set
of capabilities is still quite comprehensive, but it is still a bit less
than when starting directly as root.

The difference is basically that starting it via systemd, the openvpn
process and most of the script hooks and plugins will never have the
full root privileges, even in the early stages.  After the
initialization phase has completed, the systemd approach will have
basically the same set of capabilities enabled.  In the source code,
platform_user_group_set() is the function handling this.

It should be possible to narrow down the needed capabilities even more
in the systemd case, but that will require some refactoring to detect it
being started more restricted and drop the steps of reducing its
capability set.  And it would need some additional helper service for
the script hooks to work well without needing to be re-written as well.


-- 
kind regards,

David Sommerseth
OpenVPN Inc

Re: [Openvpn-users] Permission Error with systemd

[Stefanie L. (Febas) <ste...@pe...>]

On 5/15/25 14:48, David Sommerseth wrote:
> On 15/05/2025 12:04, Stefanie Leisestreichler (Febas) wrote:
>> On 5/15/25 11:49, David Sommerseth wrote:
>>
>>>
>>> Try to change the owner of the key file from root to openvpn.
>>>
>>> The openvpn-server@.service and openvpn-client@.service units has been
>>> written to lock down and strip the openvpn process from as many
>>> privileges as possible.  Unfortunately, the list of needed privileges is
>>> still fairly long.
>>>
>>>
>> chown will make it running.
>>
>> What I do not understand is: As far as I know, openvpn is started with
>> root rights to build the context for a running instance. If that is
>> true, why can't the key been read during that phase and has to be made
>> available for user openvpn (at least with arch)? Or is my assumption/
>> understanding wrong?
> 
> Not when starting via systemd.  In this case, when the `User=openvpn` is
> set in the service unit file, systemd will drop to that user and set the
> requested capabilities before executing the binary in ExecStart=.
> 
> But due to OpenVPN 2.x allowing a lot to happen before it normally drops
> privileges, a lot of additional capabilities was needed to grant to it -
> otherwise a lot of configurations didn't work as intended.
> 
> 
So when I get you right user openvpn in combination with systemd has a 
lot more rights than nobody ever had...

Re: [Openvpn-users] Permission Error with systemd

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

On 15/05/2025 12:04, Stefanie Leisestreichler (Febas) wrote:
> On 5/15/25 11:49, David Sommerseth wrote:
> 
>>
>> Try to change the owner of the key file from root to openvpn.
>>
>> The openvpn-server@.service and openvpn-client@.service units has been
>> written to lock down and strip the openvpn process from as many
>> privileges as possible.  Unfortunately, the list of needed privileges is
>> still fairly long.
>>
>>
> chown will make it running.
> 
> What I do not understand is: As far as I know, openvpn is started with
> root rights to build the context for a running instance. If that is
> true, why can't the key been read during that phase and has to be made
> available for user openvpn (at least with arch)? Or is my assumption/
> understanding wrong?

Not when starting via systemd.  In this case, when the `User=openvpn` is
set in the service unit file, systemd will drop to that user and set the
requested capabilities before executing the binary in ExecStart=.

But due to OpenVPN 2.x allowing a lot to happen before it normally drops
privileges, a lot of additional capabilities was needed to grant to it -
otherwise a lot of configurations didn't work as intended.


-- 
kind regards,

David Sommerseth
OpenVPN Inc

Re: [Openvpn-users] Permission Error with systemd

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

Hi,

On Thu, May 15, 2025 at 12:04:46PM +0200, Stefanie Leisestreichler (Febas) wrote:
> What I do not understand is: As far as I know, openvpn is started with root
> rights to build the context for a running instance. If that is true, why
> can't the key been read during that phase and has to be made available for
> user openvpn (at least with arch)? Or is my assumption/understanding wrong?

If you run openvpn 2.x as "openvpn --user nobody", it will start as root, 
gather what it needs, and then suids to "nobody".

This seems to be about 3.x, which works differently :-) - and SystemD,
which does everything differently again, so in this case the unit files
will do the user change, and openvpn is started with non-root permissions
-> no access to anything root-owned.

Arguably the second one is the more secure way to do things, as there is
no "still running as root" phase - but it brings much more complications
of course ("how can it then manipulate ifconfig/route/dns?").

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] Permission Error with systemd

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

On 12/05/2025 11:52, Stefanie Leisestreichler (Febas) wrote:
> Hi.
> I have a fresh install of openvpn 3.5.0.8 on arch and try to get
> autostart for systemd working.
> 
> The log is displaying this error:
> Options error: --key fails with 'gateway25.key': Permission denied
> (errno=13)
> Options error: --status fails with '/run/openvpn-server/status-
> gateway25.log': Permission denied (errno=13)
> 
> I do not know special details about when openvpn drops privilegs but I
> get a shiver when there is a need to change perms or ownership for key
> files.
> 
> What do you think/recommend?

Notice this line in the systemd unit file:

     User=openvpn

This indicates that the OpenVPN process is started as the openvpn user.
Your permissions is that only root has read access to the key file.

Try to change the owner of the key file from root to openvpn.

The openvpn-server@.service and openvpn-client@.service units has been
written to lock down and strip the openvpn process from as many
privileges as possible.  Unfortunately, the list of needed privileges is
still fairly long.


-- 
kind regards,

David Sommerseth
OpenVPN Inc

Re: [Openvpn-users] Permission Error with systemd

[Stefanie L. (Febas) <ste...@pe...>]

On 5/15/25 11:49, David Sommerseth wrote:

> 
> Try to change the owner of the key file from root to openvpn.
> 
> The openvpn-server@.service and openvpn-client@.service units has been
> written to lock down and strip the openvpn process from as many
> privileges as possible.  Unfortunately, the list of needed privileges is
> still fairly long.
> 
> 
chown will make it running.

What I do not understand is: As far as I know, openvpn is started with 
root rights to build the context for a running instance. If that is 
true, why can't the key been read during that phase and has to be made 
available for user openvpn (at least with arch)? Or is my 
assumption/understanding wrong?

[Openvpn-users] Permission Error with systemd

[Stefanie L. (Febas) <ste...@pe...>]

Hi.
I have a fresh install of openvpn 3.5.0.8 on arch and try to get 
autostart for systemd working.

The log is displaying this error:
Options error: --key fails with 'gateway25.key': Permission denied 
(errno=13)
Options error: --status fails with 
'/run/openvpn-server/status-gateway25.log': Permission denied (errno=13)

I do not know special details about when openvpn drops privilegs but I 
get a shiver when there is a need to change perms or ownership for key 
files.

What do you think/recommend?

Thanks.

The unit file looks like this:

[Unit]
Description=OpenVPN service for %I
After=network-online.target
Wants=network-online.target
Documentation=man:openvpn(8)
Documentation=https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/
Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO

[Service]
Type=notify
PrivateTmp=true
WorkingDirectory=/etc/openvpn/server
ExecStart=/usr/bin/openvpn --status %t/openvpn-server/status-%i.log 
--status-version 2 --config %i.conf
User=openvpn
Group=network
AmbientCapabilities=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SETPCAP CAP_SYS_CHROOT 
CAP_DAC_OVERRIDE CAP_AUDIT_WRITE
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SETPCAP CAP_SYS_CHROOT 
CAP_DAC_OVERRIDE CAP_AUDIT_WR>
LimitNPROC=10
DeviceAllow=/dev/null rw
DeviceAllow=/dev/net/tun rw
ProtectSystem=true
ProtectHome=true
KillMode=process
RestartSec=5s
Restart=on-failure

[Install]
WantedBy=multi-user.target

File permissions are as followed:
[root@gatway25 /etc/openvpn/server]# ll
insgesamt 24K
drwxr-x--- 2 openvpn network 4,0K 12. Mai 10:32 ./
drwxr-xr-x 4 root    root    4,0K  5. Mai 20:58 ../
-rw-r--r-- 1 root    root     684  9. Mai 19:11 gateway25.crt
-rw------- 1 root    root     306  9. Mai 19:11 gateway25.key
-rw------- 1 root    root     636 11. Mai 21:04 gateway25.ta.key
-rw-r--r-- 1 root    root    2,4K 12. Mai 11:03 gateway25.conf

Re: [Openvpn-users] OpenVPN 2.6.13 released

[Gatsi J. <gat...@gm...>]

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

This is a bugfix release.

Feature changes:

* on non-windows clients (MacOS, Linux, Unix) send "release" string from
uname()
  call as IV_PLAT_VER to server - while highly OS specific this is still
helpful
  to keep track of OS versions used on the client side (github ​#637)
* Windows: protect cached username, password and token in client memory
(using
  the CryptProtectMemory() windows API)
* Windows: use new API to get dco-win driver version from driver (newly
introduced
  non-exclusive control device) (github ​ovpn-dco-win#76)
* Linux: pass --timeout=0 argument to systemd-ask-password, to avoid
default timeout
  of 90 seconds ("console prompting also has no timeout") (github ​#649)

Security fixes:

* improve server-side handling of clients sending usernames or passwords
longer than
  USER_PASS_LEN - this would not result in a crash, buffer overflow or
other security
  issues, but the server would then misparse incoming IV variables and
produce
  misleading error messages.

Notable bug fixes:

* FreeBSD DCO: fix memory leaks in nvlist handling (github ​#636)
* purge proxy authentication credentials from memory after use
  (if --auth-nocache is in use)

Windows MSI changes since 2.6.12:

* Built against OpenSSL 3.4.0
* Included openvpn-gui updated to 11.51.0.0
  * Higher resolution eye icons (github ​openvpn-gui#697)
  * Support for concatenating OTP with password
  * Optionally always prompt for OTP
  * Fix tooltip positioning when the taskbar is at top (github
​openvpn-gui#710)

Debian/Ubuntu community packages are now available for Ubuntu 24.10
(oracular).

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-downloads/>

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/dsommers/openvpn-release-2.6/>

Kind regards,

--
  Frank Lichtenheld

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

On Thu, Jan 16, 2025, 7:22 PM Frank Lichtenheld <fr...@li...>
wrote:

> The OpenVPN community project team is proud to release OpenVPN 2.6.13.
>
> This is a bugfix release.
>
> Feature changes:
>
> * on non-windows clients (MacOS, Linux, Unix) send "release" string from
> uname()
>   call as IV_PLAT_VER to server - while highly OS specific this is still
> helpful
>   to keep track of OS versions used on the client side (github ​#637)
> * Windows: protect cached username, password and token in client memory
> (using
>   the CryptProtectMemory() windows API)
> * Windows: use new API to get dco-win driver version from driver (newly
> introduced
>   non-exclusive control device) (github ​ovpn-dco-win#76)
> * Linux: pass --timeout=0 argument to systemd-ask-password, to avoid
> default timeout
>   of 90 seconds ("console prompting also has no timeout") (github ​#649)
>
> Security fixes:
>
> * improve server-side handling of clients sending usernames or passwords
> longer than
>   USER_PASS_LEN - this would not result in a crash, buffer overflow or
> other security
>   issues, but the server would then misparse incoming IV variables and
> produce
>   misleading error messages.
>
> Notable bug fixes:
>
> * FreeBSD DCO: fix memory leaks in nvlist handling (github ​#636)
> * purge proxy authentication credentials from memory after use
>   (if --auth-nocache is in use)
>
> Windows MSI changes since 2.6.12:
>
> * Built against OpenSSL 3.4.0
> * Included openvpn-gui updated to 11.51.0.0
>   * Higher resolution eye icons (github ​openvpn-gui#697)
>   * Support for concatenating OTP with password
>   * Optionally always prompt for OTP
>   * Fix tooltip positioning when the taskbar is at top (github
> ​openvpn-gui#710)
>
> Debian/Ubuntu community packages are now available for Ubuntu 24.10
> (oracular).
>
> 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-downloads/>
>
> 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/dsommers/openvpn-release-2.6/>
>
> Kind regards,
> --
>   Frank Lichtenheld
>
>
> _______________________________________________
> Openvpn-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
>