Page 1 of 1

Reset network interfaces on disconnect

Posted: Thu Nov 10, 2016 4:58 am
by fonginator
Hi,

I get the feeling this has been addressed already, but I haven't been able to find any threads on this so hopefully I can get some help on this!

I have an SSL VPN connection to my client's corporate network and a separate AirVPN connection set up in Viscosity on my MacBook Pro. I normally leave "Reset network interfaces on disconnect" disabled (unchecked) since I hate losing active network connections when one of my VPN connections disconnects.

When I'm at home, both connections works fine together. However, when I work on-site (i.e., no need for VPN so I disconnect before leaving the house with my laptop), I find that I can no longer connect to AirVPN without first enabling the "reset network" setting; Viscosity keeps showing me its "connecting" animation in the menubar. Toggling wifi off and on doesn't seem to resolve this issue. After Viscosity resets the network connection and I'm able to connect to AirVPN, I re-disable the "reset network" setting. When I get home and try to connect to the corporate VPN, I have to jump through the same hoops.

So I guess my questions are:

  • Why does this happen? Is this a bug in Viscosity that can be resolved?
  • If this is expected behaviour (having to reset network connections when I physically change locations), would it be possible to include a menu option to manually reset network connections so that I don't have to open up the advanced prefs, check/uncheck the preference, disconnect, then reconnect, and finally disable that setting?
Thanks!

Re: Reset network interfaces on disconnect

Posted: Mon Nov 14, 2016 7:29 pm
by James
Hi fonginator,

I recommend checking the OpenVPN log when you're unable to connect, as it should contain more information:
http://www.sparklabs.com/support/kb/art ... envpn-log/

Cheers,
James

Re: Reset network interfaces on disconnect

Posted: Wed Nov 16, 2016 12:57 am
by fonginator
Hi James,

The following message keeps repeating over and over in my log for the affected VPN connection:

Nov 15 08:53:51: write UDPv4: Can't assign requested address (code=49)

The destination network's IP address space is unique to any other VPN connection's so there shouldn't be a conflict. I know that it I enable "reset network interfaces on disconnect," this would clear up.

Re: Reset network interfaces on disconnect

Posted: Wed Nov 16, 2016 3:46 am
by fonginator
I'm back at the office (where I was able to successfully connect to the "problematic" VPN yesterday), and am able to connect without issue again.

According to the Internets, the only way to resolve this is to reset network interfaces because it's an OpenVPN issue.

So I guess the question remains - would it be possible to include an option in Viscosity's menu to let me reset the interfaces on demand (I only need it once, when I change physical locations) or, barring that, is there a script available that I could use/modify to do this for me when Viscosity detects that a routing issue might be a problem? (Ooh, or better yet, could Viscosity automatically offer me the option to reset network interfaces if it detects this error? I'm assuming this would resolve many cases similar to mine.)

Re: Reset network interfaces on disconnect

Posted: Sat Nov 19, 2016 1:39 am
by James
Hi fonginator,

It sounds likely there is a network conflict in one of the environments. The conflict may not necessarily be at your home environment - it's possible it's at work. There are two likely scenarios that I can think of:

1. Either the IP range of one of the routes being pushed by the OpenVPN server is conflicting with your home network's IP range. You mention that you've checked the IP being assigned, but also check the routes being pushed. If one of these overlap with your home range, OpenVPN will remove the route (thinking it created it) when you disconnect, causing your local network access to break. My recommendation would be to check the routes being pushed by the server, or if you're not in control of the server, try changing the IP range used in your home environment to see if the problem still occurs.

2. If there is an IP range or route conflict when connecting at your work/office, it's possible a route may be remaining in place or being removed. This might not cause any noticeable problems at your workplace (e.g. if the route being removed is the same as the local IP range, or if a stuck route's gateway is reachable on the office network but not at home). I'd recommend checking your computer's routing table both before connecting (when your computer is in a known good state such as after a reboot) and after disconnecting and see if there are any discrepancies.
http://www.sparklabs.com/support/kb/art ... ng-problem

In regards to scripting a network reset, you could look at using something like the "networksetup" command to disable and re-enable your normal network connection. This isn't exactly what Viscosity does, but it should have a similar effect. You can find an example of such a script at:
https://www.sparklabs.com/support/kb/ar ... -technique

Cheers,
James

Re: Reset network interfaces on disconnect

Posted: Wed Dec 21, 2016 2:36 am
by fonginator
Hi James,

Sorry for taking so long to reply to this one. I think the problem is that one of the routers involved is sending the wrong routing info, although I'm finding it hard to decipher because I'm not good at reading routing tables. :oops:

But something I've noticed (which exacerbates this problem) is that if I have Viscosity set to reset network interfaces on disconnect and I am connected to more than one VPN tunnel when I get a disconnect, Viscosity will often get into a race condition where it will keep trying to reconnect and disconnect my tunnels in an endless loop (sometimes it breaks out of this loop by itself, but more often than not, I have to intervene to kick Viscosity out of this loop).

Is this something that could be looked into?

Re: Reset network interfaces on disconnect

Posted: Wed Dec 21, 2016 9:19 am
by James
Hi fonginator,

Hmmm, interesting. Thanks for the report, we'll look into it.

Cheers,
James