Opened 8 months ago

Last modified 6 months ago

#1306 new User question

incorrect routes after relocation

Reported by: epac Owned by:
Priority: minor Milestone: release 2.6
Component: Networking Version:
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: Tincantech

Description

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

Change History (2)

comment:1 Changed 8 months ago by tincantech

Cc: Tincantech added
Type: Bug / DefectUser question

comment:2 Changed 6 months ago by Gert Döring

Milestone: release 2.6

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.

Note: See TracTickets for help on using tickets.