Why a Broad VPN Route Breaks a Few Public Sites

Most pages load, two or three time out, and the browser blames the connection. The sites that fail have something in common that the working ones do not: their resolved addresses fall inside a prefix the VPN installed. A route wide enough to cover a public range will capture traffic the tunnel was never meant to carry, and the symptom looks like a website problem rather than a routing decision.

Resolve the failing name, then look at the routing table rather than at the browser.

Compare the Address, Not the Website Name

Look up the address the client actually tried, then check which route matches it. A destination inside 45.61.20.10 falls under 45.0.0.0/8 if that prefix is present, even though the website itself has nothing to do with the tunnel. Comparing the failing address against the installed prefixes is a subtraction problem, not a guess.

Windows can answer both halves directly, and a lookup shows which interface and next hop won the selection. Resolve the name twice if the site returns several addresses. Record each one with the route that matched. Different addresses can produce different answers, and only one of them may be the failing case.

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

Read the most specific matching prefix, not the first line that looks familiar. A route present in the table does not prove it won the lookup; the longest match does. Two prefixes can match one address, and only one of them receives the packet. The loser stays in the table and looks just as real in a listing.

Write down the prefix, its interface and the resolved address. Those three values are the whole diagnosis.

Find Who Installed the Route

Routes arrive from four places: the native VPN profile, a management policy, a connection script, or another client entirely. Deleting the live entry can confirm its relevance, but the next connection recreates it from the saved configuration, so the source is what has to change.

Check the profile route list first, then the management policy, then any script that runs on connect. That order matches how often each one turns out to be responsible. It also keeps the change scoped to one layer instead of three.

Read the Native Class-Based Behaviour Carefully

Native Windows profiles have a documented setting, NativeProfile/DisableClassBasedDefaultRoute, that controls an automatic route inferred from the interface address. A profile address beginning with 45 can produce a 45.0.0.0/8 entry under that behaviour, which is how a single public address ends up capturing a whole class-A range.

The property name invites the wrong reading: setting it to true disables the inference, and false enables it. It is also not the same object as a default route, and it does not govern third-party clients that install their own prefixes.

If the inference is the demonstrated cause, fix the profile through its management owner and provide the intended private prefixes explicitly. If a script added the entry, repair the script. Substituting one unexplained wide route for another changes the symptom without answering the question.

Repair the Source, Then Recheck Both Paths

After the change, reconnect and repeat the lookup for a failing public site and for a resource that must use the tunnel. The first should now resolve to the physical interface, and the second should still select the VPN. Do not stop at the first success; a fix that also breaks private access has traded one fault for another.

Review the server's address plan at the same time. A pool overlapping public space causes this class of problem repeatedly. A range the operator chose on purpose deserves a different conversation, not an automatic renumber.

Raising the MTU or flushing DNS will not correct a prefix that still directs that address into the tunnel. Test the selection first, then the path.