Build a route-based IKEv2 tunnel between a FortiGate firewall and a VPNGeek gateway — phase 1, phase 2, routing, and firewall policy, end to end.
This guide connects an office behind a FortiGate to a VPNGeek gateway with a route-based IKEv2 tunnel. When you finish, both networks reach each other over an encrypted link that survives reboots and IP changes. The steps use the FortiOS CLI because it is unambiguous, but every setting maps directly to the equivalent field under VPN > IPsec Tunnels in the GUI.
Before you start
Collect the following before you touch either side. Getting these straight now avoids the most common phase 1 and phase 2 mismatches later.
- A VPNGeek plan that includes IPsec Gateways, and admin access to the dashboard.
- Admin access to a FortiGate running FortiOS 7.2 or newer.
- A static public IP or resolvable DDNS hostname on at least one side.
- Non-overlapping subnets on each side — for example 10.20.0.0/16 at the VPNGeek side and 192.168.1.0/24 behind the FortiGate.
1. Create the tunnel in VPNGeek
In the dashboard, open Gateways > Tunnels and add a new site-to-site tunnel. Enter the FortiGate's public IP as the peer, and the local/remote subnets. The dashboard generates the values you will mirror on the FortiGate:
local_subnet: 10.20.0.0/16 # VPNGeek side
remote_subnet: 192.168.1.0/24 # FortiGate LAN
ike_version: 2
proposal: aes256-sha256 # phase 1 & 2
dh_group: 14
psk: (shown once)
2. Configure FortiGate phase 1
Create the IKEv2 phase 1 interface. The remote-gw is the VPNGeek gateway address shown in the dashboard, and the proposal must match what you saw in step 1.
edit "vpngeek-s2s"
set interface "wan1"
set ike-version 2
set peertype any
set net-device disable
set proposal aes256-sha256
set dhgrp 14
set remote-gw 198.51.100.20
set psksecret <your-psk>
next
end
3. Configure FortiGate phase 2
The phase 2 selectors decide which traffic enters the tunnel. They must mirror the subnets from step 1 exactly — src is your local LAN, dst is the VPNGeek subnet.
edit "vpngeek-s2s-p2"
set phase1name "vpngeek-s2s"
set proposal aes256-sha256
set dhgrp 14
set src-subnet 192.168.1.0 255.255.255.0
set dst-subnet 10.20.0.0 255.255.0.0
next
end
4. Add the route and firewall policy
A route-based tunnel exposes a virtual interface (vpngeek-s2s). Point the VPNGeek subnet at it, then allow traffic in both directions.
edit 0
set device "vpngeek-s2s"
set dst 10.20.0.0 255.255.0.0
next
end
config firewall policy
edit 0
set name "lan-to-vpngeek"
set srcintf "internal"
set dstintf "vpngeek-s2s"
set srcaddr "lan_subnet"
set dstaddr "vpngeek_subnet"
set action accept
set schedule "always"
set service "ALL"
next
end
5. Verify the tunnel
From the VPNGeek dashboard the tunnel should move to ESTABLISHED within about 30 seconds. Confirm from the FortiGate side that phase 1 and phase 2 are both up, then send real traffic:
diagnose vpn ike gateway list
# phase 2 SAs — look for a matching selector pair
diagnose vpn tunnel list
# prove traffic flows from the LAN side
execute ping-options source 192.168.1.1
execute ping 10.20.0.1
Troubleshooting
Stuck negotiating
Almost always a mismatched PSK, proposal, or DH group. Re-check that aes256-sha256 and dhgrp 14 match both sides.
Established but no traffic
A missing static route, a firewall policy that does not cover the subnets, or phase 2 selectors that do not mirror. Confirm all three.
Drops after several hours
Set matching key lifetimes on both peers, or enable DPD so a dead tunnel is detected and re-keyed promptly.