openvpn-users — OpenVPN users list

Re: [Openvpn-users] [ext] OpenVPN 2.7_alpha3 released

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

Hi,

On Mon, Aug 11, 2025 at 10:04:18PM +0200, Ralf Hildebrandt wrote:
> > I guess "systemd-resolved" comes preinstalled
> 
> So I checked (25.04):
> 
> $ sudo apt install resolvconf
> Note, selecting 'systemd-resolved' instead of 'resolvconf'
> systemd-resolved is already the newest version (257.4-1ubuntu3.1).
> systemd-resolved set to manually installed.
> 
> :(
> 
> And alas, it doesn't work with systemd-resolved, but you do know that:
> 
> ...
> 2025-08-11 17:42:11 net_addr_v4_add: 172.29.0.2/21 dev tun0
> 2025-08-11 17:42:11 /usr/libexec/openvpn/dns-updown setting DNS using resolvconf

The interesting thing is that it thinks it's *not* using systemd-resolved,
because then it should print

        echo "setting DNS using resolvectl"

... which depends on

function do_resolved {
    [[ "$(readlink /etc/resolv.conf)" =~ systemd ]] || return 1


Mmmh.

(But Heiko is aware of the bug in the other method, so we should see
a bugfix soon...)

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] [ext] OpenVPN 2.7_alpha3 released

[Ralf H. <Ral...@ch...>]

> I guess "systemd-resolved" comes preinstalled

So I checked (25.04):

$ sudo apt install resolvconf
Note, selecting 'systemd-resolved' instead of 'resolvconf'
systemd-resolved is already the newest version (257.4-1ubuntu3.1).
systemd-resolved set to manually installed.

:(

And alas, it doesn't work with systemd-resolved, but you do know that:

...
2025-08-11 17:42:11 net_addr_v4_add: 172.29.0.2/21 dev tun0
2025-08-11 17:42:11 /usr/libexec/openvpn/dns-updown setting DNS using resolvconf
/usr/libexec/openvpn/dns-updown: line 194: dns_server_1_address_*: invalid variable name
No DNS servers specified, refusing operation.
2025-08-11 17:42:11 dns up command exited with status 0
2025-08-11 17:42:11 net_route_v4_add: 10.27.0.0/16 via 172.29.0.1 dev [NULL] table 0 metric 200
...

-- 
Ralf Hildebrandt
Charité - Universitätsmedizin Berlin
Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
Invalidenstraße 120/121 | D-10115 Berlin

Tel. +49 30 450 570 155
ral...@ch...
https://www.charite.de

Re: [Openvpn-users] [ext] OpenVPN 2.7_alpha3 released

[Ralf H. <Ral...@ch...>]

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

> I have no idea, but indeed, that seems to be the solution (plus 
> possibly "apt purge systemd-resolved").  I wasn't aware that this
> part of the systemd zoo was entirely optional.

I guess "systemd-resolved" comes preinstalled

> Since I shy away from learning details about anything-systemd, I just
> didn't know - my Ubuntus come with systemd-resolvd by default, so that's
> what I tested...

-- 
Ralf Hildebrandt
Charité - Universitätsmedizin Berlin
Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
Invalidenstraße 120/121 | D-10115 Berlin

Tel. +49 30 450 570 155
ral...@ch...
https://www.charite.de

Re: [Openvpn-users] [ext] OpenVPN 2.7_alpha3 released

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

Hi,

On Sat, Aug 09, 2025 at 04:30:28PM +0200, Ralf Hildebrandt wrote:
> > Question to you, Ralf: what is needed to make Ubuntu 25.04 use "resolvconf"?
> Huh? 
[..]
> apt install resolvconf
> I guess.

I have no idea, but indeed, that seems to be the solution (plus 
possibly "apt purge systemd-resolved").  I wasn't aware that this
part of the systemd zoo was entirely optional.

Since I shy away from learning details about anything-systemd, I just
didn't know - my Ubuntus come with systemd-resolvd by default, so that's
what I tested...

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] [ext] OpenVPN 2.7_alpha3 released

[Ralf H. <Ral...@ch...>]

> Question to you, Ralf: what is needed to make Ubuntu 25.04 use "resolvconf"?

Huh? 
 
> We do have a 25.04 buildbot, and that one is testing DNS, but it's using
> "systemctl-resolved", which is one of the 2 other methods implemented in
> the Linux script...  (aand of course I tested "edit resolv.conf file" and
> "resolvectl", and none of my Linuxes have "resolvconf".  The FreeBSD script
> uses "resolvconf", but that's a different script)

apt install resolvconf
I guess.

-- 
Ralf Hildebrandt
Charité - Universitätsmedizin Berlin
Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
Invalidenstraße 120/121 | D-10115 Berlin

Tel. +49 30 450 570 155
ral...@ch...
https://www.charite.de

Re: [Openvpn-users] Request for feedback: Unbundling easy-rsa on Windows

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

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

Hi,

The issue that prompted the discussion regarding Easy-RSA support
for Windows and packaging Easy-RSA within the OpenVPN Windows
installer is as follows:

For unknown reasons, when Windows 11 executes the Easy-RSA scripts,
the code `read -p "$prompt"`, would generate the error `no coprocess`.
Then exits the entire shell, without user interaction. This error was
hard to catch without a Windows development environment.

This error has now been completely resolved and Easy-RSA works as
expected in Windows 10/11.

The question of OpenVPN Windows installer including the Easy-RSA for
Windows package is left up to the OpenVPN developer team.

Regards
Richard Bonhomme (Easy-RSA development)
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsC5BAEBCgBtBYJolgz3CZBPl5z2a5C4nUUUAAAAAAAcACBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3JnEG6z6HuSlmTD9jEed4aM61/0+hoZuQpcml8S
oimVpX0WIQQJvD1EZ6ONcnnFVVVPl5z2a5C4nQAA9GgIAKikEyDOwP8RZOdI
6xeEKcHZtBiKIyCfU1cURbRxFCZSais7YM5xkoxfQbJL3bAIvh/wDxwoFqei
CtaLPRorRjppRFWG6HQtCX0xviU3IFDYjMoZlF0KE1RUMZbaPzGvrIm14O3p
TtygdT76H3om6O04Z0pnLu3LX3WdcYIcF9LlajFDo46/g0TnbA1SQslzr7jN
5sBDo/jZZrAI9Ay+1X2F6WlEajjJ3WXj3ZNAocmkdLEIB5et+4ePRoT7H6k3
m8u5lwrv0JCIpIqWLkExGXoze7ulT+ag5QTTGuTLn61E14ELoUKANj9YMq8W
Rq8KMXtLuoh1z1bWB0kLENjntRI=
=ZR/U
-----END PGP SIGNATURE-----

Re: [Openvpn-users] EasyRSA reported as malware

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

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

Hi,

I read your links and this is my conclusion:

The VirusTotal link lists EasyRSA zip at exactly 50/50,
Which seems like guess work by different AIs, filters etc.

Easy-RSA zip files for Windows do contain executable files
and that alone is likely to trigger AV alerts.

The unix tools (eg. sed.exe/grep.exe etc) have not changed
in over a decade but I doubt they have been whitelisted by
any AV because they are not popular enough to warrant that.

The OpenSSL binaries do change quite regularly, as we try
to keep upto date with OpenSSL releases. We build these
ourselves, so they are very likely to trigger AV warnings.

The easyrsa script has also changed a lot in recent years,
so that is likely to trigger AV warnings too.

For the record, Openvpn/Easy-RSA for Windows is safe to
use. If OpenVPN started shipping malware then that would
be fairly big news on the internet.

In the long run, I would simply recommend using Linux to
run easyrsa. That way you can install easyrsa via the package
manager.

Some people recommend Windows Subsystem for Linux but I cannot
get that to install, probably because I am using VirtualBox.

And even if you can get WSL to install, you would most likely
need to install OpenSSL for Windows, which I cannot help with.

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

wsC5BAEBCgBtBYJolgAvCZBPl5z2a5C4nUUUAAAAAAAcACBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3Jnoy5C4Mt+wQrwKZBIYw5xX2+zuRlArCuLapOH
4Gxfnm8WIQQJvD1EZ6ONcnnFVVVPl5z2a5C4nQAAWXsH/ihqOtz8o5cfHwQY
b8Nil718VAYvJ8QQe1Tp3ISFZBpj+dCOx6NA8Hx6Zq4Y/WGzJn+AfjNzBzfc
Gj0a8lqIoTrDQoGhXPGP3YU0O92UUwmI7B8xxVH0xmTFu5skjKfZJbIQWDG0
OT9TqdTR2fKhXgwSNrSbIRKGdepqOnRoWiDpvoJS1PBqNYFs3mt6OIBYk2tq
RoRCu6/9+Ax1LOxN7qxHOQrKdlym3qmAQyX4t3eua2jGf7vqre9/BIuyMxGf
Ki549BT3ZVWXbpDU5dakOMi2iM2/+2gCE6K418N71asYpI9iM/1KkNeqVT7g
ilejr2yK9HlpRAk5RflQPDFDsWQ=
=693n
-----END PGP SIGNATURE-----

Re: [Openvpn-users] [ext] OpenVPN 2.7_alpha3 released

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

Hi,

On Fri, Aug 08, 2025 at 12:02:01PM +0200, Gert Doering wrote:
> > Doesn't work. Ubuntu 25.04 with 2.7_alpha3
> 
> This is... not how it should look like.
> 
> Can you open an issue, please, and include ^that error and also the
> PUSH_REPLY info sent by the server (and/or relevant bits of the config)?

That was actually somewhat easy to pinpoint...

14:57 <@djpig> This is a relatively simple bug
14:57 <@djpig> ${!dns_server_1_address_*} works
14:57 <@djpig> but "server_var=dns_server_1_address_*; ${!server_var}" does not

bugfix should pop up on https://gerrit.openvpn.net "soonish"

Question to you, Ralf: what is needed to make Ubuntu 25.04 use "resolvconf"?

We do have a 25.04 buildbot, and that one is testing DNS, but it's using
"systemctl-resolved", which is one of the 2 other methods implemented in
the Linux script...  (aand of course I tested "edit resolv.conf file" and
"resolvectl", and none of my Linuxes have "resolvconf".  The FreeBSD script
uses "resolvconf", but that's a different script)

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] [ext] OpenVPN 2.7_alpha3 released

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

Hi,

On Fri, Aug 08, 2025 at 11:48:32AM +0200, Ralf Hildebrandt via Openvpn-users wrote:
> 2025-08-08 11:44:24 /usr/libexec/openvpn/dns-updown 
> setting DNS using resolvconf 
> /usr/libexec/openvpn/dns-updown: line 194: dns_server_1_address_*: invalid variable name
> No DNS servers specified, refusing operation.
> 2025-08-08 11:44:24 dns up command exited with status 0
> 
> Doesn't work. Ubuntu 25.04 with 2.7_alpha3

This is... not how it should look like.

Can you open an issue, please, and include ^that error and also the
PUSH_REPLY info sent by the server (and/or relevant bits of the config)?

I have no Ubuntu 25 available right now, but I tested this on Gentoo and
an older Ubuntu (20.04), and it worked for me.  Our BB infrastructure does
have an 25.04 client, and I *think* Frank is using --dns-updown tests from 
t_client.rc on all the BBs nowadays - so, something "non trivial".

Thanks for testing the alpha3, so we can fix it for beta1...!

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] [ext] OpenVPN 2.7_alpha3 released

[Ralf H. <Ral...@ch...>]

* Ralf Hildebrandt via Openvpn-users <ope...@li...>:
> > If you fully install 2.7_alpha3, you get a "dns-updown" script
> > in the "libexecdir" (like, /usr/local/libexec/openvpn/dns-updown).
> 
> Yes: /usr/libexec/openvpn/dns-updown
>  
> > If there is *no* --up script set, OpenVPN will call said script 
> > (in the compiled-in location) automatically and it should do all the
> > magic.
> 
> UUUUH. Awesome (if it works, that is)

2025-08-08 11:44:24 /usr/libexec/openvpn/dns-updown 
setting DNS using resolvconf 
/usr/libexec/openvpn/dns-updown: line 194: dns_server_1_address_*: invalid variable name
No DNS servers specified, refusing operation.
2025-08-08 11:44:24 dns up command exited with status 0

Doesn't work. Ubuntu 25.04 with 2.7_alpha3

-- 
Ralf Hildebrandt
Charité - Universitätsmedizin Berlin
Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
Invalidenstraße 120/121 | D-10115 Berlin

Tel. +49 30 450 570 155
ral...@ch...
https://www.charite.de

Re: [Openvpn-users] [ext] OpenVPN 2.7_alpha3 released

[Ralf H. <Ral...@ch...>]

> If you fully install 2.7_alpha3, you get a "dns-updown" script
> in the "libexecdir" (like, /usr/local/libexec/openvpn/dns-updown).

Yes: /usr/libexec/openvpn/dns-updown
 
> If there is *no* --up script set, OpenVPN will call said script 
> (in the compiled-in location) automatically and it should do all the
> magic.

UUUUH. Awesome (if it works, that is)
 
> If --up is in use, we decided to not mess with people's pre-existing
> configurations - in that case, the DNS script is not run and "everything
> stays as it is".

Yes, don't mess with pre-existing configuration...

> If you have an --up script doing something else, and still want the new
> DNS script, use "--dns-updown force" ("always run the compiled-in script"),
> or if you want something else, use "--dns-updown /path/to/my/script.sh"
> (this will need --script-security 2).

I simply change my incantation. Will test this right away.


-- 
Ralf Hildebrandt
Charité - Universitätsmedizin Berlin
Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
Invalidenstraße 120/121 | D-10115 Berlin

Tel. +49 30 450 570 155
ral...@ch...
https://www.charite.de

Re: [Openvpn-users] EasyRSA reported as malware

[Kenneth P. <sh...@se...>]

--On Thursday, August 07, 2025 10:49 PM +0000 tincantech 
<tin...@pr...> wrote:

> This is probably a false positive.
>
> My gut feel would be the Openssl binaries that EasyRSA ships.
> Either that or the Unix tools, which have been shipped for over a decade,
> unchanged, have suddenly been flagged by your AV as dubious.
>
> If your anti-virus product is really so picky then simply download and
> install Openvpn for Windows and install Easy-RSA from that installer.
> You need to select Easy-RSA as an extra install component. IE. Custom.
>
> OpenVPN Download URL: https://community.openvpn.net/Downloads
>
> If your anti-virus also complains about the Openvpn installer then
> please let us know.

I'd just downloaded and installed the latest OpenVPN release but didn't 
think to install the EasyRSA piece, forgetting it was part of that. The 
installer's "modify" option isn't available so I uninstalled and 
re-installed with EasyRSA included and didn't get any alert. So the problem 
seems to be only in the standalone zip file.

The AV in question is Microsoft Defender that comes with Win10. Apparently 
it false positives on "TrojanScript/Wacatec.B!ml" a lot:

<https://www.reddit.com/r/antivirus/comments/1g112hr/can_wacatac_be_false_positive/>

I posted a link in the first message here to VirusTotal just to show how 
many vendors are getting it wrong. I'll submit this one to MS to let them 
analyze it and add it to their exceptions.

Re: [Openvpn-users] EasyRSA reported as malware

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

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

Hi,

On Thursday, 7 August 2025 at 22:28, Kenneth Porter <sh...@se...> wrote:

> I tried downloading the lastest EasyRSA release from GitHub only to see
> both Firefox and Windows Defender (Win10x x64) report it as malware
> "trojan.pigyx". I downloaded it on Linux and uploaded it to VirusTotal
> and many AV's think it's malware. What's going on?
> 
> https://www.virustotal.com/gui/file/ed0d5525f52d0c0ff29661e18b810cc510154aad890c37ed819ec64104512caa
> 
> Downloaded from here:
> 
> https://github.com/OpenVPN/easy-rsa/releases/tag/v3.2.3
> 
> (I haven't used this in awhile and was about to make a new client
> config, so I figured I should grab the latest package.)
> 
> 

This is probably a false positive.

My gut feel would be the Openssl binaries that EasyRSA ships.
Either that or the Unix tools, which have been shipped for over a decade,
unchanged, have suddenly been flagged by your AV as dubious.

If your anti-virus product is really so picky then simply download and
install Openvpn for Windows and install Easy-RSA from that installer.
You need to select Easy-RSA as an extra install component. IE. Custom.

OpenVPN Download URL: https://community.openvpn.net/Downloads

If your anti-virus also complains about the Openvpn installer then
please let us know.

Regards
tct

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsC5BAEBCgBtBYJolR9SCZBPl5z2a5C4nUUUAAAAAAAcACBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3JnETKT6ZqUEEg6x4EaER6KkRsnbGJoOliwYRoM
mySBtp8WIQQJvD1EZ6ONcnnFVVVPl5z2a5C4nQAAo40IAITjx/gpvtf25lxY
G3N2iWIxYlNXCWdeahPyv12/Dswa6b7XDHdvG+QesswfAvSm/nRCX4oonbEU
gLRJ5OOUnPeN/0bU9XL6z4IiXIyxB9y0bWNZhGTu5S4Fs84JTypyYPSEoC0a
NbFxGRPIZ9vMEIXZmS3JEebD8S4mvm2PwXS4qKUhhkvag6Tcvvm2+rKCN/Z8
odhm8uCg6a4voiOgdKtvsMT9RFuy+R1/fSftXKNN03c6WqZfymCD1+6Bz5Hz
kfuPh6XP8twsMxtp8p+H/ZffXROcUx30tZKmAFqhjVXlvl41SFgAUfxFExhi
5NmHO7QR7/g/4W3pta3GePYd5/A=
=XBEM
-----END PGP SIGNATURE-----

Re: [Openvpn-users] EasyRSA reported as malware

[Jonathan K. B. <jkb...@gm...>]

On Thu, Aug 7, 2025 at 5:27 PM Kenneth Porter <sh...@se...> wrote:
>
> I tried downloading the lastest EasyRSA release from GitHub only to see
> both Firefox and Windows Defender (Win10x x64) report it as malware
> "trojan.pigyx". I downloaded it on Linux and uploaded it to VirusTotal
> and many AV's think it's malware. What's going on?

I have nothing specific to say about EasyRSA (it could have been
compromised, I suppose), but
 1. False positives happen occasionally. It happened to Tunnelblick
years ago [1] and [2].
 2. Many AV vendors just copy others' results, so if one reports it's
malware then it is likely that several others will, too.

Jon Bullard
Tunnelblick Developer

[1] https://tunnelblick.net/cNoMalwareInTunnelblick.html
[2] https://tunnelblick.net/cNews.html#2018-10-01

[Openvpn-users] EasyRSA reported as malware

[Kenneth P. <sh...@se...>]

I tried downloading the lastest EasyRSA release from GitHub only to see 
both Firefox and Windows Defender (Win10x x64) report it as malware 
"trojan.pigyx". I downloaded it on Linux and uploaded it to VirusTotal 
and many AV's think it's malware. What's going on?

https://www.virustotal.com/gui/file/ed0d5525f52d0c0ff29661e18b810cc510154aad890c37ed819ec64104512caa

Downloaded from here:

https://github.com/OpenVPN/easy-rsa/releases/tag/v3.2.3

(I haven't used this in awhile and was about to make a new client 
config, so I figured I should grab the latest package.)

Re: [Openvpn-users] [ext] OpenVPN 2.7_alpha3 released

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

Hi,

On Wed, Aug 06, 2025 at 05:00:51PM +0200, Ralf Hildebrandt via Openvpn-users wrote:
> > * Improved Client support for DNS options
> >   * Client implementations for Linux/BSD, included with the default install
> 
> How do I actually use that?
> 
> I'm using ubuntu 25.04, and usually I'm using --up an --down scripts
> for that. So if there was an "easier" way, I'd sure like to see an example.

If you fully install 2.7_alpha3, you get a "dns-updown" script
in the "libexecdir" (like, /usr/local/libexec/openvpn/dns-updown).

If there is *no* --up script set, OpenVPN will call said script 
(in the compiled-in location) automatically and it should do all the
magic.

If --up is in use, we decided to not mess with people's pre-existing
configurations - in that case, the DNS script is not run and "everything
stays as it is".

If you have an --up script doing something else, and still want the new
DNS script, use "--dns-updown force" ("always run the compiled-in script"),
or if you want something else, use "--dns-updown /path/to/my/script.sh"
(this will need --script-security 2).

The --dns-updown section in the manpage explains more about the script
and the conditions when and how it's called, and how --dhcp-option DNS
and --dns interact ("do not break people's setup" leads to quite some
contortions at times - I hope we got it mostly right for DNS)

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             ge...@gr...

Re: [Openvpn-users] [ext] OpenVPN 2.7_alpha3 released

[Ralf H. <Ral...@ch...>]

> * Improved Client support for DNS options
>   * Client implementations for Linux/BSD, included with the default install

How do I actually use that?

I'm using ubuntu 25.04, and usually I'm using --up an --down scripts
for that. So if there was an "easier" way, I'd sure like to see an example.

-- 
Ralf Hildebrandt
Charité - Universitätsmedizin Berlin
Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
Invalidenstraße 120/121 | D-10115 Berlin

Tel. +49 30 450 570 155
ral...@ch...
https://www.charite.de

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