Client issues since v1.3.4261.88 when no "DNS Server" set

Pritunl
1

Hi,

Ever since I updated the Pritunl Client to version v1.3.4262.38, the client tries to connect but disconnects after a few seconds. Looking at the logs, I find this:

2025-05-21 00:00:19 OpenVPN 2.6.12 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
2025-05-21 00:00:19 library versions: OpenSSL 3.3.1 4 Jun 2024, LZO 2.10
2025-05-21 00:00:19 DCO version: N/A
2025-05-21 00:00:19 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2025-05-21 00:00:19 TCP/UDP: Preserving recently used remote address: [AF_INET]my.server.ip:1194
2025-05-21 00:00:19 UDPv4 link local: (not bound)
2025-05-21 00:00:19 UDPv4 link remote: [AF_INET]my.server.ip:1194
2025-05-21 00:00:19 VERIFY OK: depth=1, O=61b728dc4c245c3190c6234d, CN=61b728dc4c245c3190c62351
2025-05-21 00:00:19 NOTE: --mute triggered...
2025-05-21 00:00:19 6 variation(s) on previous 3 message(s) suppressed by --mute
2025-05-21 00:00:19 [61b728dd4c245c3190c6235f] Peer Connection Initiated with [AF_INET]my.server.ip:1194
2025-05-21 00:00:20 TUN/TAP device tun0 opened
2025-05-21 00:00:20 net_iface_mtu_set: mtu 1500 for tun0
2025-05-21 00:00:20 net_iface_up: set tun0 up
2025-05-21 00:00:20 net_addr_v4_add: 10.249.46.15/24 dev tun0
2025-05-21 00:00:20 /etc/openvpn/update-resolv-conf tun0 1500 0 10.249.46.15 255.255.255.0 init
Dropped protocol specifier '.openvpn' from 'tun0.openvpn'. Using 'tun0' (ifindex=32).
No DNS servers specified, refusing operation.
2025-05-21 00:00:20 WARNING: Failed running command (--up/--down): external program exited with error status: 1
2025-05-21 00:00:20 Exiting due to fatal error

On the server, I am not configuring a “DNS Server” because this causes problems with the OpenVPN client on iOS, but also because I am not interested in passing the DNS traffic of all clients through the VPN server.

I tested installing the latest versions available on GitHub, and the last one that works is v1.3.4120.52. I am also attaching the log of the successful connection using this version:

2025-05-21 00:42:42 OpenVPN 2.6.12 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
2025-05-21 00:42:42 library versions: OpenSSL 3.3.1 4 Jun 2024, LZO 2.10
2025-05-21 00:42:42 DCO version: N/A
2025-05-21 00:42:42 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2025-05-21 00:42:42 TCP/UDP: Preserving recently used remote address: [AF_INET]my.server.ip:1194
2025-05-21 00:42:42 UDPv4 link local: (not bound)
2025-05-21 00:42:42 UDPv4 link remote: [AF_INET]my.server.ip:1194
2025-05-21 00:42:42 VERIFY SCRIPT OK: depth=1, O=61b728dc4c245c3190c6234d, CN=61b728dc4c245c3190c62351
2025-05-21 00:42:42 NOTE: --mute triggered...
2025-05-21 00:42:42 8 variation(s) on previous 3 message(s) suppressed by --mute
2025-05-21 00:42:42 [61b728dd4c245c3190c6235f] Peer Connection Initiated with [AF_INET]my.server.ip:1194
2025-05-21 00:42:44 TUN/TAP device tun0 opened
2025-05-21 00:42:44 net_iface_mtu_set: mtu 1500 for tun0
2025-05-21 00:42:44 net_iface_up: set tun0 up
2025-05-21 00:42:44 net_addr_v4_add: 10.249.46.15/24 dev tun0
2025-05-21 00:42:44 /tmp/pritunl/15f438698148ea1c-up.sh tun0 1500 0 10.249.46.15 255.255.255.0 init
<14>May 21 00:42:44 15f438698148ea1c-up.sh: Link 'tun0' coming up
2025-05-21 00:42:44 Initialization Sequence Completed
2025-05-21 00:42:44 Data Channel: cipher 'AES-128-GCM', peer-id: 2, compression: 'stub'
2025-05-21 00:42:44 NOTE: --mute triggered...

The next version available with a build for Ubuntu 24.10 is v1.3.4261.88 (it has the same error as v1.3.4262.38), which, in the changelog, says:

Fix compatibility issues with Ubuntu 25.04

So I can imagine that by resolving some issue present in Ubuntu 25.04, it might have broken in previous versions.

I believe it’s easily reproducible, but if I can help with anything in investigating the issue, I’ll be happy to help.

Thanks!

2

There should be a message in the service output indicate that the AppArmor profile must be disabled. This can be done by running sudo apparmor_parser -R /etc/apparmor.d/openvpn and can be enabled again by running sudo apparmor_parser -a /etc/apparmor.d/openvpn. The issue is caused by Ubuntu Bug #2098930.

3

Thanks for your answer @zach.

That solution doesn’t seem to work on Ubuntu 24.10:

File /etc/apparmor.d/openvpn not found, skipping...

If I look inside /etc/apparmor.d, there is no “openvpn” file. As additional info, a user reports that the same thing is happening to them on Ubuntu 24.04.

Any other ideas?

Thanks!

4

Sorry I thought this was on 25.05. For Ubuntu 24.10 it was broken by switching the up script to the system /etc/openvpn/update-resolv-conf. This was done to try to keep the AppArmor profile working in the future but there appears to be issues with that script in <25.04 releases. I’ve seen emails about this and it will either throw an error and stop the connection or fail to configure DNS. I’m going to switch it back to the script that is packaged with the client that was previously used. This should be released some time today.

Older debian releases are not kept on the repository so if you have an older release in cache you can downgrade to that until it is fixed.

sudo apt-cache policy pritunl-client-electron
sudo apt install pritunl-client-electron=version
5

I have added the fix to the codebase this can be installed by running the commands below. This may not work with the older Golang release on 24.10.

sudo apt install golang git
go install github.com/pritunl/pritunl-client-electron/service@bc43bad34e33ea80fc8e31bbef1c31d154749978
sudo systemctl stop pritunl-client
sudo cp ~/go/bin/service /usr/bin/pritunl-client-service
sudo systemctl start pritunl-client
6

Hi @zach ! No worries. Thanks for taking the time to look at it.

I confirm that with those changes it works fine. I’ll have this at hand if any other user encounters the issue until there’s a new release available.

Thanks again!

7

Working fine on v1.3.4269.93 from the repo. Thanks!