Router VPN rules: match the source and the destination

Router shopping pages list VPN routing as one checkbox, and the phrase hides three different questions. Does the rule match the device that sends the traffic, the server that receives it, or both? What happens to traffic that matches neither? And when two rules overlap, which one wins? Writing the answer as a source and a destination pair turns a vague feature list into a testable design.

The feature name hides two endpoints

A media player that should use the tunnel is a source match. A private office prefix that should be reachable through the tunnel is a destination match. A workstation that should use the tunnel only for one service is both, and that intersection is the case most consumer firmware handles badly.

Write the requirement as a pair before comparing products. The pair is what you will test later.

A product that offers a device list or a global destination list may not express only this device, only these destinations. The gap is not cosmetic: a global destination rule sends every device's traffic for that site through the tunnel, and a device rule sends all of that device's traffic. Neither is the requirement. Test that case with two devices before trusting the screen.

Build the rule as an intersection

A table keeps the design honest. Put the scenario on the left, then name the sender match and the target match separately:

The third row is the interesting one, because it needs both halves at once. If the firmware can only express one axis, the requirement has to be split into two rules or moved to a device that can.

Keep source identity stable. A DHCP reservation, a dedicated segment, or a device identity mechanism all work, but an address that changes after a lease expires does not. Include IPv6, because one IPv4 address does not identify all of a device's traffic.

Priority decides the overlap

Overlapping rules are normal. A broad device rule and a narrow destination rule can both describe one flow, and the documented priority order decides which wins. An attractive settings screen does not tell you that order.

Read the manual for the ordering and for the unmatched case, then test both with traffic you can observe:

ip rule show
ip route get 203.0.113.10

If the documentation does not state the order, assume the narrower rule may not win and design around it. Two rules that cannot conflict are easier to support than one clever rule whose precedence is undocumented.

Names need a refresh policy

A destination written as a domain adds a maintenance problem. The router has to resolve it, refresh the mapping, handle multiple addresses and subdomains, and cope with application DNS that bypasses the expected resolver.

Copying one lookup result into an IP rule is a snapshot, not a domain policy.

Decide how stale an answer may be before the rule is wrong, and what the router does when resolution fails. A rule that keeps the last known address can outlive a service migration; a rule that drops the entry can silently stop tunneling. Either behavior is acceptable if it is written down next to the rule.

Define the unavailable state

A route preference does not enforce VPN-only traffic. When the tunnel is down, the router can block the flow, send it direct, or use another tunnel, and each choice has a different failure signature.

Decide which one the requirement needs, then verify it by stopping the tunnel and watching the flow:

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10

Router-originated traffic is a separate scope. DNS forwarding, update checks, and monitoring can start new flows from the router itself rather than inherit the device's source match. Account for those flows explicitly, or they will appear as unexplained leaks in the logs.