Newly released OpenVPN 2.7.0 may cause issues with Pritunl-client 1.3.4466.51

We just hit an issue with the pritunl-client-electron (version 1.3.4466.51) not working on Arch Linux with the latest OpenVPN 2.7.0-1

It authenticated but the VPN connection kept timing out and retrying.

The issue was resolved by downgrading the OpenVPN on the client system to one earlier than 2.7.0

OpenVPN 2.7.0 was released not long ago, and this Arch linux box had been upgraded to the latest version.

https://community.openvpn.net/Downloads#openvpn-270-released-11-february-2026

This has been fixed in the repo and will be included in the next release. The commands below can be run to pull the latest code from the repository.

sudo pacman -S --noconfirm git go

go install github.com/pritunl/pritunl-client-electron/service@8a34055b249b5213d09feeb9e586f991d1c94927
sudo systemctl stop pritunl-client
sudo cp -f ~/go/bin/service /usr/bin/pritunl-client-service
sudo systemctl start pritunl-client
2 Likes

thanks for the quick response!

@zach what’s the timeline for next release including this fix?

This release is also updating the macOS and Windows OpenVPN to 2.7.0, adding support for OpenVPN DCO on Windows and bundling WireGuard with the Windows client. This is taking additional time to test and this may continue until this weekend.

1 Like

The code available now in the commit below should fix all the remaining issues. Most most of the testing for the Windows and macOS OpenVPN 2.7.0 update has been completed and the client should be released tomorrow.

sudo pacman -S --noconfirm git go

go install github.com/pritunl/pritunl-client-electron/service@7900efcda922b75817dc7d91fbf80351cbc5120b
sudo systemctl stop pritunl-client
sudo cp -f ~/go/bin/service /usr/bin/pritunl-client-service
sudo systemctl start pritunl-client

I applied the recommended changes and the connection now establishes successfully. However, the DNS servers are not being written to resolv.conf.

After downgrading to version 2.6.19, the DNS configuration is applied correctly and everything works as expected.

Has anyone else experienced this behavior with this workaround?

The new update is on the unstable repositories now. It will move to the stable in about an hour when the sync completes.

You likely have systemd-resolvconf installed, probably from WireGuard which requires it. But it is not enabled. This causes the new DNS script to detect resolvconf and assume that it is in use. The previous code did an additional check to look for the stub-resolver to verify what DNS system is used. I may add this to the new script but you have a broken system configuration that will likely cause problems with DNS configuration in WireGuard. The best option is to complete the configuration of systemd-resolvconf by running the commands below.

sudo pacman -S systemd-resolvconf
sudo systemctl enable --now systemd-resolved
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

Running the command below after connecting should show the correct DNS server for the tun interface.

resolvectl status
Link 3 (tun0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6
         Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 8.8.8.8
       DNS Servers: 8.8.8.8
        DNS Domain: ~.
     Default Route: yes

In the top right menu click logs and select the profile from the dropdown menu and this will show the logs from the DNS configuration. It should look similar to the logs below.

dns-updown: script_type=dns-down dev=tun0
dns-updown: dns_vars_file=<not_set>
dns-updown: --- begin dns environment ---
dns-updown:   dns_server_1_address_1=8.8.8.8
dns-updown: --- end dns environment ---
dns-updown: attempting DNS backends in order: systemd-resolved, resolvconf, resolv.conf file
dns-updown: do_resolved: /etc/resolv.conf symlink target: <not a symlink>
dns-updown: do_resolved: skipping, /etc/resolv.conf does not point to systemd-resolved
dns-updown: do_resolvconf: checking for /sbin/resolvconf
dns-updown: resolv_conf_compat_profile: checking server profile 1: address=8.8.8.8 transport=<not set> dnssec=<not set>
dns-updown: resolv_conf_compat_profile: using server profile 1
dns-updown: do_resolvconf: selected server profile 1
unsetting DNS using resolvconf
dns-updown: DNS configuration completed successfully

I’m not using systemd-resolved, as I try to keep the systemd footprint minimal on my system. I’m using openresolv, and everything was working perfectly before these changes.

With the current version, the connection establishes successfully but the DNS entries are not written to resolv.conf. As a workaround, downgrading to version 2.6.19 restores the expected behavior and DNS is configured correctly.

For reference, the pritunl-client package version I’m using is v1.3.4554.60.

Run this command to display the state of the DNS configuration.

sudo bash -x << 'EOF'
set -x
cat /etc/resolv.conf
cat /etc/resolvconf.conf
cat /etc/resolv.conf.bak
ls -la /etc/resolv.conf
resolvectl status
resolvectl dns
systemctl status systemd-resolved
resolvconf -l
NetworkManager --print-config | grep rc-manager
EOF

I’m attaching the output using version 2.6.19.

+ set -x
+ cat /etc/resolv.conf
# Generated by resolvconf
search domain.com
nameserver 10.5.0.2
+ cat /etc/resolvconf.conf
# Configuration for resolvconf(8)
# See resolvconf.conf(5) for details

resolv_conf=/etc/resolv.conf
# If you run a local name server, you should uncomment the below line and
# configure your subscribers configuration files below.
#name_servers=127.0.0.1
+ cat /etc/resolv.conf.bak
# Generated by NetworkManager
search cpe.telecentro.net.ar
nameserver 190.55.60.130
nameserver 200.115.192.89
nameserver 190.55.60.129
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 2800:810:100:3:200:115:192:89
nameserver 2800:810:100::5
nameserver 2800:810:100:4:181:47:248:145
+ ls -la /etc/resolv.conf
-rw-r--r-- 1 root root 65 mar  4 09:12 /etc/resolv.conf
+ resolvectl status
Failed to get global data: Could not activate remote peer 'org.freedesktop.resolve1': activation request failed: unknown unit
+ resolvectl dns
Failed to get global data: Could not activate remote peer 'org.freedesktop.resolve1': activation request failed: unknown unit
+ systemctl status systemd-resolved
○ systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; disabled; preset: enabled)
     Active: inactive (dead)
TriggeredBy: ○ systemd-resolved-monitor.socket
             ○ systemd-resolved-varlink.socket
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://systemd.io/WRITING_NETWORK_CONFIGURATION_MANAGERS
             https://systemd.io/WRITING_RESOLVER_CLIENTS
+ resolvconf -l
# resolv.conf from tun0.vpn
search  domain.com
nameserver 10.5.0.2

+ NetworkManager --print-config
+ grep rc-manager
# rc-manager=symlink

the output after upgrading to 2.7.0, for comparison.

+ set -x
+ cat /etc/resolv.conf
# Generated by NetworkManager
search cpe.telecentro.net.ar
nameserver 190.55.60.130
nameserver 200.115.192.89
nameserver 190.55.60.129
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 2800:810:100:3:200:115:192:89
nameserver 2800:810:100::5
nameserver 2800:810:100:4:181:47:248:145
+ cat /etc/resolvconf.conf
# Configuration for resolvconf(8)
# See resolvconf.conf(5) for details

resolv_conf=/etc/resolv.conf
# If you run a local name server, you should uncomment the below line and
# configure your subscribers configuration files below.
#name_servers=127.0.0.1
+ cat /etc/resolv.conf.bak
# Generated by NetworkManager
search cpe.telecentro.net.ar
nameserver 190.55.60.130
nameserver 200.115.192.89
nameserver 190.55.60.129
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 2800:810:100:3:200:115:192:89
nameserver 2800:810:100::5
nameserver 2800:810:100:4:181:47:248:145
+ ls -la /etc/resolv.conf
-rw-r--r-- 1 root root 365 mar  4 09:17 /etc/resolv.conf
+ resolvectl status
Failed to get global data: Could not activate remote peer 'org.freedesktop.resolve1': activation request failed: unknown unit
+ resolvectl dns
Failed to get global data: Could not activate remote peer 'org.freedesktop.resolve1': activation request failed: unknown unit
+ systemctl status systemd-resolved
○ systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; disabled; preset: enabled)
     Active: inactive (dead)
TriggeredBy: ○ systemd-resolved-varlink.socket
             ○ systemd-resolved-monitor.socket
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://systemd.io/WRITING_NETWORK_CONFIGURATION_MANAGERS
             https://systemd.io/WRITING_RESOLVER_CLIENTS
+ resolvconf -l
# resolv.conf from tun0
nameserver 10.5.0.2
search domain.com domain.com

+ NetworkManager --print-config
+ grep rc-manager
# rc-manager=symlink

I have replicated this DNS configuration and reproduced the issue. The code has been fixed to correctly configure the DNS servers for this configuration. This will be included in the next release.

This is an incomplete openresolv configuration, you have # rc-manager=symlink in NetworkManager --print-config. You need to run these commands to complete the openresolv configuration.

sudo tee /etc/NetworkManager/conf.d/rc-manager.conf << EOF
[main]
rc-manager=resolvconf
EOF

sudo systemctl restart NetworkManager
sudo resolvconf -u

The /etc/resolv.conf should always contain # Generated by resolvconf when it is working correctly.

Thank you very much!! It works perfectly.

After additional testing the code to force resolvconf updates was removed. If the system has resolvconf installed but not enabled this will result in having no DNS entries after disconnecting from the VPN when it restores an empty resolvconf. Some code to create a backup was added to avoid this but it is too prone to failure if the VPN connection is ended earlier. It has been reverted to the functionality in the current release which should work as long as openresolv is fully configured with NetworkManager.

sudo tee /etc/NetworkManager/conf.d/rc-manager.conf << EOF
[main]
rc-manager=resolvconf
EOF

sudo systemctl restart NetworkManager
sudo resolvconf -u