Error 868 With an IP Address? What Windows Resolves First
The dialog names a lookup failure while the profile looks numeric. Read the actual profile field, then separate a name problem from an old reconnect bug.
The dialog reports that the server name could not be resolved, and the profile field you are staring at is an address. That combination is not a contradiction: the client is resolving something other than the value you believe it reads. Work out what it actually dials before concluding that DNS is broken. The order of the client's own steps tells you where to look.
The client resolves a name before it dials
A native Windows VPN connection reads its profile, resolves the server address, starts the tunnel, and only then authenticates. Error 868 belongs to the second step. Because the later steps never run, the dialog can look like a credential problem when the lookup failed first.
That ordering is useful, because it narrows the layer to inspect. When the same profile works from one network and fails from another, the difference is usually name resolution rather than the tunnel type or the account. Test the lookup where the failure happens, not where the profile was built.
Which name, when the field shows an address
Read the stored value instead of the display name. A connection's label is not its server address, and two entries with similar labels send you after the wrong one:
Get-VpnConnection -Name "Work VPN" |
Select-Object Name, ServerAddress, TunnelTypeIf the profile was provisioned for every user, query that scope as well with -AllUserConnection. Then resolve exactly the value the command printed, from the network where the failure happens. Use the operator's documented gateway, not the internal application name that only resolves after the tunnel is up. That second query fails for an expected reason and tells you nothing about the dial:
Resolve-DnsName vpn.example.comWhen the stored value is genuinely numeric, look for a second place the client reads a name. An EAP configuration can reference a server, a profile imported from another tool can carry its own value, and an earlier installer can leave a duplicate entry behind. The field in the dialog is not always the only input.
The Windows 7 reconnect pattern
The thread behind this error describes machines that connected once and then failed on a later attempt with 868, with nothing changed in the profile. Contributors reported that restarting the Remote Access Connection Manager service or signing out and back in temporarily restored the connection. Those are workarounds, not a demonstrated root cause.
Treat that pattern as a separate hypothesis. A restart resets client state, so a temporary success afterwards does not prove the DNS record was wrong:
| Observation | Points toward | What to do next |
|---|---|---|
| Fails from one network, works from another | Name resolution on that path | Resolve the stored name from both networks |
| Fails after a disconnect, works after service restart | Client state, not DNS | Record the sequence for the vendor |
| Fails only on a newly provisioned machine | Profile content or scope | Compare ServerAddress and TunnelType |
Read the table as a set of distinguishing observations rather than a diagnosis. The first row is a name problem, the second is client state, and the third is a profile that was never correct. Each one leads to a different person and a different fix.
What to collect for the administrator
Write down the profile name, the stored address, the tunnel type, the network the client was on, and whether the failure followed a disconnect. That record separates a real lookup failure from the historical reconnect behaviour without requiring anyone to guess. Keep the client event log around the attempt as well.
The workaround from older builds is evidence that the behaviour existed, not a promise that the same service restart will fix a current machine. Replacing a documented hostname with a literal address is not a repair either.
Some profiles expect a server identity that matches the configured name, so a numeric workaround can trade one error for a different one. If the name must stay, fix the resolution path rather than the profile text. Either way, record what you changed and why.