How to Read Your Own Network Settings

Every device shows its current network configuration somewhere, and the four values it lists — address, subnet mask, gateway, and DNS servers — answer most questions about why a connection is behaving oddly. Reading them takes a minute and replaces guessing with observation.

This is particularly useful with a VPN, because a connected device has two sets of these values, one per adapter, and comparing them tells you immediately whether the tunnel is doing what you think.

Where to find them

Every platform exposes the same information in a slightly different place.

• Windows: ipconfig /all at a command prompt, or Settings under network properties.
• macOS: System Settings under the network interface’s details, or ifconfig in Terminal for the raw view.
• Linux: ip addr and ip route, plus whatever your distribution uses to report resolver settings.
• Android and iOS: the Wi-Fi network’s details screen, which shows the essentials but not always the routing table.
• Your router: a status or WAN page showing the address the provider gave it.

Prefer the command-line view where you have it, because graphical panels often hide the virtual adapters that a VPN creates — which is exactly what you want to see.

What each field means

The address is your device’s identity on this network. If it starts 192.168., 10., or falls in 172.16.–172.31., it is private and only meaningful locally. Anything in the 169.254. range means your device failed to get an address and assigned itself a placeholder — a sure sign the connection is not working at the most basic level. The distinction between local and internet-facing addresses is covered in public vs private IP addresses.

The subnet mask defines which addresses count as local. With a typical home mask, everything sharing the first three number groups is on your network and reachable directly; anything else has to go through the gateway. It is rarely the cause of a problem but it explains why some addresses are reached directly and others are not.

The gateway is the router — the address your device sends anything non-local to. If it is blank, nothing outside your own network is reachable no matter how healthy the Wi-Fi looks.

The DNS servers are the resolvers your device will ask to turn names into addresses. This is the field most worth checking, because it decides who receives your list of hostnames, as discussed in who runs your DNS resolver.

What changes when a VPN connects

A new adapter appears with its own complete set of values. Its address comes from the provider’s internal range, and its DNS servers are usually the provider’s — the second-address arrangement explained in why a VPN gives you two IP addresses.

The routing table is where the real change happens. Listing routes shows which adapter default traffic uses. A working VPN installs a default route through the virtual adapter, plus a narrow exception for the VPN server’s own address so the tunnel can reach it over the physical adapter.

Four checks, in order:

1. Does the virtual adapter exist and have an address? If not, the tunnel never came up.
2. Does the default route point at it? If not, the tunnel is up but unused — which looks exactly like the VPN doing nothing.
3. Which DNS servers are listed, and on which adapter? If your provider’s resolver is still listed on the physical adapter, lookups may escape.
4. Is there still a route for your local network? If not, local devices are unreachable, which explains printing and casting failing.

Reading it under a leak

The settings tell you what should happen; a test tells you what does. They disagree more often than people expect.

The common mismatch: the tunnel’s resolver is correctly set, and a DNS test still reports your provider’s. That is not a contradiction — operating systems can query resolvers on several interfaces, so a correct setting on one adapter does not stop queries going out on another. The mechanism is the one behind DNS leaks, and the fix is enforcement rather than configuration.

Another one: everything looks right and the exit address is still yours. Check whether an application has its own proxy or connection settings, or whether a second network interface — a mobile hotspot alongside Wi-Fi, say — is carrying the traffic on a route you did not notice.

The IPv6 half of the picture

Most devices list IPv6 addresses alongside the old-style ones, and it is easy to read past them. A device commonly has several: a link-local one starting fe80:, which never leaves the network, plus one or more globally routable addresses.

When a VPN connects, look at whether the IPv6 addresses on the physical adapter are still routable and whether there is any IPv6 route through the tunnel. If IPv6 works outside the tunnel and the tunnel only carries the old family, a real share of your traffic bypasses the VPN — the failure described in why IPv6 is the leak people forget.

What to write down

Record your normal values once, while everything is working. Address, gateway, resolvers, and the routes on a healthy connection, with and without the VPN.

It converts future troubleshooting from interpretation into comparison. When something breaks, you look at the current values, diff them against the known-good set, and the difference is usually the problem. Without a baseline you are left deciding whether an unfamiliar value is wrong, which is much harder than noticing it changed.

Two minutes of note-taking now, and most connection problems become a matter of spotting which of four fields does not match.