From Newsgroup: alt.msdos.batch

Below is a well-documented version of the network killswitch which we've
been using for years on the alt.comp.os.windows-10 newsgroup since 2021
(and which, as I recall, we discussed even earlier on alt.msdos.batch).

The exquisitely elegant beauty of this killswitch is that it documents
at least a half-dozen intricacies of Windows networking proclivities
(which we've discussed from time to time on this ng over the years).

As always, please improve where I err or omit.

:: nettoggle.bat
::
:: This nettoggle killswitch toggles the Wi-Fi default gateway on and off.
:: If the gateway is on, it turns it off. If it's off, it turns it back on.
::
:: This provides a simple ON/OFF toggle for the network on any given PC.
:: a. The toggle checks if the default route exists in the routing table.
:: b. If the default route exists, the toggle deletes it.
:: c. If the default route does not exist, the toggle adds it.
:: While this toggle works with a direct Internet connection (e.g., when
:: installing installing software which might perhaps phone home), the main
:: use is to protect the user when a VPN is being used which suddenly drops.
::
:: It is called by a Windows scheduled task (elevate permissions with no UAC).
:: That scheduled task is the target of a pinned taskbar nettoggle shortcut.
::
:: The design of this toggle required a sequence of a half-dozen changes.
::
:: 1. Remove DHCP and gateway in the in the Wi-Fi network adapter setup:
:: Instead, set a static IP with no gateway in the network adapter setup.
:: Windows will auto-repair the default route if DHCP is enabled or
:: if the interface has a gateway configured. Modern Wi-Fi cards are
:: "smart" and will silently restore the gateway when it disappears.
:: To prevent this, the Wi-Fi interface must use a static IP and the
:: gateway must be set to "none". This stops Windows from repairing
:: the route after deletion.
:: C:\> netsh interface ipv4 set address name="Wi-Fi 2" static 192.168.1.20 255.255.255.0 none
::
:: 2. Favor VPN with a high metric for the routing table Wi-Fi interface:
:: Windows uses auto-metric logic to prefer certain interfaces.
:: If the Wi-Fi metric is low, Windows may inject routes or prefer the
:: Wi-Fi path over the VPN. Setting the Wi-Fi metric to a high value
:: (e.g., to 9999) ensures that VPN routes always win. This keeps the
:: killswitch stable and prevents unwanted route injection.
:: C:\> netsh interface ipv4 set interface "Wi-Fi 2" metric=9999
::
:: 3. Tell the local VPN session to ignore pull-filter "redirect-gateway":
:: This directive does NOT modify the VPN server. The server still
:: pushes redirect-gateway normally. Only the local OpenVPN client
:: session is affected, and only for this connection.
:: Modern Wi-Fi cards report a valid ROUTE_GATEWAY to OpenVPN. When
:: the server pushes redirect-gateway, the client will normally re-add
:: the Wi-Fi default route. This breaks the killswitch.
:: Adding the pull-filter directive to the openvpn.conf file tells the
:: OpenVPN client: "If the server pushes redirect-gateway, ignore it."
:: This prevents the client from adding the Wi-Fi default route back.
:: The server is unchanged. The tunnel is unchanged. Only the client
:: behavior is modified so the killswitch remains stable.
:: C:\> type pull-filter ignore "redirect-gateway" >> openvpn.conf
::
:: 4. Create a scheduled task for elevated permissions and to eliminate UAC:
:: Win+R > taskschd.msc
:: Name: task nettoggle
:: Action: Start a program
:: Program/script: %comspec%
:: Add arguments: /c start "" c:\data\sys\batch\nettoggle.bat
:: [x] Run with highest privileges
::
:: 5. Add a taskbar shortcut to run the program with elevated permissions:
:: Elevate privileges and eliminate UAC by invoking a scheduled task.
:: Route changes require admin rights. Running this batch file from a
:: normal CMD window will not modify the routing table. The taskbar
:: icon does not run the batch file directly. Instead, it triggers a
:: scheduled task configured to run with highest privileges and with
:: no UAC prompt. This is why the taskbar shortcut link is required.
:: Link target C:\Windows\System32\schtasks.exe /run /TN "task nettoggle"
::
:: 6. Use route print instead of WMIC to detect the gateway reliably:
:: Earlier versions used WMIC to read the DefaultIPGateway value.
:: WMIC reports whatever Windows believes the gateway should be,
:: based on interface configuration, DHCP state and NIC metadata.
:: This became problematic once modern Wi-Fi hardware was installed.
:: Newer Wi-Fi cards support NCSI, auto-metric, DHCP renewal and
:: route auto-repair. Because of this, WMIC may report a gateway
:: even when the routing table does not contain one.
:: The routing table is the actual source of truth. It reflects the
:: real routes that OpenVPN adds or removes, and the real routes that
:: Windows or other software (such as the Aloha Browser) may inject.
:: Using route print ensures the script sees the real default route
:: state, not the intended or configured gateway reported by WMIC.
:: C:\> set defgw=192.168.1.1
:: C:\> route print | find "0.0.0.0" | find "%defgw%" >nul
:: --------------------------------------------------------------------
:: Version history (documented on alt.comp.os.windows-10 over the years)
:: --------------------------------------------------------------------
:: v1p4 20260716 Static IP, no gateway, pull-filter, routing-table check
:: This version replaces WMIC with routing-table detection, which is
:: reliable on modern Windows. The Wi-Fi interface is configured with a
:: static IP and no gateway so Windows cannot auto-repair the route.
:: The interface metric remains high (9999) to ensure VPN routes win.
:: The OpenVPN config uses:
:: pull-filter ignore "redirect-gateway"
:: so the VPN cannot re-add the Wi-Fi default route. The scheduled task
:: remains required because route changes need elevated privileges.
:: This version restores the original killswitch behavior on modern
:: hardware and modern Windows.
::
:: v1p3 20260715 Metric control and routing-table detection
:: This version attempted to stabilize the killswitch by forcing the
:: Wi-Fi interface metric to a very high value (9999). This prevented
:: Windows from preferring Wi-Fi routes over VPN routes. However, WMIC
:: was still used to detect the gateway, and Windows continued to auto-
:: repair the default route. OpenVPN also continued to re-add the route
:: when redirect-gateway was pushed. The script needed a more reliable
:: detection method and a way to stop OpenVPN from restoring the route.
::
:: v1p2 20260714 Drat. Windows hardware change broke the old killswitch!
:: The USB Wi-Fi dongle was removed and replaced with a modern internal
:: Wi-Fi card. This card behaves like a full Windows network interface.
:: It supports NCSI, auto-metric, DHCP renewal, and route auto-repair.
:: After this upgrade, Windows began restoring the default route as
:: soon as the script deleted it. OpenVPN also began re-adding the
:: gateway because the new card reports a valid ROUTE_GATEWAY value.
:: WMIC became unreliable because multiple interfaces existed and the
:: new hardware changed how Windows exposes gateway information. The
:: killswitch failed because both Windows and OpenVPN were "helpful".
::
:: v1p1 20210207 Zaidy036 version from alt.comp.os.windows-10
:: This version was functionally identical to v1p0. The main change was
:: packaging the script to run through a scheduled task so that route
:: changes could occur without a UAC prompt. The logic still used WMIC
:: to detect the gateway, which worked fine with USB Wi-Fi hardware.
:: The dongle only had one gateway entry, so WMIC always returned the
:: correct value. The killswitch continued to work as intended.
::
:: v1p0 20190516 Modified LiquidVPN kill switch downloaded off the net
:: This was the first version of the gateway toggle. It relied on the
:: behavior of old USB Wi-Fi dongles, which were very simple devices.
:: These dongles did not support NCSI, auto-metric, DHCP renewal, or
:: gateway injection. Because of this, deleting the default route was
:: permanent. Windows never tried to repair the route, and OpenVPN
:: could not re-add it because the dongle did not report a gateway.
:: The killswitch worked reliably because the hardware was "dumb".
:: --------------------------------------------------------------------
@echo off
setlocal

:: Set to your router IP address
set defgw=192.168.1.1

:: Check if default route exists
route print | find "0.0.0.0" | find "%defgw%" >nul

if not errorlevel 1 (
:: Route to the gateway exists, remove it
route delete 0.0.0.0 %defgw%
) else (
:: Route to the gateway is missing, add it
route add 0.0.0.0 mask 0.0.0.0 %defgw%
)

endlocal
exit

:: end of nettoggle.bat
--
On Usenet, we all try to help each other by leveraging knowledge.
--- Synchronet 3.22a-Linux NewsLink 1.2