One name fails while the tunnel is up, and the browser calls it a network error, when the real cause is the DNS answer the resolver returned. A filtering resolver can withhold, refuse or rewrite a single name and leave every other lookup working. The tunnel carries the query; the resolver decides the answer. Inspect that answer before you touch encryption settings.

The tunnel is up, so encryption is not the suspect

The connection state tells you whether packets move, not whether a name resolves. Resolution is a query to whichever server the client was configured with, and a policy there can answer one domain differently from every other. From the browser side all of those answers collapse into a generic failure, which is why the status light proves so little.

Record three things first: the resolver the client used, the response code for the failing name, and the same query for a name that should work. Ask the resolver directly with dig example.com @10.20.0.1 and read the status line, not the browser message. If the control name resolves and the failing one returns a policy answer, the evidence is complete. If both fail, the filter is not involved yet.

Four answers, four different owners

A filtering resolver does not have one way of saying no, and the form of the refusal points at a different next step. Write the response code down, because the browser rewrites all four into something that sounds like a dropped connection.

AnswerWhat it points at
NXDOMAINThe name is withheld: a policy entry or a zone decision removed it
RefusedThe resolver declines to answer; usually an access or policy rule
Replacement addressA redirect to a block page or sinkhole you can query and inspect
No answer at allWeakest evidence: reachability, load or routing, not necessarily policy

Match the answer to the table before you attribute anything to the tunnel. A refusal and a withheld name both mean the resolver made a decision, while silence means the query never got an answer. That difference decides whether you chase a policy owner or a network path.

Two browsers can follow two policies

A browser that ships its own encrypted resolver need not use the server the operating system hands out, so it can ignore the policy the tunnel was built to apply. Two browsers on one machine then disagree about the same hostname, and neither is broken. Check which resolver each application is bound to before you call the filter inconsistent.

When both applications use the tunnel resolver and only one fails, the difference sits in the application, not in DNS. Write the resolver address per application, since that detail disappears when the window closes.

Change what you own, escalate what you do not

Your next move depends on who owns the resolver you are pointed at. One you run yourself is a feature you can read and configure: check the documented filtering option and its exceptions, then allow the single name. One your employer or provider runs is a ticket with the domain, the exact answer and the time.

Never swap in a public resolver to force the site open, because private names stop resolving and a deliberate policy stops applying. The narrow change also keeps the evidence intact, so the owner can line your report up against their own records. After the change, repeat the original application test rather than a lookup from a shell.

A block page is not a trusted certificate

A replacement page that presents its own certificate will raise an HTTPS identity warning, and the redirect does not make that certificate valid. Do not click through it because the tunnel is up; the warning is a separate trust decision that still has to be correct.

The diagnosis closes when the failing name returns a policy answer and a control name returns a normal one through the same resolver. At that point the repair is a policy change, not a tunnel change, and the RFC 1035 response codes are what you quote in the report. Keep both names and answers together; that is the whole case.

Аффингæй хæстæг статьялтæ