Who actually applies OpenConnect DNS settings on Windows?

Bringing the tunnel up is not the same as installing its DNS values. OpenConnect negotiates, and a Windows-side helper applies. The gap between those two steps explains most private-name failures on this client, and the helper is almost never the Windows VPN settings page.

Separate what the gateway offered from what Windows installed

The client hands connection data to a script interface, and the Unix and Windows variants are separate programs. On Windows the implementation is usually a JavaScript helper that reads variables such as the internal DNS server and internal domain before it touches any adapter. Nothing in the tunnel itself writes resolver state.

That split matters because a value can exist in the negotiation and never reach the adapter. A helper that is missing, fails halfway, or is an older copy bundled inside a GUI wrapper leaves Windows exactly as it was. The session looks connected, the private name still resolves through the local provider, and nothing in the client window hints at the difference. Reading the helper's own output is the only reliable way to learn which stage broke.

A GUI wrapper may ship its own copy of the client and helper, so a second openconnect.exe elsewhere on the disk proves nothing. Find the executable that started the session before you judge its configuration.

Read the resolver state without changing it

Three read-only queries cover the usual confusion, and each answers a different question:

Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effective

An adapter-level server is what most people mean by VPN DNS. A connection-specific suffix decides whether a short name gets expanded at all. The namespace policy list applies to matching names regardless of adapter order, and an empty result there is not a fault when the helper never intended to create one. Reading all three before editing is what prevents a fix that merely moves the symptom somewhere else.

Start with the fully qualified name. If the FQDN resolves and the short name does not, the suffix or search list is the gap rather than the server address.

Query the intended server directly as a second step, using whatever resolver tool is already installed. A direct answer proves the server is reachable and authoritative for the zone. It proves nothing about which server an application asks by default.

Name the component that owns the connection

Two arrangements are common. A client started from a terminal passes its script path explicitly, so the owner is visible in the command that ran. A packaged application starts the client for you and keeps the helper inside its own directory, which means the vendor decides when it changes.

Compare helper versions across installs before swapping anything. Running a helper fetched from a mirror with elevated rights because the filename looks familiar turns a DNS gap into a security incident.

Once the owner is known, the repair target becomes obvious: a supported script path in the launcher, a package update, or a corrected profile on the gateway. None of those require editing adapter properties by hand.

Fix the owner, not the adapter

Hand-set adapter DNS often survives disconnect, which is why it appears to work and then causes trouble on the next network. A public resolver bolted onto every interface hides the private namespace problem instead of solving it. When the helper never received a DNS value, the gateway profile is the place to look. When it received one and the adapter still shows the old server, the helper failed during connect and the client log usually records that near the tunnel setup lines.

Rebuild the state through the supported path, then verify a whole cycle: connect, resolve the private FQDN, open the service, disconnect, and confirm the adapter came back with its previous servers.

Check the application that actually fails

A browser with its own encrypted-DNS setting ignores everything above and keeps answering from a public resolver. An application holding a cached negative answer from before the tunnel came up behaves the same way. Compare it with a plain system query on the same machine before changing resolver addresses again.

If the system query is right and the application is wrong, the remaining fault sits inside that application's DNS configuration, not in the VPN path.