[gentoo-user] Sending HUP to OpenVPN after WiFi reconnect in Mesh

[gentoo-user] Sending HUP to OpenVPN after WiFi reconnect in Mesh

[Florian Gamböck]

Dearest collective knowledge of gentoo-user,

I'm using netifrc with wpa_supplicant (no custom settings in netifrc) 
for accessing a FRITZ!Box network at my parents house. They have some 
WiFi repeaters set up, connected via AVM's Meshing capabilities.

Also, I am using OpenVPN to connect to VPN servers from ProtonVPN.

 From time to time, I would see this in the syslog:

> Jan  3 16:37:01 georgi kernel: wlp0s20f3: disconnect from AP 04:b4:fe:b3:3f:71 for new auth to 3c:a6:2f:ed:5b:1b
> Jan  3 16:37:01 georgi kernel: wlp0s20f3: authenticate with 3c:a6:2f:ed:5b:1b
> Jan  3 16:37:01 georgi kernel: wlp0s20f3: 80 MHz not supported, disabling VHT
> Jan  3 16:37:01 georgi kernel: wlp0s20f3: send auth to 3c:a6:2f:ed:5b:1b (try 1/3)
> Jan  3 16:37:01 georgi kernel: wlp0s20f3: authenticated
> Jan  3 16:37:01 georgi kernel: wlp0s20f3: associate with 3c:a6:2f:ed:5b:1b (try 1/3)
> Jan  3 16:37:01 georgi kernel: wlp0s20f3: RX ReassocResp from 3c:a6:2f:ed:5b:1b (capab=0x1431 status=0 aid=9)
> Jan  3 16:37:01 georgi kernel: wlp0s20f3: associated
> Jan  3 16:37:38 georgi kernel: wlp0s20f3: disconnect from AP 3c:a6:2f:ed:5b:1b for new auth to 04:b4:fe:b3:3f:71
> Jan  3 16:37:39 georgi kernel: wlp0s20f3: authenticate with 04:b4:fe:b3:3f:71
> Jan  3 16:37:39 georgi kernel: wlp0s20f3: 80 MHz not supported, disabling VHT
> Jan  3 16:37:39 georgi kernel: wlp0s20f3: send auth to 04:b4:fe:b3:3f:71 (try 1/3)
> Jan  3 16:37:39 georgi kernel: wlp0s20f3: send auth to 04:b4:fe:b3:3f:71 (try 2/3)
> Jan  3 16:37:39 georgi kernel: wlp0s20f3: authenticated
> Jan  3 16:37:39 georgi kernel: wlp0s20f3: associate with 04:b4:fe:b3:3f:71 (try 1/3)
> Jan  3 16:37:39 georgi kernel: wlp0s20f3: RX ReassocResp from 04:b4:fe:b3:3f:71 (capab=0x1431 status=0 aid=3)
> Jan  3 16:37:39 georgi kernel: wlp0s20f3: associated

This happens even without setting "bgscan" or similar in 
wpa_supplicant.conf, so I highly suspect, this is the magic of a Mesh 
WiFi to pass me to a more fitting AP in the same network from time to 
time. All fine so far, I don't lose WiFi connection, so this seems 
normal to me.

What bugs me however is, that OpenVPN loses connection to the VPN server 
after such an AP change and is not able to reconnect automatically 
again.

> Dec 31 19:06:08 georgi openvpn[14956]: [node-ch-11.protonvpn.net] Inactivity timeout (--ping-restart), restarting
> Dec 31 19:06:08 georgi openvpn[14956]: /etc/openvpn/down.sh proton0 1500 0 10.96.0.39 255.255.0.0 restart
> Dec 31 19:06:08 georgi openvpn[14956]: SIGUSR1[soft,ping-restart] received, process restarting
> Dec 31 19:06:09 georgi openvpn[14956]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
> Dec 31 19:06:09 georgi openvpn[14956]: TCP/UDP: Preserving recently used remote address: [AF_INET]138.199.6.178:1194
> Dec 31 19:06:09 georgi openvpn[14956]: NOTE: setsockopt TCP_NODELAY=1 failed
> Dec 31 19:06:09 georgi openvpn[14956]: UDPv4 link local: (not bound)
> Dec 31 19:06:09 georgi openvpn[14956]: UDPv4 link remote: [AF_INET]138.199.6.178:1194
> Dec 31 19:06:29 georgi openvpn[14956]: Server poll timeout, restarting
> Dec 31 19:06:29 georgi openvpn[14956]: /etc/openvpn/down.sh proton0 1500 0 10.96.0.39 255.255.0.0 restart
> Dec 31 19:06:29 georgi openvpn[14956]: SIGUSR1[soft,server_poll] received, process restarting
> Dec 31 19:06:29 georgi openvpn[14956]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
> Dec 31 19:06:29 georgi openvpn[14956]: TCP/UDP: Preserving recently used remote address: [AF_INET]138.199.6.179:51820
> Dec 31 19:06:29 georgi openvpn[14956]: NOTE: setsockopt TCP_NODELAY=1 failed
> Dec 31 19:06:29 georgi openvpn[14956]: UDPv4 link local: (not bound)
> Dec 31 19:06:29 georgi openvpn[14956]: UDPv4 link remote: [AF_INET]138.199.6.179:51820

The lines from 19:06:29 are repeated every 20 seconds 
(server-poll-timeout 20), with varying IP addresses, so it seems to 
cycle infinitely through all servers without success.

While this is happening, I cannot access the internet. I suspect, this 
is because of the "persist-tun" setting in the OpenVPN config, but I 
don't want to remove it because I'd rather have no internet at all than 
having suddenly internet without VPN ("kill switch").

I can manually "repair" this situation by sending SIGHUP to OpenVPN, 
which causes a hard reconnect.

Now, with this background information, I need your help to come up with 
a strategy to survive an automatic Mesh WiFi reconnect, without the need 
of manually restarting OpenVPN all the time.

-   Might there be a problem with my OpenVPN config? I'm mostly using 
the default config that can be downloaded from ProtonVPN, with some 
additional "route" statements to make VPN unfriendly websites happy, and 
I renamed the device name to have proper logs (see code block directly 
below this bullet point). Has anyone a similar setup and did some 
adjustments to make it work properly?

> dev proton0
> dev-type tun

-   If there is nothing wrong with my OpenVPN config, how can I 
automatically send a SIGHUP on such a reconnect event? It is not a 
"proper" CONNECTED event, so wpa_cli.conf does not get triggered. How 
can I monitor such events and respond accordingly?

For now, I used the below statement in OpenVPN config to do a hard reset 
on server timeout, but for this I need to wait two minutes for the 
timeout to hit. I'd rather want this immediately when wpa_supplicant 
reconnects.

> remap-usr1 SIGHUP

Any help in this matter would highly be appreciated!

Thanks in advance!

Kind regards

FloGa

Re: [gentoo-user] Sending HUP to OpenVPN after WiFi reconnect in Mesh

[Hoël Bézier]

[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]

Am Wed, Jan 03, 2024 at 05:50:52PM +0100 schrieb Florian Gamböck:
>
>[snip]
>
>What bugs me however is, that OpenVPN loses connection to the VPN server
>after such an AP change and is not able to reconnect automatically
>again.
>
>[snip]
>
>While this is happening, I cannot access the internet. I suspect, this
>is because of the "persist-tun" setting in the OpenVPN config, but I
>don't want to remove it because I'd rather have no internet at all than
>having suddenly internet without VPN ("kill switch").
>
>I can manually "repair" this situation by sending SIGHUP to OpenVPN,
>which causes a hard reconnect.
>
>Now, with this background information, I need your help to come up with
>a strategy to survive an automatic Mesh WiFi reconnect, without the need
>of manually restarting OpenVPN all the time.

I’ve encountered the same issue as you. I fixed it by removing the persist-tun 
option from my configuration file.

The way I understand this configuration option, is that OpenVPN allows itself 
to destroy and recreate tun interfaces if needed. I’m not sure whether it means 
you may end up on the internet without going through your VPN.

What I’m sure of is that sending SIGHUP to OpenVPN tells it to destroy and 
recreate that tun interface of yours, bypassing the persist-tun instruction you 
gave it in your configuration file.

Others may have more satisfying answers than mine, but I believe the 
appropriate way to fix your issue is by allowing OpenVPN to recreate tun 
interfaces when needed, such as after a disconnect, and so you need to remove 
the persist-tun option. You might want to wait confirmation from other people 
around before doing so, though.

I’d be very interested if anyone had further information on that matter, 
whether they would contredict my claims or support them.

Hoël

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Sending HUP to OpenVPN after WiFi reconnect in Mesh

[Florian Gamböck]

Hi Hoël,

thanks for your response!

On 2024-01-03 18:11, Hoël Bézier wrote:
> I’ve encountered the same issue as you. I fixed it by removing the 
> persist-tun option from my configuration file.
>
> The way I understand this configuration option, is that OpenVPN allows 
> itself to destroy and recreate tun interfaces if needed. I’m not sure 
> whether it means you may end up on the internet without going through 
> your VPN.

I tried again to remove the "persist-tun" option, and indeed I can now 
reconnect also via SIGUSR1 without problems. Also all traffic is blocked 
/ dropped while waiting for the server timeout, so at least I'm not left 
open in the wild without VPN.

> I’d be very interested if anyone had further information on that 
> matter, whether they would contredict my claims or support them.

Yes, even though USR1 works now without falling back to no-VPN routing, 
if someone can give a little more insight if removing "persist-tun" is 
the way to go here would be nice!

So at least one of the issues is "solved" for now, but the main problem 
still remains: How can I properly detect Mesh roaming and react timely 
to send HUP or USR1 to OpenVPN?

I'm still thinking about some sort of wpa_supplicant "hook" mechanism 
for these roaming events, but I cannot find something like this in the 
docs ...

Kind regards

FloGa