A Practical PowerShell Network Troubleshooting Toolkit

PowerShell can capture the state of a Windows network without installing a diagnostic suite. The useful approach is to collect a baseline, test one layer at a time, and save evidence before changing adapters, routes, DNS, or firewall policy.

Start With Adapter State

Get-NetAdapter | Sort-Object Status, Name
Get-NetIPConfiguration
Get-NetAdapterStatistics

Confirm which physical and virtual adapters are up, their link speed, assigned gateway, and error counters. An enabled adapter is not necessarily the path Windows uses. Old VPN clients can leave virtual interfaces and filter drivers, so identify them before removal.

Inspect Addresses and Routes

Get-NetIPAddress | Sort-Object InterfaceAlias, AddressFamily
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix, RouteMetric
Get-NetRoute -AddressFamily IPv6 | Sort-Object DestinationPrefix, RouteMetric

Look for duplicate or automatic addresses, unexpected default routes, and overlapping private networks. When a VPN connects, compare route output rather than assuming all traffic entered the tunnel. A split tunnel should add only the intended remote prefixes.

Test DNS Separately

Get-DnsClientServerAddress
Resolve-DnsName vpnwp.com
Resolve-DnsName vpnwp.com -Type AAAA
Get-DnsClientCache

A successful ping to an address with a failed name lookup points toward DNS. Query a specific approved resolver with the -Server parameter when comparing results. Do not replace corporate DNS with a public service simply because an internal route is broken. Use our DNS leak guide for VPN-specific checks.

Test Reachability and Ports

Test-NetConnection 192.168.50.20
Test-NetConnection 192.168.50.20 -Port 443 -InformationLevel Detailed
Test-NetConnection vpn.example.net -Port 443

A successful ICMP test does not prove that an application port is open, and a failed ping does not prove the host is down. Test the exact TCP service. For UDP, use application-level tools or server logs because Test-NetConnection is primarily useful for TCP.

Measure Path Quality

ping -n 50 192.168.1.1
ping -n 50 1.1.1.1
tracert 1.1.1.1
pathping 1.1.1.1

First test the local gateway, then an internet target. Loss at the gateway implicates the local link. Intermediate routers may deprioritize diagnostic traffic, so only treat an apparent bad hop as causal when later hops and the destination show the same problem. See the full latency and packet-loss workflow.

Capture a Before-and-After Snapshot

$stamp = Get-Date -Format 'yyyyMMdd-HHmmss'
Get-NetAdapter | Format-Table -Auto | Out-File "network-$stamp.txt"
Get-NetIPConfiguration | Format-List * | Out-File "network-$stamp.txt" -Append
Get-NetRoute | Sort-Object InterfaceIndex,DestinationPrefix | Out-File "network-$stamp.txt" -Append
Get-DnsClientServerAddress | Out-File "network-$stamp.txt" -Append

Save output in an approved support location and redact public IPs, internal names, and identifiers before sharing. Run the same commands disconnected and connected to a VPN. This makes routing changes visible.

Use a Safe Troubleshooting Order

  1. Confirm adapter and link state.
  2. Verify address, gateway, and routes.
  3. Test the gateway, then an address beyond it.
  4. Test DNS independently.
  5. Test the exact application port.
  6. Review firewall and service logs.
  7. Change one setting and repeat.

Avoid resetting the entire network stack at the start; broad resets erase useful evidence and may disrupt VPN, Hyper-V, or managed settings.

Frequently Asked Questions

Does Test-NetConnection test UDP ports?

Its port test is for TCP. Use an application-aware test, packet capture, or server-side logs for UDP.

Why are there several default routes?

Multiple adapters, VPNs, and IPv4/IPv6 can create defaults. Windows selects routes by prefix length and metric; inspect the active interface instead of deleting routes blindly.

Can I run these commands without administrator rights?

Many read-only commands work as a normal user. Some detailed data and any configuration changes require elevation.

Final Practice

A good toolkit creates comparable facts: adapter, route, resolver, target port, latency, and timestamp. Preserve the baseline and use the smallest reversible fix. That is faster than a sequence of undocumented resets.

© Copyright 2026, All Rights Reserved