Blog

Branch Site-to-Site VPN: Address Planning Beats Tunnel Algorithms

October 17, 2025 3 min read
NetworkingVPNOps
Site-to-site VPN connecting a branch office to headquarters

My branch office has a dozen people who need the file server and AD back at HQ. There's no budget for a leased line, so site-to-site VPN it is. The endpoints can be firewall-to-firewall, or an HQ firewall to a small branch router. But which crypto suite you pick almost never matters as much as this: whether both sides happen to sit on the same 192.168.1.0/24.

Before you start: addressing and DNS

  1. Lay out three non-overlapping ranges — HQ, branch, and the VPN interconnect (if you use one)
  2. If the branch is already on 192.168.1.0/24 and HQ uses the same range: renumber the branch first, then open the tunnel. That lesson is paid for in blood.
  3. DNS: give branch clients a search suffix for the HQ domain, via conditional forwarding or a site DNS server

Overlapping subnets produce wonderfully deceptive symptoms: the tunnel comes up, some IPs answer and others don't — it looks exactly like a phantom ACL.

Choosing a tunnel mode

Mode Best for
Policy-based IPsec (interesting traffic) Simple setups, older gear, a small traffic matrix
Route-based (VTI) Multiple subnets, dynamic routing, or a clean next-hop

I default to route-based: when you add an internal segment, you just add a route — no editing a long chain of proxy-ids. I only fall back to policy-based when the two sides can't do symmetric capabilities.

The minimum viable config checklist

  • Pre-shared key or certificates — with key length and rotation schedule written into the asset ledger
  • Matching Phase 1 and Phase 2 proposals (encryption, hash, DH group, PFS)
  • Dead peer detection (DPD)
  • Interesting traffic or routes: HQ LAN ↔ branch LAN
  • NAT: bypass the remote subnets, or you'll NAT the peer's addresses into your own public range

The dual-WAN HQ trap

When HQ runs primary/backup WAN links, pin the tunnel endpoint to the stable primary public IP, or use a design that handles two ISPs. Once the primary dies and the backup takes over:

  • The far end keeps dialing the old IP → down for the long haul
  • DDNS propagation lag → half a day of "sometimes up, sometimes not"

Hardcoding the HQ FQDN on the branch side and verifying its TTL and update script beats "an IP somebody filled in once and everyone forgot."

Troubleshooting order (don't start by rebuilding)

  1. Reachability: can the branch even hit HQ's WAN IP?
  2. Is IKE up? Read the Phase 1 and Phase 2 logs.
  3. Do the selected subnets match? Swapped proxy-ids are the single most common mistake.
  4. Does the internal route point into the tunnel?
  5. Does the firewall allow the internal service ports — after decapsulation?
  6. Is clock skew between the two ends too big? (Certs and some implementations are sensitive to it.)
# 思路，不绑厂商
show vpn ike sa
show vpn ipsec sa
traceroute 对端内网网关

Business verification

  • Branch machines join the domain and log in (if they authenticate against HQ DCs)
  • \\files latency and permissions
  • Voice/video accidentally riding the VPN? (You can split: only internal prefixes enter the tunnel.)

Full-tunnel VPNs in small branches turn into "scrolling short videos blows out the tunnel." Write the split policy into the design, not into a post-launch rant about bandwidth.

Operations

  • Monitor tunnel up/down and traffic
  • Key rotation — and revoking access when people leave
  • After a branch power outage: power-on self-recovery and the tunnel bringing itself back up

Wrap-up

Site VPNs are bread-and-butter for network engineers: address planning, route/policy consistency, NAT bypass, failover, and monitoring. On a résumé, stating the scale — how many sites, how many users, whether it's dual-box — says a lot more than "configured IPsec." Tunnel up is only the start; delivery is when the business keeps running smoothly at peak hours.

← Back to Blog