Windows VPN Shows 255.255.255.255: Is the Mask Wrong?
On a point-to-point tunnel a host mask is normal. Confirm the interface model, read the route for the failing host, then separate DNS from service access.
The tunnel connects, you open the adapter details, and the mask reads 255.255.255.255. Compared with the office LAN's 255.255.255.0 it looks broken, and that is usually where the mistake starts. On a point-to-point link a host mask is the correct description of the local endpoint, and the remote networks arrive as routes rather than as an attached subnet. The runbook below separates the two questions so you do not rebuild a working DHCP scope to fix a display value.
A point-to-point link is not an Ethernet segment
An Ethernet interface needs a subnet mask because every address in that range is potentially reachable on the same wire. A PPP-style tunnel has exactly one peer at the other end. There is no broadcast domain, no ARP and no reason for the local address to describe a range.
The addressing negotiation for that model is defined in RFC 1332, which covers how the two ends agree on their addresses. What it does not do is hand the client the office LAN as a directly attached network. The client learns where the office is by installing routes through the link, and those routes are what actually decide reachability.
This is not a claim that every mask you will ever see is correct. A misconfigured client can also produce odd addressing. The point is narrower: a host mask on this kind of adapter is expected, so it is not evidence of a fault on its own.
Step 1: confirm the interface model
Look at what the adapter is before judging what it says. The description string identifies the driver, and the prefix length on the assigned address confirms what the client negotiated:
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtuThe third command is the one that settles most arguments. A low maximum transmission unit is characteristic of an encapsulated link, while an Ethernet-like value suggests a different virtual adapter model. If the description names a PPP or RAS driver and the prefix is 32, you are looking at exactly the design described above and can stop worrying about the mask.
| Observation | What it means | Reasonable next step |
|---|---|---|
| /32 on a PPP or RAS adapter | Point-to-point endpoint addressing | Look at routes, not the mask |
| /32 on an Ethernet-like adapter | Client chose host addressing deliberately | Confirm against the server's push policy |
| Mask differs from the office LAN | Usually irrelevant to reachability | Test the destination instead |
Step 2: read the route for the failing destination
Reachability is decided per destination, and a single connected interface tells you nothing about it. Ask the routing table directly, for the address the user is actually trying to reach:
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4Find-NetRoute is the direct answer: it names the interface and the source address the system would use for that destination. If it returns the tunnel, traffic for that host is going through the tunnel and the mask was never the issue.
If it returns the physical adapter, compare the two candidate routes and their metrics. A more specific local route, a leftover entry from another client, or a lower metric on the physical path will all win over a broad tunnel route. The visible result is a resource that is unreachable while everything else works. Longer prefixes always win, so the winner is often a single host route somebody added months ago and forgot.
Check both directions while you are here. A route to the server side is necessary but not sufficient, because the reply has to come back through the tunnel as well. When one internal host works and another does not, the difference is usually in this table rather than in the adapter configuration.
Step 3: separate name lookup from service access
An application that fails to open a share can be failing at one of two very different stages. Resolve the name, then reach the address. If the first fails and the second works, the tunnel is fine and the resolver is not:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445A successful address test plus a failed name test localises the problem to resolution, and the second command shows whether the tunnel interface received a server at all. Many clients push DNS as part of the tunnel configuration, and a profile that ignores those pushed options will leave the machine using a resolver that cannot see the private zone.
Do not treat a working address as the permanent fix. Connecting by address bypasses name resolution and can defeat the server identity check the application would otherwise perform. That is a security regression dressed as a workaround. Use it to localise the fault, then repair resolution.
Rollback: do not rebuild DHCP around a display value
If you have already started changing the addressing service, stop and check whether anything you changed is load-bearing. Recreating a scope, reissuing leases or moving the pool changes state that other clients depend on, and none of it is justified by a host mask on a point-to-point adapter.
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445Run these three after any targeted change and compare with the run before it. The useful outcome is a documented path to the resource, not an adapter whose mask resembles the office LAN.
Then write down what the mask actually meant, because the next person will open the same dialog and reach the same wrong conclusion. One sentence in the profile notes, saying the tunnel is point-to-point and the remote subnets arrive as routes, saves the whole investigation the next time it comes around.