That tunnel address is a peer, not a subnet you can browse
The mask on a point-to-point link describes the far end, not a range of neighbours. Read the peer address before deciding the subnet looks wrong.
Your client connects and shows an address pair, or one address wearing a 255.255.255.255 mask, and the first reaction is that the server handed out something broken. Nothing is broken: a tunnelled interface is a point-to-point link, and the mask describes the far end of that one link rather than a range of neighbours. Reading the pair as local and peer explains the odd mask, the single-host route beside it and the missing neighbour table. What the same reading does not excuse is an address plan that overlaps the office network.
Why the mask looks wrong on a tunnelled link
On an Ethernet interface, an address and a mask state two things: this host owns the address, and everything inside the prefix is a direct neighbour. The kernel derives an on-link route from those two facts and then resolves link addresses for the neighbours it believes are present. A point-to-point interface keeps the ownership and drops the neighbours, so the second address on the client line is the far end rather than another host on a shared segment. There is no hardware addressing, no resolution traffic and no broadcast domain to join, which is why the interface behaves like a pipe with exactly one destination.
That is also why a host route beside a wide mask is normal here instead of a symptom. Reachability on this link means one address, and the kernel writes down precisely that. Read the two addresses together before deciding the configuration is wrong, because either one on its own looks like a mistake.
Two topologies, two address shapes
The older point-to-point topology hands each client a small block and uses the two middle addresses, so the mask looks like a fragment of a network rather than a pool. The subnet topology hands out an address from the pool with the pool mask and names the server's tunnel address as the peer. Both produce a valid link, and they differ only in which addresses appear in the profile and in the mask a user is likely to question.
| Topology | Client address shape | Peer | Route to expect |
|---|---|---|---|
| Point-to-point block per client | Two neighbouring addresses inside a small block | The far address of that block | A single host route on the tunnel device |
| Shared pool | One address carrying the pool mask | The server's tunnel address | A single host route on the tunnel device |
Whichever row matches your client, read the peer first, because it names the far end and therefore explains the mask. A profile copied between servers that use different topologies will show the wrong shape for its new home, and that mismatch is easily mistaken for a server fault.
When the pool and the office network claim the same bits
Because the link is routed, the pool needs a prefix that appears nowhere among the networks the server can reach. Share one and the client holds a single route for a range that means two places, and the most recently installed route decides which place wins. The failure presents itself on the client even though the decision behind it belongs to the address plan. What users report is the local router disappearing when the tunnel comes up, or only some office hosts answering.
Prefixes that merely look alike are a different case, and comparing octets by eye is not a prefix comparison. Write both out and count masked bits: 192.168.4.0/24 against 192.168.6.0/24 agree through bit 22 and diverge at bit 23, because the third octet reads 00000100 against 00000110, so those two networks are genuinely separate. Put 10.8.0.0/24 beside another 10.8.0.0/24 and all 24 masked bits agree, which means one route cannot express both places. The mask length decides where the comparison stops, and the network installed second is the one that loses.
What a routed link cannot deliver
Broadcast and multicast do not travel across a routed link, and several familiar features are built on them. Browse lists, name announcements and service discovery all assume a shared segment, so a file server can answer every request by address and still never appear in a list. Name resolution that depends on link-local broadcast fails for the same reason, and no profile edit changes what the tunnel is able to carry. Whether that matters is a requirements question rather than a routing one.
A client that genuinely needs those deliveries requires a bridged interface, which carries Ethernet frames and therefore keeps the broadcast domain. The cost is a noisier link, the loss of the clean addressing described above, and a much larger failure surface once loops appear. Justify the requirement before switching, and prefer a name service that works over routed links when the requirement is only about names.
Reading the interface before you edit the profile
Ask the kernel what it installed rather than what the profile appears to say. The address output shows the peer that explains the mask, and the route output shows whether a path to it exists. Running both against the tunnel device takes a moment and settles the question.
ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1If those three agree, the profile is doing what it was configured to do and the remaining problem lies elsewhere. Change the topology only for a reason that names a missing capability, because an unfamiliar mask is not one.