slingamn/namespaced-openvpn

Connection lost after hibernation/standby

Trayshar opened this issue · 2 comments

Trayshar commented

After waking up my system from either hibernation or standby, all processes started using sudo ip netns exec protected sudo -u $USER <command> lose their connection. Restarting them inside the namespaced shell doesn't work, however, after closing and re-opening the shell everything works just fine.

Steps to reproduce

  1. Start namespaced-openvpn
  2. Start a bash shell in the protected namespace: sudo ip netns exec protected sudo -u $USER bash
  3. Run any command that requires an internet connection in the bash shell (e.g. a webbrowser). It should work just fine and route through the vpn.
  4. Put the system in standby or hibernation. Do not exit the shell from (2).
  5. Wake up, try any command that requires internet again. No connection.
  6. Exit the namespaced bash shell and reopen it using the command in (2)
  7. Connection in that shell works just fine now...

Steps to mitigate this

None I found so far, any help is appreciated.

Additional info

My system log shows that the VPN reconnects successfully after waking up, although on a different device number (e.g. in ip addr inside the namespace I get 4: tun0 ... after waking up while its 3: tun0 ... before). Maybe that's related?

I run Manjaro linux (arch-based) on Kernel 5.10

slingamn commented

This is interesting. What do ip addr and ip route display inside the namespace at step 5?

Trayshar commented

Took a measurement. Before standby:

[namespaced@shell ~]$ ip addr; ip route
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 10.3.243.246 peer 10.3.243.3/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fdbf:1d37:bbe0:0:63:19:0:f6 peer fdbf:1d37:bbe0:0:63:19:0:1/112 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::76ba:e14d:b479:3a99/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever
default dev tun0 scope link 
10.3.243.3 dev tun0 proto kernel scope link src 10.3.243.246

If the standby duration is below ~3 minutes, after standby I get the exact same output (and no connection).

If the duration is longer, I get a new tun0 device with different ip (and no connection):

[namespaced@shell ~]$ ip addr; ip route
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 10.3.244.19 peer 10.3.244.3/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fdbf:1d37:bbe0:0:63:20:0:13 peer fdbf:1d37:bbe0:0:63:20:0:1/112 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::794f:9b56:c6a8:9996/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever
default dev tun0 scope link 
10.3.244.3 dev tun0 proto kernel scope link src 10.3.244.19