Read private addresses and CIDR routes

Private IPv4 networks use three ranges: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. RFC 1918 reserves them for private use, and Internet routers do not carry them. This fact is why VPNs exist at all. The only way to reach a private address from outside is through some kind of tunnel.

The notation is CIDR. The number after the slash says how many leading bits identify the network. The remaining bits identify hosts inside it. Let’s see what three prefixes cover:

10.14.0.0/24   →  10.14.0.0 – 10.14.0.255       (256 addresses)
10.14.0.0/16   →  10.14.0.0 – 10.14.255.255     (65,536 addresses)
10.0.0.0/8     →  10.0.0.0  – 10.255.255.255    (16,777,216 addresses)

Notice the direction. The bigger the number after the slash, the smaller the network. A /24 is tiny, a /8 is enormous. That inversion trips up everyone once, so say it out loud until it sticks.

A route is a CIDR prefix with a direction attached. When several routes match a destination, the kernel picks the most specific one. We call this longest-prefix matching: the route with the biggest number after the slash wins.

You can ask which route an address would take:

ip route get 10.14.0.7
# 10.14.0.7 dev wg0 src 10.14.0.2

ip route get 10.15.0.7
# 10.15.0.7 via 192.168.1.1 dev eth0 src 192.168.1.34

The first address matched the tunnel’s /24 route and goes into wg0. The second matched nothing specific and fell through to the default route, out through the home router.

VPN routes usually point one private prefix into the tunnel. My advice is to use the narrowest prefix that covers the resources you need. Routing all of 10.0.0.0/8 into a tunnel to reach one server at 10.0.1.100 drags sixteen million addresses along for nothing. Every one of them is a potential collision with some other network.

Collisions are the classic failure. Say both your home network and the company network use 192.168.1.0/24. The operating system cannot know which 192.168.1.20 you meant. Longest-prefix matching resolves it mechanically, both routes are /24, and you get the home printer when you wanted the office server.

The only clean fixes are renumbering one side or picking unusual ranges from the start. That is exactly why our lab uses 10.14.0.0/24 instead of something popular like 192.168.1.0/24 or 10.0.0.0/24.

Try this now: run ip route on your machine and read every line as “addresses matching this prefix go that way”. If you can do that, the rest of the module is easy.