Site-to-site VPN: eight mistakes that cause outages and gaps

By the NexusSec team · 4 min read · Published
Short version: Most site-to-site VPN problems come from a few avoidable mistakes: legacy encryption settings, settings that do not match on each end, both offices using the same IP range, tunnels that allow all traffic between sites, weak or shared keys, MTU problems that break some applications, no monitoring, and a single internet link. Each is easy to avoid at setup and expensive to discover later.

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.

Frequently asked questions

Should we use IKEv1 or IKEv2 for site-to-site VPN?

IKEv2, unless one end genuinely cannot support it. It is more robust and supports modern encryption settings better.

Is a site-to-site VPN secure enough over the internet?

With modern encryption settings, strong unique keys and firewall rules on the tunnel traffic, yes. The weak points are usually configuration, not the technology.

Why does the VPN connect but some applications fail?

That pattern usually points to MTU and fragmentation. Setting MSS clamping on the tunnel and checking the path MTU normally fixes it.

When should we move from VPN tunnels to SD-WAN?

When you have several sites, more than one internet link per site, or applications such as voice that need traffic steered to the best link automatically.

VPN tunnels giving trouble?

We set up and manage site-to-site VPNs with current encryption settings and firewall policy on the tunnel traffic.

Book a free consultation