A vendor-neutral reference for the IKEv2 parameters every firewall needs — endpoints, PSK, IKE and ESP proposals, DH group, lifetimes, and traffic selectors — plus a checklist to map them onto any device.
Every firewall builds an IKEv2 site-to-site tunnel from the same handful of parameters — vendors just label and group them differently. This guide lists exactly what a VPNGeek gateway expects, in vendor-neutral terms, so you can map each value onto whatever device you have. Use it alongside a device-specific guide, or on its own when yours is not covered.
Before you start
Have these ready. The rest of the guide is about matching them precisely on both peers.
- A VPNGeek plan that includes IPsec Gateways, and admin access to the dashboard.
- Admin access to a firewall or router that supports IKEv2 with pre-shared-key authentication.
- A static public IP or resolvable DDNS hostname on at least one side.
- Non-overlapping subnets — for example 10.20.0.0/16 on the VPNGeek side and 192.168.40.0/24 behind your firewall.
1. Create the tunnel in VPNGeek
In the dashboard open Gateways > Tunnels and add a new site-to-site tunnel. Enter your firewall's public IP as the peer and the local/remote subnets. The dashboard returns the full parameter set — every value below is what you will reproduce on your device:
local_peer (yours): 203.0.113.90 # your firewall public IP
remote_peer (VPNGeek): 198.51.100.100 # VPNGeek gateway
# --- Authentication ---
ike_version: 2 (IKEv2)
auth_method: pre-shared-key
psk: (shown once)
local_id / remote_id: peer IP address (unless told otherwise)
# --- IKE / Phase 1 proposal ---
encryption: aes-256
integrity (hash): sha256
prf: sha256
dh_group: 14 (modp2048)
ike_lifetime: 28800 s (8h)
# --- ESP / Phase 2 proposal ---
esp_encryption: aes-256
esp_integrity: sha256
pfs_group: 14 (modp2048)
esp_lifetime: 3600 s (1h)
# --- Traffic selectors (subnets) ---
local_ts (yours): 192.168.40.0/24
remote_ts (VPNGeek): 10.20.0.0/16
2. Understand what each parameter controls
The values fall into four groups. If a tunnel fails, the failure almost always sits in one specific group, so knowing which is which speeds up diagnosis.
- Endpoints — the two public IPs (or hostnames). One side may be behind NAT if the device supports NAT-Traversal (UDP 4500).
- Authentication — the IKE version, the PSK, and the local/remote identities. A mismatch here stops phase 1 before anything else happens.
- Proposals — the encryption, integrity, PRF, and DH/PFS groups for phase 1 (IKE) and phase 2 (ESP). Both peers must offer an overlapping set.
- Traffic selectors — the local and remote subnets. These decide which traffic is encrypted and must be exact mirrors on the two sides.
3. Map the parameters onto your device
Firewalls organise these values differently, but the mapping is always one of a few shapes. Find the pattern that matches yours:
-------------------- -----------------------------------------
IKE / Phase 1 "Phase 1", "IKE policy/proposal/profile",
"ISAKMP", "ike-group"
ESP / Phase 2 "Phase 2", "IPsec proposal/transform-set",
"esp-group", "child SA"
DH group / PFS "key group", "modp2048 = group 14",
"Diffie-Hellman group"
Traffic selectors "local/remote network", "protected
networks", "proxy IDs", "encryption domain",
"interesting traffic ACL", "policy src/dst"
PSK "pre-shared key", "shared secret", "psksecret"
Tunnel model route-based (VTI/tunnel interface) OR
policy-based (selector list)
4. Routing and NAT
Two things commonly block traffic even after the SAs come up:
- Routing — on a route-based (VTI) device, add a static route sending 10.20.0.0/16 out the tunnel interface. On a policy-based device the selectors handle steering, so no route is needed.
- NAT exclusion — most firewalls masquerade LAN traffic to the internet. Add a "no-NAT" / NAT-exempt rule for traffic from your local subnet to the VPNGeek subnet, ordered above the general masquerade rule, or the source IP is rewritten and the selectors never match.
5. Firewall policy
Permit the tunnel traffic explicitly in both directions. Encrypted traffic still passes through the firewall's rule base:
allow src 192.168.40.0/24 dst 10.20.0.0/16 service any
# inbound: the VPNGeek network reaching your LAN
allow src 10.20.0.0/16 dst 192.168.40.0/24 service any
# allow IKE/ESP on the WAN if not implicit
allow udp 500, udp 4500 (NAT-T), proto ESP (50)
6. Verify and a final checklist
From the VPNGeek dashboard the tunnel should reach ESTABLISHED within about 30 seconds. Before you call it done, confirm every item:
[ ] IKE version set to 2 on both peers
[ ] PSK identical on both peers
[ ] Local/remote identities match (peer IP by default)
[ ] Phase 1 proposal: aes-256 / sha256 / DH 14 both sides
[ ] Phase 2 proposal: aes-256 / sha256 / PFS 14 both sides
[ ] Traffic selectors are exact mirrors (mask included)
[ ] Route to 10.20.0.0/16 (route-based) OR selector present
[ ] NAT-exempt rule above masquerade for tunnel traffic
[ ] Firewall rules allow traffic both directions
Troubleshooting
Phase 1 never establishes
Look at the authentication and endpoint groups first: wrong PSK, mismatched IKE version, wrong identity type, or UDP 500/4500 blocked between the peers. Enable IKE logging on your device to see the exact rejection.
Phase 1 up, phase 2 fails
A proposal or selector mismatch. Confirm the ESP algorithms and PFS group match, and that the local/remote subnets are exact mirrors of the VPNGeek side.
SAs up, but no data passes
Routing, NAT, or firewall policy. Verify the route (or selector), that a NAT-exempt rule sits above masquerade, and that rules permit the subnets in both directions.
Tunnel drops periodically
Set matching IKE and ESP lifetimes on both peers and enable DPD so a dead tunnel is detected and re-keyed rather than left hanging.