A Public Prefix for VPN Clients: What It Actually Breaks

A client pool picked because the numbers look tidy is a route waiting to be installed. The prefix does not have to be private for the VPN to work, and using a block that belongs to somebody else does not automatically expose your users to the internet either. What it does is make those addresses mean something different for as long as the tunnel is up, and then mean something else again when it drops. Work through the five checks below in order and stop where the answer is "assigned elsewhere".

Assignment is not announcement

Putting an address on a tunnel interface does not announce it to the internet. Public reachability needs a route, an authorised path and a provider willing to carry it, and none of those appear because a client received the address from a pool. Firewall policy and host authorisation are separate decisions again.

That is why the risk is not what most people assume. The borrowed prefix does not make your clients reachable; it makes somebody else's destinations unreachable from your clients, which is a different failure with a different owner. Nobody gets attacked and no announcement escapes. A user simply cannot open a site that worked yesterday, and the helpdesk has no reason to suspect the VPN pool.

The distinction matters when you are choosing a pool. If your only concern were internet exposure, a public block would look safe because nothing announces it. The concern is the local route the client installs for that prefix, and that route is installed whether or not anyone else can see it.

What the client route actually captures

When the tunnel comes up, the client receives a route for the pool's prefix, and that route wins over the default route for every destination inside it. A request to a legitimate host in that block now goes to the VPN instead of the internet. Whether it fails, hangs or reaches the wrong server depends on what your side does with it.

ip route get 198.51.100.20
ip -br addr show tun0
traceroute -n 198.51.100.20

Run the lookup with the tunnel up and again with it down. The address means one thing in the first case and something entirely different in the second, and any application that cached a connection or a name resolution across that transition will behave inconsistently. That inconsistency is harder to support than a clean failure, because it depends on timing. A user who reconnects at the wrong moment gets a different experience from one who does not.

That is also why a familiar IP address is not proof of identity. Keep certificate and server-name validation for the real destination, because the numeric address you reached five minutes ago may now belong to a different conversation.

Compare the pool against every network you know

RFC 1918 sets aside three blocks for private use: 192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8. Millions of separate organisations reuse them, so private is a statement about allocation and never a promise that nobody else picked the same numbers.

Compare the candidate pool against office LANs, cloud VPCs, other VPN pools, partner links and the ranges remote workers are likely to have at home. The home case is not a reason to invent a strange prefix; it is a reason to keep the pool small and documented.

Coordinate the allocation with whoever owns routing, and record the return path in the same place. A pool nobody can route back to is a pool that will be rediscovered during an outage. Put the pool in the same document as the site ranges, not in a client configuration that only one person has edited. The document is what makes the next collision avoidable.

When public addressing is the right answer

Organisations with properly assigned global space can absolutely build a public-addressed VPN pool, and some do so deliberately to avoid translation. That design still needs routing, source validation, access rules and client authentication; the allocation supplies none of them.

What it does supply is uniqueness, which is the property the borrowed prefix lacks. If you hold the block, the route your client installs points at addresses that are genuinely yours, and the meaning does not change when the tunnel drops.

Do not add NAT automatically to compensate for a pool choice. A routed private design with explicit return routes is cleaner than translation applied because the addressing was never planned, and IPv6 needs its own deliberate plan rather than a copy of the IPv4 assumptions.

Retire a bad pool without losing access

If the pool is already deployed, inventory before you change it: address reservations, installed routes, DNS records that resolve into the block, firewall scopes and the applications that depend on them. Then schedule the change with the same care as any other routing cutover. Announce it to the people who will notice, because their sessions will drop when the pool moves. A silent change to client addressing generates support tickets that look unrelated to the work.

Preserve a recovery path that does not depend on the pool you are removing, because the moment you withdraw it is the moment your remote access might disappear with it. Validate both directions afterwards: the intended private destinations still work, and the internet destinations that used to be captured now resolve to their real owners.

What you want is a pool the network team can allocate, route and retire as one coherent thing. An address format on its own establishes neither safety nor connectivity.