This post describes my attempts to configure SurfShark IPSec VPN with IKEv2 on a Cisco ISR.

I have previously been using Private Internet Access (PIA) in a separate VRF on a Cisco ISR, which was utilised by a separate SSID on my Meraki access point. This plan came to an end, which prompted me to look around. I ended up signing up for SurfShark's VPN service, as I got a 'deal' on their 2 year plan. One of my requirements was that I could continue the setup in use with PIA.

I noticed whilst poking around that their configuration guides mainly cover OpenVPN, but also support regular IPSec. I was confident until I saw it was all based on IKEv2, with certificate based authentication of the remote peer.

I could not find any guide showing someone having attempted this before, so naturally I was sceptical this would work at all. Here's what I ended up with:

Things you'll need

  1. SurfShark account
  2. "Service credentials" from this page
  3. Cisco ISR running IOS
  4. "IKEv2 certificate" from this page

Configuration Steps

  1. Import the SurfShark root CA

First, create a trustpoint:

crypto pki trustpoint surfshark_root
 enrollment terminal
 usage ike
 revocation-check none

Note: replace with a local SurfShark server.

Then you should enrol the certificate:

crypto pki authenticate surfshark_root

You'll be prompted to paste a base64 encoded CA certificate. The file you need is surfshark_ikve2.crt

Type quit after pasting and then yes to confirm.

2. Define a VRF

Create the VRF

vrf definition surfshark
 address-family ipv4

Define a DHCP Pool

ip dhcp pool VLAN31
 vrf surfshark
 lease infinite

Define a VLAN SVI

interface Vlan31
 vrf forwarding surfshark
 ip address
 ip nat inside
 ip virtual-reassembly in

3. IKEv2: Keyring

The keyring defines how we identify the peer(s) we're connecting with. In this case, I've specificed the local server I want to use using it's FQDN.

crypto ikev2 keyring surfshark
 peer london
  identity fqdn

4. IKEV2: Proposal

The IKEv2 proposal defines the cryptographic protocols to use:

crypto ikev2 proposal surfshark 
 encryption aes-cbc-256
 integrity sha256
 group 19

5. IKEv2: Profile

This starts to tie all the bits together.

crypto ikev2 profile surfshark
 match identity remote fqdn
 authentication remote rsa-sig
 keyring local surfshark
 pki trustpoint surfshark_root verify
 match certificate surfshark_root
 authentication local eap mschapv2 username abcdef password abcdef

6. IKEv2: Policy

crypto ikev2 policy surfshark 
 proposal surfshark

7. IPSec: Transform Set

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

8. IPSec: ACL

As I'm building a VRF and intending to NAT on the router, I built some ACLs at this point.

You may notice in the below configuration there's a hardcoded IP address. This is one of the server IPs returned from Surfshark's FQDN. I need to investigate if this is needed or if it can be removed.

ip access-list extended surfshark_local
 permit ip any
ip access-list extended surfshark_post_nat
 permit ip any
 permit udp host <!-your wan address!-> eq non500-isakmp host eq non500-isakmp

9. IPSec: Profile and crypto-map

You may notice in the below configuration there's a hardcoded IP address. This is one of the server IPs returned from Surfshark's FQDN. I need to investigate if this is needed or if it can be removed.

crypto ipsec profile surfshark
 set transform-set surfshark 
 set ikev2-profile surfshark
crypto map surfshark 10 ipsec-isakmp 
 set peer
 set transform-set surfshark 
 set pfs group19
 set ikev2-profile surfshark
 match address surfshark_post_nat

10. Build a tunnel interface

interface Tunnel31
 vrf forwarding surfshark
 ip address negotiated
 ip mtu 1400
 ip nat outside
 ip virtual-reassembly in max-reassemblies 1024
 tunnel source GigabitEthernet8
 tunnel mode ipsec ipv4
 tunnel destination
 tunnel protection ipsec profile surfshark

11. Apply the crypto map to your WAN interface

interface GigabitEthernet8
 crypto map surfshark

12. Configure NAT and add a default route

ip nat inside source list surfshark_local interface Tunnel31 vrf surfshark overload
ip route vrf surfshark Tunnel31

I think that's all you need. Try pinging firstly from the tunnel interface (which should be up and with a negotiated IP address by now) to the internet to verify the tunnel, and then from the VLAN SVI to verify the NAT and VRF.

There are some really useful debug commands that told me what error I was facing along the way. I'd recommend turning the error debugging on and reading through the logs if things arent't working.

router#debug crypto ikev2 ?
  client    Client
  cluster   IKEv2 Cluster load-balancer debugging
  error     IKEv2 Error debugging
  internal  IKEv2 Internal debugging
  packet    IKEv2 Packet debugging

Useful links

Some of the articles that were useful in figuring this out:

Importing the SurfShark root CA:

IKEv2 configuration:

SurfShark IKEv2 on MacOS:

Cisco IOS IKEv2 documentation:

More examples of IKEv2 on IOS: