Connect two networks end to end from the VPNGeek dashboard — create a gateway at each site, deploy the config bundle, define the tunnel, and verify traffic with the live counters.
A site-to-site tunnel joins two whole networks so that hosts on either LAN reach each other as if they shared a switch — no client software on individual machines. This guide builds that link entirely from the VPNGeek dashboard: you create a managed gateway at each site, push a signed config bundle to the appliance or VM running there, then define one tunnel object that both gateways enforce. When you finish, everything on 10.20.0.0/16 can reach 10.30.0.0/16 over an encrypted IKEv2 link that reconnects itself after reboots or IP changes.
Before you start
Line these up first — most failed first tunnels trace back to a missing item here rather than to the tunnel settings themselves.
- A VPNGeek plan that includes IPsec Gateways, and dashboard admin access.
- A VPNGeek gateway appliance or VM already installed and reachable at each site (physical appliance, or the VPNGeek image on a VM/cloud instance).
- A static public IP or resolvable DDNS hostname on at least one side. The side without one can still initiate as long as its peer is reachable.
- UDP 500 and UDP 4500 reachable from the internet to whichever side accepts connections (open them on any upstream NAT/firewall).
- Non-overlapping LAN subnets. This guide uses 10.20.0.0/16 at site A and 10.30.0.0/16 at site B.
1. Create a gateway for each site
Open Gateways > Add gateway in the dashboard and create two gateways — one per physical location. Give each a clear name and its LAN subnet so the dashboard can pre-fill selectors later. Set the public endpoint for the side that has a static address; leave the other as dynamic and it will initiate outbound.
name: hq-gw
site_subnet: 10.20.0.0/16
endpoint: 203.0.113.10 # static public IP
# Gateway B — branch office
name: branch-gw
site_subnet: 10.30.0.0/16
endpoint: dynamic # initiates outbound to hq-gw
2. Deploy the config bundle to each appliance
Each new gateway shows a Deploy panel with a one-time enrollment token. Run the bundle command on the appliance or VM at that site — it pulls the signed config, registers the device against your account, and starts the gateway service. Do this once per gateway.
vpngeek enroll --token HQ-XXXX-XXXX-XXXX
vpngeek deploy # fetches + applies the signed bundle
vpngeek status # should read: gateway ONLINE
# Run on the branch appliance/VM
vpngeek enroll --token BR-XXXX-XXXX-XXXX
vpngeek deploy
vpngeek status
3. Define the tunnel
With both gateways online, open Gateways > Tunnels > New site-to-site tunnel. Pick hq-gw as the local gateway and branch-gw as the peer. Set the local and remote subnets — these are the traffic selectors that decide what enters the tunnel — and choose the crypto proposal. VPNGeek pushes identical settings to both gateways, so there is nothing to mirror by hand.
peer_gateway: branch-gw
local_subnet: 10.20.0.0/16 # HQ LAN
remote_subnet: 10.30.0.0/16 # branch LAN
# Crypto proposal — applied to both phase 1 and phase 2
ike_version: 2 # IKEv2
encryption: aes-256
integrity: sha-256
pfs_group: 14 # DH group 14 (2048-bit MODP)
dpd: enabled # dead-peer detection re-keys a dropped link
4. Bring the tunnel up
Save the tunnel and click Bring up. The responder (HQ) begins listening; the dynamic side (branch) initiates. Within about 30 seconds the tunnel state in the dashboard should move from DOWN to ESTABLISHED. If it sticks at NEGOTIATING, jump to Troubleshooting.
vpngeek tunnel list # shows state + peer for each tunnel
vpngeek tunnel up hq-to-branch # force initiation from this side
vpngeek tunnel show hq-to-branch # phase 1 / phase 2 SA detail
5. Add static routes on each LAN router
The gateways now carry the encrypted link, but the ordinary hosts on each LAN still send remote-subnet traffic to their default gateway. Add one static route on each site's core router (or DHCP-advertised gateway) pointing the other site's subnet at the local VPNGeek gateway. Skip this only if the VPNGeek gateway already is the LAN's default route.
ip route add 10.30.0.0/16 via 10.20.0.1 # 10.20.0.1 = hq-gw LAN IP
# On the branch router — reach the HQ LAN via the branch gateway
ip route add 10.20.0.0/16 via 10.30.0.1 # 10.30.0.1 = branch-gw LAN IP
6. Verify with the live counters
Open the tunnel in the dashboard and watch the live counters — bytes in / bytes out and packet rate update every few seconds. Generate real traffic across the link and confirm both directions climb. If bytes go out but none come back, the return route or a far-side firewall is the usual culprit.
ping 10.30.0.10
# From the branch host, back to HQ
ping 10.20.0.10
# On either gateway, confirm the counters are moving
vpngeek tunnel show hq-to-branch --counters
Troubleshooting
Overlapping subnets
If both sites use the same range — the classic 192.168.1.0/24 on each end — the tunnel may come up but hosts can never tell "local" from "remote", and traffic never crosses. There is no crypto fix; you must renumber one LAN, or use VPNGeek's per-tunnel 1:1 NAT option to present each side to the other under a non-overlapping translated range.
NAT on both sides
When neither gateway has a public IP and both sit behind NAT, IKE cannot complete unless the responder is reachable. Forward UDP 500 and UDP 4500 to at least one gateway, or place that side on a public address. VPNGeek enables NAT-traversal automatically, but something on the responder side must still be reachable from the internet.
Stuck negotiating
Confirm both gateways read ONLINE in step 2, that UDP 500/4500 are open to the responder, and that the endpoint address or hostname is correct. Because VPNGeek pushes one proposal to both sides, a crypto mismatch is not possible here — so the fault is reachability, not settings.
Established but no traffic
The tunnel is up but a route is missing. Re-check the static routes in step 5 on both LAN routers, and confirm no downstream firewall drops the remote subnet. The dashboard counters will show bytes leaving but none returning.
Drops after several hours
Leave DPD enabled (step 3) so a silently dead peer is detected and the tunnel re-keys promptly instead of blackholing traffic until the next rekey interval.