What a VPN Route Table Tells You and What It Cannot

You connect, run a route listing, and see a subnet you have never heard of pointing at the tunnel. That line states one thing precisely and several things not at all. It records how this machine will forward packets to that prefix, nothing about which hosts exist there, and nothing about what your account may reach. Reading it correctly takes a minute; reading it as an inventory takes much longer to unlearn.

Read the Table as Local Instructions

A route is a forwarding instruction held by the local kernel: for this prefix, use this interface and this next hop. The prefix length decides how specific the instruction is, and the longest match wins. Nothing in that rule mentions permissions, service health or remote topology.

Policy rules can intervene before the table is consulted, which is why a route can exist and still not be the one a given packet uses. Read the rules alongside the table, then ask the kernel which path it would choose for a specific destination. The answer for one address is worth more than a page of prefixes, and it is the only answer that reflects marks, namespaces and interface bindings the client applied.

A Wide Prefix Is Not a Catalogue

A /16 routed through the tunnel does not mean sixteen thousand reachable hosts, and a default route means even less. The server decides what answers, the firewall decides what is permitted, and the account decides what is authorised.

A narrow table has the opposite trap: an absent prefix can mean the destination is reachable through another path, or simply that it is not routed at all. Those two cases look identical until you test them. Compare the table with the resource you were told to use rather than with your expectations of what a VPN should contain.

Where the Entries Come From

Routes arrive from at least four places: the configuration file, the server pushing a route during connection setup, a network manager that owns the interface, and a person typing a command during an incident. Each has a different lifetime and a different owner.

The one typed during an outage is the one that disappears at reboot and appears in nobody's documentation. A server-pushed route changes when the server changes, which is why an unexplained new prefix often shows up after a gateway update rather than after a client change. The ip-route manual documents the table and field syntax if you need to read the flags.

Check the Route Against the Service Contract

The useful comparison is between the table and the service you were promised: name, address scope, port and owner. Write those four next to the prefix and the gaps become visible.

ip route show table all dev tun0
ip route get 10.20.5.9
ip rule show

If the prefix is present and the service still fails, the table has done its job and the problem is elsewhere: name resolution, a firewall on the far side, or an account without the right group. If the prefix is missing, the question is who should have supplied it, not what to type. Either answer names a team to ask next, which is the only useful output of reading a route table. Write that name down before closing the terminal.

Record the before and after of any change, with the date and the interface. A route table is a snapshot of one moment on one machine, and it only becomes evidence when somebody wrote down when it was taken.