> On Jul 27, 2017, at 2:55 PM, Selva Nair <selva.n...@gmail.com> wrote:
>
> Hi,
>
> On Thu, Jul 27, 2017 at 2:01 PM, Karl Mueller <ewi...@gmail.com
> <mailto:ewi...@gmail.com>> wrote:
>
> I think it is due to the redirect-gateway, and def1 does not change the
> behavior. I believe it’s because Windows sends NCSI internet probes to
> determine if an adapter has “Internet” access. If you’re not redirecting your
> gateway, those probes will probably fail via the VPN interface so it won’t
> consider the VPN interface as a viable alternative.
>
> If so just redirecting msftncsi.com <http://msftncsi.com/> through VPN will
> trigger this?
Possibly, but I think there’s more (undocumented) complexity to it. I tried
blocking msftncsi.com IP’s on VPN and it had no effect.
>
>
> A frustrating part of the problem is that Windows overrides the routing table
> by *silently* directing new connections to the “better” Ethernet interface
> (in anticipation of the WiFi losing signal altogether, I suppose). The only
> way to observe this is to use the powershell command ‘find-netroute -remote
> <ip>’ which tells you where Windows will *really* send the packet. Also the
> effect of the redirection isn’t immediate, Windows waits from 30-120 seconds
> to start redirecting traffic to the VPN interface once it detects weak WiFi
> signal.
>
> So to reproduce this the wifi signal has to go weak as well?
Yes, the connection is perfectly stable until wifi drops below some internal
signal setting, or possibly until it drops a packet or two. get-netadapter
shows that when the wifi speed drops below 7mb/s it almost always triggers the
behavior. There’s no logging associated with the behavior that I can find,
which makes it difficult to troubleshoot too.
>
>
> Some more details of my setup: I use the Windows service-based VPN connection
> rather than user-initiated by way of openvpnserv2.exe. We are using build
> 1511 of Windows 10. I posted my configs here:
> https://forums.openvpn.net/viewtopic.php?f=4&t=24499
> <https://forums.openvpn.net/viewtopic.php?f=4&t=24499>
>
> I suppose you mean the opposite: that is the connection is started at boot
> using OpenVPNService (i.e., openvpnserv2.exe). User initiated connections
> (using the GUI) are started by OpenVPNServiceInteractive (i.e.,
> openvpnserv.exe).
Yes, sorry I said that backwards.
>
> Will try to reproduce, but being affected only when auto-started at boot is
> puzzling. In both cases the routes are set up the same way so it should not
> matter. Except for --redirect-gateway: the interactive service will force
> the use of def1, but again your config specifies def1 so the behaviour should
> be the same.
I am not sure about autostart being the culprit, but I think it’s another
calculation in MS’s decision to drop the connection and maybe why this isn’t so
widely reported.
The page below describes the decision making logic in Windows, but it’s
obviously missing some specifics:
https://docs.microsoft.com/en-us/windows-hardware/drivers/mobilebroadband/understanding-and-configuring-windows-connection-manager
Karl Mueller
ewi...@gmail.com
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
