A site-to-site VPN either works in fifteen minutes or takes three days. The difference is almost never the VPN software. It is whether the two networks were designed to be joined, and whether both ends agree on a small set of parameters that fail silently when they do not match.
Here is the order of work that keeps it in the fifteen-minute category.
If the office runs 192.168.1.0/24 and the VPC also uses 192.168.1.0/24, stop. No tunnel configuration will fix it: a machine cannot tell whether 192.168.1.50 is the printer down the hall or a database in the cloud, and the routing decision is made before the tunnel is ever consulted.
The fix is to renumber one side, which is exactly why the VPC address plan matters at the start of a project. If the office is the side that must move, do it before the tunnel exists rather than during a debugging session.
Also check the ranges you might add later. A tunnel that works today breaks when someone adds a subnet on one side that collides with the other.
First: mismatched phase 1 and phase 2 proposals. Both ends must agree on encryption algorithm, integrity algorithm, Diffie-Hellman group and lifetime. When they disagree, most devices log something unhelpful — no proposal chosen — and retry forever. Write both ends' proposals in a two-column table before you configure anything, and make the columns identical. IKEv2 with AES-256, SHA-256 and DH group 14 or better is a safe, widely supported starting point.
Second: mismatched traffic selectors, sometimes called the local and remote networks or the encryption domain. If the cloud side declares 10.42.0.0/16 to 192.168.10.0/24 and the office side declares 192.168.10.0/24 to 10.42.0.0/24, phase 1 comes up, phase 2 does not, and the logs blame the peer. These must mirror each other exactly. Declare the whole VPC /16 on both sides rather than listing subnets individually — it is fewer security associations and one fewer thing to keep in sync when you add a subnet.
A tunnel that is up carries nothing unless both networks know to send traffic into it.
On the cloud side, the VPC route table needs an entry sending the office range to the VPN gateway. On the office side, the router — and sometimes a separate core switch, and occasionally individual servers with their own static routes — needs an entry sending the VPC range to the VPN device. The classic failure here is a firewall that has the route but a LAN that does not, so traffic leaves the cloud, arrives at the office, and dies at the first hop.
Test from both directions. A tunnel that works cloud-to-office and not office-to-cloud is almost always a missing route or an asymmetric firewall rule, not a VPN problem.
Establishing the tunnel and permitting traffic through it are two separate decisions, and it is worth keeping them separate deliberately. The tunnel means the office and the VPC can reach each other; the network ACL decides what may actually pass.
Start closed. Allow SSH from the office management range to the bastion, allow the specific application ports the office genuinely needs, and leave the rest denied. A hybrid link that permits everything in both directions has quietly extended the office's blast radius into production, and vice versa.
Encapsulation adds overhead, so the effective MTU inside a tunnel is smaller than on the LAN. Symptom: small requests work perfectly, SSH connects and then hangs when output scrolls, HTTPS to internal services stalls after the handshake, and file transfers die at a consistent point. That is fragmentation, not the VPN.
Clamp the MSS on the tunnel interface — 1350 to 1400 is usually right — or lower the MTU on both ends. It takes one line of configuration and eliminates the most confusing class of hybrid bug.
Monitor the tunnel itself, not just the machines behind it. Watch phase 2 SA state and alert when it drops, because a dead tunnel looks exactly like an application outage to everyone else. Log rekey events — a tunnel that rekeys cleanly every few hours is healthy; one that renegotiates every few minutes has a lifetime mismatch.
Keep a redundant path if the link matters. A second tunnel from a different office device, or a client VPN as a manual fallback, turns a router failure from an outage into an inconvenience.
Check for address overlap before touching a config. Make the phase 1 and phase 2 proposals identical and the traffic selectors exact mirrors. Add routes on both sides and test both directions. Keep firewall policy separate from the tunnel and start closed. Clamp the MSS. Then monitor the tunnel as its own service.
Antyxsoft VPC includes site-to-site VPN and VPC peering, so an office or colocation rack joins your cloud network privately — see how VPC works.