Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files

Killer Punch wrote:
> Can this kill https://freevpnapp.org/downloads/.

Good question. I've never heard of that outfit, so I invested a brief look.
To be clear, nettoggle.bat will work on any Windows box even without a VPN. 

For example, let's say you're going to install an Adobe product, which you
just know is likely to phone home during or after the installation process. 
  1. You download the installer
  2. You toggle the network off
  3. You install the product
  4. Then you toggle the network back on

As for working with any particular VPN, I only use free OpenVPN config
files that I find on the Internet, so that's the only stuff I've tested.

As such, the nettoggle.bat killswitch requires all of the following:
 1. A VPN client that creates a real Windows network interface
    (TAP, TUN, Wintun, WireGuard, or similar)
 2. A VPN client that modifies the Windows routing table
    (adds 0.0.0.0/1, 128.0.0.0/1, or a full default route)
 3. A VPN client that respects Windows routing rules
    (metric, interface priority, default gateway presence)
 4. A VPN client that does not bypass the Windows routing stack
    (some VPN apps use kernel drivers or proprietary tunnels)
 5. A VPN client that does not use a browser-based tunnel
    (some "free VPNs" are just encrypted proxies inside the app)

With that in mind, the nettoggle.bat script toggles the default route.
If the VPN drops, there is no fallback route, so the system is isolated.

Hence, nettoggle.bat works because OpenVPN (and WireGuard) use the actual
Windows routing table, so it only works if the VPN uses Windows routing.	 

Looking at https://freevpnapp.org/, FreeVPN appears to be
 A. a closed-source, app-based VPN, not OpenVPN or WireGuard
 B. a proprietary tunnel, not a Windows network adapter
 C. a mobile-first product, ported to Windows
 D. a VPN that uses its own internal routing, not the OS routing table
 E. a VPN using split tunneling inside the app, not via Windows routes
 F. a VPN that may not expose a TAP/TUN/Wintun interface at all

From a quick skim of the web site, there is no indication that FreeVPN 
 a. creates a Windows network adapter
 b. adds routes to the Windows routing table
 c. uses redirect-gateway logic
 d. respects interface metrics
 e. uses ROUTE_GATEWAY
 f. uses OpenVPN or WireGuard configs
 g. can be controlled by external scripts

If the VPN does not use the Windows routing table, then:
 a. nettoggle.bat cannot protect is
 b. Because the nettoggle.bat killswitch works by deleting:
    0.0.0.0    0.0.0.0    192.168.1.1
 c. If FreeVPN does not rely on that route, deleting it does nothing.	

If you're using FreeVPN, you can tell for sure by running this test.
 1. route print
 2. Then connect FreeVPN.
 3. route print

If you see:
 A. new routes
 B. 0.0.0.0/1
 C. 128.0.0.0/1
 D. a new gateway
 E. a new interface
 F. a new metric
 G. a new adapter name
Then FreeVPN might work with this nettoggle.bat script.

However, if the routing table does not change at all, then it's likely
that FreeVPN does not use Windows routing so nettoggle cannot protect it.

Keep in mind that nettoggle.bat works on any WIndws machine even without
VPN, but the VPN killswitch action was mainly designed to work with 
 a. OpenVPN
 b. WireGuard
 c. SoftEther
 d. Any VPN that uses TAP/TUN/Wintun
 e. Any VPN that modifies Windows routes

But if FreeVPN does not modify the Windows routing table, nettoggle.bat
cannot act as a killswitch for it (but it still works in native Windows).
-- 
On Usenet, we have found the best way to do everything that we need to do.
	.