VPN Adapter Shows /32: It Does Not Mean One Destination

Adapters show 255.255.255.255, and the conclusion is often that the VPN can reach exactly one address. That reading confuses the client's own address with the set of destinations routed through the tunnel. On a point-to-point or routed interface the two are different objects, and only one of them limits reachability. The myth survives because the mask looks like the subnet mask people learned on Ethernet.

The myth: a host mask means a single reachable host

A /32 assignment tells the interface which address belongs to this end of the link, and on a point-to-point link that is all it means. The peer address is a separate field, and the routes that say what lies beyond the peer are separate again. Nothing in the mask describes the remote network, because the mask is not where remote networks are described. Reading it as a reachability limit is like reading your own house number as a list of every address you may visit.

The confusion has a real root: on Ethernet, a host mask really would mean a single address on that segment. A tunnel is not an Ethernet segment, and the client's routing table, not the mask, decides what goes through it. That is why the same /32 can sit in front of a whole data centre.

Read the address and the routes as separate objects

Print the interface and the table together, then read them as two answers to two questions. The address answers who this end is; the routes answer where traffic may go. A third question, which destinations the gateway permits, is not visible on the client at all. The iproute2 address reference describes the local, peer and prefix-route fields separately for exactly this reason.

ip addr show tun0
ip route show
ip route get 10.60.5.10

On Windows the same split exists between the address list and the routing table, and the lookup command is the fastest way to see which one wins for a specific destination. If the lookup returns the tunnel interface, the client will send the packet there. If it returns the physical adapter, the client never asks the VPN, and no amount of server-side permission will change that. Check the destination you actually need, not a generic public address.

Get-NetIPAddress -InterfaceAlias "VPN"
Find-NetRoute -RemoteIPAddress 10.60.5.10

Stop if the lookup points at the wrong interface. That is a client routing problem, and it is fixed on the client.

Why widening the mask usually makes it worse

Changing the assignment to a /24 to look like the office LAN can create an on-link prefix: the kernel now believes the whole /24 is directly attached to the tunnel interface. Traffic for addresses that should be routed through the gateway is then sent as if a neighbour were on the link. The result is a black hole that looks like a server outage.

It also hides the real problem, which is a missing route or a missing permission on the gateway. Neither of those is created by a wider mask, and both survive the change. If the design needs a larger prefix on the interface, that is a decision for the interface model in use, made with its documentation in hand. Copying a mask from another product's screenshots is not that decision.

If the remote-prefix route is missing, fix its provisioning. If it is present and the connection is still rejected, the mask was never the diagnosis.

When the route is right and the flow still fails

A correct route only proves the client will send the packet. The gateway still has to accept the destination, the return path has to exist for the assigned address, and the service has to allow the flow. Test those three separately: the lookup on the client, the gateway's permitted scope, and a request to one required server. Authentication succeeding before all three are in place is normal, and it is why a connected client can still reach nothing.

ping -c1 10.60.5.10
traceroute -n 10.60.5.10
curl -sv https://app.internal.example/ -o /dev/null

Keep network objects and group permissions with their owner on an appliance-managed service. What the client is told to reach and what it is allowed to use are different settings, often on different screens. Changing one and testing the other is how a ticket bounces between two teams.

The myth to retire is that the mask is a reachability limit. Read the address, the routes and the gateway policy as three separate facts, and a /32 stops looking like a restriction and starts looking like a normal tunnel assignment.