Mailing List Archive: Sending HUP to OpenVPN after WiFi reconnect in Mesh

Sending HUP to OpenVPN after WiFi reconnect in Mesh

Jan 3, 2024, 8:50 AM

Post #1 of 3 (60 views)

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: Sending HUP to OpenVPN after WiFi reconnect in Mesh [ In reply to ]

hoelbezier at riseup

Jan 3, 2024, 9:11 AM

Post #2 of 3 (60 views)

Permalink

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

Re: Sending HUP to OpenVPN after WiFi reconnect in Mesh [ In reply to ]

ml at floga

Jan 3, 2024, 4:34 PM

Post #3 of 3 (58 views)

Permalink

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

Mailing List Archive

Mailing List Archive

Attached Files: