Cisco IOS: site-to-site IKEv2 tunnel to a VPNGeek gateway

Build a route-based IKEv2 tunnel from a Cisco IOS router to a VPNGeek gateway — IKEv2 proposal, policy, keyring and profile, an IPsec profile, and a tunnel interface with a route.

This guide connects a network behind a Cisco IOS (or IOS-XE) router to a VPNGeek gateway with a route-based IKEv2 tunnel using a Virtual Tunnel Interface (VTI). The IKEv2 CLI is modular — a proposal, a policy, a keyring, and a profile — which then binds to an IPsec profile on the tunnel interface. Once the interface is up you route traffic to it like any other link.

Before you start

Collect these before you begin configuring. On IOS the order of the crypto objects matters because each references the previous one.

A VPNGeek plan that includes IPsec Gateways, and admin access to the dashboard.
Privileged (enable) access to a router running IOS 15.x or IOS-XE 16+ with a security/crypto feature license.
A static public IP on the router's outside interface (assumed here as GigabitEthernet0/0).
Non-overlapping subnets — for example 10.20.0.0/16 on the VPNGeek side and 192.168.50.0/24 behind the router.

1. Create the tunnel in VPNGeek

In the dashboard open Gateways > Tunnels and add a new site-to-site tunnel. Enter the router's outside IP as the peer and the local/remote subnets. The dashboard returns the values to mirror in the IKEv2 proposal and IPsec transform-set:

peer_address: 203.0.113.110 # router outside IP
gateway_address: 198.51.100.120 # VPNGeek gateway
local_subnet: 10.20.0.0/16 # VPNGeek side
remote_subnet: 192.168.50.0/24 # router LAN
ike_version: 2
encryption: aes-cbc-256
integrity: sha256
prf: 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 the IKEv2 proposal and policy

The proposal lists the phase 1 algorithms; the policy binds that proposal (optionally scoped to a local address). These must match the values from step 1.

crypto ikev2 proposal VPNGEEK-PROP
encryption aes-cbc-256
integrity sha256
prf sha256
group 14

crypto ikev2 policy VPNGEEK-POL
proposal VPNGEEK-PROP

3. Configure the keyring and IKEv2 profile

The keyring holds the pre-shared key for the VPNGeek peer. The profile ties the peer identity, the keyring, and the authentication method together.

crypto ikev2 keyring VPNGEEK-KR
peer vpngeek
address 198.51.100.120
pre-shared-key <your-psk>

crypto ikev2 profile VPNGEEK-PROF
match identity remote address 198.51.100.120 255.255.255.255
identity local address 203.0.113.110
authentication remote pre-share
authentication local pre-share
keyring local VPNGEEK-KR
dpd 20 5 periodic

4. Configure the IPsec transform-set and profile

The transform-set defines phase 2 (ESP). The IPsec profile wraps it and references the IKEv2 profile, and is what the tunnel interface will use.

crypto ipsec transform-set VPNGEEK-TS esp-aes 256 esp-sha256-hmac
mode tunnel

crypto ipsec profile VPNGEEK-IPSEC
set transform-set VPNGEEK-TS
set pfs group14
set ikev2-profile VPNGEEK-PROF

5. Create the tunnel interface

A route-based tunnel uses a VTI. The tunnel source is your outside interface, the destination is the VPNGeek gateway, and the interface protects IPsec IPv4 traffic with the profile from step 4.

interface Tunnel0
ip address 169.254.20.1 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel mode ipsec ipv4
tunnel destination 198.51.100.120
tunnel protection ipsec profile VPNGEEK-IPSEC

Note. With a VTI the phase 2 selectors are any/any (0.0.0.0/0) and routing decides what enters the tunnel. If the VPNGeek side is policy-based with specific selectors, use a crypto map or set the VTI selectors to match — otherwise phase 2 will fail to negotiate.

6. Add the route and exclude VPN traffic from NAT

Point the VPNGeek subnet at the tunnel interface. If the router does PAT/NAT to the internet, exempt the VPN traffic with a route-map deny so its source is not translated.

! route the remote subnet into the tunnel
ip route 10.20.0.0 255.255.0.0 Tunnel0

! exempt VPN traffic from NAT (if PAT is configured)
ip access-list extended NAT-EXEMPT
deny ip 192.168.50.0 0.0.0.255 10.20.0.0 0.0.255.255
permit ip 192.168.50.0 0.0.0.255 any
! reference NAT-EXEMPT from your existing "ip nat inside source route-map"

Warning. If the LAN-to-VPNGeek traffic is not excluded from NAT, its source is rewritten to the router's outside address and the tunnel selectors never match. The deny line above must appear before the permit that feeds your general NAT rule.

7. Verify the tunnel

From the VPNGeek dashboard the tunnel should reach ESTABLISHED within about 30 seconds. Confirm from the router:

! phase 1 — look for state READY
show crypto ikev2 sa

! phase 2 — encaps/decaps counters should increment
show crypto ipsec sa

! tunnel interface should be up/up
show interface Tunnel0

! prove traffic flows from the LAN side
ping 10.20.0.1 source 192.168.50.1

Troubleshooting

IKEv2 SA stuck / not READY

Run debug crypto ikev2. A stuck phase 1 is almost always a PSK mismatch, a proposal mismatch (check aes-cbc-256 / sha256 / group 14), a wrong match identity, or UDP 500/4500 filtered. Confirm the keyring peer address equals the VPNGeek gateway.

Phase 1 up, IPsec SA absent

A transform-set, PFS, or selector mismatch. Confirm esp-aes 256 / esp-sha256-hmac and PFS group14, and that the VTI selector model matches the VPNGeek side (any/any VTI vs specific policy).

Interface up, no traffic

Check the static route points at Tunnel0 and that the NAT-exempt deny line precedes the general NAT permit, so LAN traffic to 10.20.0.0/16 is not translated.

Did this guide get you connected?

← PREVIOUS MTU and fragmentation over IPsec NEXT → Ubiquiti EdgeRouter: site-to-site IKEv2 tunnel to a VPNGeek gateway