openvpn-users — OpenVPN users list

Re: [Openvpn-users] Client-specific rules and access policies with topology subnet

[kAja Z. <zie...@gm...>]

Hello developers and users,

  would anyone be so kind as to review the configuration from the previous
email?

Thank you very much in advance and have a nice day
-- 
Karel Ziegler

On Wed, Feb 19, 2025 at 11:38 AM kAja Ziegler <zie...@gm...> wrote:

> Hello developers and users,
>
> I'm trying to get inspiration from the HOW-TO
> https://openvpn.net/community-resources/how-to/#configuring-client-specific-rules-and-access-policies,
> which is based on the net30 topology, and adapt it to the subnet topology.
>
> I've prepared a small PoC and everything seems to work as I expect and
> without any problems.
>
> Please, can you take a look at the configuration snippets below to see if
> there is any logical error in it and whether it will really work flawlessly
> this way?
>
>
> *- create and configure TUN interfaces using NetworkManager, including all
> IP addresses that will serve as default gateways for different classes of
> users inside the VPN tunel:*
>
> # nmcli connection add type tun tun.mode tun autoconnect yes con-name tun0
> ipv4.addresses 172.17.17.1/24 +ipv4.addresses 172.17.18.1/24 ipv4.method
> manual ipv6.method disabled ifname tun0
>
> # ip address show dev tun0
> 95: tun0: <*NO-CARRIER*,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc
> fq_codel state *DOWN* group default qlen 500
>     link/none
>     inet 172.17.17.1/24 brd 172.17.17.255 scope global noprefixroute tun0
>        valid_lft forever preferred_lft forever
>     inet 172.17.18.1/24 brd 172.17.18.255 scope global noprefixroute tun0
>        valid_lft forever preferred_lft forever
>
>
> *- OpenVPN server configuration without directives like ifconfig and
> server and without ifconfig-pool:*
> # cat server.conf
> local AA.BB.CC.DD
>
> proto udp
> port 1194
>
> dev tun0
>
> mode server
> topology subnet
>
> tls-server
> tls-auth tlsauth.key 0
> tls-verify "/etc/openvpn/scripts/openvpn-client-verify.pl
> allowed-clients.conf"
> dh dh2048.pem
>
> remote-cert-tls client
>
> pkcs12 server.p12
>
> client-config-dir ccd
> ccd-exclusive
>
> push "topology subnet"
>
> user openvpn
> group openvpn
>
> keepalive 10 30
>
> persist-key
> persist-remote-ip
> persist-tun
>
> script-security 2
>
> *- specific configuration for the first (n-th) user from the Employee
> role:*
> # cat ccd/user-role-employee-1
> ifconfig-push 172.17.17.50 255.255.255.0
> push "route-gateway 172.17.17.1"
>
> *- specific configuration for the first (n-th) user from the System
> Administrator role:*
> # cat ccd/user-role-admin-1
> ifconfig-push 172.17.18.51 255.255.255.0
> push "route-gateway 172.17.18.1"
>
>
> *- start OpenVPN server and the status of the tun0 interface after:*
>
> # systemctl start openvpn-server.service
>
> # ip address show dev tun0
> 95: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,*LOWER_UP*> mtu 1500 qdisc
> fq_codel state *UP* group default qlen 500
>     link/none
>     inet 172.17.17.1/24 brd 172.17.17.255 scope global noprefixroute tun0
>        valid_lft forever preferred_lft forever
>     inet 172.17.18.1/24 brd 172.17.18.255 scope global noprefixroute tun0
>        valid_lft forever preferred_lft forever
>
> # ip -d link show tun0
> 95: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
> fq_codel state UP mode DEFAULT group default qlen 500
>     link/none  promiscuity 0 allmulti 0 minmtu 68 maxmtu 65535
>     tun type tun pi off vnet_hdr off persist on numtxqueues 1 numrxqueues
> 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs
> 65535 gro_max_size 65536 gso_ipv4_max_size 65536 gro_ipv4_max_size 65536
>
> # ip route show dev tun0
> 172.17.17.0/24 proto kernel scope link src 172.17.17.1 metric 450
> 172.17.18.0/24 proto kernel scope link src 172.17.18.1 metric 450
>
>
> *- REJECT communication/traffic between individual OpenVPN clients:*
> # iptables -I FORWARD -i tun+ -o tun+ -m state --state NEW -j REJECT
>
> *- specific firewalling rules for the Employee role, e.g.:*
> # iptables -A FORWARD -i tun0 -o enp6s19 -s 172.17.17.0/24 -d
> 192.168.17.0/24 -p tcp -m multiport --sports 80,443 -m state --state NEW
> -j ACCEPT
> ...
>
> *- specific firewalling rules for the System Administrator role, e.g.:*
> # iptables -A FORWARD -i tun0 -o enp6s19 -s 172.17.18.0/24 -d
> 192.168.0.0/16 -p tcp -m multiport --sports 80,443 -m state --state NEW
> -j ACCEPT
> ...
>
>
> There is certainly room for improvement in the configuration, but I am
> primarily concerned with the combination of configuring the TUN interface
> using NetworkManager and configuring the OpenVPN server together with CCD
> files or with some client-connect/client-disconnect scripts. But I'm
> certainly not opposed to any suggestions for improvement.
>
> Thank you very much in advance for your time, advice and comments.
>
> With best regards
> --
> Karel Ziegler
>
>  e-mail:    zie...@gm...
>
>

[Openvpn-users] Client-specific rules and access policies with topology subnet

[kAja Z. <zie...@gm...>]

Hello developers and users,

I'm trying to get inspiration from the HOW-TO
https://openvpn.net/community-resources/how-to/#configuring-client-specific-rules-and-access-policies,
which is based on the net30 topology, and adapt it to the subnet topology.

I've prepared a small PoC and everything seems to work as I expect and
without any problems.

Please, can you take a look at the configuration snippets below to see if
there is any logical error in it and whether it will really work flawlessly
this way?


*- create and configure TUN interfaces using NetworkManager, including all
IP addresses that will serve as default gateways for different classes of
users inside the VPN tunel:*

# nmcli connection add type tun tun.mode tun autoconnect yes con-name tun0
ipv4.addresses 172.17.17.1/24 +ipv4.addresses 172.17.18.1/24 ipv4.method
manual ipv6.method disabled ifname tun0

# ip address show dev tun0
95: tun0: <*NO-CARRIER*,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc
fq_codel state *DOWN* group default qlen 500
    link/none
    inet 172.17.17.1/24 brd 172.17.17.255 scope global noprefixroute tun0
       valid_lft forever preferred_lft forever
    inet 172.17.18.1/24 brd 172.17.18.255 scope global noprefixroute tun0
       valid_lft forever preferred_lft forever


*- OpenVPN server configuration without directives like ifconfig and server
and without ifconfig-pool:*
# cat server.conf
local AA.BB.CC.DD

proto udp
port 1194

dev tun0

mode server
topology subnet

tls-server
tls-auth tlsauth.key 0
tls-verify "/etc/openvpn/scripts/openvpn-client-verify.pl
allowed-clients.conf"
dh dh2048.pem

remote-cert-tls client

pkcs12 server.p12

client-config-dir ccd
ccd-exclusive

push "topology subnet"

user openvpn
group openvpn

keepalive 10 30

persist-key
persist-remote-ip
persist-tun

script-security 2

*- specific configuration for the first (n-th) user from the Employee role:*
# cat ccd/user-role-employee-1
ifconfig-push 172.17.17.50 255.255.255.0
push "route-gateway 172.17.17.1"

*- specific configuration for the first (n-th) user from the System
Administrator role:*
# cat ccd/user-role-admin-1
ifconfig-push 172.17.18.51 255.255.255.0
push "route-gateway 172.17.18.1"


*- start OpenVPN server and the status of the tun0 interface after:*

# systemctl start openvpn-server.service

# ip address show dev tun0
95: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,*LOWER_UP*> mtu 1500 qdisc
fq_codel state *UP* group default qlen 500
    link/none
    inet 172.17.17.1/24 brd 172.17.17.255 scope global noprefixroute tun0
       valid_lft forever preferred_lft forever
    inet 172.17.18.1/24 brd 172.17.18.255 scope global noprefixroute tun0
       valid_lft forever preferred_lft forever

# ip -d link show tun0
95: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel
state UP mode DEFAULT group default qlen 500
    link/none  promiscuity 0 allmulti 0 minmtu 68 maxmtu 65535
    tun type tun pi off vnet_hdr off persist on numtxqueues 1 numrxqueues 1
gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535
gro_max_size 65536 gso_ipv4_max_size 65536 gro_ipv4_max_size 65536

# ip route show dev tun0
172.17.17.0/24 proto kernel scope link src 172.17.17.1 metric 450
172.17.18.0/24 proto kernel scope link src 172.17.18.1 metric 450


*- REJECT communication/traffic between individual OpenVPN clients:*
# iptables -I FORWARD -i tun+ -o tun+ -m state --state NEW -j REJECT

*- specific firewalling rules for the Employee role, e.g.:*
# iptables -A FORWARD -i tun0 -o enp6s19 -s 172.17.17.0/24 -d
192.168.17.0/24 -p tcp -m multiport --sports 80,443 -m state --state NEW -j
ACCEPT
...

*- specific firewalling rules for the System Administrator role, e.g.:*
# iptables -A FORWARD -i tun0 -o enp6s19 -s 172.17.18.0/24 -d 192.168.0.0/16
-p tcp -m multiport --sports 80,443 -m state --state NEW -j ACCEPT
...


There is certainly room for improvement in the configuration, but I am
primarily concerned with the combination of configuring the TUN interface
using NetworkManager and configuring the OpenVPN server together with CCD
files or with some client-connect/client-disconnect scripts. But I'm
certainly not opposed to any suggestions for improvement.

Thank you very much in advance for your time, advice and comments.

With best regards
-- 
Karel Ziegler

 e-mail:    zie...@gm...

Re: [Openvpn-users] Migrating OpenVPN server - easyrsa question...

[Bo B. <bo....@gm...>]

On Mon, 17 Feb 2025 20:39:57 +0000, tincantech via Openvpn-users
<ope...@li...> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA512
>
>Hi Bo,
>
>On Monday, 17 February 2025 at 15:28, Bo Berglund <bo....@gm...> wrote:
>
>> On the old server I have migrated over the years through easyrsa versions up to
>> 3.1.5, which is what is now used there.
>> 
>> Can I just copy over the directory tree in $HOME/openvpn where all the
>> management stuff resides and then replace easyrsa with the now latest version
>> from Github (3.2.2) without editing my scripts that use easyrsa?
>
>Yes, copy your data and upgrade to Easy-RSA v 3.2.2 - That is supported.

Good, then I will just tar the old server's directories and write them on the
new server's disk at the proper places.

>> I.e. has there been some functional change regarding the way to use easyrsa
>> between those versions?
>
>There is one functional change:
>
>Command `revoke` can only be used in --batch mode.
>Otherwise, for interactive use, the command is now `revoke-issued`.
>This is to protect against revoking an 'issued' certificate when it
>is intended to revoke a 'renewed' or 'expired' certificate.

Well, I have a limited number of clients and I have "solved" this by using the
ccd entries to block the ones that have left us if they try to connect.
It was safer than using the revocation as I tried to do once but managed to
block the whole server for everyone...

I think I wrote about that here when it happened a couple of years back.
By using the ccd entries I get what we need: preventing them from connecting,
without messing with the revocation handling.

So I am fine with the new easyrsa then! :)

Thanks again!


-- 
Bo Berglund
Developer in Sweden

Re: [Openvpn-users] Migrating OpenVPN server - easyrsa question...

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

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

Hi Bo,

Sent with Proton Mail secure email.

On Monday, 17 February 2025 at 15:28, Bo Berglund <bo....@gm...> wrote:

> On the old server I have migrated over the years through easyrsa versions up to
> 3.1.5, which is what is now used there.
> 
> Can I just copy over the directory tree in $HOME/openvpn where all the
> management stuff resides and then replace easyrsa with the now latest version
> from Github (3.2.2) without editing my scripts that use easyrsa?

Yes, copy your data and upgrade to Easy-RSA v 3.2.2 - That is supported.

> I.e. has there been some functional change regarding the way to use easyrsa
> between those versions?

There is one functional change:

Command `revoke` can only be used in --batch mode.
Otherwise, for interactive use, the command is now `revoke-issued`.
This is to protect against revoking an 'issued' certificate when it
is intended to revoke a 'renewed' or 'expired' certificate.

Regards
R

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

wsC5BAEBCgBtBYJns56NCZBPl5z2a5C4nUUUAAAAAAAcACBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3Jn5xDQevSF/X3k+F/2S9lUtUPO6SHNq2nkTCLt
T4Vrzo0WIQQJvD1EZ6ONcnnFVVVPl5z2a5C4nQAAVZ4IALyekfqGeUWvEzN2
MC7x07oAJvKFgBWO06N3bX9Iv5DAEmSnz8Cq5G9xantZwYg+Ht0z+VBybZlA
sxjqb0Gn3JNysC4B4BiZQJS7BzOs4QCN/lVbGehM7IWMMLFzY6IFSUJwcv3o
GTv0SFPTM+A8eQko05I33ZnxFbBtk4YaCPC1HW4KCI0mopc6gwkhcWJdGT0I
8GDh5MecFzKUCzwKlLmVeRTJDwDtuXcFUZODKeG8EOXcW4MIyaBAX3SiNa7R
9eir7EwgSUKtuHo9PRQF0epc1fKPz7tGLh0eIlpUT+DMkhlbUaGs6bQBlBEl
q/H+lZTCvqebnuKDrIlClUHRYgU=
=M/kS
-----END PGP SIGNATURE-----

[Openvpn-users] Migrating OpenVPN server - easyrsa question...

[Bo B. <bo....@gm...>]

So I have migrated my old Ubuntu Server 20.04.1 to version 24.04.1 and then to
new hardware on a new install of Ubuntu version 24.04.1.

The hardware migration was done as a fresh Ubuntu install followed by installing
the support for all the functions handled by the server (Apache and Subversion
among others) and migrating the configuration files.

Now I have come to the OpenVPN part and regarding the infrastructure to manage
the server logins and certs etc I have this question:

On the old server I have migrated over the years through easyrsa versions up to
3.1.5, which is what is now used there.

Can I just copy over the directory tree in $HOME/openvpn where all the
management stuff resides and then replace easyrsa with the now latest version
from Github (3.2.2) without editing my scripts that use easyrsa?

I.e. has there been some functional change regarding the way to use easyrsa
between those versions?

My options are:
---------------
1) Just transfer the full content of the openvpn dir from the old to the new
server as is.

2) Transfer as above but then replace easyrsa with the most recent version.

The OpenVPN server's active crypto files are *copies* which are located in dir
/etc/openvpn/keys and those I believe can be transferred as is to the new system
and it will work as needed.

But when creating new user logins and perhaps when upgrading the certs before
they expire I need a working easyrsa and the original crypto files...

Any advice appreciated!


-- 
Bo Berglund
Developer in Sweden

Re: [Openvpn-users] OpenVPNConnect: Support of IOS Keychain

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

Hi,

On Mon, Feb 03, 2025 at 12:16:12PM +0100, Ralf Hildebrandt via Openvpn-users wrote:
> We have the requirement to make the key & cert used within an openvpn
> connection profile not exportable.
> 
> So we thought it would be a sensible approach to install key & cert
> into the IOS Keychain, but currently I'm unsure if openvpnConnect
> (3.5.1) can actually use them.
> 
> The documentation seems to suggest that exporting from the keychain an
> dimporting into openvpnConnect (and later referencing the imported
> key/cert)
> 
> Is that approach supported at all?

Unfortunately, there doesn't seem to be anyone from the Connect team
here (or in my reach).  So I have no answer from you - in theory, that
is the approach to use, "import Cert into secure element, reference from
there" (Windows keyapi, iOS keystore, ...).

Maybe opening a Connect ticket via https://support.openvpn.net/ might
get useful responses.

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] easyrsa build-ca does not use my var file

[Bruce B. <bru...@gm...>]

Many thanks Richard,

That did the trick.

Debian Stable v12.9 is using easyrsa v3.1.0

I did note though that an 'easyrsa init-pki’ deleted my ~/easy-rsa/pki/var file.

Fortunately I had a backup.  I assume that this has been fixed in v3.2.2

Kind regards,

Bruce
 

> On 5 Feb 2025, at 05:35, tincantech <tin...@pr...> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Hi Bruce,
> 
> EasyRSA 3.0.8 is ancient.
> Debian 11 is no spring chicken.
> 
> My only suggestion is that you upgrade EasyRSA to v3.2.2
> 
> Regards
> Richard
> 
> 
> Sent with Proton Mail secure email.
> 
> On Tuesday, 4 February 2025 at 06:23, Bruce Bannerman <bru...@gm...> wrote:
> 
>> Hello everyone,
>> 
>> Environment: Debian 11.11
>> 
>> easyrsa version 3.0.8
>> 
>> Issue:
>> 
>> I’m trying to initialise and build my intermediate CA
>> 
>> easyrsa build-ca does not use my modified variables when it creates my new CA.
>> 
>> My custom variables are in the file “vars" in my ~/easy-rsa directory
>> 
>> The vars file is a copy of the file “vars.example"
>> 
>> in vars, I have modified the following variables:
>> 
>> set_var EASYRSA “~/easy-rsa/"
>> set_var EASYRSA_KEY_SIZE 4096
>> set_var EASYRSA_DIGEST "sha512"
>> 
>> The file permissions assign to the file ~/easy-rsa/vars are u=rw,go=, where the file owner is the owner of ~/
>> 
>> I’ve also tried an ownership definition of u=rw,go=r, but this makes no difference.
>> 
>> When I run the commands:
>> 
>> ./easyrsa init-pki
>> ./easyrsa build-ca
>> 
>> and then check the created certificate with: openssl x509 -noout -text -in ~/easy-rsa/pki/ca.crt
>> 
>> I find:
>> 
>> Signature Algorithm: sha256WithRSAEncryption
>> Public Key Algorithm: rsaEncryption
>> RSA Public-Key: (2048 bit)
>> 
>> This is not what I had defined in ~/esay-rsa/vars.
>> 
>> Any pointers on how to get this working will be appreciated.
>> 
>> Kind regards,
>> 
>> Bruce
>> 
>> 
>> 
>> _______________________________________________
>> Openvpn-users mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/openvpn-users
> -----BEGIN PGP SIGNATURE-----
> Version: ProtonMail
> 
> wsC5BAEBCgBtBYJnol3TCZBPl5z2a5C4nUUUAAAAAAAcACBzYWx0QG5vdGF0
> aW9ucy5vcGVucGdwanMub3JnpYUuVXHh5MBr3LV6uomFhv5ul1g9oMoFsXsR
> 6xkl8wYWIQQJvD1EZ6ONcnnFVVVPl5z2a5C4nQAA9RMH/R10S9ARpe8KZ/I/
> r8gr5v/+bI4yW5mNKcvNp2ooQDf+RK9MckvISQNE++F4oZJJUCpp9Kph3ea2
> jnSKskxYZJ9YJCgXR+8O544dRfsbjOLCtJc4rE1dAaO5fJcC3Vp0M2xKuByB
> jLwYG/RWlgt3BVZKfgBHctAmxRCm5GDAhCqgCcnP4x+HYOVCTyxor2sEfr70
> uoS5ge7MSyi3+W6Hu2tsHG6ZTfvIzeiamEQwn+UUn84UpQdhUYsXIP/zXPc0
> VaKR+JUqs/eRN+WFBVmFmtr6H1vrjUMuYLoBpBNLHxSR20jK734Sls/NzyOA
> 3Dz9O5jHUjlGSBRQHtr1sOgG61U=
> =rCdM
> -----END PGP SIGNATURE-----
> <publickey - tin...@pr... - 0x09BC3D44.asc><publickey - tin...@pr... - 0x09BC3D44.asc.sig>

Re: [Openvpn-users] easyrsa build-ca does not use my var file

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

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

Hi Bruce,

EasyRSA 3.0.8 is ancient.
Debian 11 is no spring chicken.

My only suggestion is that you upgrade EasyRSA to v3.2.2

Regards
Richard


Sent with Proton Mail secure email.

On Tuesday, 4 February 2025 at 06:23, Bruce Bannerman <bru...@gm...> wrote:

> Hello everyone,
> 
> Environment: Debian 11.11
> 
> easyrsa version 3.0.8
> 
> Issue:
> 
> I’m trying to initialise and build my intermediate CA
> 
> easyrsa build-ca does not use my modified variables when it creates my new CA.
> 
> My custom variables are in the file “vars" in my ~/easy-rsa directory
> 
> The vars file is a copy of the file “vars.example"
> 
> in vars, I have modified the following variables:
> 
> set_var EASYRSA “~/easy-rsa/"
> set_var EASYRSA_KEY_SIZE 4096
> set_var EASYRSA_DIGEST "sha512"
> 
> The file permissions assign to the file ~/easy-rsa/vars are u=rw,go=, where the file owner is the owner of ~/
> 
> I’ve also tried an ownership definition of u=rw,go=r, but this makes no difference.
> 
> When I run the commands:
> 
> ./easyrsa init-pki
> ./easyrsa build-ca
> 
> and then check the created certificate with: openssl x509 -noout -text -in ~/easy-rsa/pki/ca.crt
> 
> I find:
> 
> Signature Algorithm: sha256WithRSAEncryption
> Public Key Algorithm: rsaEncryption
> RSA Public-Key: (2048 bit)
> 
> This is not what I had defined in ~/esay-rsa/vars.
> 
> Any pointers on how to get this working will be appreciated.
> 
> Kind regards,
> 
> Bruce
> 
> 
> 
> _______________________________________________
> Openvpn-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsC5BAEBCgBtBYJnol3TCZBPl5z2a5C4nUUUAAAAAAAcACBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3JnpYUuVXHh5MBr3LV6uomFhv5ul1g9oMoFsXsR
6xkl8wYWIQQJvD1EZ6ONcnnFVVVPl5z2a5C4nQAA9RMH/R10S9ARpe8KZ/I/
r8gr5v/+bI4yW5mNKcvNp2ooQDf+RK9MckvISQNE++F4oZJJUCpp9Kph3ea2
jnSKskxYZJ9YJCgXR+8O544dRfsbjOLCtJc4rE1dAaO5fJcC3Vp0M2xKuByB
jLwYG/RWlgt3BVZKfgBHctAmxRCm5GDAhCqgCcnP4x+HYOVCTyxor2sEfr70
uoS5ge7MSyi3+W6Hu2tsHG6ZTfvIzeiamEQwn+UUn84UpQdhUYsXIP/zXPc0
VaKR+JUqs/eRN+WFBVmFmtr6H1vrjUMuYLoBpBNLHxSR20jK734Sls/NzyOA
3Dz9O5jHUjlGSBRQHtr1sOgG61U=
=rCdM
-----END PGP SIGNATURE-----

[Openvpn-users] easyrsa build-ca does not use my var file

[Bruce B. <bru...@gm...>]

Hello everyone,

Environment: Debian 11.11

easyrsa version 3.0.8

Issue:

I’m trying to initialise and build my intermediate CA

easyrsa build-ca does not use my modified variables when it creates my new CA.

My custom variables are in the file “vars" in my ~/easy-rsa directory 

The vars file is a copy of the file “vars.example"

in vars, I have modified the following variables:

set_var EASYRSA        “~/easy-rsa/"
set_var EASYRSA_KEY_SIZE        4096
set_var EASYRSA_DIGEST          "sha512"

The file permissions assign to the file ~/easy-rsa/vars are u=rw,go=, where the file owner is the owner of ~/

I’ve also tried an ownership definition of u=rw,go=r, but this makes no difference.

When I run the commands:

./easyrsa init-pki
./easyrsa build-ca

and then check the created certificate with: openssl x509 -noout -text -in ~/easy-rsa/pki/ca.crt

I find:

Signature Algorithm: sha256WithRSAEncryption
Public Key Algorithm: rsaEncryption
    RSA Public-Key: (2048 bit)

This is not what I had defined in ~/esay-rsa/vars.

Any pointers on how to get this working will be appreciated.

Kind regards,

Bruce

[Openvpn-users] Easy-RSA CVE Announcment

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

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

Hi,

Easy-RSA has issued it's first CVE.

During the transitionary phase between OpenSSL v1.1.x and v3.x.x
a minor weakness was discovered when encryption the CA private key.

CVE Record:
* https://www.cve.org/CVERecord?id=CVE-2024-13454

Full details:
* https://community.openvpn.net/openvpn/wiki/CVE-2024-13454

Bug report:
* https://github.com/OpenVPN/easy-rsa/issues/1122

Thanks are given to the help and guidance received,
while confirming this CVE.

If there are further questions then please feel free to ask.

Kind Regards
Richard Bonhomme.

On behalf of OpenVPN & Easy-RSA.

Sent with Proton Mail secure email.
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsC5BAEBCgBtBYJnoQR1CZBPl5z2a5C4nUUUAAAAAAAcACBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3Jn3Gu49ybv2mRAB8J0EVehHzJbtiVxBjPL4O7D
Xnp8gysWIQQJvD1EZ6ONcnnFVVVPl5z2a5C4nQAA7aMIAIGmvQOaatP8Gdor
pU1VqPzji84e+rz2PiTCZtqMdwa8uHhYD0z1PycrAOBU/F/zGmFdsC1z1SRm
xXnHuGKn3RRiqzAPVaNCoHAx5tA1mV436QlZOtmUKt+RtadKt4ZZeT20Dt2i
zioM1YLbCgv+BNOWUEwhvhtpNmwE+0RpCrw4YQLc3DNCjF5P3mAQI7naq/LZ
00l1KPPxp5ulbWtLIgqtXMxsgSbydK1wjNJvf5GZDlADFc5BbHHC5RoPjQZm
Eezci+9LdAH5xa6G1l9tOA/8F3qgx1nF/rx7VzWspYRIMeF9B57S831TN3z4
dAOsomGnxaeO1zggz8XRLTeyYYc=
=U8pi
-----END PGP SIGNATURE-----

[Openvpn-users] OpenVPNConnect: Support of IOS Keychain

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

We have the requirement to make the key & cert used within an openvpn
connection profile not exportable.

So we thought it would be a sensible approach to install key & cert
into the IOS Keychain, but currently I'm unsure if openvpnConnect
(3.5.1) can actually use them.

The documentation seems to suggest that exporting from the keychain an
dimporting into openvpnConnect (and later referencing the imported
key/cert)

Is that approach supported at all?

-- 
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] OpenVPN 2.6.13 released

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

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

This is a bugfix release.

Feature changes:

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

Security fixes:

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

Notable bug fixes:

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

Windows MSI changes since 2.6.12:

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

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

More details can be found in the Changes document:

<https://github.com/OpenVPN/openvpn/blob/release/2.6/Changes.rst>

(The Changes document also contains a section with work-arounds for
common problems encountered when using OpenVPN with OpenSSL 3)

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

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

Debian and Ubuntu packages are available in the official apt repositories:

<https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos#DebianUbuntu:UsingOpenVPNaptrepositories>

On Red Hat derivatives we recommend using the Fedora Copr repository.

<https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-release-2.6/>

Kind regards,
-- 
  Frank Lichtenheld

Re: [Openvpn-users] OpenVPN and CWE-316?

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

On Tue, Aug 13, 2024 at 12:57:49PM +0200, Jakob Curdes wrote:
> The original seccuvera article states that OpenVPN (I assume they mean the
> Windows client) is "vulnerable" to this weakness and leaves data like
> emails, passwords and 2FA codes in the main memory after the program is
> closed. I have not tested this myself so I canot say if that is true.

On Mon, Aug 19, 2024, 10:43 AM Gert Doering <ge...@gr...> wrote:

> Hi,
>
> On Sun, Aug 18, 2024 at 07:15:44PM +0200, H H F wrote:
> > My password manager now all passwords are gone, so makes sense.
>
> This sentence does not make very much sense...
>
> 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 mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
>

[Openvpn-users] OpenVPN 3 Linux v24 released

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

OpenVPN 3 Linux v24 (Stable release)

The v24 release is another stable release.  This resolves issues
reported in several earlier releases and improves OpenVPN 3 Linux
in several areas.


* Improvement: Add --dns option support

    DNS resolver settings has been troublesome for many years, since
    there are slightly different implementations which handles the
    possible pushed DNS options differently between OS platforms and
    even across client implementations on a single platform.  This
    is being attempted resolved by a new --dns option which can be
    used instead of the various --dhcp-option settings related to
    DNS.

    The --dns option has been available since OpenVPN 2.6.  The
    OpenVPN 3 Core Library has had this support v3.7.  But the needed
    processing of this option has been lacking in OpenVPN 3 Linux
    until now.

    With the --dns option, it provides possibilities to configure
    more modern DNS features such as split-DNS, DNS-over-TLS and
    DNSSEC.  This will in most cases work out-of-the box when using
    systemd-resolved as the local DNS resolver - but it also depends
    on the features available in systemd-resolved in the Linux
    distribution being used.

    Currently, systemd-resolved does not support DNS-over-HTTPS [1].
    If this is being attempted, the connection will disconnect.
      For users only using /etc/resolv.conf, only the traditional
    DNS server and search domain settings will be configured.
    All the additional DNS features will be ignored.

    [1] <https://github.com/systemd/systemd/issues/8639>


* Improvement: Provide better details about the remote server

    The openvpn3 sessions-list would list a "Session name" when
    a client session has successfully connected to a remote server.
    This information was static and not changed since the initial
    connection.  If the VPN configuration profile had more and
    different --remote lines, only the first connection would be
    reflected in this "Session name".

    In v24 this has been changed by querying the VPN client
    process about the server it is currently connected to.  The
    "Session name" line has thus been replaced with a "Connected to"
    line which will also include details about connection protocol,
    DCO mode and port number in use.

    Note: Due to an issue in the OpenVPN 3 Core Library, the
    port number is currently not provided on DCO connections.


* Improvement: Provide better messages to end-user on session start issues

    When starting a VPN session, it could fail for various reasons.
    The reason itself was never provided to the end-user starting the
    session and it was needed to dig into the log files to figure out
    why it was failing.

    With this release, the openvpn3 session-start command will present
    an end-user friendly reason when the client process provides a
    reason for the failure.  This reduces the need to search the
    logs for the initial understanding why it failed.


* Improvement: Better error message when modifying sealed configurations

    When attempting to modify a sealed VPN configuration profile
    (which are read-only), a fairly verbose, debug-like error
    message was provided to the user.  This has been improved
    to give a more end-user friendly error message instead.


* Improvement: Upgrade to OpenVPN 3 Core Library v3.10.4

    This resolves an issue where a configuration profile using
    --pull-filter with single quotes instead of double quotes would
    be incorrectly parsed.

    There could also appear issues for VPN sessions with DCO enabled
    could fail if --inactive was used.  This has been fixed in this
    Core Library release.


* Bugfix: Starting VPN sessions could fail on slower systems

    In some cases, the openvpn3-service-backendstart would not
    start quickly enough.  This would result in the Session Manager
    as it would not get a response back soon enough that the
    VPN client process has been started - and it would fail
    the VPN session start.

    With the updated GDBus++ and further improvements in the
    Session Manager, it will now be more graceful to slower
    starting services and not fail as quickly.  This allows
    the supporting helper services to be able to start properly
    before interacting with them.


* Bugfix: Add support for dhcp-option ADAPTER_DOMAIN_SUFFIX

    The ADAPTER_DOMAIN_SUFFIX is one of these ambiguous
    --dhcp-options being treated differently across client
    implementations.  This setting has so far been ignored in
    OpenVPN 3 Linux until this release.  The best user experience
    seemed to be achieved by parsing this as an alias to the
    DOMAIN-SEARCH feature.  This seems to align best with
    common user expectations.


* Bugfix: DNS search domains might not be removed from /etc/resolv.conf

    Under some unclear situations, the DNS search domains was not
    always removed in /etc/resolv.conf.  This has been an open issue
    for a long time, but it seems to have improved since the v22_dev
    with GDBus++.  We still see this occasionally on a few Linux
    distributions with systemd-resolved.  But since we also see the
    systemd-resolved accepting the DNS updates and removals, we
    believe this is might be more an issue in systemd-resolved at
    this point.  This issue appears now only with systemd-resolved
    and is not reproducible in all environments.


* Bugfix: Duplicated name servers or search domains to /etc/resolv.conf

    In prior releases, when the Network Configuration service was
    configured to use /etc/resolv.conf for DNS resolving it could
    append duplicated DNS name servers and search domains if
    duplicates where pushed or added by other VPN connections or
    present prior to starting the VPN session.

    In v24 duplicated name servers and search domains are filtered
    out to only have a single presence of them in /etc/resolv.conf.


* Bugfix: openvpn3 sessions-list does not reflect the correct DCO status

    When running the openvpn3 sessions-list and
    openvpn3-admin sessionmgr-service --list-sessions commands, the
    DCO status was not necessarily reflecting the reality.

    Typically, if the VPN client process failed to activate and use
    the DCO kernel module, it would still be listed as DCO enabled
    while in reality being a normal tun interface.

    This has been resolved in v24 where it will now query the VPN
    client process for the actual DCO status - not just the
    configured and requested DCO mode.


* Bugfix: Stray VPN sessions not cleaned up

    In cases where a VPN session have had a log forwarder enabled
    (like via the openvpn3 log command) and that log forwarder
    has been stopped, the VPN session would be lingering
    in the Session Manager as a stray session with no available
    session details.  This is also seen via openvpn3 sessions-list.
    Attempting to remove the session using openvpn3 session-manage
    would fail with an error.

    This has been resolved in v24, where the error situations which
    might appear if a previous log forwarder could not be identified
    are now properly handled and will not block the internal session
    clean-up in the Session Manager.


* Bugfix: Spurious CreateVirtualInterface() errors when re-starting 
failing sessions

    In some special situations where a running VPN session stopped
    and attempted restarted after a openvpn3 session-manage --cleanup,
    the tunnel would fail with various CreateVirtualInterface() and
    TUN_SETUP_FAILED errors.

    The session management code has been gradually improved since
    v22_dev, v23 and now v24 - where stopped and failing sessions
    are handled better and removed correctly in the Session Manager.


* Bugfix: openvpn3 log with --session-path does not work

    In some scenarios, using openvpn3 log --session-path did not
    work and did not report any log events.  This has been under
    investigation for a long time and this issue has not been seen
    since the release with v22_dev and GDBus++.  We consider this
    issue resolved with the updated openvpn3-service-log service in
    the v22_dev release.


* Bugfix: openvpn3 session-start fails with only 2FA authentication

    The openvpn3 session-start would fail to start a session if the
    configuration profile would only require 2FA authentication.  This
    has also been fixed since the v22_dev with GDBus++ release which
    included a refactoring of how VPN sessions were established.


* Bugfix: Spurious GLib error messages

    The shell completion (with bash-completion installed) could
    often appear with disturbing and confusing GLib-GObject-CRITICAL
    errors in the output.  This has most likely been fixed since
    v22_dev and the migration to the GDBus++ library.  Since this did
    not happen each time and it varied a bit which Linux distributions
    it happened on we've kept this on our radar for some time.  We
    now feel more confident this type of errors is being handled
    properly and should not disturb the user any more.


Known issues:

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


Credits
-------

Thanks goes to those continuing testing and reporting issues. Razvan
Cojocaru has continued to improve aspects of OpenVPN 3 Linux and
Petr Portnov has provided fixes enabling OpenVPN 3 Linux to become
available in NixOS.


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

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

Red Hat Enterprise Linux 10 Beta is in also tech preview.
Fedora 39 has reached EOL and is no longer supported.

Installation and getting started instructions can be found here:

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


--
kind regards,

David Sommerseth
OpenVPN Inc


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

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

9ecf8dccdbc601c4325b0248db7cb1e39c8689e3b99f5fc801b42056d68a7256 
openvpn3-linux-24.tar.xz
a3d6bd735d46958f2458484a4338eaf894e710ac895852c9c734671a2e46e821 
openvpn3-linux-24.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: v24
     git commit: 92c63ad9511dfe730416d4ac63c7cd0353638471

   - 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 v23 to v24 ---------------------------------------

David Sommerseth (56):
        configmgr: Improve error message on sealed config profiles
        configmgr: Switch to std::set<> for target lists for ACL checks
        docs: Re-enable doxygen build target
        client: Add support for --dhcp-option ADAPTER_DOMAIN_SUFFIX
        client: Stop running VPN clients in client destructor
        client: Properly plug-in DBus::MainLoop handling in 
BackendClientObject
        client: Make BackendSignals::LogFATAL() thread safe
        client: Extend BackendSignals to have access to a DBus::MainLoop 
object
        client: Improve exception handling when starting client worker 
thread
        client: Handle COMPRESS_ERROR events
        ovpn3cli/session-start: Retrieve more status details when 
throwing SessionException
        client: Fix incorrect error message in 
NetCfgTunBuilder::socket_protect()
        client: Move DNS scope logging from LOG_DEBUG to LOG_VERB2
        cleanup: Remove pointless local scope 
ovpn3cli::session::start_session()
        configmgr: Add debug option --use-session-bus
        log: Rework the tear-down of ProxyLogEvents objects
        netcfg: Cleanup NetCfgException
        dbus/signals: Add Signals::StatusChange::LastEvent()
        client: Add BackendSignals::LastStatusEvent()
        client: Add new property: connection
        sessionmgr:  Implement extraction of connection details from client
        client: Extract DCO status from ConnectionInfo when available
        ovpn3cli/sessions-list: Improve session information with 
connection details
        build: Minor tweaks to D-Bus/systemd/state-dir build options
        netcfg/proxy: Make all proxy methods const methods
        netcfg/proxy: Extend NetCfgProxy::Device with 
openvpn::DnsOptions parsing
        client: Enable --dns option parsing in the VPN client
        netcfg/resolved: Extend systemd-resolved proxy with DNSSEC support
        policy/netcfg: Grant privilege to set DNSSEC on systemd-resolved
        netcfg/systemd-resolved: Implement support for setting the 
DNSSEC mode
        netcfg: Extend NetCfgDevice with D-Bus APIs for DNSSEC
        netcfg/proxy: Extend NetCfgProxy::Device with DNSSEC support
        netcfg/proxy: Extend NetCfgProxy::Device::AddDnsOptions() with 
DNSSEC support
        netcfg/resolved: Extend systemd-resolved proxy with SetDNSOverTLS()
        policy/netcfg: Grant privilege to set DNS-overTLS in 
systemd-resolved
        netcfg/systemd-resolved: Implement support for setting the DNS 
transport mode
        netcfg/systemd-resolved: Refactor and simplify the code
        netcfg: Extend NetCfgDevice with D-Bus APIs for setting DNS 
transport
        netcfg/proxy: Extend NetCfgProxy::Device with DNS transport support
        netcfg/proxy: Extend NetCfgProxy::Device::AddDnsOptions() with 
DNS transport support
        codestyle: Fix misc deviating code style to conform with 
.clang-format
        dbus/signals: Include iostream
        client: Improve debugging in openvpn3-service-backendstart
        client/backendstart: Move LogServiceProxy inside the service object
        sessionmgr: Add RegistrationRequest debug logging
        sessionmgr: Allow net.openvpn.v3.backends to settle before 
accessing it
        ovpn3cli: Start a glib2 MainLoop in the command line tools
        sessionmgr/proxy: Replace sleep with waiting for SESS_CREATED signal
        ovpn3cli/sessions-list: Don't show "Connected to" without any 
details
        netcfg/proxy: Disable support for DoH
        core: Update to latest OpenVPN 3 Core Library v3.10.4
        vendor: Update to ASIO 1.32.0
        client: Fix missing handling of the delayed shutdown thread in 
BackendSignals
        sessionmgr: Fix misbehaviour if GetUID() fails in 
Session::helper_stop_log_forwards()
        client: Add support for a couple more TLS error events
        ovpn3cli: Improve mainloop start synchronisation

Petr Portnov (2):
        build: reduce hardcoded 'asio_path'
        build: allow installation directories' customization

Razvan Cojocaru (7):
        cleanup: Remove stray semicolons
        configmgr/overrides: Remove OverrideType::invalid
        configmgr/overrides: Use glib2::DataType::Extract(value)
        configmgr/overrides: Remove struct OverrideValue
        configmgr/overrides: Rename ValidOverride -> Override
        sessionmgr: Remove unused Session::connection_started bool
        netcfg/resolvconf-file: Don't add nameservers that already exist

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

Re: [Openvpn-users] OpenVPN Certificates renewal

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

Forgot to include the list in my reply. Below are the steps I did to use
stacked certificates so as to gradually roll out new certs:

https://alexkaouris.medium.com/openvpn-roll-out-new-certificates-5ddcd1b3a6f3

Thanks to Rui for the tips.

Cheers,
Alex

On Wed, 27 Nov 2024 at 7:13 PM, Rui Santos <rs...@ru...> wrote:

> Great to hear that 🙂
>
> Your notes were far better than my text on the mailing list 😞
> Could you probably share those same notes to the list, it may help others?
>
> Cheers,
> Rui
>
> On Wed, 27 Nov 2024, 17:00 Alex K, <rig...@gm...> wrote:
>
>> Yes Rui, it worked great. Using stacked CA at both sides provides the
>> flexibility to roll out the certs gradually.
>>
>> Thanks for the pointer. It was really helpful.
>>
>> On Wed, 27 Nov 2024 at 9:52 AM, Rui Santos <rs...@ru...> wrote:
>>
>>> Hi Alex,
>>>
>>> Did it work as you expected?
>>>
>>> Regards,
>>> Rui
>>>
>>> On Tue, 26 Nov 2024, 22:55 Alex K, <rig...@gm...> wrote:
>>>
>>>> Hi Rui,
>>>>
>>>> Thanks for your reply. I was able to stack both CAs into the same
>>>> config at server and client side and simulated a certs roll-out. I did the
>>>> following steps:
>>>>
>>>> - issue new CA and server certificates
>>>> - create a stacked CA (containing the old and the new CA) and load on
>>>> server and clients.
>>>> - roll-out new client certs
>>>> - eventually decommission old server certs and install new ones.
>>>>
>>>> On Tue, 26 Nov 2024 at 7:41 PM, Rui Santos <rs...@ru...>
>>>> wrote:
>>>>
>>>>> Hi Alex,
>>>>>
>>>>> Both client and server accept certificates from a specific trusted
>>>>> Certificate Authority. If you keep the same CA, then you can just
>>>>> issue new certificates for server and clients, using that same CA.
>>>>>
>>>>> If you have a new CA, you'll need to include both CA's, for both
>>>>> server and clients in advance, on their configuration file. Once it's
>>>>> propagated, you should be able to issue new certificates using the new
>>>>> CA, and they'll be accepted.
>>>>> Once all are running smoothly using the new CA, just remove the old
>>>>> one from the config files :)
>>>>>
>>>>> Hope this helps.
>>>>>
>>>>> Regards,
>>>>> Rui
>>>>>
>>>>>
>>>>> On Tue, Nov 26, 2024 at 5:33 PM Alex K <rig...@gm...>
>>>>> wrote:
>>>>> >
>>>>> > Hi all,
>>>>> >
>>>>> > I was wondering how can one tackle the issue of issuing new
>>>>> certificates to clients and the server which expire at some point with the
>>>>> minimum downtime. The issue is that it seems I need to go with a big bang
>>>>> approach where the server certificates are replaced with new ones and then
>>>>> have all the clients updated somehow to use the new client certificates.
>>>>> This seems like a headache when one has to manage hundreds of remote
>>>>> clients that might not be accessible out of vpn.
>>>>> >
>>>>> > Is there any alternative approach which can resemble a gradual
>>>>> roll-out? Perhaps through the use of additional vpn port at server side
>>>>> which uses the new certificates and have clients updated to use the new
>>>>> port and fail back to the previous one in case of issue? Looked also if I
>>>>> could load a stacked certificate at the server and have the same server
>>>>> authenticate both existing client certificates and new ones but the server
>>>>> was complaining about the certificate.
>>>>> >
>>>>> > Apart from automating this with other tooling such as Ansible or
>>>>> code, is there any other approach or openvpn feature that might help with
>>>>> such kind of migrations? How do you usually tackle this problem?
>>>>> >
>>>>> > Thanks,
>>>>> > Alex
>>>>> > _______________________________________________
>>>>> > Openvpn-users mailing list
>>>>> > Ope...@li...
>>>>> > https://lists.sourceforge.net/lists/listinfo/openvpn-users
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Rui Santos
>>>>> Veni, Vidi, Linux
>>>>>
>>>>

Re: [Openvpn-users] OoenVPN Certificates renewal

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

Hi Alex,

Both client and server accept certificates from a specific trusted
Certificate Authority. If you keep the same CA, then you can just
issue new certificates for server and clients, using that same CA.

If you have a new CA, you'll need to include both CA's, for both
server and clients in advance, on their configuration file. Once it's
propagated, you should be able to issue new certificates using the new
CA, and they'll be accepted.
Once all are running smoothly using the new CA, just remove the old
one from the config files :)

Hope this helps.

Regards,
Rui


On Tue, Nov 26, 2024 at 5:33 PM Alex K <rig...@gm...> wrote:
>
> Hi all,
>
> I was wondering how can one tackle the issue of issuing new certificates to clients and the server which expire at some point with the minimum downtime. The issue is that it seems I need to go with a big bang approach where the server certificates are replaced with new ones and then have all the clients updated somehow to use the new client certificates. This seems like a headache when one has to manage hundreds of remote clients that might not be accessible out of vpn.
>
> Is there any alternative approach which can resemble a gradual roll-out? Perhaps through the use of additional vpn port at server side which uses the new certificates and have clients updated to use the new port and fail back to the previous one in case of issue? Looked also if I could load a stacked certificate at the server and have the same server authenticate both existing client certificates and new ones but the server was complaining about the certificate.
>
> Apart from automating this with other tooling such as Ansible or code, is there any other approach or openvpn feature that might help with such kind of migrations? How do you usually tackle this problem?
>
> Thanks,
> Alex
> _______________________________________________
> Openvpn-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-users



-- 
Rui Santos
Veni, Vidi, Linux

[Openvpn-users] OoenVPN Certificates renewal

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

Hi all,

I was wondering how can one tackle the issue of issuing new certificates to
clients and the server which expire at some point with the minimum
downtime. The issue is that it seems I need to go with a big bang approach
where the server certificates are replaced with new ones and then have all
the clients updated somehow to use the new client certificates. This seems
like a headache when one has to manage hundreds of remote clients that
might not be accessible out of vpn.

Is there any alternative approach which can resemble a gradual roll-out?
Perhaps through the use of additional vpn port at server side which uses
the new certificates and have clients updated to use the new port and fail
back to the previous one in case of issue? Looked also if I could load a
stacked certificate at the server and have the same server authenticate
both existing client certificates and new ones but the server was
complaining about the certificate.

Apart from automating this with other tooling such as Ansible or code, is
there any other approach or openvpn feature that might help with such kind
of migrations? How do you usually tackle this problem?

Thanks,
Alex

Re: [Openvpn-users] hide openvpn traffic completely

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

Hi,

On Tue, Nov 19, 2024 at 08:03:52PM +0000, J.W...@mi... wrote:
> How about feeding OpenVPN through Stunnel?

Sure.  But that is not "an openvpn thing" but "use a generic method
to hide traffic".  And you need infrastructure on both ends to do that.

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] hide openvpn traffic completely

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

How about feeding OpenVPN through Stunnel?


From: "Gert Doering" <ge...@gr...<mailto:ge...@gr...>>
Date: Tuesday, 19 November 2024 at 17:53:32
To: "sergio" <se...@ou...<mailto:se...@ou...>>
Cc: "Tincantech via Openvpn-users" <ope...@li...<mailto:ope...@li...>>
Subject: Re: [Openvpn-users] hide openvpn traffic completely

Hi,

On Tue, Nov 19, 2024 at 07:03:47PM +0300, sergio wrote:
> I thought tls-crypt makes the traffic indistinguishable from random data,
> and was surprised to see P_DATA_V2 sent by the client in Wireshark.
>
> Is there a way to completely hide OpenVPN traffic and make it
> indistinguishable from random data?

No.

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] hide openvpn traffic completely

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

On 19/11/2024 20:44, sergio wrote:
> On 19/11/2024 19:49, Gert Doering wrote:
> 
>> No.
> 
> I would like more details.
> 
> Not sure why, but in my setup wireshark detects P_DATA_V2 packets only 
> on tun connection and does not on tap. So it sounds like it's possible 
> to completely hide openvpn traffic. (Though possible wireshark is fooled 
> by 1195 port used for tap.)

What is shown in Wireshark depends on the dissector implementation - 
nothing else.

It could well be that the dissector is activated by the 1194/UDP port.
If with TAP you are using 1195/UDP, it's possible that wireshark is 
therefore missing it.

You can select the packets and force them being decoded with the OpenVPN 
dissector (you may want to look in the wireshark doc about how do to it).

What Gert wanted to say is that OpenVPN per se has no option to 
obfuscate its own traffic and make it undetectable.

You may want to try with external tools and pipe the openvpn traffic 
through them.

Regards,


-- 
Antonio Quartulli

Re: [Openvpn-users] hide openvpn traffic completely

[sergio <se...@ou...>]

On 19/11/2024 19:49, Gert Doering wrote:

> No.

I would like more details.

Not sure why, but in my setup wireshark detects P_DATA_V2 packets only 
on tun connection and does not on tap. So it sounds like it's possible 
to completely hide openvpn traffic. (Though possible wireshark is fooled 
by 1195 port used for tap.)

-- 
sergio.

Re: [Openvpn-users] hide openvpn traffic completely

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

Hi,

On Tue, Nov 19, 2024 at 07:03:47PM +0300, sergio wrote:
> I thought tls-crypt makes the traffic indistinguishable from random data,
> and was surprised to see P_DATA_V2 sent by the client in Wireshark.
> 
> Is there a way to completely hide OpenVPN traffic and make it
> indistinguishable from random data?

No.

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] hide openvpn traffic completely

[sergio <se...@ou...>]

Hello,

I thought tls-crypt makes the traffic indistinguishable from random 
data, and was surprised to see P_DATA_V2 sent by the client in Wireshark.

Is there a way to completely hide OpenVPN traffic and make it 
indistinguishable from random data?

-- 
sergio.

Re: [Openvpn-users] AUTH_FAILED only on a client

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

Hi,

On Sat, Nov 09, 2024 at 10:45:10AM +0100, Pol Hallen wrote:
> 2024-11-09 10:35:08 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
> 2024-11-09 10:35:08 AUTH: Received control message: AUTH_FAILED

The server is telling you that you're not welcome.  *Why* can only
be answered by checking the server logs.

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] AUTH_FAILED only on a client

[Pol H. <pol...@gm...>]

Hello guys!

I've same working linux clients with openvpn 2.4.7 (debian) with:

remote IP PORT
client
dev tap
proto udp
nobind
user nobody
group nobody
persist-key
persist-tun
keepalive 10 60
cipher AES-256-CBC
auth SHA512
tls-cipher 
TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client01.crt
key /etc/openvpn/client01.key
tls-auth /etc/openvpn/ta.key 1
comp-lzo
verb 3
mute 20
ping-restart 0
remote-cert-tls server
askpass /etc/openvpn/askpass
auth-user-pass /etc/openvpn/pass

on a new debian 12 client (openvpn 2.6.3) I have same config with 
different client key but I can't connect:

2024-11-09 10:35:04 TLS: Initial packet from [AF_INET]IP, sid=3f598f7a 
e6dc1665
2024-11-09 10:35:04 VERIFY OK: depth=1, C=IT, ST=IT, L=Italy, O=Italy, 
OU=Italy, CN=noname.org, name=VPN, ema...@no...
2024-11-09 10:35:04 VERIFY KU OK
2024-11-09 10:35:04 Validating certificate extended key usage
2024-11-09 10:35:04 ++ Certificate has EKU (str) TLS Web Server 
Authentication, expects TLS Web Server Authentication
2024-11-09 10:35:04 VERIFY EKU OK
2024-11-09 10:35:04 NOTE: --mute triggered...
2024-11-09 10:35:07 2 variation(s) on previous 20 message(s) suppressed 
by --mute
2024-11-09 10:35:07 [server] Peer Connection Initiated with [AF_INET]IP:PORT
2024-11-09 10:35:07 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL 
reinit_src=1
2024-11-09 10:35:07 TLS: tls_multi_process: initial untrusted session 
promoted to trusted
2024-11-09 10:35:08 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
2024-11-09 10:35:08 AUTH: Received control message: AUTH_FAILED
2024-11-09 10:35:08 SIGTERM[soft,auth-failure] received, process exiting

any idea to solve?
thanks!

-- 
Pol