Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Restoring from suspend, openvpn sometimes requires a restart
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
danielittlewood
n00b
n00b


Joined: 13 Apr 2020
Posts: 60

PostPosted: Sun Dec 26, 2021 12:59 pm    Post subject: Restoring from suspend, openvpn sometimes requires a restart Reply with quote

I use openvpn to connect to a Private Internet Access VPN (set up following the wiki).

When I suspend my laptop, sometimes (but not always) my VPN fails to connect, and I have to restart openvpn in order to continue. Restarting NetworkManager works too, but that's only because it restarts openvpn in the process, I think.

I asked about this in IRC, and they suggested checking /var/log/messages.log, and ip addr. A gist showing /var/log/messages.log is here: https://gist.github.com/danielittlewood0/f3d8e7b5e73ebbe935b45a63aa5cc0e5

Before and after restarting openvpn, my ip addr shows a change in tun0:

Code:
# before
35: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none
    inet 10.9.112.248/24 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::4f0e:27f6:e405:3e53/64 scope link stable-privacy
       valid_lft forever preferred_lft forever

# after
39: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none
    inet 10.1.112.47/24 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::a874:9d00:6ff0:abf6/64 scope link stable-privacy
       valid_lft forever preferred_lft forever


I'm guessing at the moment that whatever that IP in ip addr means, the corresponding machine changed its IP while the machine was suspended, and for that reason connection over the VPN is impossible. Restarting the VPN presumably finds the VPN without a direct connection (maybe it uses a different DNS?) and once the connection is active, the problem stops.

But I have no idea how to test that hypothesis, or how to investigate further.
_________________
With man it is impossible, but with gcc all things are possible.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6098
Location: Dallas area

PostPosted: Sun Dec 26, 2021 2:03 pm    Post subject: Reply with quote

Every time openvpn is started, it connects to the vpn service and gets a 10.* address (in your case).
When you come back from suspend, that address might not be available to you (because of the vpn service)
The reason it works (sometimes) is that the 10.* address is still valid (available from vpn service)

I know that I've stopped openvpn for a short period of time, and when I restart openvpn, sometimes the 10.* addy is the same, sometimes it changes.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
pa4wdh
l33t
l33t


Joined: 16 Dec 2005
Posts: 812

PostPosted: Sun Dec 26, 2021 2:06 pm    Post subject: Reply with quote

In my experience VPN and suspend is a combination that always ends up with trouble.

Your hypothesis is quite likely to be right, although openvpn does have a feature called "floating" where you can safely change IP address without losing your VPN. I would expect the client to have changed IP address, not the server.
An other thing is, depending on the server-side configuration, that the server simply forgot about your VPN session because the sleep time of your laptop is longer than the timeouts configured server side (usually a few minutes). In that case there is nothing to be restored and the only way out is a restart of your VPN.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com
Back to top
View user's profile Send private message
danielittlewood
n00b
n00b


Joined: 13 Apr 2020
Posts: 60

PostPosted: Sun Dec 26, 2021 2:52 pm    Post subject: Reply with quote

Ok - seems like this is a more general problem than I first thought.

It makes sense that IP would be constantly changing, and also that if the IP changes subnet then it can't be rerouted and the connection might just fail. I'm surprised something scriptable (like restarting openvpn when NetworkManager finishes connecting?) isn't already implemented. Maybe there's a complexity I don't know about.

I'm optimistic that the "ipchange" directive might be useful. (docs here: https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/). At the moment I'm just logging what it reports as ip_address and port_number. But the following sounds promising:

Quote:
If you are running in a dynamic IP address environment where the IP addresses of either peer could change without notice, you can use this script, for example, to edit the /etc/hosts file with the current address of the peer. The script will be run every time the remote peer changes its IP address.


I assume they mean to edit /etc/hosts so that the `remote` declared in openvpn.conf points to the new IP? So in my case add (programmatically)

143.244.37.82 uk-southampton.privacy.network

maybe?

Update: I realise now that the IP indicated above is the public IP assigned to *my* computer, not to the VPN server. The VPN has a 10.*, while I have a 143.*. In particular, whenever I restart openvpn I appear to get a new IP - but when I resumed just now I did not.
_________________
With man it is impossible, but with gcc all things are possible.
Back to top
View user's profile Send private message
danielittlewood
n00b
n00b


Joined: 13 Apr 2020
Posts: 60

PostPosted: Sun Dec 26, 2021 4:19 pm    Post subject: Reply with quote

I have had some success, I think. The proposed config on the wiki includes

Code:
# persistent device and keys
persist-key
persist-tun


The /var/log/messages file indicates that --ping-restart (which triggers a SIGUSR1 signal) is being run, but the options above suggest that the tunnel is being persisted. My hypothesis is that by removing persist-tun, the tunnel will be cleared, and the connection will be set up correctly.

There is another option --persist-remote-ip, which is not set, which I would expect to have the same effect. So I don't completely understand why it doesn't work at the moment.

Anyway, I'm going to do some experimentation. I did a suspend for about 20 minutes just now with those options set,

Code:
# before
67: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none
    inet 10.24.112.248/24 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::af91:33b8:483f:aab7/64 scope link stable-privacy
       valid_lft forever preferred_lft forever
# after
68: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none
    inet 10.14.112.114/24 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::f488:754e:444c:42e2/64 scope link stable-privacy
       valid_lft forever preferred_lft forever


which is encouraging. But I was sure I tried it before and it didn't work. So I need to do more tests.
_________________
With man it is impossible, but with gcc all things are possible.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum