From Newsgroup: alt.comp.os.windows-10

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

I ran into a problem that Windows and OpenVPN were being "too helpful" when
it comes to repairing the actions of my killswitch batch file which
originated 5 years ago from the LiquidVPN's killswitch batch script.

For years, on my circa 2009 desktop, I used a Zaidy-modified killswitch
that worked perfectly with my Wi-Fi USB dongle, but recently, I changed to
an internal Wi-Fi NIC, which screwed everything up because it's too smart.

Being smart, every time I wiped out the gateway with the taskbar-mounted killswitch icon, Windows would try to be helpful & restore the gateway.

Likewise, with the new Wi-Fi card, even OpenVPN started being helpful, when
it wasn't this helpful with the USB Wi-Fi dongle, by "fixing" the gateway.

The end result was that my killswitch stopped working because both VPN and Windows were being too helpful in trying to add the gateway back when
removed, but, get this... but only when using the Wi-Fi NIC.

This "helpful gateway repair" didn't happen with the USB Wi-Fi dongle.
I'll post the latest batch script, which explains the problem & solution.
--
Usenet allows good friends around the world to discuss their experiences.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

On 7/17/2026 7:32 AM, Maria Sophia wrote:

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

Just uninstall that stupid OpenVPN!
No need to play with kill-switch!

Why do you use VPN? What are you conspiring?
--

@~@ Simplicity is Beauty! Remain silent! Drink, Blink, Stretch!
/ v \ May the Force and farces be with you! Live long and prosper!!
/( _ )\ https://sites.google.com/site/changmw/
^ ^ https://github.com/changmw/changmw
The game is afoot... Meow...
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

The killswitch works by deleting the Wi-Fi default gateway:

0.0.0.0 0.0.0.0 192.168.1.1

No gateway means no internet unless the VPN is active.
If the VPN drops, the system becomes isolated.
This worked perfectly with my old USB Wi-Fi dongle.

Then I installed a modern internal Wi-Fi NIC, and everything fell apart.
Why?

Apparently, modern Wi-Fi cards are "smart".
Old USB Wi-Fi dongles are "dumb".
This difference matters.

With the old USB Wi-Fi dongle:
a. It did not report a gateway
b. It did not support NCSI
c. It did not auto-repair routes
d. It did not push metrics
e. It did not renew DHCP leases
f. OpenVPN could not detect a ROUTE_GATEWAY
g. Windows did not try to fix anything

With the USB dongle, when the killswitch deleted the gateway, it stayed deleted.
a. OpenVPN did not re-add it.
b. Windows did not re-add it.
c. When I "broke" the network, it stayed broken.

With the new internal Wi-Fi card:
a. It reports a valid gateway (192.168.1.1)
b. It supports NCSI and auto-metric
c. It performs DHCP lease renewal
d. It auto-repairs missing routes
e. OpenVPN now sees a gateway and re-adds it

So the sequence became:
1. Killswitch deletes the gateway
2. Windows silently restores it
3. OpenVPN also restores it
4. Killswitch fails

Both Windows and OpenVPN were being "helpful" and that broke the killswitch that we all had worked on together, five years ago, to get it working.

So what was the simple solution?
1. Configure Wi-Fi with a static IP and NO gateway:
C:\> netsh interface ipv4 set address name="Wi-Fi 2" static 192.168.1.20 255.255.255.0 none
This prevents Windows from auto-repairing the route.

2. Set a very high interface metric:
C:\> netsh interface ipv4 set interface "Wi-Fi 2" metric=9999
This prevents Windows from preferring Wi-Fi over VPN routes.

3. Block OpenVPN from re-adding the gateway by adding this to your .ovpn file:
pull-filter ignore "redirect-gateway"
This stops OpenVPN from injecting the default route.

4. Detect the gateway using the routing table (not WMIC):
C:\> route print | find "0.0.0.0" | find "%defgw%"
WMIC is deprecated and unreliable on modern Windows.

5. Run the killswitch via a scheduled task so route changes have admin privileges.

The bottom line is that if your killswitch suddenly stops working
after upgrading your Wi-Fi hardware, it might not be in your script.
It may be your NIC is being too helpful in restoring the gateway
moments after you remove it.

Modern Wi-Fi cards actively repair missing gateways and give OpenVPN
enough information to re-add them. Older USB dongles did not.

Switch to:
a. static IP
b. no gateway
c. high metric
d. pull-filter ignore "redirect-gateway"
e. routing-table detection

Your killswitch will work again exactly as intended.

Note that you need elevated privileges to modify the routing table.
So the target of the taskbar icon is a scheduled task, e.g.,
C:\Windows\System32\schtasks.exe /run /TN "task nettoggle"

That task runs the batch script I will append after this article.
--
Usenet is where people with vast knowledge converge to discuss ideas.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

Maria Sophia wrote:

Note that you need elevated privileges to modify the routing table.
So the target of the taskbar icon is a scheduled task, e.g.,
C:\Windows\System32\schtasks.exe /run /TN "task nettoggle"

That task runs the batch script I will append after this article.

Here is the script written today to fix the problem that both Windows and OpenVPN were being "too helpful" in repairing when I removed the gateway.

:: nettoggle.bat
:: v1p3 20260715
::
:: This nettoggle.bat killswitch only works when there is no gateway,
:: by default. This killswitch is what adds and removes the gateway
:: a. Windows is not allowed to add/remove the gateway on its own
:: b. The VPN server is not allowed to add/remove the gateway on its own
::
:: Logic:
:: 1. When you tap the tasbar icon, check if the default route exists;
:: 2. If it exists, delete it; if it does not exist, add it
::
:: For VPN, we need this directive:
:: pull-filter ignore "redirect-gateway" ; VPN server can't change gateway
:: For Windows, we need to remove the gateway from the default setup:
:: netsh interface ipv4 set address name="Wi-Fi 2" static 192.168.1.20 255.255.255.0 none
::
:: This logic is simple, reliable, and does not depend on WMIC, netsh
:: parsing, or interface-specific quirks. It works with modern Windows
:: network stacks and full-featured Wi-Fi cards.
:: This script provides a simple ON/OFF toggle for the default gateway.
:: When the gateway exists, the script deletes it.
:: When the gateway is missing, the script adds it back.
:: The toggle is activated by clicking a taskbar shortcut that runs a
:: scheduled task with highest privileges. Running the batch file
:: directly in a normal CMD window will NOT work because route changes
:: require elevated privileges.
::
:: Earlier versions prior to v1p3 used WMIC to detect the current gateway.
:: WMIC is now deprecated and (supposedly) unreliable in Windows 10.
::
:: Hence, the v1p3 script does NOT use WMIC. Instead, it checks the routing
:: table directly. The routing table is the source of truth for whether
:: the system has a default route. This method is reliable and does not
:: depend on interface names, DHCP state, or WMIC formatting.
::
:: The default route 0.0.0.0 determines whether the system has a path to
:: the internet. Removing this route blocks all non-VPN traffic. Adding
:: it back restores normal internet access. The VPN supplies its own
:: route when active, so removing the local default route does not break
:: the VPN. If the VPN later drops, the system has no fallback route,
:: which creates a killswitch effect.
::
:: The problem with DHCP is that Windows will recreate the default gateway
:: automatically if DHCP is enabled. To prevent this, the Wi-Fi interface
:: must be configured with a static IP address and no gateway.
:: This ensures that Windows does not auto-repair the route after deletion.
::
:: The Wi-Fi interface metric is set to a high value (9999) to prevent
:: Windows from preferring it over VPN routes. This avoids automatic
:: route injection and keeps the killswitch stable.
::
:: The route command requires elevated privileges. Running the batch file
:: directly from a normal CMD window will not modify the routing table.
:: The scheduled task is configured to run with admin privileges
:: but without a UAC prompt.
::
:: --------------------------------------------------------------------
@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

--
Usenet allows kind intelligent good-hearted people to help each other out.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

Here is the old version that Zaidy helped write five years ago.
It worked fine with the dumb USB Wi-Fi dongle.
But it needed the previous enhancements to work with a Wi-Fi NIC.

@echo off
REM nettoggle.bat
REM v1p1 by Zaidy036 20210207 on alt.comp.os.windows-10
set defgw=192.168.1.1
set "ip="
for /f "tokens=2,3 delims={,}" %%a in ('"WMIC NICConfig where IPEnabled="True" get DefaultIPGateway /value | find "I" "') do if not defined ip set ip=%%~a
IF "%ip%"=="%defgw%" ( %comspec% /c %windir%\system32\route.exe delete 0.0.0.0 %defgw%) ELSE ( %comspec% /c %windir%\system32\route.exe add 0.0.0.0 mask 0.0.0.0 %defgw%)
exit

REM nettoggle.lnk
REM C:\Windows\System32\schtasks.exe /run /TN "task nettoggle"
REM ~
REM taskschd.msc
REM task nettoggle
REM Run with highest privileges = checked
REM Action = Start a program
REM Program/script = %comspec%
REM Add arguments = /c start "" c:\pathto\nettoggle.bat
REM
REM nettoggle.bat
REM @echo off
REM set defgw=192.168.1.1
REM set "ip="
REM for /f "tokens=2,3 delims={,}" %%a in ('"WMIC NICConfig where IPEnabled="True" get DefaultIPGateway /value | find "I" "') do if not defined ip set ip=%%~a
REM IF "%ip%"=="%defgw%" ( %comspec% /c %windir%\system32\route.exe delete 0.0.0.0 %defgw%) ELSE ( %comspec% /c %windir%\system32\route.exe add 0.0.0.0 mask 0.0.0.0 %defgw%)
REM exit
REM
REM
REM
REM USE MODEL:
REM a. Hit the taskbar shortcut (gwtoggle.lnk)
REM b. If the network was on, it (the gateway) will be turned off.
REM If the network was off, it (the gateway) will be turned on.
REM The Windows hardware icons will show the status accordingly.
REM c. If VPN was on, nothing will happen until the VPN drops.
REM If the VPN subsequently drops, the network (gateway) will be turned off.
REM The Windows hardware icons will show the status accordingly.
REM
REM TASKBAR SHORTCUT:
REM gwtoggle.lnk
REM Target = C:\Windows\System32\schtasks.exe /run /TN "task gwtoggle"
REM
REM SCHEDULED TASK:
REM taskschd.msc
REM task gwtoggle
REM Run with highest privileges = checked
REM Action = Start a program
REM Program/script = %comspec%
REM Add arguments = /c start "anything" c:\pathto\gwtoggle.bat
REM
REM BATCH SCRIPT:
REM c:\pathto\gwtoggle.bat
REM @echo off
REM set defgw=192.168.1.1
REM set "ip="
REM for /f "tokens=2,3 delims={,}" %%a in ('"WMIC NICConfig where IPEnabled="True" get DefaultIPGateway /value | find "I" "') do if not defined ip set ip=%%~a
REM IF "%ip%"=="%defgw%" ( %comspec% /c %windir%\system32\route.exe delete 0.0.0.0 %defgw%) ELSE ( %comspec% /c %windir%\system32\route.exe add 0.0.0.0 mask 0.0.0.0 %defgw%)
REM exit
REM
REM SHORTCUT ICONS:
REM https://www.flaticon.com/free-icons/on-off
REM https://icons8.com/icons/set/on-off
REM https://iconarchive.com/tag/on-off
REM
REM Example icon:
REM https://cdn.icon-icons.com/icons2/1535/PNG/512/3298613-onoff-switch-switchoff-switchon_106998.png

:: end of c:\data\sys\batch\nettoggle.bat
--
Usenet is a wonderful place to discuss topics among thousands of experts.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

For reference, here is the LiquidVPN killswitch that started this endeavor. Regards, bill

@echo off
:: LiquidVPN-Kill-Switch.bat 20210209
:: GetAdmin
:-------------------------------------
:: Verify permissions
>nul 2>&1 "%SYSTEMROOT%\system32\cacls.exe" "%SYSTEMROOT%\system32\config\system"

:: On Error No Admin
if '%errorlevel%' NEQ '0' (
echo Getting administrative privileges...
goto DoUAC
) else ( goto getAdmin )

:DoUAC
echo Set UAC = CreateObject^("Shell.Application"^) > "%temp%\getadmin.vbs"
set params = %*:"=""
echo UAC.ShellExecute "cmd.exe", "/c %~s0 %params%", "", "runas", 1 >> "%temp%\getadmin.vbs"

"%temp%\getadmin.vbs"
del "%temp%\getadmin.vbs"
exit /B

:getAdmin
pushd "%CD%"
CD /D "%~dp0"
:--------------------------------------


@echo off
:: CHANGE DEFAULT GW IP BELOW
set defgw=192.168.1.1


@For /f "tokens=3" %%1 in (
'route.exe print 0.0.0.0 ^|findstr "\<0.0.0.0.*0.0.0.0\>"') Do set defgw=%%1
cls
:start
cls
echo.
color 0C
echo LiquidVPN's Simple VPN Kill Switch, ver. 0.1 - by LiquidVPN

echo.
echo.
echo Your routers gateway is probably "%defgw%"
echo -if nothing appears or its incorrect, add it manually (Press '3')
echo.
echo USAGE:
echo.
echo -Press "1" to Enable Kill Switch (IP "%defgw%")
echo -Press "2" to Disable Kill Switch (IP "%defgw%")
echo -Press "3" to manually set default gateway if its not detected above.
echo -Press "h" for Kill Switch Help
echo -Press "x" to exit Kill Switch.
echo.
set /p option=Your option:
if '%option%'=='1' goto :option1
if '%option%'=='2' goto :option2
if '%option%'=='3' goto :option3
if '%option%'=='x' goto :exit
if '%option%'=='h' goto :help
echo Insert 1, 2, x or h
timeout 3
goto start
:option1
route delete 0.0.0.0 %defgw%
echo Default gateway "%defgw%" removed
timeout 3
goto start
:option2
route add 0.0.0.0 mask 0.0.0.0 %defgw%
echo Defaulte gateway "%defgw%" restored
timeout 3
goto start
:option3
echo
set /p defgw=your gw IP (e.g. 192.168.0.1):
goto start
:help
cls
echo.
echo.
echo ======================
echo This simple kill switch removes your default gateway
echo and blocks traffic from reaching the internet when
echo your VPN gets disconnected.
echo.
echo Here is how you use it.
echo.
echo Step 1: Connect to LiquidVPN
echo Step 2: Enable LiquidVPN's Kill Switch (option "1")
echo.
echo Now Any internet traffic will pass through LiquidVPN only.
echo.
echo - If your VPN gets disconnected so will your internet.
echo - Disable the Kill Switch and reconnect.
echo.
echo.
echo When you disconnect from LiquidVPN follow these steps
echo to reconnect or to browse the internet normally.
echo.
echo Step 1: Close any software that may leak your real IP
echo Step 2: Disable the LiquidVPN kill switch (Option "2")
echo Step 3: Reconnect to LiquidVPN and enable the kill switch (Option "1")
echo.
timeout /T -1
goto start
:exit
exit
:: end of LiquidVPN-Kill-Switch.bat 20210209
--
Just one person on Usenet paying it forward so all benefit daily.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

On 17/07/2026 00:32, Maria Sophia wrote:

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

Can this kill https://freevpnapp.org/downloads/.

Hooray! Las Malvinas son Argentinas
--
*Newsgroup Post *

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

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.

The exquisitely elegant beauty of this killswitch is that it documents
at least a half-dozen intricacies of Windows networking proclivities.

:: 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
--
Let's see if, together, we can raise the intellectual level of this ng.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

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.
.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

Maria Sophia wrote:

for /f "tokens=2,3 delims={,}" %%a in ('"WMIC NICConfig where IPEnabled="True" > get DefaultIPGateway /value | find "I" "') do if not defined ip set

ip=%%~a

Bear in mind that the default install does not include WMIC since 24H2,
worth having some form of test for

if not exist %windir%\system32\wmic.exe


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

On 2026-07-17 01:35, Mr. Man-wai Chang wrote:

On 7/17/2026 7:32 AM, Maria Sophia wrote:

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

Just uninstall that stupid OpenVPN!
No need to play with kill-switch!

Why do you use VPN? What are you conspiring?

He is our resident paranoid :-)

Said with a smile. Humour intended.
--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

Carlos E. R. wrote:

Said with a smile.

The good news is we learned a ton about Windows during this debugging task.

What we learned is not trivial tinkering. It's a practical crash-course in
how Windows networking actually works in 2026, not how people assume it
works .

For example, Andy rightly noticed that WMIC is deprecated, so all the
scripts with WMIC need to be changed eventually to use other methods.

We learned that modern Wi-Fi NICs auto-repair the default route and even
that OpenVPN servers determine the gateway and then re-inject it back such
that the lesson is nodern NICs behave like autonomous network devices, not passive pipes and VPN routing behavior is not just "server pushes, client obeys." We learned that the hardware and OS metadata influence the client.

We learned metrics are part of Windows' security posture where
misconfigured metrics can cause privacy leaks.

If we didn't already know about batch elevation sans UAC prompt, we would
have learned Windows security boundaries shape how automation must be
designed.

This project wasn't just about toggling a gateway. It was about discovering
how modern Windows networking actually behaves, which is very different
from how it behaved even a few years ago.

I had to learn:
a. how modern NICs auto-repair routes
b. how Windows auto-metric affects VPN routing
c. why WMIC is deprecated and unreliable
d. how VPN clients interact with OS routing
e. how Windows security boundaries affect automation

Each of these behaviors broke the earlier versions of the killswitch, so I
had to understand them deeply to build something stable.

The time spent wasn't "just scripting." It was diagnosing and adapting to
the real, modern Windows networking stack, which is knowledge that is
essential for secure VPN use, routing control, and system automation.

I'm still digging into how Aloha is affected by this killswitch, given
Aloha is the fastest VPN browser on earth, but also the most dangerous.
--
On Usenet, we can combine the vast knowledge of many people together.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

Andy Burns wrote:

Bear in mind that the default install does not include WMIC since 24H2, worth having some form of test for

if not exist %windir%\system32\wmic.exe

Hi Andy,

Yes, WMIC is deprecated.
Thanks for pointing that out as others will benefit.

Worse, WMIC is lying to us, so our old scripts utilizing it are failing.

WMIC used to be a reliable way to read gateway information.
Now WMIC reports the configured gateway, not the actual routing table
state.

We learned from this endeavor that modern NICs and Windows networking subsystems auto-repair routes, so WMIC often shows a gateway even when the route is gone.

WMIC is deprecated entirely, meaning scripts depending on it will break
over time.

That's why I had written the lesson that the routing table is the real
source of truth. Anything else is metadata.

This is a fundamental Windows networking principle in 2026.
--
If we don't strive to understand how Windows works, we should not be here.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

Maria Sophia wrote:

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

Drat. I ran a comprehensive set of tests with this nettest.bat script, and
it turned out that I needed to *remove* the openvpn directive I had added.

So that others can benefit, here's the script that added the directive to,
oh, maybe a few thousand free openvpn config files I've gathered over time.

@echo off
:: add_pull-filter-ignore.bat
setlocal enabledelayedexpansion

:: This will use current working directory where the script is run
set "config_dir=%~dp0"
:: This will use whatever directory you specify to run the script in
REM set config_dir="C:\tmp\vpn\0\test"

echo Updating .ovpn files in: %config_dir
echo.

for %%F in (%config_dir%\*.ovpn) do (
echo Appending to: %%~nxF
call :append_lines "%%F"
)

echo.
echo Done. All .ovpn files updated.
pause
exit /b

:: Subroutine for appending settings
:append_lines
>>%1 echo.
>>%1 echo pull-filter ignore "redirect-gateway" ; Do not let server set gateway
exit /b


And here's the script that removed that added directive, when I found out
not only was it not needed, but it was causing VPN to not correctly work.

:: remove_pull-filter-ignore.bat
:: Remove the pull-filter line so VPN can set redirect-gateway again.
:: This fixes the problem where the killswitch accidentally blocked the VPN
:: from becoming the default route. See notes below for future reference.
@echo off
setlocal


set "dir=C:\tmp\vpn\0\config"

echo Removing pull-filter ignore "redirect-gateway" from all .ovpn
files...
echo.

for %%f in ("%dir%\*.ovpn") do (
powershell -Command ^
"(Get-Content '%%f') | Where-Object { $_ -notmatch 'pull-filter ignore \"redirect-gateway\"' } | Set-Content '%%f'"
echo Cleaned: %%~nxf
)

echo.
echo Done. All configs updated.
pause
endlocal
--
I avoid complex solutions when a leaner one already solves known issues.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

Maria Sophia wrote:

Drat. I ran a comprehensive set of tests with this nettest.bat script, and
it turned out that I needed to *remove* the openvpn directive I had added.

Oops. I forgot to add the nettest.bat script I used to debug the network.

:: ------------------------------------------------------------------------
:: nettest.bat
:: Diagnostic file for debugging VPN-killswitch and VPN-routing analysis.
:: Designed to output important network metrics into a short log file.
:: Designed to be easily customizable to add/subtract commands as needed.
:: ------------------------------------------------------------------------
:: v1p4 20260717
:: Adds additional debugging that has reasonably short output
:: arp -a
:: netsh interface ipv4 show subinterfaces
:: netsh interface ipv4 show interfaces
:: netsh interface ipv4 show addresses
:: netsh interface ipv4 show route
:: netsh interface ipv4 show wins
:: netstat -rn
:: powershell Get-NetAdapter
:: v1p3 20260716
:: Adds a user comment field at the top of the log for the future you.
:: v1p2 20260715
:: Prints the filename at the top of the log and pauses so the gvim
:: line remains so it can be copied & pasted to Win+R for efficiency.
:: v1p1 20260714
:: Outputs to a single short log file timestamped as YYYYMMDDHHMM,
:: prints commands, and outputs where to find the logfile for viewing.
:: v1p0 20260713
:: Outputs network debugging into short individual log files.
:: netsh interface ipv4 show route
:: netsh interface ipv4 show interfaces
:: netsh interface ipv4 show addresses
:: curl icanhazip.com
:: tracert 8.8.8.8
:: These useful commands output too much to keep the log file short.
:: route print -4
:: ipconfig /all
:: netstat -an
:: ------------------------------------------------------------------------
@echo off
setlocal enabledelayedexpansion

:: Ask user for a comment
set /p usercomment=Enter comment for this log (e.g., "before VPN"):

:: Extract date parts from locale-dependent %date%
for /f "tokens=2-4 delims= " %%a in ("%date%") do (
for /f "tokens=1-3 delims=/" %%x in ("%%a") do (
set mm=%%x
set dd=%%y
set yyyy=%%z
)
)

:: Extract time parts from %time%
for /f "tokens=1-2 delims=: " %%a in ("%time%") do (
set hh=%%a
set nn=%%b
)

:: Remove leading spaces from hour
set hh=%hh: =%

:: Build timestamp YYYYMMDDHHMM
set stamp=%yyyy%%mm%%dd%%hh%%nn%

:: Define the output directory
set out=C:\tmp\nettest
if not exist "%out%" mkdir "%out%"

:: Define the output file
set logfile=%out%\%stamp%nettest.log

echo Writing diagnostics to %logfile%
echo.

:: Write filename and user comment at top of log
echo LOGFILE: %logfile% > "%logfile%"
echo COMMENT: %usercomment% >> "%logfile%"
echo. >> "%logfile%"

:: Commands to run
for %%C in (
"netsh interface ipv4 show route"
"netsh interface ipv4 show interfaces"
"netsh interface ipv4 show addresses"
"arp -a"
"netsh interface ipv4 show subinterfaces"
"netstat -rn"
"powershell Get-NetAdapter"
"route print -4"
"curl icanhazip.com"
"tracert 8.8.8.8"
) do (
echo =============================================================== >> "%logfile%"
echo COMMAND: %%~C >> "%logfile%"
echo --------------------------------------------------------------- >> "%logfile%"
%%~C >> "%logfile%"
echo. >> "%logfile%"
)

echo.
echo Log complete.
echo gvim "%logfile%" >> "%logfile%"
echo gvim "%logfile%"
echo.
pause
endlocal
exit /b

:: end of nettest.bat
--
Usenet allows purposefully helpful people to pool their experiences.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

Maria Sophia wrote:

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

Discouraging news...

I just learned the hard way that if you completely disable IPv6,
the entire strategy of this network gateway toggle falls apart.
netsh interface ipv6 set teredo disabled
netsh interface ipv6 set 6to4 disabled (deprecated on my Win10Pro box)
netsh interface ipv6 set isatap disabled (deprecated on my Win10Pro box)
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 0xFF /f

You have to only partially disable IPv6 if you want this method to work.

This old LiquidVPN killswitch methodology relies on
a. A static IPv4 address
b. No IPv4 gateway
c. A predictable default route
d. Windows not trying to fix connectivity
The kill switch depends on the default route being static.
However, after fully disabling IPv6, Windows made it dynamic.

What happened is after fully disabling IPv6, Windows thrashed wildly
when I ran the killswitch, and since the only thing I had changed
was I completely removed IPv6, it was easy to determine the cause.

Without IPv6, the nettoggle methodology broke because Windows
a. Removes the default route
b. Adds a temporary default route
c. Removes it again
d. Recalculates interface metrics
e. Re-adds a default route through the VPN
f. Re-adds a default route through Wi-Fi
g. Removes both
h. Re-adds one
i. Re-adds the other
j. Re-adds a link-local IPv6 route (even though IPv6 is disabled)

I observed all this route thrashing in real time after instrumenting
the script with simple popup messages like the following modification:
@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
set routeExists=%errorlevel%

if %routeExists%==0 (
:: Route to the gateway exists, remove it
route delete 0.0.0.0 %defgw%
msg * "Default route DISABLED"
) else (
:: Add a delay to account for NCSI connectivity checks,
:: DHCP discovery attempts (even though DHCP is disabled)
:: and route validation (all of which can cause a bounce).
timeout /t 2 >nul
:: Route to the gateway is missing, add it
route add 0.0.0.0 mask 0.0.0.0 %defgw%
msg * "Default route ENABLED"
)

endlocal
exit

The script expects the route print to return stable results:
route print | find "0.0.0.0" | find "192.168.1.1"
But with IPv6 completely removed, Windows was adding/removing default
routes every few seconds, which made the killswitch unpredictable.

But with IPv6 completely removed, the kill switch was no longer
toggling a stable route.

I'm in the process of more gracefully removing IPv6, but the
warning here is that we need a better method of building a
killswitch since Windows tries to repair the route aggressively
the instant we completely remove IPv6 from Windows networking.

Newsgroups: alt.comp.os.windows-10,alt.comp.microsoft.windows,alt.comp.os.windows-11
Subject: Have you ever disabled IPv6 for privacy (to prevent IP leaks)?
Date: Sat, 18 Jul 2026 12:47:22 -0400
Message-ID: <113gamq$ii0$1@nnrp.usenet.blueworldhosting.com>
--
Sometimes, what we should have known all along is only learned later.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

Maria Sophia wrote:

I'm in the process of more gracefully removing IPv6, but the
warning here is that we need a better method of building a
killswitch since Windows tries to repair the route aggressively
the instant we completely remove IPv6 from Windows networking.

Yikes! A lesson in IPv6 networking was just learned (the hard way)...

Recovering from wiping out IPv6 completely was/is a bch.
But if anyone needs it, this is how to partially wipe it out.
(Wiping it out is easy, but recovering from that act is the bch.)

This is too aggressive as it causes
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 0xFF /f

This is the goldilocks IPv6 setting, apparently:
reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v DisabledComponents /t REG_DWORD /d 0x20 /f

Unfortunately, wiping out the network adapter & re-installing
drivers means too much changed to recover from just running.
netsh interface ipv6 set teredo default
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 0 /f
Reset the TCP/IP stack
netsh int ip reset
Reset the IPv6 stack
netsh int ipv6 reset
ID the exact name and hardware ID of the Wi-Fi adapter.
pnputil /enum-devices /class Net
Instance ID:
PCI\VEN_168C&DEV_002A&SUBSYS_1000168C&REV_01\4&1a388ce3&0&0038
Device Description:
Qualcomm Atheros 802.11 a|b|g|n Dualband Wireless Network Module
Driver Name:
netathrx.inf
ID the driver package name.
pnputil /enum-drivers
Qualcomm Atheros 802.11 a|b|g|n Dualband Wireless Network Module
Driver Name: netathrx.inf
Instance ID:
PCI\VEN_168C&DEV_002A&SUBSYS_1000168C&REV_01\4&1a388ce3&0&0038
Disable the Wi-Fi adapter
Get-PnpDevice -InstanceId "PCI\VEN_168C&DEV_002A&SUBSYS_1000168C&REV_01\4&1a388ce3&0&0038" | Disable-PnpDevice -Confirm:$false
Uninstall the Wi-Fi adapter
pnputil /remove-device "PCI\VEN_168C&DEV_002A&SUBSYS_1000168C&REV_01\4&1a388ce3&0&0038"
Delete the Wi-Fi driver package
pnputil /delete-driver netathrx.inf /uninstall /force
Reboot Windows will reinstall the NIC with fresh IPv6 metadata.
shutdown /r /t 0

The problem is the whole system state has changed out from under me.

After re-recovering from DisabledComponents 0xFF, I now have
a. persistent DHCP gateways
b. DHCP Client auto-repair behavior
c. NCSI connectivity healing
d. auto-metric recalculation
e. VirtualBox route normalization
f. IPv6-triggered repair state
g. stored gateway metadata
h. interface "smart Wi-Fi" auto-gateway restoration

Which I found using the following debug commands:
reg query HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces /s | find "DefaultGateway"
DhcpDefaultGateway REG_MULTI_SZ 192.168.1.1
DhcpDefaultGateway REG_MULTI_SZ 192.168.28.35
DhcpDefaultGateway REG_MULTI_SZ 192.168.1.1
sc query Dhcp
sc qc Dhcp
DHCP Client service is running and auto-started
STATE: RUNNING
START_TYPE: AUTO_START
sc query NlaSvc
NCSI STATE: RUNNING
Get-NetIPInterface | sort-object InterfaceMetric
Wi-Fi IPv4 InterfaceMetric 50
OpenVPN Wintun IPv4 InterfaceMetric 5
OpenVPN DCO IPv4 InterfaceMetric 25
wmic nic get name, index
sc query openvpnservice

Before the IPv6 mistake the PC was in a clean static mode
a. No DHCP metadata.
b. No NCSI repair.
c. No persistent gateways.
d. No auto-gateway restoration.
But after recovering from the IPv6 mistakes, the PC is
in a draconian connectivity-repair mode where I will be
a. Removing persistent gateways
b. Disabling the DHCP client
c. Disabling NCSI
d. Again raising the Wi-Fi metric
e. Neutralizing the VirtualBox interference
And then I can re-apply the two commands from yesterday
netsh interface ipv4 set address name="Wi-Fi 2" static 192.168.1.20 255.255.255.0 none
netsh interface ipv4 set interface "Wi-Fi 2" metric=9999
--
Sometimes I wish I knew what would happen before I mess with things
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

On Sat, 18 Jul 2026 17:10:29 -0400, Maria Sophia <mariasophia@comprehension.com> wrote:

Sometimes I wish I knew what would happen before I mess with things

Just sometimes?

My luck isn't that good!
--
croy
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

On Sun, 7/19/2026 9:39 AM, croy wrote:

On Sat, 18 Jul 2026 17:10:29 -0400, Maria Sophia <mariasophia@comprehension.com> wrote:

Sometimes I wish I knew what would happen before I mess with things

Just sometimes?

My luck isn't that good!

This is why we have backups.

I don't make a lot of backups, but I tend to make
safety backups before something blows up on me.

A "safety backup" is something you delete three days later,
after it turns out nothing got destroyed by one of your
experiments.

The tethered boot SSD is backed up right now, so I
can restore it later.

Paul
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

Paul wrote:

Sometimes I wish I knew what would happen before I mess with things

Just sometimes?

My luck isn't that good!

This is why we have backups.

I don't make a lot of backups, but I tend to make
safety backups before something blows up on me.

A "safety backup" is something you delete three days later,
after it turns out nothing got destroyed by one of your
experiments.

The tethered boot SSD is backed up right now, so I
can restore it later.

Paul & croy are right. I wish I had a backup. I've been offline for a day.
For a decade or so, I haven't "bothered" to make backups. Now I wish I had.

I destroyed Windows so badly that Wi-Fi will never work again, unless I do something drastic where I already ran DISM & sfc scannow to no avail.

I'll bet I put Windows into such a state that NOBODY on this ng has ever
seen, in that the entire Wi-Fi infrastructure is crashing when utilized.

I ended up plugging an old DD-WRT bridge-mode router into the RJ45 port,
just to get the pc back on the net because even Windows settings crashes.

Can you believe that?

I press "Win+I" and then go to "Network & Internet" and in a second, it crashes, every single time. I have no Wi-Fi icon in the notification area.

In all my decades on Windows, I've never seen *that* error before.
Have you?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

Maria Sophia wrote on 7/19/2026 9:29 PM:

Paul wrote:

Sometimes I wish I knew what would happen before I mess with things

Just sometimes?

My luck isn't that good!

This is why we have backups.

I don't make a lot of backups, but I tend to make
safety backups before something blows up on me.

A "safety backup" is something you delete three days later,
after it turns out nothing got destroyed by one of your
experiments.

The tethered boot SSD is backed up right now, so I
can restore it later.

Paul & croy are right. I wish I had a backup. I've been offline for a day. For a decade or so, I haven't "bothered" to make backups. Now I wish I had.

I destroyed Windows so badly that Wi-Fi will never work again, unless I do something drastic where I already ran DISM & sfc scannow to no avail.

I'll bet I put Windows into such a state that NOBODY on this ng has ever seen, in that the entire Wi-Fi infrastructure is crashing when utilized.

I ended up plugging an old DD-WRT bridge-mode router into the RJ45 port,
just to get the pc back on the net because even Windows settings crashes.

Can you believe that?

I press "Win+I" and then go to "Network & Internet" and in a second, it crashes, every single time. I have no Wi-Fi icon in the notification area.

In all my decades on Windows, I've never seen *that* error before.
Have you?

It sounds like you finally outsmarted yourself.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

On Sun, 7/19/2026 10:29 PM, Maria Sophia wrote:

Paul wrote:

Sometimes I wish I knew what would happen before I mess with things

Just sometimes?

My luck isn't that good!

This is why we have backups.

I don't make a lot of backups, but I tend to make
safety backups before something blows up on me.

A "safety backup" is something you delete three days later,
after it turns out nothing got destroyed by one of your
experiments.

The tethered boot SSD is backed up right now, so I
can restore it later.

Paul & croy are right. I wish I had a backup. I've been offline for a day. For a decade or so, I haven't "bothered" to make backups. Now I wish I had.

I destroyed Windows so badly that Wi-Fi will never work again, unless I do something drastic where I already ran DISM & sfc scannow to no avail.

I'll bet I put Windows into such a state that NOBODY on this ng has ever seen, in that the entire Wi-Fi infrastructure is crashing when utilized.

I ended up plugging an old DD-WRT bridge-mode router into the RJ45 port, just to get the pc back on the net because even Windows settings crashes.

Can you believe that?

I press "Win+I" and then go to "Network & Internet" and in a second, it crashes, every single time. I have no Wi-Fi icon in the notification area.

In all my decades on Windows, I've never seen *that* error before.
Have you?

You can try a Repair Install, using the same version of DVD as
"winver" tells you is currently running.

There is no guarantee that will fix it, but the hardware should be rediscovered, and maybe the TCP/IP stack will be returned to nominal conditions.

Even Repair Install has its dangers. I tried to Repair Install the
Test Machine a few weeks back, and as soon as the first phase reboot
was attempted, the machine "bailed" on the install... without cleaning up!
And what this means, is every subsequent attempt to Repair Install,
will fail the same way. The cure for that, is to pretend to do a Repair Install, and bail out before giving it permission to proceed, and
when it says on the screen "cleaning up", it's actually cleaning up
the little mess that was breaking it.

Then, the next step, is you have to flatten the FAT32 ESP, and
repopulate it.

ESP repair:

format K: /fs:fat32 # use "diskpart.exe" to assign partition 1 the letter K:
bcdboot c:\Windows /s K: /f uefi # This rebuilds the K:\EFI\Microsoft\Boot folder and makes a new BCD

Paul

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

Paul wrote:

You can try a Repair Install, using the same version of DVD as
"winver" tells you is currently running.

There is no guarantee that will fix it, but the hardware should be rediscovered, and maybe the TCP/IP stack will be returned to nominal conditions.

Even Repair Install has its dangers. I tried to Repair Install the
Test Machine a few weeks back, and as soon as the first phase reboot
was attempted, the machine "bailed" on the install... without cleaning up! And what this means, is every subsequent attempt to Repair Install,
will fail the same way. The cure for that, is to pretend to do a Repair Install, and bail out before giving it permission to proceed, and
when it says on the screen "cleaning up", it's actually cleaning up
the little mess that was breaking it.

Then, the next step, is you have to flatten the FAT32 ESP, and
repopulate it.

ESP repair:

format K: /fs:fat32 # use "diskpart.exe" to assign partition 1 the letter K:
bcdboot c:\Windows /s K: /f uefi # This rebuilds the K:\EFI\Microsoft\Boot folder and makes a new BCD

Paul

Hi Paul,

Thanks for the kind-hearted helpful advice. I finally figured it out.
As you've astutely surmised, there is only one solution, unfortunately.

Funny how understanding arrives long after the moment that needed it.
I'm documenting it all here for future people who have the same issue.

Newsgroups: alt.comp.os.windows-10
Subject: Taskbar notification network symbol gone & Network & Internet crashes
Date: Sun, 19 Jul 2026 22:48:18 -0400
Message-ID: <113k29i$2n69$1@nnrp.usenet.blueworldhosting.com>

I understand what networking I did wrong now, but only because I had to.
--
I didn't find the answer as the answer found me after everything fell apart .
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

As a related aside, if your network ever does go to hell in a handbasket,
the following manual commands seem to surgically fix mine in a flash.

I renamed interfaces so that I don't have to deal with spaces:
netsh interface set interface name="Ethernet 2" newname="eth0"
netsh interface set interface name="Wi-Fi 2" newname="wlan0"

Set your network for Ethernet (in my case, via a wireless router):
netsh interface set interface "wlan0" admin=disabled
netsh interface set interface "eth0" admin=enabled
netsh interface ipv4 set address name="eth0" static 192.168.1.15 255.255.255.0 192.168.1.1
netsh interface ipv4 set dns name="eth0" static 1.1.1.1
netsh interface ipv4 add dns name="eth0" 1.0.0.1
netsh interface ipv4 show dnsservers
netsh interface ipv4 show config name="eth0"
netsh interface ipv4 show config
netsh interface ipv4 show dnsservers
ping -n 1 192.168.1.1
ping -n 1 1.1.1.1
ping -n 1 www.google.com
wmic nic where (NetEnabled=true) get Name, Speed
curl -o NUL http://speedtest.tele2.net/1MB.zip
curl -o NUL http://speedtest.tele2.net/10MB.zip
curl -o NUL http://speedtest.tele2.net/100MB.zip
speedtest.exe (from <https://www.speedtest.net/apps/cli>)
route print -4
ipconfig /all
At this point you can now run psiphon.bat or vpn.bat

Set your network for Wi-Fi (in my case, via a Wi-Fi NIC card):
netsh interface set interface "eth0" admin=disabled
netsh interface set interface "wlan0" admin=enabled
netsh interface ipv4 set address name="wlan0" static 192.168.1.16 255.255.255.0 192.168.1.1
netsh interface ipv4 set dns name="wlan0" static 1.1.1.1
netsh interface ipv4 add dns name="wlan0" 1.0.0.1
netsh wlan connect name="my.ssid_nomap"
netsh wlan connect name="starbucks.office_nomap"
netsh interface ipv4 show config
netsh interface ipv4 show config name="wlan0"
netsh interface ipv4 show dnsservers
ping -n 1 192.168.1.1
ping -n 1 1.1.1.1
ping -n 1 www.google.com
wmic nic where (NetEnabled=true) get Name, Speed
curl -o NUL http://speedtest.tele2.net/1MB.zip
curl -o NUL http://speedtest.tele2.net/10MB.zip
curl -o NUL http://speedtest.tele2.net/100MB.zip
speedtest.exe (from <https://www.speedtest.net/apps/cli>)
route print -4
ipconfig /all
At this point you can now run psiphon.bat or vpn.bat

============================================================
Here's a networking cheat sheet if anyone needs the commands. ============================================================
Layer 1: link & adapter state
check NIC driver + link status
wmic nic get Name,NetEnabled,Speed
show adapter statistics (errors/drops)
netstat -e
show interface statistics
netsh interface ipv4 show interfaces ============================================================
Layer 2: arp & neighbor discovery
show arp table
arp -a
show ipv4 neighbor cache
netsh interface ipv4 show neighbors ============================================================
Layer 3: ip configuration & routing
show ipv4 global settings
netsh interface ipv4 show global
show ipv4 addresses
netsh interface ipv4 show address
show routing table (ipv4 only)
route print -4
show active tcp/udp endpoints
netstat -an
============================================================
Layer 4: dhcp
check dhcp server discovery
netsh dhcp show server
show dhcp-assigned addresses
netsh interface ip show addresses
force dhcp renew
ipconfig /release && ipconfig /renew ============================================================
Layer 5: dns
test dns resolution
nslookup example.com
show dns cache
ipconfig /displaydns
flush dns cache
ipconfig /flushdns ============================================================
Layer 6: firewall
show firewall rules
netsh advfirewall firewall show rule name=all
show firewall profile state
netsh advfirewall show allprofiles ============================================================
Layer 7: winsock
show winsock providers
netsh winsock show catalog
reset winsock (fixes corruption)
netsh winsock reset ============================================================
Layer 8: connectivity tests
ping gateway
ping <gateway>
ping ipv4-only target
ping -4 8.8.8.8
trace ipv4 route
tracert 8.8.8.8
test ipv4 http
curl -4 http://example.com ============================================================
Layer 9: system logs
open event viewer
eventvwr.msc
check dhcp logs
(event viewer i= microsoft i= windows i= dhcp-client)
check tcp/ip logs
(event viewer i= system i= tcpip)
check ndis driver logs
(event viewer i= system i= ndis) ============================================================
Layer 10: advanced routing & bindings
show interface metrics
netsh interface ipv4 show interfaces
show binding joins
netsh interface ip show joins
show tcp global parameters
netsh interface tcp show global ===========================================================
--
Some people are on Usenet for their own amusement but others
are on Usenet to help others daily and to learn from them.
--- Synchronet 3.22a-Linux NewsLink 1.2