openvpn-users — OpenVPN users list

[Openvpn-users] What is UNDEF user?

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

Hello,
When I checked the server log I saw a user named UNDEF:

ROUTING TABLE Virtual Address,Common Name,Real Address,Last Ref
10.10.0.11,User1,X.X.X.X:53346,2025-08-03 19:30:27
10.10.0.6,User2,X.X.X.X:54894,2025-08-03 19:30:35
10.10.0.14,User3,X.X.X.X:65400,2025-08-03 19:30:26
10.10.0.5,UNDEF,X.X.X.X:51162,2025-08-03 19:30:35
GLOBAL STATS
Max bcast/mcast queue length,0
END

I don't have such a user on the server. What is it?

Thank you.

[Openvpn-users] ERR_NAME_NOT_RESOLVED

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

Hello,
I have combined OpenVPN with Tor and when clients connect to the OpenVPN server, their connection is routed into the Tor network.

The Tor configuration is:

RunAsDaemon 1
DataDirectory /var/lib/tor_OpenVPN
MaxCircuitDirtiness 3600
VirtualAddrNetwork 10.192.0.0/10
AutomapHostsOnResolve 1
DNSPort 10.10.0.1:53530
TransPort 10.10.0.1:9040


And The OpenVPN configuration is:


port 2024
proto udp
dev tun2

ca /.../ca.crt
cert /.../Employee_Server.crt
key /.../Employee_Server.key
dh /.../dh.pem

server 10.10.0.0 255.255.255.0               

push "redirect-gateway def1 bypass-dhcp"

push "dhcp-option DNS 10.10.0.1"

push "route 10.10.0.1 255.255.255.255"
push "block-outside-dns"

topology subnet

keepalive 10 120
tls-crypt /etc/openvpn/server/Employee/ta.key 0

cipher AES-256-GCM
data-ciphers AES-256-GCM
user nobody
group nogroup
persist-key
persist-tun
verb 3
explicit-exit-notify 1


The iptables is:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:f2b-sshd - [0:0]

# Allow loopback
-A INPUT -i lo -j ACCEPT

# Allow ICMP (ping) with rate limiting
-A INPUT -p icmp --icmp-type 8 -m limit --limit 2/sec -j ACCEPT
-A INPUT -p icmp --icmp-type 8 -j DROP
-A INPUT -p icmp -j ACCEPT

# Allow established connections
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# OpenVPN and Tor ports
-A INPUT -p udp --dport 2024 -j ACCEPT
-A INPUT -p tcp --dport 9050 -j ACCEPT
-A INPUT -p tcp --dport 1337 -j ACCEPT

# Allow VPN clients to access Tor
-A INPUT -s 10.10.0.0/24 -i tun2 -p udp --dport 53530 -j ACCEPT
-A INPUT -s 10.10.0.0/24 -i tun2 -p tcp --dport 9040 -j ACCEPT

# Allow new VPN connections
-A INPUT -s 10.10.0.0/24 -i tun2 -m state --state NEW -j ACCEPT

# Fail2ban rule
-A INPUT -p tcp --dport 1337 -j f2b-sshd

# Forwarding rules
-A FORWARD -i enX1 -o tun2 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.10.0.0/24 -o enX1 -j ACCEPT
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]

# Redirect DNS to Tor
-A PREROUTING -s 10.10.0.0/24 -i tun2 -p udp --dport 53 -j DNAT --to-destination 10.10.0.1:53530

# Redirect all other traffic to Tor
-A PREROUTING -s 10.10.0.0/24 -i tun2 -p tcp -j DNAT --to-destination 10.10.0.1:9040
-A PREROUTING -s 10.10.0.0/24 -i tun2 -p udp -j DNAT --to-destination 10.10.0.1:9040

# Masquerade VPN traffic
-A POSTROUTING -s 10.10.0.0/24 -o enX1 -j MASQUERADE
COMMIT


The problem is that the speed is extremely slow and some apps like Telegram keep disconnecting. Where is the problem in the configuration?


Thank you.

[Openvpn-users] OpenVPN 2.7_alpha3 released

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

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

Feature changes since 2.7_alpha2:

* --dns-updown script for macOS
* Client-side support for PUSH_UPDATE handling
* Support for floating TLS clients when DCO is active
  (requires latest versions of DCO drivers)
* Use of user-defined routing tables on Linux
* PQE support for WolfSSL

Important bug fixes since 2.7_alpha2:

* Fix issue in handling DCO messages on Linux that could lead to
  various problems due to unhandled messages
* Fix issues with DHCP on Windows with tap driver

Highlights of 2.7 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.
* Client-side support for new PUSH_UPDATE control-channel message
  This allows servers to send updates to options like routing and DNS config without
  triggering a reconnect.
* 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://community.openvpn.net/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

Re: [Openvpn-users] WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1500'

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

Hi,

On Thu, Jul 24, 2025 at 08:38:44AM +0200, Marc SCHAEFER wrote:
>    WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1500'
[..]
> Any idea why this happens, or should I just ignore this warning?

Just ignore the warning.  As long as all interfaces end up with the same
configured MTU, things are working.

These option warnings do not work very well across major versions (2.5
to 2.6) - I think, in this case, because we actually *fixed* the reporting
in the "OCC" handshake ("OpenVPN Config Check"), but 2.5 is still using
"something plus some guesswork" to arrive at "1532".

You can try to set "occ-mtu 1532" on the server to silence 2.5 :-)

              The OCC MTU can be used to avoid warnings about mismatched MTU
              from clients. If occ-mtu is not specified, it will to default to
              the tun-mtu.

... workarounds for old code, old versions, long history...  (and we can't
"just remove" an option from the OCC string, because then the clients would
complain "warning: 'tun-mtu' configured locally and missing on remote" or so)

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] WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1500'

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

Hello,

An OpenVPN 2.6 server is connected to multiple OpenVPN 2.5 clients.

On the clients, a warning happens regularly:

   WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1500'

There is no tun-mtu config neither on the server nor on the clients.  There is
however a `mssfix 1200' on the server.

tap interface is used (also because there is some L2 magic involved), not tun.
All tap0 interfaces on the clients and servers have a 1500 MTU.

The connect script pushes routes but no MTU config on the clients.

Searching a bit in the doc might me think, especially since MTU > 1500 is not
possible on our configuration, that it could be the --tun-mtu-extra 32 default
settings (involving I/O buffers and not really MTU)?

Any idea why this happens, or should I just ignore this warning?

Thank you for any pointers!

Re: [Openvpn-users] Monitoring client traffic

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

Through the VPN?  If not then you're asking the wrong group.

If through the VPN, keep in mind that, unless you force all traffic to go through the VPN once a client connects, you have no control over how they get to the web.  And even if you attempt to do this, if the client has enough technical skill, they can circumvent it.

Second point, you have unencrypted traffic at the OpenVPN server (the web traffic can't go out OpenVPN-encrypted to a web server).  However, doing what you want is non-trivial.  Unless you can find a package which can monitor traffic and filter for http or https (assuming a web site hasn't set up a different port for access) you're going to need more sophisticated firewall rules.  Something like "if source IP address is 'the client' and destination port is either 80 or 443 and 'who knows what else' (so that you don't capture all web traffic)".  This assumes the client always uses the same source IP address.  Hopefully this makes the point that, without a specialized package, you're signing up for an enormous (if even possible) task.

If someone knows an elegant solution I'd be very interested to hear about all possibilities.

If you're trying to block "illegitimate" web access (and this is only a wild guess) probably the better approach is to find a blacklisting tool that tracks "evil" website identities and can block them.  However, even this is problematic because their "list" or "criteria" for defining what to block has to be maintained and probably will never be complete.


On Tuesday, July 22, 2025 at 01:13:42 PM CDT, Peter Davis via Openvpn-users <ope...@li...> wrote: 





Hello,
How can I find out which websites a client has visited? Does this require traffic decryption?

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

[Openvpn-users] Monitoring client traffic

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

Hello,
How can I find out which websites a client has visited? Does this require traffic decryption?

Thank you.

[Openvpn-users] OpenVPN 3 Linux v25 released

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

OpenVPN 3 Linux v25 (Stable release)

The v25 release provides three new features and several enhancements
since the previous release.

Please notice the deprecation of openvpn3-autoload.

* Feature: Live route updates (PUSH_UPDATE) support
   When connecting to OpenVPN servers capable of pushing new
   network configurations, such as new network routes, the
   OpenVPN 3 Linux client will now update the current VPN
   network setup, including DNS, and replace it with the previous
   configuration without triggering a reconnect to the server.

* Feature: Automatic restart of VPN client processes disappearing
   When configured, the OpenVPN 3 Linux Session Manager service
   will now detect if a VPN process unexpectedly disappears and
   will attempt to restart it automatically.
   See the --automatic-restart option in the openvpn3 config-manage
   man page for further details.  This feature is disabled by
   default.

* Feature: AWS VPC integration can now use named routing tables
   When the "route-table-name" setting is configured in the
   OpenVPN 3 AWS Integration add-on, this add-on will perform a
   lookup for this AWS VPC routing table and apply the routes here.
   If this table is not to be found, the add-on will create it
   on-the-fly as needed.

* FEATURE DEPRECATION: openvpn3-autoload
   The openvpn3-autoload feature was deprecated already in the
   v20 release.  This feature will be removed in a coming stable
   release.
   The replacement is the openvpn3-session@.service systemd unit.
   Please see the openvpn3-systemd man page [1] for more details.
   If you depend on openvpn3-autoload today, please migrate ASAP
   to the systemd approach.
   [1] 
<https://codeberg.org/OpenVPN/openvpn3-linux/src/branch/master/docs/man/openvpn3-systemd.8.rst>

* Improvement: Better error messages for SSL/TLS issues
   The openvpn3 command will now provide more details on SSL/TLS
   related issues, due to enhancements in the update OpenVPN 3
   Core Library.

* Improvement: openvpn3-admin journal shows correct time
   It has been an open issue for a long time where time zone
   and the local DST state resulted in the openvpn3-admin journal
   command presenting the wrong time in the log events.  This
   has been resolved by the conversion taking the current time zone
   and DST state into consideration.

* Improvement: A more resilient systemd-resolved integration
   The prior systemd-resolved integration could in many cases
   fail to properly configure the DNS resolver settings.  This
   was often due to the systemd-resolved service responding slower
   than expected.  This could in the most sever situations result
   in the VPN session failing to properly start.
   This has been improved by doing all the calls to systemd-resolved
   in the background, allowing the VPN session to be properly
   connected while the systemd-resolved integration will be more
   persistent in allowing the low-level D-Bus calls to complete
   independently of the main VPN session itself.

* OpenVPN 3 Core Library update
   The OpenVPN 3 Core Library has been updated to version 3.11.3,
   which also provide new features such as Epoch Data Keys support,
   Live route updates (PUSH_UPDATE), improved events on TLS alerts,
   support for more pushed routes, improved --dns and --dhcp-option
   parsing.


Known issues:

   - The openvpn3-service-netcfg service does not differentiate
     between --dns server X resolve-domains and --dns search-domains
     when using the --resolv-conf mode, which is not as this feature
     is intended to work.  This was discovered in the v24 release
     and is on the schedule to be fixed in the next releases.  When
     this gets fixed, only --dns search-domains will be considered
     as search domains and --dns server X resolve-domains will
     enable split-DNS when using --systemd-resolved and otherwise
     ignored when using --resolv-conf with openvpn3-service-netcfg.


Credits
-------

Thanks goes to those continuing testing and reporting issues. In
particular Razvan Cojocaru, Marc Leeman, Fabio Pedretti, Lev
Stipakov, Leonard Ossa, Yuriy Darnobyt, Oleh Salnikov and Nazar
Vasiuchyn, Brandon Jimenez and Gabriel Palmar for contributing
and improving this release through code changes, documentation,
reviewing, testing and making the finished packages available to
us all.


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

   - Debian: 12
   - Fedora: 41, 42
   - Red Hat Enterprise Linux 8, 9, 10[*]
   - Ubuntu: 22.04, 24.04, 25.05

Installation and getting started instructions can be found here:

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

There are in addition other Linux distributions now providing
OpenVPN 3 Linux packages.  These distributions are primarily
supported by their respective distribution communities.  We will
naturally review and apply fixes deemed needed for any other
distributions as they occur.

NOTE: Red Hat Enterprise Linux 10
   The Fedora Copr repository definition for RHEL+EPEL-10 *may*
   use a wrong URL.  After doing the 'dnf copr enable' step
   on RHEL-10, please ensure the URL contains 'rhel+epel' and
   not just 'epel'.  This is expected to automatically improve
   after a bit.
   The stable repositories provided by OpenVPN Inc should not
   have this issue.

--
kind regards,

Yuriy Darnobyt
OpenVPN Inc


---- Source tarballs ---------------------------------------------------
* OpenVPN 3 Linux v25

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

* GDBus++ v3

<https://swupdate.openvpn.net/community/releases/gdbuspp-3.tar.xz>
<https://swupdate.openvpn.net/community/releases/gdbuspp-3.tar.xz.asc>

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

efccb7958fefcea4e03a9b96e5391c87c7f55bb28ae36782e41e22f7ff6d15b5 
  openvpn3-linux-25.tar.xz
2ee1f653b8f5d7062d92120a7daa56f97f532e9d4098a56e4dc5a6a616a7e5d0 
  openvpn3-linux-25.tar.xz.asc
c7a053a13c4eb5811a542b747d5fcdb3a8e58a4a42c7237cc5e2e2ca72e0c94e 
  gdbuspp-3.tar.xz
b9cf732d7a347f324d6a5532dc48f80c2815dbf6704c169b4ee97a411506a99b 
  gdbuspp-3.tar.xz.asc

---- 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: v25
    git commit: f68cacc65bbb5b706de1fee987304e810ed9d3a0

  - GDBus++
<https://codeberg.org/OpenVPN/gdbuspp/>       (PRIMARY)
<https://gitlab.com/openvpn/gdbuspp/>         (code-only mirror)
<https://github.com/openvpn/gdbuspp/>         (code-only mirror)

    git tag: v3
    git commit: 96f7fb688ed2dea3f192c63c5fe283dbe4900f16

---- Changes from v24 to v25 ---------------------------------------

David Sommerseth (79):
       spelling: Fix various spelling mistakes
       build: Fix incorrect default value assignment for create_statedir 
option
       common: Check if org.freedesktop.hostname1 is available in 
PlatformInfo
       client: Handle exceptions in ~BackendStarterSrv
       tests: Only build journal-log-parse if systemd is present
       netcfg/resolved: Remove no longer needed service check
       configmgr: Catch SetOverride issues at JSON config import
       ovpn3cli: Improve session-start details on successful connection
       configmgr/proxy: Improve error message on SetOverride() failures
       tests: Improve config-override-selftest failure situations
       ovpn3cli/admin: Improve sessionmgr-service verose session list
       core: Update to OpenVPN 3 Core 3.11 QA/stabilization branch
       ovpn3cli/init-config: Add --debug argument
       sessionmgr: Minor log verbosity changes in the session 
auto-restart feature
       build: Misc cleanup in Meson build scripts
       client: Refactor D-Bus initialization during process start
       configmgr/docs: Update man page for the --automatic-restart feature
       netcfg: Refactor D-Bus initialization during process start
       netcfg: Extend NetCfgOptions to handle log settings
       netcfg: Remove the "default log level" passing
       netcfg: Use logging settings from NetCfgOptions
       netcfg: Remove support for --signal-broadcast
       netcfg: Remove unused NetCfgService member - srv_obj
       core: Update to final OpenVPN 3 Core Library v3.11
       sessionmgr: Ignore Detach() exceptions in SessionManager::~Service()
       docs: Update build dependencies in BUILD.md
       log: Add missing cstdint header in logmetadata.hpp
       sessionmgr: Use Events::Status::operator<<() for tunnel restart info
       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
       netcfg/resolved: Add internal error message storage to proxy code
       netcfg/resolved: Implement base features for background async calls
       netcfg/resolved: Switch serveral D-Bus calls to async background 
calls
       netcfg/resolved: Handle errors from background D-Bus calls
       netcfg/resolved: Retry if systemd-resolved background calls times out
       core: Upgrade to OpenVPN 3 Core v3.11.1
       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
       python: Add FAT DEPRECATION WARNING in openvpn3-autoload
       build: Allow version tags to contain dots and minor version digits
       configmgr/proxy: Ignore minor version number in feature check
       tests: Upgrade to googletest-1.17.0-1
       docs/man: Minor language improvements to the 
openvpn3-service-aws.8 man page
       addon/aws: Prepare for bumping the required C++ standard version 
to C++20
       log/journald: Fix wrong timezone/dst handling in journald filter
       log/journald: Refactor log event sending with better error handling
       netcfg: Read the config file before parsing options
       netcfg/proxy: Kick out Device::RemoveDNS() and 
Device::RemoveDNSSearch()
       core: Update to OpenVPN 3 Core Library v3.11.2
       core: Update to OpenVPN 3 Core Library v3.11.3
       log: Extend CoreLog with a more flexible log prefix
       build: Avoid including build-config.h in header files
       netcfg/dns/systemd-resolved: Provide alternative logging 
framework when the signal APIs are unavailable
       netcfg/dns/systemd-resolved: Ensure the GVariant objects used in 
background D-Bus calls are freed correctly
       netcfg/dns/systemd-resolved: Ensure the ASIO background worker 
thread always runs
       netcfg/dns/systemd-resolved: Rework the 
resolved::Link::BackgroundCall() implementation
       client: Ensure DNS domains pushed via --dhcp-option will not 
enable split-DNS
       netcfg/dns/resolved: Avoid race condition in BackgroundCall()
       client/netcfg: Restore --dns-setup-disabled functionality
Fabio Pedretti (1):
       spelling: Fix systemd-resolved spelling
Lev Stipakov (1):
       addons/aws: Implement support for additional route table
Marc Leeman (1):
       build: Fix incorrect OPENVPN_USERNAME in D-Bus autostart files
Razvan Cojocaru (13):
       configmgr: Fix idle-exit comment
       signals: Allow signal re-subscription
       sessionmgr: Expose the method_ready() and method_connect() logic
       sessionmgr: Allow a Session object to re-associate with a backend 
process
       sessionmgr: Add current backend bus name and last event accessors
       sessionmgr: Restart prematurely stopped backend processes
       sessionmgr: Only retry to restart backend process a limited 
number of times
       sessionmgr: Don't always try to restart a crashed backend process
       Remove superfluous try block
       sessionmgr: Reset the log forwarders on client process restart
       netcfg: Clean up network setup for crashed client processes
       sessionmgr: Reset the client process restart timer after a while
       build: Prepare for bumping the required C++ standard version to C++20
--------------------------------------------------------------------

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.