Hosts File vs Router Filter: Blocking a Site Over VPN

A hosts entry and a router filter block the same site for completely different reasons, which is why one keeps working under a VPN and the other quietly stops. The hosts file answers a name before any packet leaves the machine. The router filter inspects traffic that crosses it. Put a tunnel between those two points and the second one loses its view while the first does not notice.

Where the name is resolved decides everything

Every block starts with a question: who turns the name into an address? On a normal desktop the answer is the system resolver, which walks its configured order and typically reads the hosts file before querying DNS. On a filtered network the answer may be the router, which sees the query only if the client sends it through the router unprotected. Change the path and you change who is allowed to answer.

A VPN does two things at once here: it moves the default route, and it may push its own DNS server. Either change is enough to move name resolution away from the device that was enforcing the block.

That is the mechanism behind the familiar complaint that the filter works until the VPN connects.

A hosts entry answers before the tunnel exists

A line such as 127.0.0.1 www.example.com is read by the local resolver, so the answer is produced on the machine with no network involved. Connect a tunnel, change the DNS server, switch networks: the entry still returns loopback. This is why a hosts block is the only one of the two that is unaffected by where the VPN terminates.

Its blind spots are equally local. An application that bundles its own resolver, speaks DNS over HTTPS, or connects to a literal address never asks the system, so the entry is not consulted. A cached address inside a running process has the same effect until that process restarts.

Confirm the answer with getent ahosts on Linux or Resolve-DnsName on Windows rather than trusting a browser tab.

A router filter only sees what crosses it

A content or URL filter on a home router matches names and requests that traverse it in a readable form. When the client builds an encrypted tunnel to a server somewhere else, the router sees a single flow to that server and nothing inside it. The filter has no name to match, so it allows the traffic, which looks like the filter failed rather than like it was bypassed.

The topology that does work is the other one: the router holds the tunnel itself, decrypts at the endpoint and applies the filter there. In that design the filter sits where the plaintext appears.

If the tunnel ends on the laptop, the router is outside the protected path by definition, no matter how the rule is written.

Four enforcement points and what each misses

Four places can enforce a block, and each one fails differently. Read the list as a coverage map rather than a ranking.

• Hosts file or local resolver: works offline and under any tunnel, but is bypassed by a bundled resolver or a hard-coded address.
• DNS filtering at the VPN gateway: covers clients that use the pushed resolver, and misses clients that override DNS.
• Gateway egress rules by address or SNI: independent of client DNS, but blind to names it cannot read and to addresses it has not learned.
• Managed browser or device policy: strong on managed hardware, absent on personal devices.

None of these is a security boundary against a determined user on an unmanaged device. They are policy controls, and an honest description says which traffic each one actually covers.

Pick the layer that matches the intent: household convenience belongs on the device, and an organisational rule belongs at the gateway.

Test both states before you call it done

Run the same three commands with the VPN connected and disconnected: getent ahosts to see the resolver's answer, nslookup to see what the query returns, and curl -I against the site to see whether a connection still completes. If the first returns loopback while the third connects to the real address, something bypassed the resolver and the hosts entry is not the control you think it is.

On the router, read the filter counters before and after a request. A counter that never moves means the traffic never reached the filter, which is a routing answer rather than a rule answer.

Write the result down together with the topology, because the next VPN change will move the path again.