How to limit access between two VPN-connected offices

A site-to-site tunnel answers one question, whether the two offices can exchange packets, and leaves the important one open: which branch device may reach which central service. Treating the tunnel as mutual trust is how a guest laptop ends up on the same path as the finance server. The fix is not a better tunnel but an explicit allow list enforced after decryption. This runbook takes that list from definition to a proven denial.

Work in this order, and do not widen the tunnel route until the policy steps below pass.

Write the matrix before touching the gateway

A useful row names three things: a source group, a destination host or service network, and the protocol and port the application actually uses. The branch and the data centre are not entries. Private DNS and authentication services earn their own rows only when the application cannot work without them.

Group sources by role rather than by subnet convenience: staff, guest, administration. When all three share one flat LAN the gateway cannot tell them apart at the network layer, so identity controls or segmentation have to come first. Then put the matrix in writing with an owner and a review date on every row.

Enforce where the packets are decrypted

The rules that permit IKE and ESP only build the outer tunnel. Inner traffic arrives in clear on the tunnel interface, and that is where the allow list belongs: a forward chain on the decrypted device, default drop, one rule per matrix row. On Linux gateways that means forwarding enabled and filter rules on the tunnel device, not on the physical uplink, as the strongSwan forwarding guide sets out.

Traffic selectors are a routing decision, not an authorization one. A wide selector that covers both subnets can be right for routing while the firewall still permits only TCP 443 to one host. The selector is negotiated for the tunnel and describes what may enter it, not what any given device may use. Never widen a firewall rule because the selector is wide.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT and overlapping subnets change the rules

When the branch gateway translates every host to a single address before the tunnel, every source-based row collapses into that one address. Either stop translating tunnel traffic or accept that rules must key on something else, such as the original source address recorded before translation. The far end has the same problem, because the destination host sees the post-NAT address rather than the original one.

Overlapping ranges are the other trap. Two offices that both use 192.168.1.0/24 cannot be described in one policy table without mapping a side, and a mapping is not a substitute for addressing that does not collide. Fix the plan before writing rules you will have to unwind later.

Prove a denial, not just a success

Testing the permitted application alone proves very little, because a permissive rule somewhere upstream produces the same result.

From an ordinary branch device, reach the intended service and confirm the whole session works. Then try a destination that must stay closed, such as an administrative port on a server the branch has no business reaching, and read the counter or log entry that dropped it. Disabling the rule set to check whether it works invalidates the test and leaves the gateway open while you look.

Keep the list alive

Applications move, and a rule that outlives its application becomes a hole nobody owns. Attach the review date to the row, and change the selector scope and the firewall rule in the same maintenance step when a service moves address.

Host-level restrictions still matter behind the tunnel: the server's own firewall should accept the branch range only for the service it publishes. Two layers that agree are easier to audit than one layer that is trusted completely.