OpenVPN setup does not offer what i need for my vpn server....

Vlad Nirky

@gpatel-fr
I guess TLS key has to be feed at the begining of the connection (as it does in openvpn connection)

With the NetworkManager

phablet@ubuntu-phablet:~$ route -v
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.238.198.1    0.0.0.0         UG    50     0        0 tun0
default         192.168.43.1    0.0.0.0         UG    600    0        0 wlan0
10.238.198.0    0.0.0.0         255.255.255.0   U     50     0        0 tun0
171.167-240-81. 192.168.43.1    255.255.255.255 UGH   50     0        0 wlan0
147.69.137.0    0.0.0.0         255.255.255.192 U     0      0        0 rmnet_data0
192.168.43.0    0.0.0.0         255.255.255.0   U     600    0        0 wlan0
192.168.43.1    0.0.0.0         255.255.255.255 UH    50     0        0 wlan0
192.168.128.0   0.0.0.0         255.255.254.0   U     50     0        0 tun0

But i was not able to ping 192.168.129.161 (my PC)

No NAT/MASQUERADE on the openvpn server?

No idea, i have tried to had
push "route 192.168.128.0 255.255.254.0"
push "dhcp-option DNS 192.168.128.1"
in server config but without result.(/etc/openvpn/server.conf)

sudo systemctl status NetworkManager
and
sudo systemctl status openvpn
gave me some clues (such as the TLS issue)

I haven't had time yet to look at the various logs

VPN on my PC works fine with the actual openvpn server but not the phone...

gpatel-fr

@Vlad-Nirky said in OpenVPN setup does not offer what i need for my vpn server....:

Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.238.198.1 0.0.0.0 UG 50 0 0 tun0
default 192.168.43.1 0.0.0.0 UG 600 0 0 wlan0

2 default routes ? Is this really recommended by the Openvpn doc ?

All Vpns I have seen have ONE default route going by the standard network interface (wlan0 in your case), and a route for the specifc network to contact through the VPN, this route being created dynamically by Openvpn on instructions from the server. 2 default routes seems a recipe for getting random results.

Vlad Nirky

@gpatel-fr
My first openvpn...
It is usable (Ratchanan has connected my phone to debug some issues) and i use it to connect to my proxmox infra.

[jll @ rpi3 - 06:33:20 ]  ~ 
> cat /etc/openvpn/server.conf
dev tun
proto udp
port 1194
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/rpi3_9b0ae2d9-f297-4706-ab24-8a9d63b3b51f.crt
key /etc/openvpn/easy-rsa/pki/private/rpi3_9b0ae2d9-f297-4706-ab24-8a9d63b3b51f.key
dh none
ecdh-curve prime256v1
topology subnet
server 10.238.198.0 255.255.255.0
# Set your primary domain name server address for clients
push "dhcp-option DNS 10.238.198.1"
push "block-outside-dns"
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"
client-to-client
client-config-dir /etc/openvpn/ccd
keepalive 15 120
remote-cert-tls client
tls-version-min 1.2
 tls-crypt /etc/openvpn/easy-rsa/pki/ta.key
cipher AES-256-CBC
auth SHA256
user openvpn
group openvpn
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 3
#DuplicateCNs allow access control on a less-granular, per user basis.
#Remove # if you will manage access by user instead of device. 
#duplicate-cn
# Generated for use by PiVPN.io

Vlad Nirky

@gpatel-fr
On the PC
Connected through my wife phone

[jll @ fedora - 06:42:15 ]  ~ 
> ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether fe:aa:b6:35:ee:2d brd ff:ff:ff:ff:ff:ff permaddr 94:e6:f8:ed:7d:c6
    altname wlp0s20f3
    altname wlx94e6f7ed7dc6
    inet 192.168.43.91/24 brd 192.168.43.255 scope global dynamic noprefixroute wlo1
       valid_lft 3583sec preferred_lft 3583sec
    inet6 2a02:a020:3ca:ad84:2f98:edb3:fe4a:5d89/64 scope global dynamic noprefixroute 
       valid_lft 3583sec preferred_lft 3583sec
    inet6 fe80::fa56:6baf:9454:41db/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 7a:36:73:60:85:f6 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 10.238.198.3/24 brd 10.238.198.255 scope global noprefixroute tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::1ba:8201:6599:7bb8/64 scope link stable-privacy proto kernel_ll 
       valid_lft forever preferred_lft forever
[jll @ fedora - 06:42:20 ]  ~ 
> route -v
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    50     0        0 tun0
default         _gateway        0.0.0.0         UG    600    0        0 wlo1
10.238.198.0    0.0.0.0         255.255.255.0   U     50     0        0 tun0
171.167-240-81. _gateway        255.255.255.255 UGH   50     0        0 wlo1
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.43.0    0.0.0.0         255.255.255.0   U     600    0        0 wlo1
_gateway        0.0.0.0         255.255.255.255 UH    50     0        0 wlo1
[jll @ fedora - 06:49:12 ]  ~ 
> ping 10.238.198.1
PING 10.238.198.1 (10.238.198.1) 56(84) octets de données.
64 octets de 10.238.198.1 : icmp_seq=1 ttl=64 temps=37.5 ms
64 octets de 10.238.198.1 : icmp_seq=2 ttl=64 temps=48.1 ms
^C
--- statistiques ping 10.238.198.1 ---
2 paquets transmis, 2 reçus, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 37.533/42.797/48.062/5.264 ms
[jll @ fedora - 06:49:24 ]  ~ 
> ping 10.238.198.2
PING 10.238.198.2 (10.238.198.2) 56(84) octets de données.
De 10.238.198.1 icmp_seq=2 Rediriger l'hôte(Nouveau sautsuivant : 10.238.198.2)
De 10.238.198.1 icmp_seq=3 Rediriger l'hôte(Nouveau sautsuivant : 10.238.198.2)
De 10.238.198.1 icmp_seq=4 Rediriger l'hôte(Nouveau sautsuivant : 10.238.198.2)
^C
--- statistiques ping 10.238.198.2 ---
4 paquets transmis, 0 reçus, +3 erreurs, 100% packet loss, time 3031ms

[jll @ fedora - 06:44:05 ]  ~ 
> ping 192.168.129.64
PING 192.168.129.64 (192.168.129.64) 56(84) octets de données.
64 octets de 192.168.129.64 : icmp_seq=1 ttl=254 temps=51.0 ms
64 octets de 192.168.129.64 : icmp_seq=2 ttl=254 temps=49.7 ms
64 octets de 192.168.129.64 : icmp_seq=3 ttl=254 temps=51.5 ms
^C
--- statistiques ping 192.168.129.64 ---
3 paquets transmis, 3 reçus, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 49.699/50.727/51.526/0.763 ms

Vlad Nirky

@gpatel-fr
I think a have something interresting in the openvpn server log (as you expected)


After phone connexion to VPN
root@rpi3:/var/log# 
cat openvpn.log 
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 TLS: Initial packet from [AF_INET]188.5.220.190:1210, sid=e5f0bc02 623c1eb2
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 VERIFY OK: depth=1, CN=Easy-RSA CA
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 VERIFY KU OK
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 Validating certificate extended key usage
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 VERIFY EKU OK
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 VERIFY OK: depth=0, CN=phde
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 peer info: IV_VER=2.6.14
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 peer info: IV_PLAT=linux
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 peer info: IV_TCPNL=1
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 peer info: IV_MTU=1600
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 peer info: IV_CIPHERS=AES-256-CBC
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 peer info: IV_PROTO=990
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 peer info: IV_LZO_STUB=1
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 peer info: IV_COMP_STUB=1
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 peer info: IV_COMP_STUBv2=1
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1569', remote='link-mtu 1557'
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 WARNING: 'auth' is used inconsistently, local='auth SHA256', remote='auth SHA1'
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 256 bit EC, curve: prime256v1
Oct 26 07:14:56 rpi3 ovpn-server[11385]: 188.5.220.190:1210 [phde] Peer Connection Initiated with [AF_INET]188.5.220.190:1210
Oct 26 07:14:56 rpi3 ovpn-server[11385]: MULTI: new connection by client 'phde' will cause previous active sessions by this client to be dropped.  Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.
Oct 26 07:14:56 rpi3 ovpn-server[11385]: MULTI_sva: pool returned IPv4=10.238.198.2, IPv6=(Not enabled)
Oct 26 07:14:56 rpi3 ovpn-server[11385]: OPTIONS IMPORT: reading client specific options from: /etc/openvpn/ccd/phde
Oct 26 07:14:56 rpi3 ovpn-server[11385]: MULTI: Learn: 10.238.198.3 -> phde/188.5.220.190:1210
Oct 26 07:14:56 rpi3 ovpn-server[11385]: MULTI: primary virtual IP for phde/188.5.220.190:1210: 10.238.198.3
Oct 26 07:14:56 rpi3 ovpn-server[11385]: Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Oct 26 07:14:56 rpi3 ovpn-server[11385]: Outgoing Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 26 07:14:56 rpi3 ovpn-server[11385]: Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Oct 26 07:14:56 rpi3 ovpn-server[11385]: Incoming Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 26 07:14:56 rpi3 ovpn-server[11385]: SENT CONTROL [phde]: 'PUSH_REPLY,dhcp-option DNS 10.238.198.1,block-outside-dns,redirect-gateway def1,route-gateway 10.238.198.1,topology subnet,ping 15,ping-restart 120,ifconfig 10.238.198.3 255.255.255.0,peer-id 0,cipher AES-256-CBC' (status=1)
Oct 26 07:14:56 rpi3 ovpn-server[11385]: phde/188.5.220.190:1210 Authenticate/Decrypt packet error: packet HMAC authentication failed
Oct 26 07:15:00 rpi3 ovpn-server[11385]: phde/188.5.220.190:1210 Authenticate/Decrypt packet error: packet HMAC authentication failed
Oct 26 07:15:07 rpi3 ovpn-server[11385]: phde/188.5.220.190:1210 Authenticate/Decrypt packet error: packet HMAC authentication failed
Oct 26 07:15:21 rpi3 ovpn-server[11385]: phde/188.5.220.190:1210 Authenticate/Decrypt packet error: packet HMAC authentication failed

After PC connexion to VPN
///Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 TLS: Initial packet from [AF_INET]188.5.220.190:1898, sid=0bfa998b 8f16b815
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 VERIFY OK: depth=1, CN=Easy-RSA CA
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 VERIFY KU OK
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 Validating certificate extended key usage
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 VERIFY EKU OK
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 VERIFY OK: depth=0, CN=phde
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 peer info: IV_VER=2.6.15
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 peer info: IV_PLAT=linux
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 peer info: IV_TCPNL=1
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 peer info: IV_MTU=1600
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 peer info: IV_NCP=2
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 peer info: IV_PROTO=990
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 peer info: IV_LZO_STUB=1
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 peer info: IV_COMP_STUB=1
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 peer info: IV_COMP_STUBv2=1
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 256 bit EC, curve: prime256v1
Oct 26 07:25:28 rpi3 ovpn-server[678]: 188.5.220.190:1898 [phde] Peer Connection Initiated with [AF_INET]188.5.220.190:1898
Oct 26 07:25:28 rpi3 ovpn-server[678]: phde/188.5.220.190:1898 MULTI_sva: pool returned IPv4=10.238.198.2, IPv6=(Not enabled)
Oct 26 07:25:28 rpi3 ovpn-server[678]: phde/188.5.220.190:1898 OPTIONS IMPORT: reading client specific options from: /etc/openvpn/ccd/phde
Oct 26 07:25:28 rpi3 ovpn-server[678]: phde/188.5.220.190:1898 MULTI: Learn: 10.238.198.3 -> phde/188.5.220.190:1898
Oct 26 07:25:28 rpi3 ovpn-server[678]: phde/188.5.220.190:1898 MULTI: primary virtual IP for phde/188.5.220.190:1898: 10.238.198.3
Oct 26 07:25:28 rpi3 ovpn-server[678]: phde/188.5.220.190:1898 Data Channel: using negotiated cipher 'AES-256-GCM'
Oct 26 07:25:28 rpi3 ovpn-server[678]: phde/188.5.220.190:1898 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Oct 26 07:25:28 rpi3 ovpn-server[678]: phde/188.5.220.190:1898 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Oct 26 07:25:28 rpi3 ovpn-server[678]: phde/188.5.220.190:1898 SENT CONTROL [phde]: 'PUSH_REPLY,dhcp-option DNS 10.238.198.1,block-outside-dns,redirect-gateway def1,route-gateway 10.238.198.1,topology subnet,ping 15,ping-restart 120,ifconfig 10.238.198.3 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)
Oct 26 07:25:29 rpi3 ovpn-server[678]: phde/188.5.220.190:1898 PUSH: Received control message: 'PUSH_REQUEST'

gpatel-fr

@Vlad-Nirky said in OpenVPN setup does not offer what i need for my vpn server....:

overriding but not wiping out the original default gateway.

I see. I have never seen this kind of configuration where road warriors are getting their internet access routed through the server, it has always been a theoretical thing because the combined download speed of several road warriors can't exceed a fraction of the upload speed of the server - and for a small business in my country, getting a 'business quality' connection of even 40Mbits/s is expensive and not worth the extra control that this is providing, hence routing access like that would make for a miserable performance for each road warrior whose personal network download performance would often exceed the total upload speed of the server.

So this is outside of my experience with Openvpn

OtaDr

@gpatel-fr
VPN or OVPN, if it does not route to the required network, it will be on the router side. It depends on how you are able to experiment and what your options are. If you have the option to build a router from a PC, I personally have had good experience (and tested functionality with "UT") with https://www.ipfire.org. It is Linux, so a lot of things can be configured there. / Unlike a router—a company, a brand, a box where even the instructions tend to be brief....

Translated with DeepL.com (free version)

Vlad Nirky

@OtaDr @gpatel-fr
Openvpn is a cherry pick on my pihole rpi server...
The first goal was to anonymize the DNS so i have installed pihole and unbound.
The vpn is for rare take over from outdoor UT developpers to debug issue on my hardware.

I thing there is some issue in the packet decryption.
This issue don't seem to happen when i launch openvpn manually on the phone (to be confirmed) so i have something to look out there.

The openvpn are not in the same version on the different parts

[jll @ rpi3 - 07:44:11 ]  ~ 
> openvpn --version
OpenVPN 2.5.1 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Aug 25 2025
library versions: OpenSSL 1.1.1w  11 Sep 2023, LZO 2.10
Originally developed by James Yonan
Copyright (C) 2002-2018 OpenVPN Inc <sales@openvpn.net>
Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_iproute2=no enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_maintainer_mode=no enable_management=yes enable_multihome=yes enable_option_checking=no enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_shared=yes enable_shared_with_static_runtimes=no enable_silent_rules=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_werror=no enable_win32_dll=yes enable_x509_alt_username=yes with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_sysroot=no

[jll @ fedora - 07:42:40 ]  ~ 
> openvpn --version
OpenVPN 2.6.15 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
library versions: OpenSSL 3.2.6 30 Sep 2025, LZO 2.10
DCO version: N/A
Originally developed by James Yonan
Copyright (C) 2002-2024 OpenVPN Inc <sales@openvpn.net>
Compile time defines: enable_async_push=yes enable_comp_stub=no enable_crypto_ofb_cfb=yes enable_dco=yes enable_dco_arg=yes enable_debug=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_iproute2=no enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_management=yes enable_pam_dlopen=no enable_pedantic=no enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_silent_rules=yes enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_werror=no enable_win32_dll=yes enable_wolfssl_options_h=yes enable_x509_alt_username=yes with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_openssl_engine=auto with_sysroot=no

phablet@ubuntu-phablet:~$ openvpn --version
OpenVPN 2.6.14 aarch64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
library versions: OpenSSL 3.0.13 30 Jan 2024, LZO 2.10
DCO version: N/A
Originally developed by James Yonan
Copyright (C) 2002-2024 OpenVPN Inc <sales@openvpn.net>
Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto_ofb_cfb=yes enable_dco=yes enable_dco_arg=yes enable_debug=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_iproute2=no enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_maintainer_mode=no enable_management=yes enable_option_checking=no enable_pam_dlopen=no enable_pedantic=no enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_shared=yes enable_shared_with_static_runtimes=no enable_silent_rules=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_unit_tests=no enable_werror=no enable_win32_dll=yes enable_wolfssl_options_h=yes enable_x509_alt_username=yes with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_openssl_engine=auto with_sysroot=no

gpatel-fr

@Vlad-Nirky said in OpenVPN setup does not offer what i need for my vpn server....:

Authenticate/Decrypt packet error: packet HMAC authentication failed

looks like a mismatch for the ta.key file.

@Vlad-Nirky said in OpenVPN setup does not offer what i need for my vpn server....:

'auth' is used inconsistently, local='auth SHA256', remote='auth SHA1'

should have the same value for client and server...how that can be possible if you generated the config for the phone from the working config on the PC ?

gpatel-fr

@zakafx

I don't know if you are still struggling with this OpenVpn configuration, it seems that the default configuration generated with PIVpn assumes that every access should be routed by the server, if you have as a symptom that all Internet access is lost after launching the VPN this could be a reason, routing everything through the server is often not what is wanted anyway. Try to use easy-openvpn-server instead, from what I remember it generates a more usable configuration.

Vlad Nirky

@gpatel-fr
Solved.
Add this in nmconnection file before import.
~~cipher AES-256-CBC~~
cipher AES-256-GCM
auth SHA256
ncp-disable

Critical lines in your Ubuntu Touch log
WARNING: ‘auth’ is used inconsistently, local=‘auth SHA256’, remote=‘auth SHA1’
phde/188.5.220.190:1210 Authenticate/Decrypt packet error: packet HMAC authentication failed
The server uses SHA256 authentication
The Ubuntu Touch client uses SHA1 authentication
Result: the HMACs of the data packets do not match → rejection.

Why does Fedora work?

Fedora (OpenVPN 2.6.15 with AEAD/DCO) does not need separate “auth” because AES-256-GCM mode already includes authentication in the encryption.
Ubuntu Touch, on the other hand, still forces an older mode (AES-256-CBC + SHA1 authentication).

Vlad Nirky

@gpatel-fr @OtaDr @gpatel-fr

Thanks for your help !

gpatel-fr

@Vlad-Nirky said in OpenVPN setup does not offer what i need for my vpn server....:

Fedora (OpenVPN 2.6.15 with AEAD/DCO) does not need separate “auth” because AES-256-GCM mode already includes authentication in the encryption.

probably a mismatch in Openvpn versions, they have this habit of changing some parameters meaning. Nice wrap-up, thanks for the explanation.

jagdtigger

@Vlad-Nirky
Did your method with the nmcli import command (only had to add the user+pass in the UT GUI), still get timeout on the phone and the same errors in openvpn log. And i think i know why. Seems like nmcli has its own mind and omitted settings from the imported config....
Original

client
remote '<domain>'
tun-ipv6
cert '/home/phablet/Documents/vpn/phone.crt'
key '/home/phablet/Documents/vpn/phone.key'
ca '/home/phablet/Documents/vpn/server.crt'
auth-user-pass
dev tun
dev-type tun
proto udp
port <port>
tls-crypt '/home/phablet/Documents/vpn/tls.key'
tls-version-min '1.3' or-highest
nobind
auth-nocache
script-security 2
persist-key
persist-tun
user nm-openvpn
group nm-openvpn

Imported:

root@ubuntu-phablet:/home/phablet/Documents/vpn# cat /etc/netplan/90-NM-f1365f35-54fb-432f-8a95-fd811aafd906.yaml 
network:
  version: 2
  nm-devices:
    NM-f1365f35-54fb-432f-8a95-fd811aafd906:
      renderer: NetworkManager
      networkmanager:
        uuid: "f1365f35-54fb-432f-8a95-fd811aafd906"
        name: "main-vpn"
        passthrough:
          connection.type: "vpn"
          vpn.ca: "/home/phablet/Documents/vpn/server.crt"
          vpn.cert: "/home/phablet/Documents/vpn/phone.crt"
          vpn.cert-pass-flags: "1"
          vpn.connection-type: "password-tls"
          vpn.dev: "tun"
          vpn.dev-type: "tun"
          vpn.key: "/home/phablet/Documents/vpn/phone.key"
          vpn.password-flags: "1"
          vpn.port: "<port>"
          vpn.remote: "<domain>"
          vpn.username: "<user>"
          vpn.service-type: "org.freedesktop.NetworkManager.openvpn"
          ipv4.method: "auto"
          ipv6.addr-gen-mode: "default"
          ipv6.method: "auto"
          proxy._: ""

No wonder the server has tls errors, the tls-crypt option is missing.

Vlad Nirky

@jagdtigger
I imagine it also depends on the VPN server and its configuration...
This works for me.

phablet@ubuntu-phablet:~$ cat /home/phablet/Documents/KeePass/phde.nmconnection 
client
remote '<my_server>.ddns.net' 1194
cert '/home/phablet/.cert/nm-openvpn/phde-cert.pem'
key '/home/phablet/.cert/nm-openvpn/phde-key.pem'
ca '/home/phablet/.cert/nm-openvpn/phde-ca.pem'
cipher AES-256-GCM
auth SHA256
ncp-disable
dev tun
proto udp
remote-cert-tls server
verify-x509-name rpi3_9b0ae2d9-f297-4706-ab24-8b9d63b3a51f name
tls-crypt '/home/phablet/.cert/nm-openvpn/phde-tls-crypt.pem'
tls-version-min '1.2'
nobind
auth-nocache
script-security 2
persist-key
persist-tun
user nm-openvpn
group nm-openvpn
route 192.168.128.0 255.255.254.0

gpatel-fr

@jagdtigger

oh well TIL that Ubuntu is patching network-manager to backup the network configuration changes to netplan. I was sticking to the old advice 'either netplan OR network-manager'.

For your information, network manager is a Gnome thing and wants nothing to do with netplan that is an Ubuntu thing. Since Ubuntu mostly uses Gnome, this patching tries to make for a better config since network manager is deeply integrated into Gnome. Adding OpenVpn and Ubuntu Touch (that don't use Gnome) is not making things much clearer in the corner cases unfortunately.
So I don't find the idea of getting a netplan config invalid or fighting with Network Manager particularly surprising.
I have no idea if just editing the netplan file and restarting netplan with sudo netplan apply will 'stick' in UT.