A site-to-site VPN joins two offices over the internet as if they were one network. When it works nobody thinks about it; when it fails, a branch stops billing. These are the mistakes behind most of those failures.
1. Legacy encryption settings
Old tunnels often still use IKEv1, DES or 3DES, MD5 or SHA-1, and small Diffie-Hellman groups. Use IKEv2 with AES (GCM where supported), SHA-256 or stronger, and Diffie-Hellman group 14 or above, or the elliptic-curve groups 19 and 20.
2. Settings that do not match on each end
Different proposals or lifetimes on each side lead to tunnels that will not come up or that drop at rekey. Write down one standard set of parameters and use it on every tunnel.
3. Overlapping IP ranges
If both offices use 192.168.1.0/24, traffic cannot be routed between them cleanly. Give every site its own address range from the start. NAT can work around an overlap, but it adds complexity that someone has to remember.
4. Tunnels that allow everything
A VPN encrypts traffic; it does not filter it. A tunnel that allows any traffic between sites lets a problem at one branch reach every server at head office. Apply firewall rules to VPN traffic the same way as to any other zone, as described in zone-based firewall policy.
5. Weak or shared pre-shared keys
A short key, or the same key on every tunnel, means one leak exposes them all. Use long, random keys unique to each tunnel, or certificates, and change them when someone who knew them leaves.
6. MTU and fragmentation problems
The tunnel is up and pings work, but some websites hang, file copies stall or one application keeps timing out. That pattern usually points to packet size. VPN headers make packets larger, and oversized packets get dropped. Setting MSS clamping on the tunnel, and checking the path MTU, usually fixes it.
7. No monitoring
A tunnel that drops overnight is often discovered when staff arrive. Monitor tunnel status and latency, alert on failures, and use dead peer detection so a broken tunnel is noticed and rebuilt.
8. No redundancy
One internet link per site means one outage takes the tunnel down. A second link with failover helps, and for several sites SD-WAN handles multiple links and application-aware routing more cleanly. Our SD-WAN vs MPLS guide covers when to move.
Write it down
For every tunnel, record both endpoints, the networks on each side, the encryption settings, where the key is stored, and who to call at each site. When a tunnel fails at 9 am on a Monday, that page saves the most time.
Our VPN setup and management covers site-to-site tunnels and remote access; for remote users, see VPN or ZTNA.