A range is not a route: turn 200-255 into three prefixes
A route line takes a network and mask, never a start and end address. Sum the range into aligned prefixes before OpenVPN will install it.
Firewall rules accept a first and last address, such as 192.168.0.200 through 192.168.0.255, while routes do not. A route entry has room for a network and a mask only, which means a contiguous range has to become one or more aligned prefixes before OpenVPN will install it. A profile that pairs route-nopull with an unaligned interval is where the failure usually hides, because the file parses and no route matches. Get the blocks right and the failure becomes visible in one command.
The myth: a range is a route
Routing tables store network and mask pairs and choose the longest match, so an interval with a start and an end has nowhere to live. One prefix spanning 256 addresses covers .0 to .255, half that size covers .0 to .127, and only a range aligned to those edges maps in one step. Anything else has to be cut into blocks. No smaller route still means the original interval.
A range that is not prefix-aligned is not a compressed route. It is a different kind of object, and treating it as a route is where the silent failure starts.
Alignment is arithmetic, not style
Block sizes are fixed by prefix length. A /29 can only begin at an address divisible by 8, a /28 at one divisible by 16, a /27 at one divisible by 32. Move a block off its boundary and the mask covers a different set of addresses than the one you intended.
Sum from the low end. At each step, take the largest aligned block that does not pass the range end, then continue at the first address after it. The blocks cannot overlap, because each begins where the previous one stopped.
Two people doing this by hand should reach the same result. A disagreement means someone allowed a start that was not aligned.
Work through 200 to 255
| Step | Start | Block that fits | Line for the profile |
|---|---|---|---|
| 1 | .200, multiple of 8 | /29, 8 addresses | 192.168.0.200 255.255.255.248 |
| 2 | .208, multiple of 16 | /28, 16 addresses | 192.168.0.208 255.255.255.240 |
| 3 | .224, multiple of 32 | /27, 32 addresses | 192.168.0.224 255.255.255.224 |
The range starts at .200, which is a multiple of 8, so the first block is a /29 from .200 to .207. After those eight addresses the first free value is .208, which divides by 16, so a /28 takes .208 through .223. What remains is .224 to .255, thirty-two addresses starting on a multiple of 32, so a /27. Those three rows are the entire decomposition.
Write them as route lines rather than as prose. A profile holding only the first line covers eight addresses and leaves the rest outside the tunnel.
route-nopull
route 192.168.0.200 255.255.255.248
route 192.168.0.208 255.255.255.240
route 192.168.0.224 255.255.255.224The last block needs a boundary check. Inside 192.168.0.224/27, .224 is the network address and .255 is the broadcast address, so a host that must answer on .255 is covered by the prefix and still unreachable. Move that host or split the range differently rather than routing the block and hoping.
What route-nopull does to the picture
Only add route-nopull when the server's pushed routes are unwanted. Without the directive, pushed routes and these lines coexist, and the most specific prefix wins. With it present, pushed DNS and DHCP options disappear as well, so internal name resolution needs its own configuration. That side effect surprises people who added the directive to fix a route problem.
Add it for the right reason, not as a default reflex. Removing pushed routes is a policy decision with a DNS consequence. If the server can push the same three prefixes, let it, and delete the client-side copies so one owner controls the list.
Checks that catch the usual mistakes
Check that every mask is one contiguous run of one bits. The value 255.255.255.248 passes and 255.255.255.200 fails, and a mask that is not contiguous gets rejected or misread. Then confirm the path for one address in each block.
ip route get 192.168.0.205
ip route get 192.168.0.220
ip route get 192.168.0.240Each answer should name the tunnel interface. A result naming the physical adapter means the line was never installed, which often happens when a desktop network manager rewrites the table after the profile connects.
Choose one owner for the list. When the server can push the same prefixes, push them and remove the client-side edits. A single owner means a typo has one place to live, and the client and server cannot disagree about which addresses sit inside the tunnel.