Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.comp.microsoft.windows > #3425 > unrolled thread

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

Back to article view | Back to alt.comp.microsoft.windows

Contents

  PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files Maria Sophia <mariasophia@comprehension.com> - 2026-07-16 19:32 -0400
    Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-07-17 07:35 +0800
      Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files Maria Sophia <mariasophia@comprehension.com> - 2026-07-17 01:05 -0400
      Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-17 14:43 +0200
        Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files Maria Sophia <mariasophia@comprehension.com> - 2026-07-17 10:35 -0400
    Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files Maria Sophia <mariasophia@comprehension.com> - 2026-07-16 19:47 -0400
      Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files Maria Sophia <mariasophia@comprehension.com> - 2026-07-16 19:53 -0400
        Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files Maria Sophia <mariasophia@comprehension.com> - 2026-07-16 19:57 -0400
          Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files Maria Sophia <mariasophia@comprehension.com> - 2026-07-16 20:01 -0400
          Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files Andy Burns <usenet@andyburns.uk> - 2026-07-17 08:23 +0100
            Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files Maria Sophia <mariasophia@comprehension.com> - 2026-07-17 10:36 -0400
    Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files Maria Sophia <mariasophia@comprehension.com> - 2026-07-17 01:34 -0400
    Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files Maria Sophia <mariasophia@comprehension.com> - 2026-07-17 14:17 -0400
      Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files Maria Sophia <mariasophia@comprehension.com> - 2026-07-17 14:23 -0400
    Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files Maria Sophia <mariasophia@comprehension.com> - 2026-07-18 13:08 -0400
      Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files Maria Sophia <mariasophia@comprehension.com> - 2026-07-18 17:10 -0400
        Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files Maria Sophia <mariasophia@comprehension.com> - 2026-07-19 22:29 -0400
          Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files Hank Rogers <Hank@nospam.invalid> - 2026-07-19 21:41 -0500
            Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files Maria Sophia <mariasophia@comprehension.com> - 2026-07-24 10:59 -0700
          Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files Paul <nospam@needed.invalid> - 2026-07-19 22:49 -0400
            Re: PSA: Simple Wi-Fi gateway killswitch that works with OpenVPN config files Maria Sophia <mariasophia@comprehension.com> - 2026-07-20 00:28 -0400

Page 1 of 2  [1] 2  Next page →

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

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.

[toc] | [next] | [standalone]

#3426

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...

[toc] | [prev] | [next] | [standalone]

#3431

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.

[toc] | [prev] | [next] | [standalone]

#3434

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.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#3435

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.

[toc] | [prev] | [next] | [standalone]

#3427

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.

[toc] | [prev] | [next] | [standalone]

#3428

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.

[toc] | [prev] | [next] | [standalone]

#3429

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.

[toc] | [prev] | [next] | [standalone]

#3430

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.

[toc] | [prev] | [next] | [standalone]

#3433

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

[toc] | [prev] | [next] | [standalone]

#3436

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.

[toc] | [prev] | [next] | [standalone]

#3432

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.
	.	 

[toc] | [prev] | [next] | [standalone]

#3437

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.

[toc] | [prev] | [next] | [standalone]

#3438

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.

[toc] | [prev] | [next] | [standalone]

#3441

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.

[toc] | [prev] | [next] | [standalone]

#3446

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

[toc] | [prev] | [next] | [standalone]

#3452

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?

[toc] | [prev] | [next] | [standalone]

#3453

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.

[toc] | [prev] | [next] | [standalone]

#3462

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 ¡÷ microsoft ¡÷ windows ¡÷ dhcp-client)
  check tcp/ip logs
   (event viewer ¡÷ system ¡÷ tcpip)
  check ndis driver logs
   (event viewer ¡÷ system ¡÷ 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.

[toc] | [prev] | [next] | [standalone]

#3454

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | alt.comp.microsoft.windows

csiph-web