Moving VPN to a new notebook

Support Network
1

Hello to Everyone,

i am moving from an old Notebook to a new one and part of this process is moving the openvpn-connection i need for business to the new notebook.

I am using KDE as desktop environment and duplicated everything including the certificates to the new notebooks networkmanager. I am able to connect to the vpn flawlessly, but exactly after 2 minutes, the log-files shows that the tunnel needs a reauthentication, which can’t be done with the former credentials, because they include a onetime password, that expires after 30 seconds (Sophos Firewall). So i am droped out of the vpn, even though the networkmanager shows a stable tunnel should be still up. Every connection i establish, lasts only for about 2 minutes, until it exits again because of failed reauthentication.

On my old notebook the logs show “wpa_supplicant”, which does a “Group rekeying completed” every 3-4 minutes and i think, this could be the tool, that helps the tunnel to stay flawless up. But when i install the “wpa_supplicant” package on the new notebook, it doesn’t do the magic all by itself. Perhaps i did something in the past to configure this tool, but i don’t know what it was.

Does anyone know what i am doing wrong?

Thanks

furby

Here are the needed logs:

  1. my old notebook starting the vpn and reconnecting to it after 4 minutes:
Jan 19 11:33:10 hostname kded6[1072]: Unhandled VPN connection state change:  NetworkManager::VpnConnection::Connecting
Jan 19 11:33:10 hostname nm-openvpn[1991]: OpenVPN 2.6.17 [git:makepkg/fa20154d58ca609b+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on Nov 28 2025
Jan 19 11:33:10 hostname nm-openvpn[1991]: library versions: OpenSSL 3.6.0 1 Oct 2025, LZO 2.10
Jan 19 11:33:10 hostname nm-openvpn[1991]: DCO version: N/A
Jan 19 11:33:10 hostname nm-openvpn[1991]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Jan 19 11:33:10 hostname nm-openvpn[1991]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jan 19 11:33:10 hostname nm-openvpn[1991]: TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xxx.xx.xx:8443
Jan 19 11:33:10 hostname nm-openvpn[1991]: Attempting to establish TCP connection with [AF_INET]xx.xxx.xx.xx:8443
Jan 19 11:33:10 hostname nm-openvpn[1991]: TCP connection established with [AF_INET]xx.xxx.xx.xx:8443
Jan 19 11:33:10 hostname nm-openvpn[1991]: TCPv4_CLIENT link local: (not bound)
Jan 19 11:33:10 hostname nm-openvpn[1991]: TCPv4_CLIENT link remote: [AF_INET]xx.xxx.xx.xx:8443
Jan 19 11:33:10 hostname nm-openvpn[1991]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Jan 19 11:33:10 hostname nm-openvpn[1991]: [Appliance_Certificate_ob2Vf9QO1H2muw4] Peer Connection Initiated with [AF_INET]xx.xxx.xx.xx:8443
Jan 19 11:33:12 hostname nm-openvpn[1991]: TUN/TAP device tun0 opened
Jan 19 11:33:12 hostname nm-openvpn[1991]: /usr/lib/nm-openvpn-service-openvpn-helper --debug 0 1975 --bus-name org.freedesktop.NetworkManager.openvpn.Connection_3 --tun -- tun0 1500 0 xx.xxx.x.x 255.255.255.0 init
Jan 19 11:33:12 hostname NetworkManager[665]: <info>  [1768818792.1261] manager: (tun0): new Tun device (/org/freedesktop/NetworkManager/Devices/6)
Jan 19 11:33:12 hostname kded6[1072]: Unhandled VPN connection state change:  NetworkManager::VpnConnection::GettingIpConfig
Jan 19 11:33:12 hostname nm-openvpn[1991]: UID set to nm-openvpn
Jan 19 11:33:12 hostname nm-openvpn[1991]: GID set to nm-openvpn
Jan 19 11:33:12 hostname nm-openvpn[1991]: Capabilities retained: CAP_NET_ADMIN
Jan 19 11:33:12 hostname nm-openvpn[1991]: Initialization Sequence Completed
Jan 19 11:33:12 hostname NetworkManager[665]: <info>  [1768818792.1683] device (tun0): state change: unmanaged -> unavailable (reason 'connection-assumed', managed-type: 'external')
Jan 19 11:33:12 hostname NetworkManager[665]: <info>  [1768818792.1697] device (tun0): state change: unavailable -> disconnected (reason 'connection-assumed', managed-type: 'external')
Jan 19 11:33:12 hostname NetworkManager[665]: <info>  [1768818792.1713] device (tun0): Activation: starting connection 'tun0' (a9c17244-0ad5-40f2-a9ff-dac171ed1341)
Jan 19 11:33:12 hostname NetworkManager[665]: <info>  [1768818792.1716] device (tun0): state change: disconnected -> prepare (reason 'none', managed-type: 'external')
Jan 19 11:33:12 hostname NetworkManager[665]: <info>  [1768818792.1720] device (tun0): state change: prepare -> config (reason 'none', managed-type: 'external')
Jan 19 11:33:12 hostname NetworkManager[665]: <info>  [1768818792.1723] device (tun0): state change: config -> ip-config (reason 'none', managed-type: 'external')
Jan 19 11:33:12 hostname NetworkManager[665]: <info>  [1768818792.1727] device (tun0): state change: ip-config -> ip-check (reason 'none', managed-type: 'external')
Jan 19 11:33:12 hostname systemd[1]: Starting Network Manager Script Dispatcher Service...
Jan 19 11:33:12 hostname systemd[1]: Started Network Manager Script Dispatcher Service.
Jan 19 11:33:12 hostname NetworkManager[665]: <info>  [1768818792.2155] policy: set 'sslvpn-furby-client-config' (tun0) as default for IPv4 routing and DNS
Jan 19 11:33:12 hostname NetworkManager[665]: <info>  [1768818792.2164] device (tun0): state change: ip-check -> secondaries (reason 'none', managed-type: 'external')
Jan 19 11:33:12 hostname NetworkManager[665]: <info>  [1768818792.2166] device (tun0): state change: secondaries -> activated (reason 'none', managed-type: 'external')
Jan 19 11:33:12 hostname NetworkManager[665]: <info>  [1768818792.2170] device (tun0): Activation: successful, device activated.
Jan 19 11:33:12 hostname kded6[1072]: Failed to notify "Created too many similar notifications in quick succession"
Jan 19 11:33:22 hostname systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
.
.
Jan 19 11:37:01 hostname wpa_supplicant[731]: wlp0s20f3: RSN: Group rekeying completed with c8:0e:14:3d:b0:66 [GTK=CCMP]
  1. and my new notebook, falling out of the tunnel after about 2 minutes:
Jan 19 11:17:49 hostname nm-openvpn[4447]: OpenVPN 2.6.17 [git:makepkg/fa20154d58ca609b+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on Nov 28 2025
Jan 19 11:17:49 hostname nm-openvpn[4447]: library versions: OpenSSL 3.6.0 1 Oct 2025, LZO 2.10
Jan 19 11:17:49 hostname nm-openvpn[4447]: DCO version: N/A
Jan 19 11:17:49 hostname nm-openvpn[4447]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Jan 19 11:17:49 hostname nm-openvpn[4447]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jan 19 11:17:49 hostname nm-openvpn[4447]: TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xxx.xx.xx:8443
Jan 19 11:17:49 hostname nm-openvpn[4447]: Attempting to establish TCP connection with [AF_INET]xx.xxx.xx.xx:8443
Jan 19 11:17:49 hostname nm-openvpn[4447]: TCP connection established with [AF_INET]xx.xxx.xx.xx:8443
Jan 19 11:17:49 hostname nm-openvpn[4447]: TCPv4_CLIENT link local: (not bound)
Jan 19 11:17:49 hostname nm-openvpn[4447]: TCPv4_CLIENT link remote: [AF_INET]xx.xxx.xx.xx:8443
Jan 19 11:17:49 hostname nm-openvpn[4447]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Jan 19 11:17:50 hostname nm-openvpn[4447]: [Appliance_Certificate_ob2Vf9QO1H2muw4] Peer Connection Initiated with [AF_INET]xx.xxx.xx.xx:8443
Jan 19 11:17:52 hostname nm-openvpn[4447]: TUN/TAP device tun0 opened
Jan 19 11:17:52 hostname nm-openvpn[4447]: /usr/lib/nm-openvpn-service-openvpn-helper --debug 0 4434 --bus-name org.freedesktop.NetworkManager.openvpn.Connection_6 --tun -- tun0 1500 0 xx.xxx.x.x 255.255.255.0 init
Jan 19 11:17:52 hostname NetworkManager[714]: <info>  [1768817872.1930] manager: (tun0): new Tun device (/org/freedesktop/NetworkManager/Devices/5)
Jan 19 11:17:52 hostname kded6[1206]: Unhandled VPN connection state change:  NetworkManager::VpnConnection::GettingIpConfig
Jan 19 11:17:52 hostname avahi-daemon[716]: Joining mDNS multicast group on interface tun0.IPv6 with address xxxx::xxxx:xxxx:xxxx:xxxx.
Jan 19 11:17:52 hostname avahi-daemon[716]: New relevant interface tun0.IPv6 for mDNS.
Jan 19 11:17:52 hostname avahi-daemon[716]: Registering new address record for xxxx::xxxx:xxxx:xxxx:xxxx on tun0.*.
Jan 19 11:17:52 hostname nm-openvpn[4447]: UID set to nm-openvpn
Jan 19 11:17:52 hostname nm-openvpn[4447]: GID set to nm-openvpn
Jan 19 11:17:52 hostname nm-openvpn[4447]: Capabilities retained: CAP_NET_ADMIN
Jan 19 11:17:52 hostname nm-openvpn[4447]: Initialization Sequence Completed
.
.
Jan 19 11:18:02 hostname systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Jan 19 11:19:46 hostname nm-openvpn[4447]: AUTH: Received control message: AUTH_FAILED
Jan 19 11:19:46 hostname nm-openvpn[4447]: SIGUSR1[soft,auth-failure] received, process restarting
2

Since the process

I could suspect that it is an issue with power configuration.

wpa_supplicant only handles the connection to your access point - it has nothing to do with the VPN tunnel.

If then when network is idle - implying the tunnel is idle too, power configuration may think it is safe to cut power to the wifi card.

3

Thank you @linux-aarhus for your quick response. OK, understood that the wpa_supplicant isn’t what i was searching for.

I deactivated the “sleep-mode” at the kde battery symbol, started a new tunnel, ssh’ed to a server at the end of the tunnel and started typing some commands. After about 2 Minutes of continuous typing, the tunnel broke and the session freezed as always :-(.

In the journal i found this:

Jan 19 14:29:36 hostname nm-openvpn[6858]: AUTH: Received control message: AUTH_FAILED
Jan 19 14:29:36 hostname nm-openvpn[6858]: SIGUSR1[soft,auth-failure] received, process restarting

There seems to be continuous authentication in the background after some minutes.

4

I am thinking you may try to disable IPv6 - you can do it from the configuration page for your local network connection on the IPv6 tab.

5

sorry, the same error without IPv6 :frowning:

6

You will likely need to talk to the administrator of your company VPN connection.

The may know what you need to check.

7

That’s the problem. There solution: use windows with openvpn! :thinking:. that is sure to work. They don’t support linux and even don’t discuss about it, because they don’t like and understand it.

But my old notebook with the same manjaro / kde combination and all updates until today is still working and building a stable tunnel. I took the certificates from my old notebook. But i think, on my way through the years using my old notebook, i may have installed something that does “the magic”.

I will continue searching. Thank you for your suggestions to fix the problem.

8

If they use OpenVPN and your configuration is for OpenVPN, then it should work.

There is no magic involved - none - whatsoever.

How the connection is configured and routed is all in the configuration files.

When it comes to secure network connections - due to the security concerns - those in charge are the best qualified to troubleshoot problems.

There is very little an ordinary forum member like myself can do to help in such case.

9

I would try adding a keepalive directive to the server’s configuration by creating the file

/etc/openvpn/server/server.conf

with the content

keepalive 10 120

In this case the server will send ping-like messages to all of its clients every 10 seconds, thus keeping the tunnel up. If the server does not receive a response within 120 seconds from a specific client, it will assume this client is down.

1 Like
10

Where did you install that from? It’s not in the repos, and it’s not in the AUR or Flatpak, for Manjaro.

It looks like something from one of those shonky AV companies.

…and why, when Manjaro comes with an Open Source Fire Wall.

11

I haven’t commented on that - but a Sophos Firewall is a physical hardware device - usually at the front of a corporate network - thus not relevant.

And I am thinking that it is part of the connection as it appears the openvpn tunnel is running on a custom port.

Port 8443 is not the default OpenVPN port - but as OpenVPN is flexible in that regard, it is likely correct. Back-in-time the Citizen VPN provider had options to run OpenVPN over port 53 or 443.

As I said earlier - and it is completely clear now - contact your IT department - they will know more than this forum

Download client - Sophos Firewall

Sophos Connect client - Sophos Firewall

12

Thank you all for your suggestions. Sorry, my english is not so good. Perhaps it’s not clear what i am doing:
I am establishing a VPN from my notebook (client) through the openvpn-function from the networkmanager to the sophos firewall at work. I got an configuration-file from the sophos firewall for openvpn, which could be imported to the networkmanager. The port it is using is 8443. I am not able to add a “keepalive”-config-entry to the company firewall and the firewall is not a software running on my client-notebook which i installed from the repos or from foreign repos.

The Sophos Connect client can be an alternative as linux-aarhus mentioned. Perhaps that’s worth a try.

I still can’t believe why one Manjaro-Linux can establish a stable VPN-connection and another can’t keep it up and running. I am experimenting with NixOS which has the same problem: no stable vpn-connection.

My next move will be comparing installed packages. Perhaps i find some differences on the 2 notebooks, which can explain the different behaviour.

1 Like
13

When you have two Manjaro systems, one working, the other not, then it is clearly not a Manjaro issue but a configuration issue on the non working system.

As you have - presumably - kept your old system up-to-date, then OpenVPN and NetworkManager will be the same with the new installation - so comparing packages will not make any difference.

Instead, I suggest you compare the settings between the working system and the non-working system.

To compare the two you will not only need to compare the immediate visible properties e.g. the General, VPN(openvpn), IPv4 and IPv6 tabs, but also the properties behind the Advanced… button in the VPN page, which has further properties configured.

You should also be able to export the working connection.

  • On old laptop where the connection work as expected
  • right-click the profile and choose export
  • save the config onto a USB stick
  • attach the stick to the new system
  • open network manager settings
  • click the +sign at the bottom of the connection list
  • scroll to the bottom → Other
  • click import VPN configuration
  • navigate to the location with the configuration

Manually fill in the username and password if that is required and connect.

14

Your OpenVPN configuration file is most useful for troubleshooting. If you only have the NetworkManger connection config file, that should be good enough (I think).

But just quickly looking now (never using Sophos before). I found in their Apple client configuration page (same as Linux). Their documentation says:

  • If the Protocol for SSL VPN connection is configured as TCP, then set the parameter proto as TCP.

  • If the Protocol is configured as UDP, no change is required. Set the parameter reneg-sec to 3600.

And then they provide a sample configuration file. Pretty standard for the most part. But there are two things that you may need in your config from it.

Otherwise, it’s a pretty standard config.

client
dev tun
port 8443
proto tcp
remote 10.103.6.148
remote 172.16.16.148
remote 10.10.1.1
resolv-retry infinite
nobind
persist-key
persist-tun
auth-user-pass
comp-lzo
verb 3
reneg-sec 3600
status crssl_client_status.log
ca RootCertificate.pem
cert UserCertificate.pem
key UserPrivateKey.key

And reneg-sec 3600 seems about right.

15

Sorry, there was no time for the last days for ongoing research at this problem.

Thank you both for your comments. I think they point in the right direction.

@linux-aarhus: I’ve done what you mentioned. I exported the configuration from my working old notebook and my new notebook an used “diff” to find the differences. There should not be any, because i exported the configuration on my old notebook and imported it at the new one, but there are!

The difference is the “reneg-sec” entry, @Molski mentioned. The configuration on my old notebook showed here an entry of 86400. On my new notebook, the entry showed 99. I can’t find the entry in the graphical configuration on Networkmanager, so i wonder how to set it on my new notebook?

Btw: I searched the original OpenVPN-Configuration file i got from the Sophos Firewall. There the “reneg-sec” entry was set to “0” :face_with_monocle:

16

OK, found it at the “Advanced” Tab :sleepy_face:

17

…but can only be set to 99! :face_with_monocle:

18

There seems to be an error at the NetworkManager. When i look at the value on my old notebook, it also shows 99 (seconds?). When i leave the configuration, it says, there are changes (which i didn’t do manually) and i should save my configuration! Of course i don’t to it, because after that the error strikes my old now functioning notebook to!

19

I found out, that the NetworkManager stores it’s configuration-files in /etc/NetworkManager/system-configuration. Perhaps it’s not the best way to fix this problem, but i stopped the NetworkManager with “sudo systemctl stop NetworkManager”, then inserted the different values from my old notebook (except the uuid) and started the NetworkManager again. Now the VPN-connection stays up.

Thank you all for helping me finding the problem.

1 Like
20

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.