openvpn-users — OpenVPN users list

[Openvpn-users] OpenVPN 2.6.20 released

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

The OpenVPN community project team is proud to release OpenVPN 2.6.20. This is a bugfix release containing security fixes.

For details see [Changes.rst](https://github.com/OpenVPN/openvpn/blob/v2.6.20/Changes.rst)

Security fixes:

* CVE-2026-40215: fix race condition in TLS handshake that could lead to leaking of
  packet data from a previous handshake under specific circumstances
* CVE-2026-35058: fix server ASSERT() on receiving a suitably malformed packet with
  a valid tls-crypt-v2 key
  
Bugfixes:

* management: stop periodic bytecount output on mgmt client disconnection
* FreeBSD: make DCO work on systems with no IPv4 support
* FreeBSD: fix compilation with --enable-async-push on FreeBSD 15
* Linux: make DCO work on big endian architectures (MIPS, PowerPC)
* Windows: fix deinstallation progress bar on adapter deletion.
* Linux: fix problem with DCO kernel notifications getting lost, leading
  to overcounting of number of connected clients and general confusion
  between kernel and userland regarding peer status (Github openvpn#900,
  openvpn#918, openvpn#931, openvpn#919, openvpn#945) - this is a backport of
  the fixes in 2.7 plus the infrastructural changes around DCO needed to support it.

Windows MSI changes since 2.6.19-I001:
* Built against OpenSSL 3.6.2
* Included openvpn-gui updated to 11.63.0.0
  * Translation cleanup. Remove obsolete strings related to support for OpenVPN < 2.0
  * Translation updates.

More details can be found in the Changes document:

<https://github.com/OpenVPN/openvpn/blob/v2.6.20/Changes.rst <https://github.com/OpenVPN/openvpn/blob/v2./Changes.rst>>

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

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

Packages for Debian, Ubuntu, Fedora, RHEL, and openSUSE are available in the various
official Community repositories:

<https://community.openvpn.net/Pages/OpenVPN%20software%20repos>

Kind regards,
Yuriy Darnobyt

[Openvpn-users] OpenVPN 2.7.2 released

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

The OpenVPN community project team is proud to release OpenVPN 2.7.2.
This is a bugfix release containing security fixes.


Security fixes:

* CVE-2026-40215: fix race condition in TLS handshake that could lead to leaking of
  packet data from a previous handshake under specific circumstances
* CVE-2026-35058: fix server ASSERT() on receiving a suitably malformed packet with
  a valid tls-crypt-v2 key

New features:

* management interface: permit input of very long passwords in
  base64-encoded multiline format.  Signal support to management
  clients via "management version 6".

User-visible Changes:

* improve error messages on ``--verify-x509-name`` failures
* improve error logging when overlong username or passwords can not
  be written to TLS buffer

Bugfixes:

* when using a config file with inlined username and no password,
  fix prompting for the password from management interface.
* Windows: fix DNSSEC flag handling - this got never applied due to
  a bad comparison being always false.
* Windows: fix deinstallation progress bar on adapter deletion.

Windows MSI changes since 2.7.1:
* Built against OpenSSL 3.6.2
* Included openvpn-gui updated to 11.63.0.0
  * Translation cleanup. Remove obsolete strings related to support for OpenVPN < 2.0
  * Translation updates.

More details can be found in the Changes document:

<https://github.com/OpenVPN/openvpn/blob/v2.7.2/Changes.rst <https://github.com/OpenVPN/openvpn/blob/v2.7./Changes.rst>>

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

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

Packages for Debian, Ubuntu, Fedora, RHEL, and openSUSE are available in the various
official Community repositories:

<https://community.openvpn.net/Pages/OpenVPN%20software%20repos>

[Openvpn-users] OpenVPN 2.7.1 released

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

The OpenVPN community project team is proud to release OpenVPN 2.7.1.
This is a bug fix release.

New features:

* Add a new username-only flag argument to --auth-user-pass which will now make 
  OpenVPN only query for username and send a dummy password to the server. This is 
  only useful if auth schemes are used on the server side that will do some sort of 
  external challenge base on username, and not password authentication. See 
  discussion in GH OpenVPN/openvpn#501 (starting Jan 30, 2024).
* Increase default sizing of internal hash maps to 4 * --max-clients. The default 
  used to be 256 with a --max-clients default of 1024 - this is bad for 
  performance, while the memory savings are minimal. On a very memory constrained 
  system, reduce --max-clients.

User-visible Changes:

* When compiled with the AWS-LC SSL library, using --tls-cert-profile will now 
  print a run-time warning - the library does not support it, so it would silently do 
  nothing.
* Systemd unit files: change LimitNPROC to TasksMax and increase limit (GH: 
  OpenVPN/openvpn#929)
* Documentation improvements.
* port-share: log incoming connections at verb 3, not on error level anymore (GH: 
  OpenVPN/openvpn#976).

Bugfixes:

* Fix usage of --lport inside a <connection> block - this got broken with the 
  multi-socket patchset (GH: OpenVPN/openvpn#995)
* Do not try to run auto-pam unit test when cross-compiling.
* Do not break private-key passphrases of length >= 64 (GH: OpenVPN/openvpn#993)
* Fix obscure ASSERT() crash on TCP connects with TAP and no ip config.
* Make DCO work on FreeBSD systems that have no IPv4 support in kernel (FreeBSD 
  PR 286263)
* Make DCO work on Linux on big endian (namely, MIPS and PowerPC)
  (GH: OpenVPN/ovpn-dco#96)
* Fixup responses to management interface version command (for >= 4)
* Make --enable-async-push work on FreeBSD 15 (which has native
  inotify support, and consequently no libinotify.pc anymore)
* Adjust some code parts to new "const" handling on string function
  returns (ISO C23, as implemented by glibc 2.43 and newer).

Windows MSI changes since 2.7.1:

* Make sure that included openvpnserv2.exe is signed
  (GH: OpenVPN/openvpn-build#1293)
* Included openvpn-gui updated to 11.62.0.0
  * Translation updates

More details can be found in the Changes document:

<https://github.com/OpenVPN/openvpn/blob/v2.7.1/Changes.rst>

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

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

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,
-- 
  Frank Lichtenheld

[Openvpn-users] Starting a particular configuration at the command prompt

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

Using systemctl allows specifying the configuration with openvpn@<config>.  Although 'service' on Linux should also allow specifying a configuration, testing on Ubuntu 24 isn't working using "service openvpn start <conf file without the ".conf" extension).
Is there a way on Windows to specify which configuration to use when using "net start <openvpn service name>"?
Thanks for your help.

Re: [Openvpn-users] server: listening on two ports at the same time

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

Hi,

On Fri, Mar 20, 2026 at 01:35:40PM +0000, André via Openvpn-users wrote:
> sslh to the rescue ?
> 
> https://github.com/yrutschle/sslh

Thanks for reminding me.  I had seen this project some years in the
past, but forgotten about it.

Indeed, this might solve the original poster's problem - run all these
services unmodified on tcp/443 :-)

(It will not help with firewalls on the way that look really deep into
the tcp/443 stream and block OpenVPN "because it's not smelling like 
https TLS" - but these are not very common)

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] server: listening on two ports at the same time

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

Hi,

On Thu, Mar 19, 2026 at 06:30:53PM +0100, Jochen Bern wrote:
> I'd like to disagree with Gert and Jans "nobody's done it yet" statements
> for the TCP variant, too:
> 
> https://www.nocrew.org/software/httptunnel.html

I wasn't saying "nobody has done tunneling of things over http or ssl or
https yet".  Or DNS, for that matter.

I was saying "nobody has implement https proxy support *in OpenVPN* yet"
("openvpn --https-proxy myhomeserver:443 --remote myhomeserver:1194").

This is not "technologically hard" ("nobody could ever do this"), but
it might not be fully trivial to get done in OpenVPN.  Much of the code
expects a client socket to be "a socket", not "an openssl interface"
(so maybe another way could be to approach this by having an external
program deal with the https proxying, and interface to it using a
socketpair).  Someone who wants this needs to look into the sources and
see how complicated it is, and then discuss implementation strategies
with the dev team.

I won't invest time into this - if I want an OpenVPN server run on port
443, I run an OpenVPN server on Port 443 :-) (next to the OpenSSH server
on port 443).  IPv6 gives me sufficient IP addresses to sidestep the need
to run multiple services on the same IP+443.  (If it turns out I'm stuck
in an IPv4 environment and my LTE hotspot isn't working either, I have
OpenVPN on udp/53 and SSH on tcp/443, which usually is good enough to
get me out)

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] server: listening on two ports at the same time

[André <pip...@pr...>]

sslh to the rescue ?

https://github.com/yrutschle/sslh






Sent with Proton Mail secure email.

On Wednesday, March 18th, 2026 at 11:57 PM, Greg Troxel <gd...@le...> wrote:

> I have long wanted to listen on two ports, one UDP and one (different)
> TCP, so that clients could have a better chance of connecting
> 
> I find that many wifi networks block lots of things, including 1194/udp.
> Apparently the people who configure firewalls think people using
> facebook etc. is ok, and nerd protocols like openvpn, xmpp and matrix
> are harmful, so it seems best to blend in :-(
> 
> 
> I saw in the 2.7.0 release notes one could do this, but couldn't figure
> it out.   Finally I found this blog post:
> 
>   https://www.willifix.net/blog/openvpn-2-7-multisocket-howto
> 
> which says that instead of "udp" and "port 1194" in the config, one
> should instead have (with my changing the tcp port to be different):
> 
>   local 0.0.0.0 1200 udp
>   local 0.0.0.0 1300 tcp
> 
> I have a configuration with a specific listen address, and different
> ports on udp and tcp, and it seems to work.
> 
> 
> (It would be great if someone could do a blog post or docs change to
> explain how to configure nginx to function as a proxy to reach an
> openvpn server on the same host, so that the connection from the client
> to the server would just be on 443/tcp.   Critically, this should work
> without interfering with the web server, so no remapping /.)
> 
> 
> 
> _______________________________________________
> Openvpn-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
> 

Re: [Openvpn-users] server: listening on two ports at the same time

[<J.W...@mi...>]

Hi Gert,
You wrote: "...but nobody really felt like implementing it..."

It isn't implemented native to openvpn, but can be obtained through stunnel.

http-encapsulation seems like a solution of days long gone by, when most web0traffic used http.
Nowadays, most webtraffic is https.


-----Original Message-----
From: Gert Doering <ge...@gr...>
Sent: donderdag 19 maart 2026 15:35
To: Greg Troxel <gd...@le...>
Cc: ope...@li...
Subject: Re: [Openvpn-users] server: listening on two ports at the same time

Hi,

On Thu, Mar 19, 2026 at 10:12:53AM -0400, Greg Troxel wrote:
> I would also like the TLS connection from openvpn to appear to any
> networks in between just like web traffic, at least until you look at
> timing and data sizes.  I am finding that many wifi networks
> purportedly for customer convenience at businesses are blocking openvpn's udp/1194.

OpenVPN TCP is not "looks like web traffic TLS" and will never be.

The feature request to "run openvpn via a https proxy" has been voiced here and there, but nobody really felt like implementing it.

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

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

Re: [Openvpn-users] server: listening on two ports at the same time

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

Am 19.03.26 um 18:11 schrieb Bernhard Schmidt:
> Gert Doering <ge...@gr...> wrote:
>> The feature request to "run openvpn via a https proxy" has been voiced
>> here and there, but nobody really felt like implementing it.
> 
> There is Proxyguard (used widely to tunnel UDP-only Wireguard through
> HTTPS in the EduVPN project)
> 
> https://codeberg.org/eduVPN/proxyguard
> 
> I haven't personally used it, but it is real HTTP (th deployment docs
> talk about using Apache as reverse proxy) and I think the UDP-side is
> not specific to Wireguard at all.

I'd like to disagree with Gert and Jans "nobody's done it yet" 
statements for the TCP variant, too:

https://www.nocrew.org/software/httptunnel.html

Kind regards,
-- 
Jochen Bern
Systemingenieur
Binect GmbH

Re: [Openvpn-users] server: listening on two ports at the same time

[Bernhard S. <be...@bi...>]

Gert Doering <ge...@gr...> wrote:

> On Thu, Mar 19, 2026 at 10:12:53AM -0400, Greg Troxel wrote:
>> I would also like the TLS connection from openvpn to appear to any
>> networks in between just like web traffic, at least until you look at
>> timing and data sizes.  I am finding that many wifi networks purportedly
>> for customer convenience at businesses are blocking openvpn's udp/1194.
>
> OpenVPN TCP is not "looks like web traffic TLS" and will never be.
>
> The feature request to "run openvpn via a https proxy" has been voiced
> here and there, but nobody really felt like implementing it.

There is Proxyguard (used widely to tunnel UDP-only Wireguard through
HTTPS in the EduVPN project)

https://codeberg.org/eduVPN/proxyguard

I haven't personally used it, but it is real HTTP (th deployment docs
talk about using Apache as reverse proxy) and I think the UDP-side is
not specific to Wireguard at all.

Bernhard

Re: [Openvpn-users] server: listening on two ports at the same time

[Jan J. K. <jan...@gm...>]

Hi Greg,

On 19/03/2026 17:32, Greg Troxel wrote:
> Gert Doering<ge...@gr...>  writes:
>
>> On Thu, Mar 19, 2026 at 10:12:53AM -0400, Greg Troxel wrote:
>>> I would also like the TLS connection from openvpn to appear to any
>>> networks in between just like web traffic, at least until you look at
>>> timing and data sizes.  I am finding that many wifi networks purportedly
>>> for customer convenience at businesses are blocking openvpn's udp/1194.
>> OpenVPN TCP is not "looks like web traffic TLS" and will never be.
> Thanks.  My wording was not careful enough.   I did not mean to ask to
> change the normal mode.   I was expressing that for me, one of the main
> uses is to be able to use a network when various things are blocked, and
> that I am frequently encountering not just filtering of 1194/udp, but
> apparently everything except 80/443.
>
> I would like to have a vpn server on machines that are already running
> nginx on 443.
>
> So therefore it would be nice if openvpn had a mode where it could
> connect via an nginx reverse proxy somehow, that did not demand a
> particular place in the web namespace, or to be primary on the port.
>
>> The feature request to "run openvpn via a https proxy" has been voiced
>> here and there, but nobody really felt like implementing it.
> Are you simply saying "nobody's done it yet" or is there some kind of
> philosophical or other objection to adding things  like that, for
> getting around blocking?
>
> Sooner or later I will be able to report back on how openvpn on just 443
> works in blocked networks.  I checked my notes and of 5 fairly-blocked
> networks, 4 of them blocked 1194/udp, and those 4 also blocked
> submission, imaps, xmpp, and Tor (over 443!).
>
>
the only way to technically achieve what you want (connect to openvpn 
via an https (nginx) connection) is if someone implements, as Gert says 
"run openvpn via a https proxy" .  And yes, it is just a matter of 
"nobody's done it yet".  A couple of years ago, when I had more time to 
involve myself with OpenVPN, I looked at it and decided it was 
non-trivial to implement in the codebase at that time.

JM2CW,

JJK

Re: [Openvpn-users] server: listening on two ports at the same time

[Greg T. <gd...@le...>]

Jochen Bern <Joc...@bi...> writes:

> I suppose that one could configure nginx so as to offer a
> password(?)-protected HTTP CONNECT to the OpenVPN server, and tell the
> client-side OpenVPN to use that as a proxy.

That is sort of what I was thinking, but was hoping someone had already
worked this out and posted how to do it.

> *Or* you could use --bind to make the client use a specific *source*
>  port, hoping that it won't get SNATed away on the Internet uplink,
>  and use that "identifier" and iptables rules so as to have "home
>  base" DNAT the connection to the OpenVPN server instead of the nginx

My belief is that source ports will rarely survive, especially on the
kinds of networks where you need to get around blocking.

Re: [Openvpn-users] server: listening on two ports at the same time

[Greg T. <gd...@le...>]

Gert Doering <ge...@gr...> writes:

> On Thu, Mar 19, 2026 at 10:12:53AM -0400, Greg Troxel wrote:
>> I would also like the TLS connection from openvpn to appear to any
>> networks in between just like web traffic, at least until you look at
>> timing and data sizes.  I am finding that many wifi networks purportedly
>> for customer convenience at businesses are blocking openvpn's udp/1194.
>
> OpenVPN TCP is not "looks like web traffic TLS" and will never be.

Thanks.  My wording was not careful enough.   I did not mean to ask to
change the normal mode.   I was expressing that for me, one of the main
uses is to be able to use a network when various things are blocked, and
that I am frequently encountering not just filtering of 1194/udp, but
apparently everything except 80/443.

I would like to have a vpn server on machines that are already running
nginx on 443.

So therefore it would be nice if openvpn had a mode where it could
connect via an nginx reverse proxy somehow, that did not demand a
particular place in the web namespace, or to be primary on the port.

> The feature request to "run openvpn via a https proxy" has been voiced
> here and there, but nobody really felt like implementing it.

Are you simply saying "nobody's done it yet" or is there some kind of
philosophical or other objection to adding things  like that, for
getting around blocking?

Sooner or later I will be able to report back on how openvpn on just 443
works in blocked networks.  I checked my notes and of 5 fairly-blocked
networks, 4 of them blocked 1194/udp, and those 4 also blocked
submission, imaps, xmpp, and Tor (over 443!).

Re: [Openvpn-users] server: listening on two ports at the same time

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

Am 19.03.26 um 15:12 schrieb Greg Troxel:
> It would be nice if openvpn's TCP support could somehow be over https
> and a prefix within the webroot (or vhost, if it must be).   I think I'm
> asking for "openvpn over https" instead of "openvpn over tcp".  But
> we're arriving to a world where https to 443 works and much else is
> blocked.

I suppose that one could configure nginx so as to offer a 
password(?)-protected HTTP CONNECT to the OpenVPN server, and tell the 
client-side OpenVPN to use that as a proxy.

*Or* you could use --bind to make the client use a specific *source* 
port, hoping that it won't get SNATed away on the Internet uplink, and 
use that "identifier" and iptables rules so as to have "home base" DNAT 
the connection to the OpenVPN server instead of the nginx ...

Kind regards,
-- 
Jochen Bern
Systemingenieur
Binect GmbH

[Openvpn-users] server: listening on two ports at the same time

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

Hello,

On Thu, Mar 19, 2026 at 10:12:53AM -0400, Greg Troxel wrote:
> I would also like the TLS connection from openvpn to appear to any
> networks in between just like web traffic, at least until you look at

Sorry if I am introducing myself in an otherwise very interesting discussion,
but this looks more and more like traffic obfuscation.

I found this about OpenVPN options in that area:
https://community.openvpn.net/Pages/TrafficObfuscation

Some recommendations go in the direction of tor obfuscators (without tor
performance issues), which I did have experience with.

Also, in the past, some people disguised VPN traffic in DNS queries.

Re: [Openvpn-users] server: listening on two ports at the same time

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

Hi,

On Thu, Mar 19, 2026 at 10:12:53AM -0400, Greg Troxel wrote:
> I would also like the TLS connection from openvpn to appear to any
> networks in between just like web traffic, at least until you look at
> timing and data sizes.  I am finding that many wifi networks purportedly
> for customer convenience at businesses are blocking openvpn's udp/1194.

OpenVPN TCP is not "looks like web traffic TLS" and will never be.

The feature request to "run openvpn via a https proxy" has been voiced
here and there, but nobody really felt like implementing it.

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] server: listening on two ports at the same time

[Greg T. <gd...@le...>]

Antonio Quartulli <a...@un...> writes:

> On 19/03/2026 10:18, Gert Doering wrote:
>> On Thu, Mar 19, 2026 at 10:08:45AM +0100, Antonio Quartulli wrote:

>>> It sounds as if you are looking for the --port-share option?
>>> It's been there for a while (way before multisocket was implemented) and it
>>> seems to be what you are looking for.
>> I think he wants it the other way round - connections go to nginx,
>> and
>> *if* openvpn, then forward to openvpn.
>
> Ah. This would require nginx to be able to detect OpenVPN packets and
> forward them accordingly. Not sure this can be done at all.

Yes.  I don't want to make my web service dependent on openvpn.

These days, it seems things can mostly be set up on their own port on
127.0.0.1 and then have nginx reverse proxy for them.

I would also like the TLS connection from openvpn to appear to any
networks in between just like web traffic, at least until you look at
timing and data sizes.  I am finding that many wifi networks purportedly
for customer convenience at businesses are blocking openvpn's udp/1194.

It would be nice if openvpn's TCP support could somehow be over https
and a prefix within the webroot (or vhost, if it must be).   I think I'm
asking for "openvpn over https" instead of "openvpn over tcp".  But
we're arriving to a world where https to 443 works and much else is
blocked.

Re: [Openvpn-users] server: listening on two ports at the same time

[Antonio Q. <a...@un...>]

Hi,

On 19/03/2026 10:18, Gert Doering wrote:
> Hi,
> 
> On Thu, Mar 19, 2026 at 10:08:45AM +0100, Antonio Quartulli wrote:
>> On 18/03/2026 23:55, Greg Troxel wrote:
>>> (It would be great if someone could do a blog post or docs change to
>>> explain how to configure nginx to function as a proxy to reach an
>>> openvpn server on the same host, so that the connection from the client
>>> to the server would just be on 443/tcp.   Critically, this should work
>>> without interfering with the web server, so no remapping /.)
>>
>> It sounds as if you are looking for the --port-share option?
>> It's been there for a while (way before multisocket was implemented) and it
>> seems to be what you are looking for.
> 
> I think he wants it the other way round - connections go to nginx, and
> *if* openvpn, then forward to openvpn.

Ah. This would require nginx to be able to detect OpenVPN packets and 
forward them accordingly. Not sure this can be done at all.

> 
> No idea if this can be done today - there are some patches floating around
> to add various aspects of PROXY PROTOCOL, so maybe it can, maybe not.

Those patches waiting review are only about parsing the Proxy Protocol 
header that is prepended to a packet after it went through some 
CloudFlare machinery.

Regards,

-- 
Antonio Quartulli

Re: [Openvpn-users] server: listening on two ports at the same time

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

Hi,

On Thu, Mar 19, 2026 at 10:08:45AM +0100, Antonio Quartulli wrote:
> On 18/03/2026 23:55, Greg Troxel wrote:
> > (It would be great if someone could do a blog post or docs change to
> > explain how to configure nginx to function as a proxy to reach an
> > openvpn server on the same host, so that the connection from the client
> > to the server would just be on 443/tcp.   Critically, this should work
> > without interfering with the web server, so no remapping /.)
> 
> It sounds as if you are looking for the --port-share option?
> It's been there for a while (way before multisocket was implemented) and it
> seems to be what you are looking for.

I think he wants it the other way round - connections go to nginx, and
*if* openvpn, then forward to openvpn.

No idea if this can be done today - there are some patches floating around
to add various aspects of PROXY PROTOCOL, so maybe it can, maybe not.

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] server: listening on two ports at the same time

[Antonio Q. <a...@un...>]

Hi Greg,

Thanks a lot for testing the new multi socket feature!
Glad it was helpful!

On 18/03/2026 23:55, Greg Troxel wrote:
> (It would be great if someone could do a blog post or docs change to
> explain how to configure nginx to function as a proxy to reach an
> openvpn server on the same host, so that the connection from the client
> to the server would just be on 443/tcp.   Critically, this should work
> without interfering with the web server, so no remapping /.)

It sounds as if you are looking for the --port-share option?
It's been there for a while (way before multisocket was implemented) and 
it seems to be what you are looking for.

Regards,


-- 
Antonio Quartulli

[Openvpn-users] server: listening on two ports at the same time

[Greg T. <gd...@le...>]

I have long wanted to listen on two ports, one UDP and one (different)
TCP, so that clients could have a better chance of connecting

I find that many wifi networks block lots of things, including 1194/udp.
Apparently the people who configure firewalls think people using
facebook etc. is ok, and nerd protocols like openvpn, xmpp and matrix
are harmful, so it seems best to blend in :-(


I saw in the 2.7.0 release notes one could do this, but couldn't figure
it out.   Finally I found this blog post:

  https://www.willifix.net/blog/openvpn-2-7-multisocket-howto

which says that instead of "udp" and "port 1194" in the config, one
should instead have (with my changing the tcp port to be different):

  local 0.0.0.0 1200 udp
  local 0.0.0.0 1300 tcp

I have a configuration with a specific listen address, and different
ports on udp and tcp, and it seems to work.


(It would be great if someone could do a blog post or docs change to
explain how to configure nginx to function as a proxy to reach an
openvpn server on the same host, so that the connection from the client
to the server would just be on 443/tcp.   Critically, this should work
without interfering with the web server, so no remapping /.)

[Openvpn-users] OpenVPN 3 Linux v27 released

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

OpenVPN 3 Linux v27 (Stable release)

The v27 release is a bug fix release with a few enhancements.


* FEATURE DEPRECATION: openvpn3-autoload

  ** THIS IS THE LAST RELEASE SHIPPING THIS UTILITY - MIGRATE NOW **

  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>


* Bugfix: Use dynamic naming schema for ovpn-dco interfaces

  Prior releases would not be able to start an OpenVPN configuration
  profile if the --dev argument used the device name while there
  already existed a device with the same name.  This has been resolved
  and OpenVPN 3 Linux will now use a dynamic naming schema similar to
  what non-DCO configurations use, appending a digit at the end of
  the device name.


* Bugfix: Deny starting the same configuration more times in parallel

  Prior releases would allow users to start more VPN sessions using
  the same configuration profile.  This could easily cause issues
  where none of the VPN tunnels would work.

  The OpenVPN 3 Session Manager will now block a user from starting
  duplicated VPN sessions if it detects the configuration D-Bus path
  is already used in a session the user owns.

  The openvpn3-systemd unit helper has also been extended to check
  the configuration profile name given via the systemd unit name.


* Bugfix: systemd-resolved integration has been refactored

  When the OpenVPN 3 Network Configuration Service wanted to
  configure the DNS resolver settings, it used a unique D-Bus
  path to the virtual network device in the org.freedesktop.resolve1
  service.  Unfortunately, the systemd-resolved could be a bit slow
  at creating and making these D-Bus objects available, which could
  cause the OpenVPN session to not see the DNS settings in a timely
  manner.  In some cases, it could even completely fail and the
  VPN session was running without the proper DNS resolver configured.

  This release makes use of a different systemd-resolved D-Bus API
  which is more responsive and available before the needed D-Bus
  object has been created and made available.  This results in DNS
  resolver settings being configured with a much higher success rate
  than earlier.


* Bugfix: Fix CreateVirtualInterface timeout errors

  When starting a new VPN session, on some systems, especially when
  under load, the OpenVPN 3 Backend VPN Client process could end up
  not getting the new virtual interface created and the client
  connection would fail.

  In other scenarios, if the user would try to restart VPN sessions
  too quickly - especially with ovpn-dco interfaces, it could also
  trigger a similar behaviour and in some cases also result in a
  deadlock in the OpenVPN 3 Network Configuration Service, making
  it impossible to start new VPN sessions.

  The whole logic related to the CreateVirtualInterface call chains
  has been remodelled to be more much more robust and ensure the
  order of creation and destruction of virtual interfaces are tighter
  and clearer.
  
  
* Bugfix: Properly stop sessions which has been disconnected via --inactive

  The OpenVPN 3 Backend Client process and the Session Manager was
  lacking the logic to properly handle VPN sessions being automatically
  disconnected when session was considered inactive, configured via
  the --inactive option.

  In prior releases, the related openvpn3-service-client process would
  not stop and the OpenVPN 3 Session Manager would need to be
  explicitly told to disconnect the session, even though it was
  already stopped.

  This has been improved and the openvpn3-service-client process will
  now properly shutdown itself and the OpenVPN 3 Session Manager will
  register that the session has been stopped and mark the session as
  disconnected and closed.


* Bugfix: OpenVPN 3 Configuration Manager does not log persisted profiles

  When the OpenVPN 3 Configuration Manager starts, it will load all
  the persistent configuration profiles into memory.  But due to an
  incorrect log level handling internally, it would never respect the
  log level value when starting up.  This resulted in not logging all
  the imported persistent configuration profiles.


* Bugfix: OpenVPN 3 Configuration Manager did not transfer ownership

  When the net.openvpn.v3.configuration.TransferOwnership method was
  called on a configuration profile path, it would not do the transfer
  unless it was root who owned the profile.  This meant that only
  root could transfer profiles the root user imported and could not
  do any other transfers after that point.

  This release improves this by allowing root to always be able
  to transfer the ownership of any configuration profile paths
  to all users, regardless of who owns the profile.


* Bugfix: Avoid a file descriptor leak on tun interfaces

  When the VPN session was restarted or reconnecting with a full
  interface teardown, the openvpn3-service-client process would
  leak a file descriptor, which could end up in a crash if this
  happened too often.  It could also block the other openvpn3
  background service processes from operating as well in some
  cases.
  

* Bugfix: System logs shows g_variant_new_object_path assertion errors

  When starting a new VPN session, this error would be found in the
  system logs (syslog, journald):
  
    g_variant_new_object_path: assertion 'g_variant_is_object_path (object_path)' failed

  This has been fixed by avoiding replying with an invalid D-Bus path
  before the information with this path would be available.


* Enhancement: Log the process ID (pid) of the log event sender

  When the systemd-journald is configured to do the system logging,
  all log events have the _PID value of the openvpn3-service-log
  process.  This release adds an O3_SENDER_PID meta data field
  in the systemd-journal, representing the process ID of the process
  sending the log event.

  This is handy when there are system logs indicating issues
  with a process but only indicating the PID value.  The
  'openvpn3-admin journal' command has been extended with a --pid
  argument to filter only log events from this process ID.  Or
  the same can be done via 'journalctl O3_SENDER_PID=1234'.


* Enhancement: Add openvpn3-desktop-session-watcher

  This is a simple stand-alone utility for graphical desktop
  environments.  It will issue a desktop notification when new VPN
  sessions are started or the running status of the session changes.

  If the VPN session requires web-based authentication, the
  notification will also include the URL for the authentication which
  the user can click on to start the user authentication process.

  There is also a systemd unit file provided with this tool, to be
  used by the end-user.  See the openvpn3-desktop-session-watcher(1)
  man page for details how to enable this feature at login.


* Deprecated command removed: openvpn3 config-show

  This has bee an alias for openvpn3 config-dump since the v17_beta
  release.
  

* OpenVPN 3 Core Library update

  The OpenVPN 3 Core Library has been updated to version 3.11.6
  providing a fix for the ovpn-dco interface name resolution when
  there is a name conflict.


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.

  - There is a file descriptor leak with ovpn-dco interfaces when VPN
    session are restarted or a reconnect with a full interface
    teardown is needed.  This is noticeable in environments with
    unstable connections to the VPN server.  The current workaround
    is to not use DCO interfaces if this is an issue.


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

  - Debian: 12, 13
  - Fedora: 42, 43
  - 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>

The OpenVPN Inc. provided repositories will be updated in the coming
days.  The community provided repositories on Fedora Copr and
openSUSE Build Service are already published.

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
distributions as they occur.

NOTE: Red Hat Enterprise Linux 10
  It is needed to use the 'rhel+epel-10-x86_64' chroot when running
  the 'dnf copr enable' command on RHEL-10.

      # dnf copr enable dsommers/openvpn3 rhel+epel-10-x86_64

  The stable repositories provided by OpenVPN Inc should not
  have this issue.


A few words on the git repositories
-----------------------------------

OpenVPN 3 Linux and GDBus++ has been pushed to three different
git hosting repositories.  The intention has been to have a reduntant
setup where those being very careful in pulling code can pull the
same code from more source trees, and they should all match.  If they
do not match, something unexpected has happened.

For a while now, Codeberg has been the primary repository, where
GitHub and GitLab has been code-mirrors only.  This will not change for
the time being.

With this release, another distributed approach is being tested out.
The Radicle network has been added as well, which is a distributed
git hosting.  This is a very different approach from the ones most
users knows quite well.  Radicle does not have a centralised server,
but all the repository data is distributed across a number of nodes
in the Radicle network.  For now, only the source code will pushed
to the Radicle network, as a code-mirror in parallel to GitLab and
GitHub.

For more details about Radicle: <https://radicle.xyz/>

Consider the Radicle repositories provided as experimental for the
time being.  We will spend some time getting to know Radicle better
before we decide how we will move forward with Radicle in the future.


--
kind regards,

David Sommerseth
OpenVPN Inc


---- Source tarballs ---------------------------------------------------
* OpenVPN 3 Linux v27

  <https://swupdate.openvpn.net/community/releases/openvpn3-linux-27.tar.xz>
  <https://swupdate.openvpn.net/community/releases/openvpn3-linux-27.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 --------------------------------------------------

d8c474032546bdd90b5b7f67e40c57b4b6030253f07bda7bb6ad0db84b9eed73  openvpn3-linux-27.tar.xz
c2da9a93a8db3555e640272f38b950702581ab219e87d62fc6797ee3f503224d  openvpn3-linux-27.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)
   
   rad:zN58oopqzrAkTregNZaRQpgg7x3c              (Radicle, code-only mirror)
   <https://app.radicle.xyz/nodes/iris.radicle.xyz/rad:zN58oopqzrAkTregNZaRQpgg7x3c>

   git tag: v27
   git commit: f0c5ff798e38439ea2595c6edfe392010f82394e


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

   rad:z2Tpg8xVSDgTpoU4Q5FN1aPGqf6mG             (Radicle, code-only mirror)
   <https://app.radicle.xyz/nodes/iris.radicle.xyz/rad:z2Tpg8xVSDgTpoU4Q5FN1aPGqf6mG>
   
   git tag: v3
   git commit: 96f7fb688ed2dea3f192c63c5fe283dbe4900f16

---- Changes from v26 to v27 ---------------------------------------

David Sommerseth (89):
      deprecation: Remove openvpn3 config-show
      spelling: Fix a few minor misspellings of OpenVPN
      netcfg: Add missing throw keyword for exceptions
      netcfg: NetCfgOptions::str() should be a const method
      configmgr: Fix failing TransferOwnership() D-Bus method
      configmgr: Set the log level earlier in the program startup
      configmgr: Improve logging of imported persistent configuration profiles
      configmgr: Improve logging when configuration profile changes owner
      coverity: Remove std::move() where not needed
      coverity: Add missing initialization
      coverity: Fix "dead code" findings
      configmgr: Report errors when failing to delete profile file
      log/journal: Catch date/timestamp parsing errors
      netcfg/device: Use the object variable not ctor variable
      netcfg: Remove pointless check for logservice in main function
      sessionmgr: Catch exception in Session::GetDeviceName()
      tests: Ensure request-queue test iterations do not overflow
      sessionmgr: Improve exception handling in main()
      ovpn3cli/session: Improve session_start() helper sigaction implementation
      coverity: Use std::move() on quite some objects
      coverity: Fix incorrect std::string::find() usage
      log: Catch all exceptions in openvpn3-service-log main()
      client: Pass openvpn::ClientAPI::Config object as a ref to worker thread
      configmgr/proxy: Pass DBus::Object::Path as const refs
      common/requiresqueue: Refactor argument passing - const ref std::string
      code cleanup: Use std::vector::emplace_back()
      code cleanup: Remove const from function returns
      code cleanup: Pass string objects as const ref
      code cleanup: Remove const flag from function arguments
      client: Use DBus::Object::Path for variables containing a D-Bus path
      client: Remove not needed virtual declaration on an override
      events: Remove const arugment declaraions in methods
      distro/systemd: Rework error handling in OpenVPN3systemd.__request_handler()
      distro/systemd: Add a failsafe starting the same configuration more times
      events/status: Refactor Events::Status::PrintMode handling
      client: Refactor DBus::Connection::Ptr passing
      dbus/path: Code cleanup in generate_path_uuid()
      client: Improve arg/env buffer allocation logic
      common: Fix typ0 in terminal type detection
      distro/systemd: Make the status reporting prettier
      vendor: Upgrade to ASIO 1.36.0
      netcfg: Make the Cleanup() D-Bus method call async
      netcfg: Catch errors better when calling GetUID, GetPID and GetSubscriptionOwner
      netcfg: Improve error handling in the Destroy() D-Bus method
      netcfg/resolved: Pass if_index into resolved::Link object
      netcfg/resolved: Refactor all log/debug functions to use fmt::format()
      netcfg/resolved: Extend Link::BackgroundCall() with error callback
      netcfg/resolved: Add missing lock_guard mutex in Link::Storage::NumErrors()
      netcfg/resolved: Switch SetDefaultRoute() to use SetLinkDefaultRoute() D-Bus method
      netcfg/resolved: Add Link::WaitForBackgroundTasks() method
      netcfg/resolved: Rework background_call_data implementation
      netcfg/resolved: Simplify the AsioWorkerClass implementation
      dbus: Add GDBus++ support function - LookupObject()
      dbus: Replace CheckObjectExists() with LookupObject()
      netcfg/dco: Replace ASIO worker/io_context implementation
      netcfg/proxy: Replace g_variant_new() with glib2::Builder
      netcfg/device: Make the CreateVirtualInterface() call more robust
      netcfg/proxy: Make Manager::getVirtualInterface() return std::shared_ptr
      client: Add more debug info in NetCfgTunBuilder::tun_builder_teardown()
      netcfg/dco: Refactor the DCO device teardown
      log/journald: Add O3_SENDER_PID as log event meta data
      ovpn3cli/journal: Add --pid argument to openvpn3-admin journal
      docs: Remove outdated information from openvpn3-admin-journal man page
      netcfg: Don't attach logging for net.openvpn.v3.netcfg.core
      ovpn3cli: Mark "object not found" errors as ExitReason::ABORTED in query_user_input()
      sessionmgr: Extend SessionManager::Session with GetConfigPath()
      sessionmgr: Block starting duplicated sessions
      ovpn3cli/session proxy: Improve error messages sent to the command line user
      common/utils: Slight refactoring of version retrival functions
      common/utils: Move Doxygen comment for set_console_echo()
      tests: Remove log-listener2 test program
      netcfg/resolved: std::move() a arguments which can benefit from it
      client: Catch DBus::Exception as well in ~NetCfgTunBuilder()
      client: Log the D-Bus path to the NetCfg object on device creation
      netcfg/proxy: Fix incorrect DCO::SwapKeys() D-Bus argument
      client: Plug a file descriptor leak with virtual tun interfaces
      python: Add openvpn3-desktop-session-watcher
      tests/python: Add a simple example script for watching log/status changes
      configmgr: Add possibility for root to override Configuration::CheckACL() check
      configmgr: Grant root access to TransferOwnership regardless of the configuraiton profile ACL
      core: Update to OpenVPN 3 Core Library v3.11.6
      client: device_path property cannot be empty
      client: Check if client thread is joinable when disconnecting
      client: Use std::make_shared() when creating CoreVPNClient
      client: Properly assign main loop to signals in BackendClientObject
      client: Properly signal connection is done in inactivity timeout
      dbus/signals: Add callback hook to Signals::StatusChange
      events/status: Extend Status::Check() to also check multiple StatusMinor codes
      sessionmgr: Act upon StatusChange signals from backend client

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

Re: [Openvpn-users] 2.7.0 regression: lport inside <connection> is ignored

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

Hi,

On Tue, Mar 03, 2026 at 01:48:31PM +0300, Evgeniy Berdnikov wrote:
>  OpenVPN allows some configuration directives to be placed inside
>  <connection>..</connection> blocks. In particular, "lport" directive
>  should bind source port of outgoing UDP packets. This option works fine
>  in versions up to 2.6.15, and is ignored in all 2.7.0(-rc*) I tried.
>  Configuration example:
> 
>  <connection>
>    remote some.openvpn.srv 1234 udp
>    lport 54321
>  </connection>
> 
>  It should result in src_port=54321 in UDP packets. But in 2.7.0 it
>  results in global lport configuration value (defaults to 1194).

openvpn-users@ is totally the wrong forum to report bugs - the developers
are over there in openvpn-devel@, and no *users* in here can fix that.

This particular issue has already been reported by Debian, in

  https://github.com/OpenVPN/openvpn/issues/995

Nobody had time to diagnose it yet, and come up with a fix.

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] 2.7.0 regression: lport inside <connection> is ignored

[Evgeniy B. <b4...@pr...>]

 Hi.

 OpenVPN allows some configuration directives to be placed inside
 <connection>..</connection> blocks. In particular, "lport" directive
 should bind source port of outgoing UDP packets. This option works fine
 in versions up to 2.6.15, and is ignored in all 2.7.0(-rc*) I tried.
 Configuration example:

 <connection>
   remote some.openvpn.srv 1234 udp
   lport 54321
 </connection>

 It should result in src_port=54321 in UDP packets. But in 2.7.0 it
 results in global lport configuration value (defaults to 1194).

 PS. I know that using the same lport over repeated connections is bad.
 My configuration have multiple <connection> blocks with different lport's,
 and I understand what I'm doing.

 PSS. Probably some other options are ignored inside <connection> blocks,
 which are mentioned in OpenVPN manual:

|    The  following  OpenVPN  options  may  be  used inside of a <connection>
|    block:
|
|    bind,    connect-retry,    connect-retry-max,    connect-timeout,    ex‐
|    plicit-exit-notify,   float,  fragment,  http-proxy,  http-proxy-option,
|    key-direction, link-mtu, local, lport, mssfix, mtu-disc,  nobind,  port,
|    proto,  remote,  rport,  socks-proxy, tls-auth, tls-crypt, tls-crypt-v2,
|    tun-mtu and, tun-mtu-extra.
-- 
 Eugene Berdnikov

Re: [Openvpn-users] Easy-RSA - x509-type CA, basicConstraint = critical, proposal

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

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

Hi,

thanks for the question, I clarify below.

The current proposal is as follows:

The x509-types/ca file will include 'Basic Constraints: critical'
bit being set, which will impact All new CA/subCA certificates.

There is no proposed command line option to revert this behavior.

In the event that this causes unexpected/unacceptable subsequent
problems then the user would be advised to edit the x509-types/ca
file and remove the "critical" attribute. At which time, this
proposed change could be reviewed further.

This is why we are asking for any known issues, with, for example,
older software, which may have difficulty with the 'critical'
attribute.


Regards.
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsC5BAEBCgBtBYJpmN/JCRBPl5z2a5C4nUUUAAAAAAAcACBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3Jno8Y43WmYKPFS5Ja88HjQoqG08eRwVokB/wyw
cDl4D/wWIQQJvD1EZ6ONcnnFVVVPl5z2a5C4nQAAQycH/jBxEaBFpQuftOn4
7PwECwriOotAbyNL+HqF1IbNpHZ3OUYuJLiZnvH4EFECqIhFZgguxLXPiMYT
YuBAI9HgqKEXzMywtJ/6wA+QpTwo0aB4jwblMV4qoz+yS52JdN8g5l2jHRIg
NLFGLruKNq0wyZRD1AVrQurt8BNLhDUPHjT6YuIaoFVsnMeh4db0oe82theT
CZ6j3BBnoCsWgnedqrfAqo6BG1xPG1xP4Z7hLFKssdCYK1NqfZlfnM8N6Rkt
ZxiQrCyZd6b+9A2yYuEHE2w4Sa3G7CROPLyxHMFdPmScUWNy2ccTbAE3nEci
PcWw2b34RqLylUTwbVU0GCjEiUY=
=EcCb
-----END PGP SIGNATURE-----