OpenVPN not working after Core 170 upgrade

Virtual Private Networks OpenVPN
1

Hi, all

All the OpenVPN clients where working before the Core 170 upgrade, and after server reboot, they can not complete the connection. I’ve checked the whole configuration and made a start for zero, without success. Is someone with the same issue?
I’ll be grateful if you have any suggestion about the matter as I really don’t know how to proceed.

Thanks in advance
Best regards

Here are the logs and configuration for both server and client:

                                          SERVER CONFIG

#OpenVPN Server conf

daemon openvpnserver
writepid /var/run/openvpn.pid
#DAN prepare OpenVPN for listening on blue and orange
;local 147.83.92.136
dev tun
proto udp
port 1194
script-security 3
ifconfig-pool-persist /var/ipfire/ovpn/ovpn-leases.db 3600
client-config-dir /var/ipfire/ovpn/ccd
tls-server
ca /var/ipfire/ovpn/ca/cacert.pem
cert /var/ipfire/ovpn/certs/servercert.pem
key /var/ipfire/ovpn/certs/serverkey.pem
dh /var/ipfire/ovpn/ca/dh1024.pem
server 10.8.0.0 255.255.255.0
tun-mtu 1500
mssfix
keepalive 10 60
status-version 1
status /var/run/ovpnserver.log 30
ncp-disable
cipher AES-256-GCM
auth SHA512
tls-version-min 1.2
tls-auth /var/ipfire/ovpn/certs/ta.key
push “dhcp-option DOMAIN cttc.org”
push “dhcp-option DNS 10.1.1.1”
max-clients 100
tls-verify /usr/lib/openvpn/verify
crl-verify /var/ipfire/ovpn/crls/cacrl.pem
auth-user-pass-optional
reneg-sec 86400
user nobody
group nobody
persist-key
persist-tun
verb 3

Log clients connecting/disconnecting

client-connect “/usr/sbin/openvpn-metrics client-connect”
client-disconnect “/usr/sbin/openvpn-metrics client-disconnect”

Enable Management Socket

management /var/run/openvpn.sock unix
management-client-auth

#---------------------------

Start of custom directives

from server.conf.local

#---------------------------

topology subnet
management localhost 7505

#-----------------------------

End of custom directives

#-----------------------------

                                          SERVER LOG

2022-10-12 15:19:40 DEPRECATED OPTION: ncp-disable. Disabling cipher negotiation is a deprecated debug feature that will be removed in OpenVPN 2.6
2022-10-12 15:19:40 OpenVPN 2.5.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jul 7 2022
2022-10-12 15:19:40 library versions: OpenSSL 1.1.1q 5 Jul 2022, LZO 2.10
2022-10-12 15:19:40 MANAGEMENT: unix domain socket listening on localhost
2022-10-12 15:19:40 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2022-10-12 15:19:40 Diffie-Hellman initialized with 2048 bit key
2022-10-12 15:19:40 CRL: loaded 1 CRLs from file /var/ipfire/ovpn/crls/cacrl.pem
2022-10-12 15:19:40 Outgoing Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
2022-10-12 15:19:40 Incoming Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
2022-10-12 15:19:40 TUN/TAP device tun0 opened
2022-10-12 15:19:40 /sbin/ip link set dev tun0 up mtu 1500
2022-10-12 15:19:40 /sbin/ip link set dev tun0 up
2022-10-12 15:19:40 /sbin/ip addr add dev tun0 10.8.0.1/24
2022-10-12 15:19:40 Could not determine IPv4/IPv6 protocol. Using AF_INET
2022-10-12 15:19:40 Socket Buffers: R=[212992->212992] S=[212992->212992]
2022-10-12 15:19:40 UDPv4 link local (bound): [AF_INET][undef]:1194
2022-10-12 15:19:40 UDPv4 link remote: [AF_UNSPEC]
2022-10-12 15:19:40 GID set to nobody
2022-10-12 15:19:40 UID set to nobody
2022-10-12 15:19:40 MULTI: multi_init called, r=256 v=256
2022-10-12 15:19:40 IFCONFIG POOL IPv4: base=10.8.0.2 size=253
2022-10-12 15:19:40 IFCONFIG POOL LIST
2022-10-12 15:19:40 Initialization Sequence Completed
2022-10-12 15:20:15 93.176.132.127:33999 Outgoing Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
2022-10-12 15:20:15 93.176.132.127:33999 Incoming Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
2022-10-12 15:20:15 93.176.132.127:33999 TLS: Initial packet from [AF_INET]93.176.132.127:33999, sid=10409916 84230194
2022-10-12 15:20:15 93.176.132.127:33999 VERIFY SCRIPT OK: depth=1, C=ES, ST=Barcelona, L=Terrassa, O=Universitat Politecnica de Catalunya, OU=Centre Tecnologic de Tranferencia de Calor, CN=Universitat Politecnica de Catalunya CA, emailAddress=ramiro.alba@upc.edu
2022-10-12 15:20:15 93.176.132.127:33999 VERIFY OK: depth=1, C=ES, ST=Barcelona, L=Terrassa, O=Universitat Politecnica de Catalunya, OU=Centre Tecnologic de Tranferencia de Calor, CN=Universitat Politecnica de Catalunya CA, emailAddress=ramiro.alba@upc.edu
2022-10-12 15:20:15 93.176.132.127:33999 VERIFY SCRIPT OK: depth=0, C=ES, ST=Barcelona, O=Universitat Politecnica de Catalunya, OU=Centre Tecnologic de Transferencia de Calor, CN=Ramiro Alba Queipo D
2022-10-12 15:20:15 93.176.132.127:33999 VERIFY OK: depth=0, C=ES, ST=Barcelona, O=Universitat Politecnica de Catalunya, OU=Centre Tecnologic de Transferencia de Calor, CN=Ramiro Alba Queipo D
2022-10-12 15:20:15 93.176.132.127:33999 peer info: IV_VER=2.5.5
2022-10-12 15:20:15 93.176.132.127:33999 peer info: IV_PLAT=linux
2022-10-12 15:20:15 93.176.132.127:33999 peer info: IV_PROTO=6
2022-10-12 15:20:15 93.176.132.127:33999 peer info: IV_NCP=2
2022-10-12 15:20:15 93.176.132.127:33999 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM
2022-10-12 15:20:15 93.176.132.127:33999 peer info: IV_LZ4=1
2022-10-12 15:20:15 93.176.132.127:33999 peer info: IV_LZ4v2=1
2022-10-12 15:20:15 93.176.132.127:33999 peer info: IV_LZO=1
2022-10-12 15:20:15 93.176.132.127:33999 peer info: IV_COMP_STUB=1
2022-10-12 15:20:15 93.176.132.127:33999 peer info: IV_COMP_STUBv2=1
2022-10-12 15:20:15 93.176.132.127:33999 peer info: IV_TCPNL=1
2022-10-12 15:20:15 93.176.132.127:33999 TLS: Username/Password authentication deferred for username ‘’
2022-10-12 15:20:15 93.176.132.127:33999 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
2022-10-12 15:20:15 93.176.132.127:33999 [Ramiro Alba Queipo D] Peer Connection Initiated with [AF_INET]93.176.132.127:33999
2022-10-12 15:20:16 93.176.132.127:33999 PUSH: Received control message: ‘PUSH_REQUEST’
2022-10-12 15:20:21 93.176.132.127:33999 PUSH: Received control message: ‘PUSH_REQUEST’
2022-10-12 15:20:27 93.176.132.127:33999 PUSH: Received control message: ‘PUSH_REQUEST’
2022-10-12 15:20:32 93.176.132.127:33999 PUSH: Received control message: ‘PUSH_REQUEST’

                                          CLIENT CONFIG

#OpenVPN Client conf
tls-client
client
nobind
dev tun
proto udp
tun-mtu 1500
remote 147.83.92.136 1194
pkcs12 RamiroAlbaD.p12
cipher AES-256-GCM
auth SHA512
tls-auth ta.key
verb 3
remote-cert-tls server
verify-x509-name cttc.upc.es name
mssfix
auth-nocache
auth-token-user USER
auth-token TOTP
auth-retry interact

#---------------------------

Start of custom directives

from client.conf.local

#---------------------------

Uncomment if the Operating System is Linux. In that case, the

package ‘openresolv’ must be installed.

data-ciphers-fallback ‘AES-256-GCM’

log /var/log/openvpn.log
status /var/log/openvpn-status.log

up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

#---------------------------

End of custom directives

#---------------------------

                                          CLIENT LOG

2022-10-12 15:20:15 OpenVPN 2.5.5 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2022
2022-10-12 15:20:15 library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
2022-10-12 15:20:15 NOTE: starting with OpenVPN 2.1, ‘–script-security 2’ or higher is required to call user-defined scripts or executables
2022-10-12 15:20:15 Outgoing Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
2022-10-12 15:20:15 Incoming Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
2022-10-12 15:20:15 TCP/UDP: Preserving recently used remote address: [AF_INET]147.83.92.136:1194
2022-10-12 15:20:15 Socket Buffers: R=[212992->212992] S=[212992->212992]
2022-10-12 15:20:15 UDP link local: (not bound)
2022-10-12 15:20:15 UDP link remote: [AF_INET]147.83.92.136:1194
2022-10-12 15:20:15 TLS: Initial packet from [AF_INET]147.83.92.136:1194, sid=3974a395 0c904902
2022-10-12 15:20:15 VERIFY OK: depth=1, C=ES, ST=Barcelona, L=Terrassa, O=Universitat Politecnica de Catalunya, OU=Centre Tecnologic de Tranferencia de Calor, CN=Universitat Politecnica de Catalunya CA, emailAddress=ramiro.alba@upc.edu
2022-10-12 15:20:15 VERIFY KU OK
2022-10-12 15:20:15 Validating certificate extended key usage
2022-10-12 15:20:15 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2022-10-12 15:20:15 VERIFY EKU OK
2022-10-12 15:20:15 VERIFY X509NAME OK: C=ES, ST=Barcelona, O=Universitat Politecnica de Catalunya, OU=Centre Tecnologic de Tranferencia de Calor, CN=cttc.upc.es
2022-10-12 15:20:15 VERIFY OK: depth=0, C=ES, ST=Barcelona, O=Universitat Politecnica de Catalunya, OU=Centre Tecnologic de Tranferencia de Calor, CN=cttc.upc.es
2022-10-12 15:20:15 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
2022-10-12 15:20:15 [cttc.upc.es] Peer Connection Initiated with [AF_INET]147.83.92.136:1194
2022-10-12 15:20:16 SENT CONTROL [cttc.upc.es]: ‘PUSH_REQUEST’ (status=1)
2022-10-12 15:20:21 SENT CONTROL [cttc.upc.es]: ‘PUSH_REQUEST’ (status=1)
2022-10-12 15:20:27 SENT CONTROL [cttc.upc.es]: ‘PUSH_REQUEST’ (status=1)
2022-10-12 15:20:32 SENT CONTROL [cttc.upc.es]: ‘PUSH_REQUEST’ (status=1)

2

can you reboot also the clients?

3

Hi @ramiro_alba.

Are you activate OpenVpn double factor?.

Bye.

4

@cfusco,

Yes, I’ve done that and also played with config options on both client and server

Cheers

5

Hi @Roberto,

Well, I do not intend to use OTP. That lines have been put by the web ui config once I did a config rebuild. In fact I’ve commented on config client the lines:
auth-nocache
auth-token-user USER
auth-token TOTP
auth-retry interact

and the result is the same. Watch that the option in server:

auth-user-pass-optional

bypass the need of authentication

Regards

6

On which operating system are you running the OpenVPN client?
Edit
And which version client, OpenVPN Connect, Community Edition Community Edition version…

7

Hi,

I’m using Ubuntu Linux 22.04 which have OpenVPN version 2.5.5

Regards

8

What is strange, OpenVPN server has not changed from 169.

9

Yes. This issue do not seem to do with OpenVPN version which is 2.5.6 in both. That’s why I’m really confused with all this matter.
And I’m not able to understand what the client/sever messages are meaning

Do anyone know?

Regards

10

I think the server is not answering a PUSH_REPLY to the PUSH_REQUEST coming from the client, but it should keep trying until giving up and giving a message stating that. Are you sure that there are no more lines in the logs?

1 Like
11

No at the verbose level it is set. If a higher level is selected, the messages are not meneafull . At least for me. May be for an OpenVPN expert, they do…

Regards

12

[edit]

If I remember correctly

1.This problem occurs when “Enable OTP” is checked.
There are topics on the forum about this problem.

Look for the keywords TOTP , PUSH_REPLY

2.TOTP managed to run on Windows, OpenVPN client in Community edition.

Regards.

1 Like
13

Right. But, I am NOT enabling OTP on client config. The lines:

auth-nocache
auth-token-user USER
auth-token TOTP
auth-retry interact

Which in previous ipfire versions were not generated, now they always do. The question is if I am not checking ‘Enagle OTP:’ at ‘Advanced client options:’, can I be sure that OTP is totaly disabled?.
If the answer is ‘yes’, why client is displaying ‘SENT CONTROL [cttc.upc.es]: ‘PUSH_REQUEST’ (status=1)’ lines?

Regards

14

In your Server Config you have defined the dhcp push options

In the certificates etc you have the domain set as cttc.upc.es instead of cttc.org which is defined in the dhcp-options

Also is your IPFire green IP 10.1.1.1
If not is the definition of the DNS IP as 10.1.1.1 correct

15

Adolf,

Nop. The same result:

2022-10-13 12:28:15 VERIFY X509NAME OK: C=ES, ST=Barcelona, O=Universitat Politecnica de Catalunya, OU=Centre Tecnologic de Tranferencia de Calor, CN=cttc.cttc.org
2022-10-13 12:28:15 VERIFY OK: depth=0, C=ES, ST=Barcelona, O=Universitat Politecnica de Catalunya, OU=Centre Tecnologic de Tranferencia de Calor, CN=cttc.cttc.org
2022-10-13 12:28:16 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
2022-10-13 12:28:16 [cttc.cttc.org] Peer Connection Initiated with [AF_INET]147.83.92.136:1194
2022-10-13 12:28:17 SENT CONTROL [cttc.cttc.org]: 'PUSH_REQUEST' (status=1)
2022-10-13 12:28:22 SENT CONTROL [cttc.cttc.org]: 'PUSH_REQUEST' (status=1)
2022-10-13 12:28:27 SENT CONTROL [cttc.cttc.org]: 'PUSH_REQUEST' (status=1)
2022-10-13 12:28:32 SENT CONTROL [cttc.cttc.org]: 'PUSH_REQUEST' (status=1)
2022-10-13 12:28:37 SENT CONTROL [cttc.cttc.org]: 'PUSH_REQUEST' (status=1)

Regards

16

This seems to be a third domain name.

I have also triple checked now on my CU170 system with both an Android phone client and a Linux Network Manager client on a laptop and both work the same as when they were on the earlier CU’s. The operation of OpenVPN Road Warriors is something I always test at each Core Update Testing release.

I have also checked through the changes in the IPFire git repository.

There were two bug fixes in recent times for the ovpnmain.cgi page but both of these were released in CU169 and are related to fixes when creating new client connections.
https://bugzilla.ipfire.org/show_bug.cgi?id=12865
https://bugzilla.ipfire.org/show_bug.cgi?id=12883

CU170 has had no changes to ovpnmain.cgi or to the OpenVPN package itself.

I don’t believe that the problems you are experiencing are due to CU170.

Either something has been changed with the OpenVPN clients/server or something got corrupted during the update.

My suggestion would be to do a fresh install of CU169 and restore your settings and then test out the existing OpenVPN road warrior connections. If those work then re-do the CU170 update and test again.

Of course if your system is part of a commercial organisation that might be more challenging to do.

I have no further ideas for why you are seeing this and I can’t reproduce it on my systems.

2 Likes
17

Adolf,

Thanks for all your help. Yes I should do a fresh install. The difficulty is about having some virtual machines running on libvirt, but I would manage

Regards

18

Good luck and let us know how it goes. :+1:

19

Hi all,

Finally the problem was the conflict with two openvpn server options:

management /var/run/openvpn.sock unix (inserted by the ipfire gui admin)

management localhost 7505 (inserted by me)

In Core 169 and previous, no problem. Starting from Core 170, the related issue

Thans to all for all your help

Regards

1 Like
20

Good day
I also had a problem with OVPN, functional in May 2022, without configuration changes, non-functional in December 2022 (client ubuntu 18.04)

it helped to install according to this post : “openresolv” package installed