Arch Linux

kivot

Member

Registered: 2021-11-20

Posts: 14

[SOLVED] OpenVPN client fails to reconnect PIA VPN after WLAN lapse

How to debug the following reconnection issue?
I have configured the openvpn client to connect to PIA VPN according to their manual https://www.privateinternetaccess.com/h … e-terminal.
It connects just fine but once my WLAN is interrupted (with a weather radar, happens approx daily) it can not reconnect.
systemctl restart openvpn-client@us_east works with no problem but the automatic reconnect fails. Please see the log below.
I have written to PIA support but have had not reply other than the above manual for more than a week now.
What can I do to debug this?

Feb 01 12:51:41 arch-box dhcpcd[572]: wlan0: carrier acquired
Feb 01 12:51:41 arch-box dhcpcd[572]: wlan0: rebinding lease of 192.168.178.33
Feb 01 12:51:41 arch-box dhcpcd[572]: wlan0: probing address 192.168.178.33/24
Feb 01 12:51:46 arch-box dhcpcd[572]: wlan0: leased 192.168.178.33 for 864000 seconds
Feb 01 12:51:46 arch-box avahi-daemon[565]: Joining mDNS multicast group on interface wlan0.IPv4 with address 192.168.178.33.
Feb 01 12:51:46 arch-box avahi-daemon[565]: New relevant interface wlan0.IPv4 for mDNS.
Feb 01 12:51:46 arch-box avahi-daemon[565]: Registering new address record for 192.168.178.33 on wlan0.IPv4.
Feb 01 12:51:46 arch-box dhcpcd[572]: wlan0: adding route to 192.168.178.0/24
Feb 01 12:51:46 arch-box dhcpcd[572]: wlan0: adding default route via 192.168.178.1
Feb 01 12:54:31 arch-box openvpn[37920]: [newjersey428] Inactivity timeout (--ping-restart), restarting
Feb 01 12:54:31 arch-box openvpn[37920]: SIGUSR1[soft,ping-restart] received, process restarting
Feb 01 12:54:36 arch-box openvpn[37920]: TCP/UDP: Preserving recently used remote address: [AF_INET]102.165.16.102:1198
Feb 01 12:54:36 arch-box openvpn[37920]: UDP link local: (not bound)
Feb 01 12:54:36 arch-box openvpn[37920]: UDP link remote: [AF_INET]102.165.16.102:1198
Feb 01 12:55:37 arch-box openvpn[37920]: [UNDEF] Inactivity timeout (--ping-restart), restarting
Feb 01 12:55:37 arch-box openvpn[37920]: SIGUSR1[soft,ping-restart] received, process restarting
Feb 01 12:55:42 arch-box openvpn[37920]: TCP/UDP: Preserving recently used remote address: [AF_INET]102.165.16.122:1198
Feb 01 12:55:42 arch-box openvpn[37920]: UDP link local: (not bound)
Feb 01 12:55:42 arch-box openvpn[37920]: UDP link remote: [AF_INET]102.165.16.122:1198

etc. goes forever, every five minutes a different IP.

Actual log with startup sequence and the software versions. The connection is established @Feb 18 03:58:52 but then drops @Feb 18 06:10:27 to never come up again. So maybe there is no information in this log to pin the culprit at all. So where else could I look?

Feb 18 03:58:37 arch-box openvpn[609]: DEPRECATED OPTION: --cipher set to 'aes-128-cbc' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --ciph>
Feb 18 03:58:37 arch-box openvpn[609]: WARNING: file '/etc/openvpn/login' is group or others accessible
Feb 18 03:58:37 arch-box openvpn[609]: OpenVPN 2.5.5 [git:makepkg/869f194c23ae93c4+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Dec 15 >
Feb 18 03:58:37 arch-box openvpn[609]: library versions: OpenSSL 1.1.1m  14 Dec 2021, LZO 2.10
Feb 18 03:58:37 arch-box systemd[1]: Started OpenVPN tunnel for us_east.
░░ Subject: A start job for unit openvpn-client@us_east.service has finished successfully
░░ Defined-By: systemd
░░ Support: [url]https://lists.freedesktop.org/mailman/listinfo/systemd-devel[/url]
░░ 
░░ A start job for unit openvpn-client@us_east.service has finished successfully.
░░ 
░░ The job identifier is 89.
Feb 18 03:58:37 arch-box openvpn[609]: CRL: loaded 1 CRLs from file -----BEGIN X509 CRL-----
...
Feb 18 03:58:37 arch-box openvpn[609]: -----END X509 CRL-----
Feb 18 03:58:37 arch-box openvpn[609]: RESOLVE: Cannot resolve host address: us-newjersey.privacy.network:1198 (Temporary failure in name resolution)
Feb 18 03:58:37 arch-box openvpn[609]: RESOLVE: Cannot resolve host address: us-newjersey.privacy.network:1198 (Temporary failure in name resolution)
Feb 18 03:58:37 arch-box openvpn[609]: Could not determine IPv4/IPv6 protocol
Feb 18 03:58:37 arch-box openvpn[609]: SIGUSR1[soft,init_instance] received, process restarting
Feb 18 03:58:42 arch-box openvpn[609]: RESOLVE: Cannot resolve host address: us-newjersey.privacy.network:1198 (Temporary failure in name resolution)
Feb 18 03:58:42 arch-box openvpn[609]: RESOLVE: Cannot resolve host address: us-newjersey.privacy.network:1198 (Temporary failure in name resolution)
Feb 18 03:58:42 arch-box openvpn[609]: Could not determine IPv4/IPv6 protocol
Feb 18 03:58:42 arch-box openvpn[609]: SIGUSR1[soft,init_instance] received, process restarting
Feb 18 03:58:47 arch-box openvpn[609]: RESOLVE: Cannot resolve host address: us-newjersey.privacy.network:1198 (Temporary failure in name resolution)
Feb 18 03:58:47 arch-box openvpn[609]: RESOLVE: Cannot resolve host address: us-newjersey.privacy.network:1198 (Temporary failure in name resolution)
Feb 18 03:58:47 arch-box openvpn[609]: Could not determine IPv4/IPv6 protocol
Feb 18 03:58:47 arch-box openvpn[609]: SIGUSR1[soft,init_instance] received, process restarting
Feb 18 03:58:52 arch-box openvpn[609]: TCP/UDP: Preserving recently used remote address: [AF_INET]102.165.16.194:1198
Feb 18 03:58:52 arch-box openvpn[609]: UDP link local: (not bound)
Feb 18 03:58:52 arch-box openvpn[609]: UDP link remote: [AF_INET]102.165.16.194:1198
Feb 18 06:10:27 arch-box openvpn[609]: [newjersey431] Inactivity timeout (--ping-restart), restarting
Feb 18 06:10:27 arch-box openvpn[609]: SIGUSR1[soft,ping-restart] received, process restarting
Feb 18 06:10:32 arch-box openvpn[609]: TCP/UDP: Preserving recently used remote address: [AF_INET]102.165.16.194:1198
Feb 18 06:10:32 arch-box openvpn[609]: UDP link local: (not bound)
Feb 18 06:10:32 arch-box openvpn[609]: UDP link remote: [AF_INET]102.165.16.194:1198
Feb 18 06:11:32 arch-box openvpn[609]: [UNDEF] Inactivity timeout (--ping-restart), restarting
Feb 18 06:11:32 arch-box openvpn[609]: SIGUSR1[soft,ping-restart] received, process restarting
Feb 18 06:11:37 arch-box openvpn[609]: TCP/UDP: Preserving recently used remote address: [AF_INET]191.96.185.72:1198
Feb 18 06:11:37 arch-box openvpn[609]: UDP link local: (not bound)
Feb 18 06:11:37 arch-box openvpn[609]: UDP link remote: [AF_INET]191.96.185.72:1198
Feb 18 06:12:38 arch-box openvpn[609]: [UNDEF] Inactivity timeout (--ping-restart), restarting
Feb 18 06:12:38 arch-box openvpn[609]: SIGUSR1[soft,ping-restart] received, process restarting
Feb 18 06:12:43 arch-box openvpn[609]: TCP/UDP: Preserving recently used remote address: [AF_INET]102.165.16.219:1198
Feb 18 06:12:43 arch-box openvpn[609]: UDP link local: (not bound)
Feb 18 06:12:43 arch-box openvpn[609]: UDP link remote: [AF_INET]102.165.16.219:1198
Feb 18 06:13:43 arch-box openvpn[609]: [UNDEF] Inactivity timeout (--ping-restart), restarting
Feb 18 06:13:43 arch-box openvpn[609]: SIGUSR1[soft,ping-restart] received, process restarting
Feb 18 06:13:48 arch-box openvpn[609]: TCP/UDP: Preserving recently used remote address: [AF_INET]102.165.16.99:1198
Feb 18 06:13:48 arch-box openvpn[609]: UDP link local: (not bound)
Feb 18 06:13:48 arch-box openvpn[609]: UDP link remote: [AF_INET]102.165.16.99:1198
Feb 18 06:14:48 arch-box openvpn[609]: [UNDEF] Inactivity timeout (--ping-restart), restarting
Feb 18 06:14:48 arch-box openvpn[609]: SIGUSR1[soft,ping-restart] received, process restarting
Feb 18 06:14:53 arch-box openvpn[609]: TCP/UDP: Preserving recently used remote address: [AF_INET]102.165.16.195:1198
Feb 18 06:14:53 arch-box openvpn[609]: UDP link local: (not bound)
Feb 18 06:14:53 arch-box openvpn[609]: UDP link remote: [AF_INET]102.165.16.195:1198
Feb 18 06:15:54 arch-box openvpn[609]: [UNDEF] Inactivity timeout (--ping-restart), restarting
Feb 18 06:15:54 arch-box openvpn[609]: SIGUSR1[soft,ping-restart] received, process restarting
Feb 18 06:15:59 arch-box openvpn[609]: TCP/UDP: Preserving recently used remote address: [AF_INET]102.165.16.90:1198
Feb 18 06:15:59 arch-box openvpn[609]: UDP link local: (not bound)
Feb 18 06:15:59 arch-box openvpn[609]: UDP link remote: [AF_INET]102.165.16.90:1198

Last edited by kivot (2022-02-21 08:12:53)

-thc

Member

Registered: 2017-03-15

Posts: 1,086

Re: [SOLVED] OpenVPN client fails to reconnect PIA VPN after WLAN lapse

Looks like all subsequent VPN packets are simply dismissed by the VPN server.

Can you verify that your external (WAN) IP address did not change during such a lapse (via e.g. checkip.dyndns.org)?
The IPv4 numbering scheme suggests an AVM Fritz!Box - is this correct?
Do you need the VPN for privacy or primarily for GeoIP reasons?

kivot

Member

Registered: 2021-11-20

Posts: 14

Re: [SOLVED] OpenVPN client fails to reconnect PIA VPN after WLAN lapse

Thanks for looking into this!

Looks like all subsequent VPN packets are simply dismissed by the VPN server.

Hm, is this my problem or should the PIA side handle this issue gracefully?

Can you verify that your external (WAN) IP address did not change during such a lapse (via e.g. checkip.dyndns.org)?

Will do and will report here.

The IPv4 numbering scheme suggests an AVM Fritz!Box - is this correct?

Yes, this is an AVM Fritz!Box infront of this box.

Do you need the VPN for privacy or primarily for GeoIP reasons?

privacy

Last edited by kivot (2022-02-18 11:57:46)

-thc

Member

Registered: 2017-03-15

Posts: 1,086

Re: [SOLVED] OpenVPN client fails to reconnect PIA VPN after WLAN lapse

Hm, is this my problem or should the PIA side handle this issue gracefully?

Too early to say.

privacy

Hmmm. I have some 18+ years of experience with OpenVPN on all kinds of platforms (Windows, macOS, Linux, iOS, Android) and the configuration files of PIA are - in my experience - messy. The more interesting side (the PIA servers and their configuration) is invisible to us. Those can overrule (and correct) some of the client configuration items.

Can you copy your PIA configuration file, change the verbosity to "3" (verb 3) and post the OpenVPN messages (from "OpenVPN 2.5.5...." to "Initialization Sequence Completed") here?

kivot

Member

Registered: 2021-11-20

Posts: 14

Re: [SOLVED] OpenVPN client fails to reconnect PIA VPN after WLAN lapse

I got an answer from the PIA (below). It will probably take a few days to go over them seven configuration options (unless I find a way to simulate wlan failure in a helpful way). Let me do that though first because it might save everybody's time here.

https://www.privateinternetaccess.com/h … e-terminal

Some networks are configured to be more restrictive than others, which can sometimes interfere with VPN connections. In the event the default files do not work, please try redoing the config file portion of the OpenVPN install and replace the https://www.privateinternetaccess.com/o … penvpn.zip file with one of the URLs listed below; please try each set until one of them works:

    OPENVPN CONFIGURATION FILES (DEFAULT)
    OpenVPN Configuration Files (Recommended Default windows only plus block-outside-dns)
    OPENVPN CONFIGURATION FILES (IP)
    OPENVPN CONFIGURATION FILES (STRONG)
    OPENVPN CONFIGURATION FILES (TCP)
    OPENVPN CONFIGURATION FILES (STRONG-TCP)

Last edited by kivot (2022-02-19 05:10:13)

kivot

Member

Registered: 2021-11-20

Posts: 14

Re: [SOLVED] OpenVPN client fails to reconnect PIA VPN after WLAN lapse

Can you verify that your external (WAN) IP address did not change during such a lapse (via e.g. checkip.dyndns.org)?

The WAN IP address did not change.

kivot

Member

Registered: 2021-11-20

Posts: 14

Re: [SOLVED] OpenVPN client fails to reconnect PIA VPN after WLAN lapse

Can you copy your PIA configuration file, change the verbosity to "3" (verb 3) and post the OpenVPN messages (from "OpenVPN 2.5.5...." to "Initialization Sequence Completed") here?

So I have managed to test all the offered configurations and all of them except the bare IP connect but do not reconnect. IP does not connect at all.

Here is the requested log for for us_east/openvpn/strong/tcp

Feb 19 07:28:40 arch-box openvpn[3543]: OpenVPN 2.5.5 [git:makepkg/869f194c23ae93c4+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Dec 15 2021
Feb 19 07:28:40 arch-box openvpn[3543]: library versions: OpenSSL 1.1.1m  14 Dec 2021, LZO 2.10
Feb 19 07:28:40 arch-box systemd[1]: Started OpenVPN tunnel for us_east/openvpn/strong/tcp.
░░ Subject: A start job for unit openvpn-client@us_east-openvpn-strong-tcp.service has finished successfully
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit openvpn-client@us_east-openvpn-strong-tcp.service has finished successfully.
░░ 
░░ The job identifier is 1435.
Feb 19 07:28:40 arch-box openvpn[3543]: CRL: loaded 1 CRLs from file -----BEGIN X509 CRL-----
Feb 19 07:28:40 arch-box openvpn[3543]: -----END X509 CRL-----
Feb 19 07:28:40 arch-box openvpn[3543]: TCP/UDP: Preserving recently used remote address: [AF_INET]191.96.185.13:501
Feb 19 07:28:40 arch-box openvpn[3543]: Socket Buffers: R=[131072->131072] S=[16384->16384]
Feb 19 07:28:40 arch-box openvpn[3543]: Attempting to establish TCP connection with [AF_INET]191.96.185.13:501 [nonblock]
Feb 19 07:28:41 arch-box openvpn[3543]: TCP connection established with [AF_INET]191.96.185.13:501
Feb 19 07:28:41 arch-box openvpn[3543]: TCP_CLIENT link local: (not bound)
Feb 19 07:28:41 arch-box openvpn[3543]: TCP_CLIENT link remote: [AF_INET]191.96.185.13:501
Feb 19 07:28:41 arch-box openvpn[3543]: TLS: Initial packet from [AF_INET]191.96.185.13:501, sid=7d1f677a fbcd908c
Feb 19 07:28:41 arch-box openvpn[3543]: VERIFY OK: depth=1, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=Private Internet Access, name=Private Internet Access, emailAddress=secure@privateinternetaccess.com
Feb 19 07:28:41 arch-box openvpn[3543]: VERIFY KU OK
Feb 19 07:28:41 arch-box openvpn[3543]: Validating certificate extended key usage
Feb 19 07:28:41 arch-box openvpn[3543]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Feb 19 07:28:41 arch-box openvpn[3543]: VERIFY EKU OK
Feb 19 07:28:41 arch-box openvpn[3543]: VERIFY OK: depth=0, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=newjersey433, name=newjersey433
Feb 19 07:28:41 arch-box openvpn[3543]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bit RSA, signature: RSA-SHA512
Feb 19 07:28:41 arch-box openvpn[3543]: [newjersey433] Peer Connection Initiated with [AF_INET]191.96.185.13:501
Feb 19 07:28:41 arch-box openvpn[3543]: PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway def1,route-ipv6 2000::/3,dhcp-option DNS 10.0.0.243,route-gateway 10.4.19.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.4.19.3 255.255.255.0,peer-id 0,cipher AES-256-GCM'
Feb 19 07:28:41 arch-box openvpn[3543]: OPTIONS IMPORT: timers and/or timeouts modified
Feb 19 07:28:41 arch-box openvpn[3543]: OPTIONS IMPORT: compression parms modified
Feb 19 07:28:41 arch-box openvpn[3543]: OPTIONS IMPORT: --ifconfig/up options modified
Feb 19 07:28:41 arch-box openvpn[3543]: OPTIONS IMPORT: route options modified
Feb 19 07:28:41 arch-box openvpn[3543]: OPTIONS IMPORT: route-related options modified
Feb 19 07:28:41 arch-box openvpn[3543]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Feb 19 07:28:41 arch-box openvpn[3543]: OPTIONS IMPORT: peer-id set
Feb 19 07:28:41 arch-box openvpn[3543]: OPTIONS IMPORT: adjusting link_mtu to 1627
Feb 19 07:28:41 arch-box openvpn[3543]: OPTIONS IMPORT: data channel crypto options modified
Feb 19 07:28:41 arch-box openvpn[3543]: Data Channel: using negotiated cipher 'AES-256-GCM'
Feb 19 07:28:41 arch-box openvpn[3543]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Feb 19 07:28:41 arch-box openvpn[3543]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Feb 19 07:28:41 arch-box openvpn[3543]: net_route_v4_best_gw query: dst 0.0.0.0
Feb 19 07:28:41 arch-box openvpn[3543]: net_route_v4_best_gw result: via 192.168.178.1 dev wlan0
Feb 19 07:28:41 arch-box openvpn[3543]: ROUTE_GATEWAY 192.168.178.1/255.255.255.0 IFACE=wlan0 HWADDR=
Feb 19 07:28:41 arch-box openvpn[3543]: GDG6: remote_host_ipv6=n/a
Feb 19 07:28:41 arch-box openvpn[3543]: net_route_v6_best_gw query: dst ::
Feb 19 07:28:41 arch-box openvpn[3543]: sitnl_send: rtnl: generic error (-95): Operation not supported
Feb 19 07:28:41 arch-box openvpn[3543]: ROUTE6: default_gateway=UNDEF
Feb 19 07:28:41 arch-box openvpn[3543]: TUN/TAP device tun0 opened
Feb 19 07:28:41 arch-box openvpn[3543]: net_iface_mtu_set: mtu 1500 for tun0
Feb 19 07:28:41 arch-box openvpn[3543]: net_iface_up: set tun0 up
Feb 19 07:28:41 arch-box openvpn[3543]: net_addr_v4_add: 10.4.19.3/24 dev tun0
Feb 19 07:28:41 arch-box openvpn[3543]: net_route_v4_add: 191.96.185.13/32 via 192.168.178.1 dev [NULL] table 0 metric -1
Feb 19 07:28:41 arch-box openvpn[3543]: net_route_v4_add: 0.0.0.0/1 via 10.4.19.1 dev [NULL] table 0 metric -1
Feb 19 07:28:41 arch-box openvpn[3543]: net_route_v4_add: 128.0.0.0/1 via 10.4.19.1 dev [NULL] table 0 metric -1
Feb 19 07:28:41 arch-box openvpn[3543]: WARNING: OpenVPN was configured to add an IPv6 route. However, no IPv6 has been configured for tun0, therefore the route installation may fail or may not work as expected.
Feb 19 07:28:41 arch-box openvpn[3543]: add_route_ipv6(2000::/3 -> :: metric -1) dev tun0
Feb 19 07:28:41 arch-box openvpn[3543]: net_route_v6_add: 2000::/3 via :: dev tun0 table 0 metric -1
Feb 19 07:28:41 arch-box openvpn[3543]: sitnl_send: rtnl: generic error (-95): Operation not supported
Feb 19 07:28:41 arch-box openvpn[3543]: ERROR: Linux IPv6 route can't be added
Feb 19 07:28:41 arch-box openvpn[3543]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Feb 19 07:28:41 arch-box openvpn[3543]: Initialization Sequence Completed

Last edited by kivot (2022-02-19 12:22:08)

-thc

Member

Registered: 2017-03-15

Posts: 1,086

Re: [SOLVED] OpenVPN client fails to reconnect PIA VPN after WLAN lapse

For me this now splits into 2 problems - privacy and reliability. Privacy first:

Here is the requested log for for us_east/openvpn/strong/tcp

The security (TLS, suite, ciphers) looks good - I expected worse. Please continue using strong (UDP).

Reliability second:

The WAN IP address did not change.

O.K. - this would have been the only understandable reason for PIA to drop your packets.

So I have managed to test all the offered configurations and all of them except the bare IP connect but do not reconnect. IP does not connect at all.

I suspected this.

I tried to come up with a simulation of your Wi-Fi lapse. I used a fixed 5 GHz channel (44) and changed that to 36 (later 56 - see below) and back first without and later with an active OpenVPN connection in the background.

First try the channel change immediately triggered a full disconnect.
On the second try I activated a VPN connection via NetworkManager. The full WiFi disconnect killed that as well.

All subsequent tries (with a "sudo openvpn config.conf" process in another window) suddenly triggered a different behavior:

Feb 19 10:26:26 box wpa_supplicant[501]: wlp3s0: WPA: EAPOL-Key Replay Counter did not increase - dropping packet
Feb 19 10:26:27 box wpa_supplicant[501]: wlp3s0: WPA: EAPOL-Key Replay Counter did not increase - dropping packet
Feb 19 10:26:28 box wpa_supplicant[501]: wlp3s0: WPA: EAPOL-Key Replay Counter did not increase - dropping packet
Feb 19 10:26:29 box NetworkManager[431]: <info>  [1645262789.7790] device (wlp3s0): supplicant interface state: completed -> 4way_handshake
Feb 19 10:26:29 box wpa_supplicant[501]: wlp3s0: WPA: Key negotiation completed with de:ad:be:ef:00:0a [PTK=CCMP GTK=CCMP]
Feb 19 10:26:29 box NetworkManager[431]: <info>  [1645262789.7926] device (wlp3s0): supplicant interface state: 4way_handshake -> completed

The full disconnect was replaced with a simple renewed handshake.

Then I tried channel 56 - this is a channel the WiFi module inside that notebook doesn't like - at all. It reliably triggers a disconnect and I have to switch the channel back for a reconnect.

But while the background OpenVPN process complains it can no longer send packets for the duration of the disconnect it never stops working. After the WiFi reconnect it works as nothing had happened.

So your VPN should continue normally.

Do you (accidentally) use more than one network management? If not, which one?

kivot

Member

Registered: 2021-11-20

Posts: 14

Re: [SOLVED] OpenVPN client fails to reconnect PIA VPN after WLAN lapse

Do you (accidentally) use more than one network management? If not, which one?

My installation is a recent one and I have not configured much apart from getting the WLAN channel frequencies set.

sudo systemctl enable wpa_supplicant@wlan0
sudo systemctl enable dhcpcd
#Disable ipv6
sudo vim /boot/loader/entries/arch-uefi.conf
add ipv6.disable=1

Next step as per my notes was installing openvpn and pia profiles.
No additional network management installed.

Last edited by kivot (2022-02-19 12:17:40)

-thc

Member

Registered: 2017-03-15

Posts: 1,086

Re: [SOLVED] OpenVPN client fails to reconnect PIA VPN after WLAN lapse

Hmm - there is one small caveat with your setup.

Establishing the VPN connection rewrites your default gateway:

Feb 19 07:28:41 arch-box openvpn[3543]: net_route_v4_add: 0.0.0.0/1 via 10.4.19.1 dev [NULL] table 0 metric -1

This in turn would disrupt the outer VPN tunnel packets themselves - so there is this single (VPN server) host route added beforehand:

Feb 19 07:28:41 arch-box openvpn[3543]: net_route_v4_add: 191.96.185.13/32 via 192.168.178.1 dev [NULL] table 0 metric -1

If the WiFi connection is disrupted, dhcpd will reset the default gateway to its old value:

Feb 01 12:51:46 arch-box dhcpcd[572]: wlan0: adding default route via 192.168.178.1

Although the outer VPN tunnel packets don't mind the "old" default route, the VPN is no longer in use because packets no longer flow that way. While the tunnel itself is successfully reestablished (without resetting the routes) - inactivity timeouts have to occur very time.

So - either the VPN gets fully restarted after a WiFi lapse or we try to prevent those in the first place.

kivot

Member

Registered: 2021-11-20

Posts: 14

Re: [SOLVED] OpenVPN client fails to reconnect PIA VPN after WLAN lapse

So - either the VPN gets fully restarted after a WiFi lapse or we try to prevent those in the first place.

Thanks for investing your time again. It looks like you got the culprit.
I don't think I can prevent WiFi lapses because they may be indeed caused by the actual overflying aircraft.
Restarting is not a problem per se. I just did not want to start with workarounds  right away.
Do you have anything specific in mind how to configure for a restart instead of a reconnect attempt?

Last edited by kivot (2022-02-19 14:46:34)

-thc

Member

Registered: 2017-03-15

Posts: 1,086

Re: [SOLVED] OpenVPN client fails to reconnect PIA VPN after WLAN lapse

I had a similar problem shortly after replacing my Fritz!Box with a newer model.

Per default "Wi-Fi 5" was activated for 5 GHz - leading to a bandwidth demand of more than one channel (I think 4 but I'm not sure) and a 5 GHz channel on the low end (36, 40 or 44). Alt least once a day the radar interfered  - starting with channel 48. Now the demand of 4 channels "could no longer fit" into the lower area and the Fritz!Box chose 4 channels above 100 instead.

Some of my 5 GHz devices didn't enjoy that. They lost WiFi connectivity.

I had to step down to "Wi-Fi 4" (width: 1 channel) and setting the channel manually to 44. All problems were gone.

Unfortunately the only OpenVPN connection with a default gateway is my own server@home and I only use it when I'm abroad. So I'm unable to reproduce your setup and thus cannot say if a network management like "NetworkManager" is aware of such a situation.

kivot

Member

Registered: 2021-11-20

Posts: 14

Re: [SOLVED] OpenVPN client fails to reconnect PIA VPN after WLAN lapse

I have changed the WiFi level to 4. Observing now.

kivot

Member

Registered: 2021-11-20

Posts: 14

Re: [SOLVED] OpenVPN client fails to reconnect PIA VPN after WLAN lapse

No luck. With WiFi Level 4 the same disconnection happens.

Wireless auto channel: Current detection of the Wi-Fi environment [GHz] in progress, in order to optimize the channels in use; some wireless devices may be re-registered.
Wi-Fi auto channel: The channel settings (previously channel [number]  ([frequency]) were changed; now active on channel [number] ([frequency]).

So any suggestion on what is the best way to get OpenVPN to do a complete restart or handle the default gateway issue correctly?

P.S. BTW I have also explicitly opened the port 501 and many others on the suggestion from PIA support.

kivot

Member

Registered: 2021-11-20

Posts: 14

Re: [SOLVED] OpenVPN client fails to reconnect PIA VPN after WLAN lapse

OK, so I have resolved this changing the SIGUSR1[soft,ping-restart]  with --remap-usr1 SIGTERM and also adding Restart=always, RestartSec=5s to the /etc/systemd/system/multi-user.target.wants/openvpn-client@us_east-openvpn-strong-tcp.service that is created on service activation.

Thanks a lot @-thc for figuring out what is going on. I am still on a thread with PIA support to see if they will suggest a better resolution.

[Service]
...
ExecStart=/usr/bin/openvpn --suppress-timestamps --nobind --config %i.conf --remap-usr1 SIGTERM
...
Restart=always
RestartSec=5s

kivot

Member

Registered: 2021-11-20

Posts: 14

Re: [SOLVED] OpenVPN client fails to reconnect PIA VPN after WLAN lapse

notes for testing various PIA profiles

# manually copy into pia-vnp-types-links.txt 
# links from https://www.privateinternetaccess.com/helpdesk/guides/linux/linux-installing-openvpn-through-the-terminal
# excluding the Windows one 
#download zip files
while IFS= read -r line; do wget "$line"; done < pia-vnp-types-links.txt
# make a list
ls -1 openvpn*.zip > pia-vnp-types.txt
# choose the pia server you want to test against
export SERVER=us_east
# /etc/openvpn/login is where the your pia login and password credentials go
# add the login line and increase verbosity to 3
while IFS= read -r line; do unzip "$line" "$SERVER".ovpn; sed -i 's#auth-user-pass#auth-user-pass /etc/openvpn/login#; s#verb 1#verb 3#' "$SERVER".ovpn; mv "$SERVER".ovpn "$SERVER-${line%.zip}.conf"; done < pia-vnp-types.txt 
#now move all files to the directory where they should reside
sudo cp ./*.conf /etc/openvpn/client/
# generate the lines to run the configurations
while IFS= read -r line; do for ACTION in {enable,start,status,disable,stop}; do echo "sudo systemctl $ACTION openvpn-client@$SERVER-${line%.zip}"; done; echo "journalctl -xeu openvpn-client@$SERVER-${line%.zip}.service"; echo ""; done < pia-vnp-types.txt