incorrect routes after relocation

[epac]

Step:

• while home, connect to VPN
• put laptop to sleep
• move to office and open laptop
• openvpn reconnects to the VPN endpoint
• close VPN

Starting routes after VPN on, at home:

default            192.168.16.1       UGSc           en0       
10.0.1/24          172.27.224.1       UGSc         utun6       
10.3/20            172.27.224.1       UGSc         utun6       
[snip]

once at work, post-vpn-reconnect, routes are as follows:

Destination        Gateway            Flags        Netif Expire
default            10.0.1.1           UGSc           en0       
10.0.1/24          172.27.224.1       UGSc         utun6       
10.0.1.1/32        link#6             UCS            en0      !
10.0.1.1           ec:bd:1d:44:63:e5  UHLWIir        en0   1183
10.0.1.170/32      link#6             UCS            en0      !
10.0.1.170         3c:22:fb:c:d6:1    UHLWIi         lo0       

and then, once VPN is disconnected:

Destination        Gateway            Flags        Netif Expire
default            10.0.1.1           UGSc           en0       
10.0.1.1/32        link#6             UCS            en0      !
10.0.1.1           ec:bd:1d:44:63:e5  UHLWIir        en0   1196
10.0.1.170/32      link#6             UCS            en0      !
10.0.1.170         3c:22:fb:c:d6:1    UHLWI          lo0       

Note that the local route for 10.0.1.0/24 is missing from the output.

Is there a way to "grab the state of the routes" before the connection is re-established or something and bring it back? or at least add some logic to not remove routes that would be provided by dhcp prior to the vpn coming back online again?

In any case, the workaround is to down the primary interface and bring it back up (in my case en0 on my mbp), and the routes are restored to their proper state.

version:

package-id: net.openvpn.connect
version: 2.7.1.100

[Gert Döring]

Yeah, this is somewhat problematic - before suspend, 10.0.1.0/24 is connected via VPN, afterwards it is "the LAN". Since OpenVPN did not notice that it went down, it did not have a chance to see "oh, I need to re-read routes".

But since this is about openvpn connect, I can easily defer to the commercial side of things :-)

You could try Tunnelblick instead, maybe it handles suspend/resume differently.

A *real* solution would be to monitor the routing socket and act accordingly. But getting this in place across all platforms (MacOS, Linux, Windows) is a major undertaking.

[tct]

A follow up question:

How would this effect a client floating and receiving a new default gateway when their VPN is redirecting all data ?

This would not require that the client PC be in sleep mode, all that is required is that the client changes network and receives a new default gateway (via DHCP for instance).

Adding this question for your consideration and not expecting a fix.

(I guess the VPN would time-out and restart with the new gateway)