Turn a First-to-Last IP Range Into Exact VPN Routes

Somebody hands you a first and last address and asks for a VPN route. The tempting move is to pick the shortest prefix that contains both ends, and that move quietly adds destinations nobody asked about. A CIDR block always has a power-of-two size and a starting address aligned to it, so an arbitrary interval usually needs more than one. Walk the interval, split it exactly, then check the addresses just outside it.

Start with the interval, not the prefix

Write down the first address and the last address before you write anything else. The pair is the requirement; a prefix is only one possible expression of it, and sometimes a wrong one. Two numbers are also much easier to check than a mask.

An aligned interval collapses to one block. An unaligned one decomposes into several, and the decomposition is exact rather than approximate. What you must not do is round outward and call it close enough, because the extra addresses receive whatever policy the route carries.

Both directions of error matter. For a route into the tunnel, extra addresses get pulled into the VPN. For a bypass exception, extra addresses skip it. Neither outcome is visible in a route table that only shows the prefix you installed.

Case one: the interval happens to align

Take 198.51.100.64 through 198.51.100.127. The first address is aligned on a 64-address boundary and the interval is exactly 64 addresses, so a single /26 describes it with nothing left over.

That is the easy case and it is worth recognising, because it means the requirement was probably written by someone who was already thinking in prefixes. It also means the check is short: confirm the size is a power of two and the start is a multiple of that size.

Documentation ranges make good examples precisely because nobody owns them. Do not install these addresses on a real tunnel, and do not assume that a range you were given is documentation space just because it looks unusual.

Case two: it does not, so split it

Now take 198.51.100.100 through 198.51.100.107. That is eight addresses, which is a power of two, but 100 is not a multiple of eight. A single block of that size cannot start there, so the interval has to be covered by more than one.

The exact cover is two /30 blocks: 198.51.100.100/30 covers 100 through 103, and 198.51.100.104/30 covers 104 through 107. Eight addresses in total, nothing outside the interval, and the decomposition is unique for a given interval.

python3 -c "from ipaddress import ip_address, summarize_address_range as s; print(*s(ip_address('198.51.100.100'), ip_address('198.51.100.107')), sep='\n')"

The standard library function does the arithmetic for you, and the ipaddress documentation defines what it returns. What it does not do is choose a gateway, decide who owns the addresses, or grant access to any service behind them.

Measure what the wider prefix would have captured

Before you accept a shortcut, compute what it costs. A /28 starting at 198.51.100.96 covers 96 through 111, which is sixteen addresses instead of eight. The extra eight are 96 through 99 and 108 through 111, and every one of them would inherit the route.

python3 -c "from ipaddress import ip_network as n; w=set(n('198.51.100.96/28')); t=set(n('198.51.100.100/30'))|set(n('198.51.100.104/30')); print(len(w), len(t), sorted(w-t))"

Eight extra destinations is a concrete number you can put in a change request. It is also the number that decides whether the shortcut is acceptable, which is a policy question rather than an arithmetic one.

Keep arithmetic and discovery separate. An interval supplied by the network operator converts exactly. A single DNS answer from a changing service does not establish that service's complete or permanent range, and unrelated names can share an address.

Install the exact set and verify the edges

Hand each resulting prefix to whoever owns the VPN configuration and let them install it through the supported mechanism. If the requirement needs two entries, keep two entries rather than widening one to make a form shorter.

sudo ip route add 198.51.100.100/30 via 10.90.0.1 dev tun0
sudo ip route add 198.51.100.104/30 via 10.90.0.1 dev tun0
ip route get 198.51.100.101
ip route get 198.51.100.97

The last two commands are the ones people skip. The first inside address should follow the new route, and the address just outside the interval should not. If both go the same way, the interval was widened somewhere between the requirement and the configuration.

Record the first address, the last address and the prefixes that express them. The next person to review the rule can then check the requirement against the configuration without redoing the arithmetic, and the difference between an exact route and a convenient one stays visible.