Site-to-site tunnels
Join two networks with an encrypted IKEv2 tunnel and get traffic flowing across it.
Prerequisites
Two gateways, both reachable, with non-overlapping local subnets. If both sides advertise 10.10.0.0/24, routing is ambiguous and the tunnel will carry no useful traffic — give each site a distinct range first.
Define the tunnel
Create a tunnel and select the two gateways as endpoints. Each side contributes the local subnet it advertises; the far side learns to route that range across the tunnel. Accept the default IKEv2 / AES-256-GCM / PFS proposal unless you are matching a third-party device with a fixed policy.
vpngeek tunnel create \
--name hq-to-branch \
--peer-a hq-gateway \
--peer-b branch-gateway \
--pfs on
# Watch it negotiate to 'established'
vpngeek tunnel status hq-to-branch
Add routes
If your gateways are not the default route on each LAN, add a static route on each site's router pointing the remote subnet at the local gateway. Without it the tunnel establishes but return traffic never finds its way back, which looks like a one-way connection.
Test and monitor
From a machine at one site, ping a device on the remote subnet. A reply confirms the tunnel is carrying traffic; the dashboard's live counters should show packets climbing in both directions. Common failure modes:
- Stuck negotiating — mismatched pre-shared key or crypto proposal. Confirm both ends agree.
- Established but silent — a missing static route or overlapping subnets.
- Drops after a while — upstream firewall closing UDP 500/4500; DPD will restart the tunnel, but fix the firewall to stop the churn.