pfSense: site-to-site IKEv2 tunnel to a VPNGeek gateway

Connect a network behind pfSense to a VPNGeek gateway with a policy-based IKEv2 tunnel — Phase 1, Phase 2, the IPsec firewall rules, and the route that ties it together.

This guide connects a LAN behind pfSense to a VPNGeek gateway with a policy-based IKEv2 tunnel. pfSense uses strongSwan under the hood, so once Phase 1 and Phase 2 match the VPNGeek side the tunnel comes up automatically and stays up across reboots. Every step below is done in the pfSense web GUI under VPN > IPsec.

Before you start

Collect these details before you open either console. Most failed tunnels trace back to a mismatch in one of them.

A VPNGeek plan that includes IPsec Gateways, and admin access to the dashboard.
Admin access to pfSense 2.7 CE or Plus.
A static public IP or resolvable DDNS hostname on the pfSense WAN.
Non-overlapping subnets — for example 10.20.0.0/16 on the VPNGeek side and 192.168.10.0/24 behind pfSense.
The pre-shared key (or a certificate) that both peers will use.

1. Create the tunnel in VPNGeek

In the dashboard open Gateways > Tunnels and add a new site-to-site tunnel. Enter the pfSense WAN address as the peer and the local/remote subnets. The dashboard returns the parameters you will mirror on pfSense:

peer_address: 203.0.113.30 # pfSense WAN IP
gateway_address: 198.51.100.40 # VPNGeek gateway
local_subnet: 10.20.0.0/16 # VPNGeek side
remote_subnet: 192.168.10.0/24 # pfSense LAN
ike_version: 2
encryption: aes256-gcm # phase 1 & 2
hash: sha256
dh_group: 14
psk: (shown once)

Note. The pre-shared key is displayed only once. Copy it into your password manager before leaving the page — afterwards you can regenerate it but not read the original.

2. Configure Phase 1

Go to VPN > IPsec > Tunnels and click Add P1. Set the following, leaving anything not listed at its default.

Key Exchange version: IKEv2
Internet Protocol: IPv4
Interface: WAN
Remote Gateway: 198.51.100.40 (the VPNGeek gateway)
Authentication Method: Mutual PSK
My identifier: My IP address; Peer identifier: Peer IP address
Pre-Shared Key: the PSK from step 1
Encryption Algorithm: AES256-GCM, 128-bit; Key Group: 14 (2048 bit)

The equivalent lines in /var/etc/ipsec/swanctl.conf — useful for verifying what the GUI generated — look like this:

# Phase 1 (IKE SA) as generated by pfSense
version = 2
proposals = aes256gcm16-sha256-modp2048
local_addrs = 203.0.113.30
remote_addrs = 198.51.100.40
local {
auth = psk
id = 203.0.113.30
}
remote {
auth = psk
id = 198.51.100.40
}

3. Configure Phase 2

Under the Phase 1 entry click Show Phase 2 Entries, then Add P2. The selectors here decide which traffic enters the tunnel and must be the exact mirror of the VPNGeek subnets.

Mode: Tunnel IPv4
Local Network: LAN subnet — 192.168.10.0/24
Remote Network: Network 10.20.0.0/16
Protocol: ESP
Encryption: AES256-GCM 128-bit; Hash: SHA256; PFS Key Group: 14

Warning. Mismatched selectors are the top cause of "tunnel up, no traffic". The Local/Remote networks here must be the exact mirror of the local/remote subnets configured on the VPNGeek side.

4. Add the IPsec firewall rules

By default pfSense blocks traffic arriving on the tunnel. Go to Firewall > Rules > IPsec and add a rule allowing the remote VPNGeek subnet to reach your LAN. Make sure the automatic outbound NAT does not rewrite VPN traffic — on Firewall > NAT > Outbound, if you use manual/hybrid mode add a "Do not NAT" rule for the tunnel selectors.

# Firewall > Rules > IPsec tab — allow the tunnel traffic
Action: Pass
Protocol: Any
Source: 10.20.0.0/16 (VPNGeek subnet)
Destination: 192.168.10.0/24 (pfSense LAN)

# Firewall > NAT > Outbound (manual/hybrid) — do not NAT VPN traffic
Interface: WAN
Source: 192.168.10.0/24
Destination: 10.20.0.0/16
Do not NAT: checked

5. Routing

For a policy-based tunnel the Phase 2 selectors already steer matching traffic into the tunnel — no manual static route is required for the remote subnet. If you route additional internal subnets toward pfSense, add them as extra Phase 2 entries (or use a matching static route pointing at pfSense as the LAN gateway) so their traffic is also encrypted.

Note. Each extra subnet you want to carry over the tunnel needs its own Phase 2 entry on both peers. A subnet that only exists on one side's selectors will silently drop.

6. Verify the tunnel

Apply the changes, then from the VPNGeek dashboard the tunnel should reach ESTABLISHED within about 30 seconds. Confirm from the pfSense side under Status > IPsec, or from the shell:

# IKE and child SA status — look for "ESTABLISHED" / "INSTALLED"
swanctl --list-sas

# prove traffic flows from the LAN side
ping -S 192.168.10.1 10.20.0.1

# follow live negotiation if it does not come up
clog -f /var/log/ipsec.log

Troubleshooting

Stuck at "connecting" / no IKE SA

Almost always a PSK, encryption, or DH-group mismatch, or a WAN firewall blocking UDP 500/4500. Confirm aes256-gcm, sha256, and key group 14 match both peers, and that both identifiers are set to the peer IP.

SA established but no traffic

Check three things: the IPsec-tab firewall rule allows the remote subnet, an outbound NAT rule is not rewriting the VPN source, and the Phase 2 selectors mirror the VPNGeek side exactly.

Tunnel drops after a few hours

Set matching lifetimes on both peers and enable DPD (Dead Peer Detection) under Phase 1 so a dead tunnel is detected and re-keyed rather than left hanging.

Did this guide get you connected?

← PREVIOUS AWS Site-to-Site VPN: connect a VPC to a VPNGeek gateway NEXT → Android: always-on VPN and kill switch