18 thoughts on “NordVPN IKEv2/IPsec with Cisco IOS”

1. Interesting article. I am looking for a VPN that I can use with my Cisco router and this may be the solution.

   PS Why capitals only allowed?

   Reply

   1. I’m glad this helped. I’m a better network engineer than a website maintainer. I think it’s because I have this in my CSS… “text-transform: uppercase”. I’ll take a look.

      Reply

      1. Fixed

         Reply

2. , the tunnel goes in but when I go to apply the policy on the interface crashes the internet?

   Reply

3. , the tunnel goes in but when I go to apply the policy on the interface crashes the internet?

   thanks

   Reply

4. Hey,
   Great Howto!
   But i fail already on the first step. Could you please describe howto import the root.der?
   Thank you!

   Reply

   1. The mass of HEX below “crypto pki certificate chain NORDVPN” is the root.der. It’s already part of this config, so no need to import the file.

      Reply

5. Hey Matt,

   Just tried to get it to work with iOS 15.8 and can’t seem to get it to work;

   I get renegotiations every 60 seconds on IPSEC phase, although the IKEv2 exchange successfully completes and the tunnel comes up.

   Ping seems to work, even with large packets of 1400 bytes.

   Any ideas/suggestions? eventually the IPSEC SA renegotiations exhaust router memory space causing errors.

   Reply

   1. Perhaps debugs could help you pinpoint the cause of the renegotiating. I’ve only tried this on my IOS 15.5 1941, maybe this is a bug introduced in 15.8?

      Reply

      1. Hey Matt,

         Was out of town for a bit but the next step is to downgrade and see what that does. I’ll try 15.7 and 15.5 to see if I can pinpoint it. Will get back on this.

         Cheers

         Michel

         Reply

      2. Hey Matt,

         Tried in the same config with 15.5(3)M9 as well as 15.7(3)M4a with the same result. It does not work, multiple SA’s get inserted at the rate of about 1 / minute. I’m wondering if my IPSEC settings are wrong somehow, which would cause the router to renegotiate the IPSEC SA every minute.

         Are there any global settings done to disable multiSA support, or are there any other specific settings i may have missed? (IPSEC or IKEwise)?

         What i see that may be related, is that around every minute I get
         (debug crypto ipsec, then all possible options enabled)
         [] -> [ACL automatic]: message ACL for always up maps
         [ACL automatic]: message = ACL for always up maps
         [ACL automatic] -> [ACL automatic]: delayed (60000 msec) message ACL for always up maps

         shortly followed by another SA being inserted.

         I am using vrf, although the tunnel interface can be in the global routing table or the VRF i assign it to with the same result. I tried the PBR approach you use with the same result.

         I do have the following IKE proposal, but as IKE completes I don’t think this is the problem.
         crypto ikev2 proposal NordVPN
         encryption aes-cbc-256
         integrity sha256
         group 14

         I have the MTU on the tunnel interface set to 1380, and the MSS to 1330 because of the PPPoEoVLAN implementation my ISP uses.

         Reply

6. Slight update;
   I do have traffic working now, even with VRF and NAT.
   It seemed that an erroneous NAT configuration triggered ping working but other traffic not

   However, still getting the number of IPSEC SA’s increase by 2 every minute.

   As a suggestion, an outbound acccesslist restricting outgoing traffic to 10.0.0.0/8 > any and dropping all others will prevent the number of IPSEC SA’s increasing drastically; this happens if the IPSEC traffic selector does not match. It doesn’t solve the issue I’m seeing yet, but to be continued.

   Michel

   Reply

   1. Hi Michael,
      I have had similar problems with far too many IPSEC SA’s being created. I am finally down to one inbound and one outbound SA. I can’t pinpoint the exact fix but here are a few thing I recently added to my config.

      1. The access list you recommended on Tunnel1. Even after configuring route-maps and ZPFW I had a lot of traffic headed towards the tunnel that was not from my NATed address.
      ip access-list extended ACL_VPN_NORD_INT
      10 permit ip 10.0.0.0 0.255.255.255 any (200792 matches)
      20 permit icmp 10.0.0.0 0.255.255.255 any
      999 deny ip any any (740 matches)
      interface Tunnel1
      ip access-group ACL_VPN_NORD_INT out

      2. I enabled pfs. I though it might change the way SA negotiation is initiated. It won’t appear to be working in when you view the security association until SAs have been regenerated according to this post https://community.cisco.com/t5/vpn-and-anyconnect/pfs-shown-as-disabled-in-show-crypto-ipsec-sa-even-tough/m-p/1844350/highlight/true#M62114
      crypto ipsec profile NORDVPN
      set pfs group5

      3. I deleted the default ipsec profile to be sure I was always using the NORDVPN profile.
      no crypto ipsec profile default

      4. After the SAs were under control I added a security-association idle-time to clean up in case they got bad again.
      crypto ipsec profile NORDVPN
      set security-association idle-time 120

      Reply

7. Hey Adam,

   Thanks for the response!

   “set pfs” in the ipsec profile is what basically caused the issue to be resolved. This would be group1, there’s doubtlessly a better group to use, but at least it works now, thanks!

   Cheers,

   Michel

   Reply

   1. Hi Michael,
      Can you please post your VRF configuration? I am having difficulty bringing up my tunnel interfaces after applying the VRF configuration. I am aiming to have all VPN encapsulated traffic in a dedicated VRF and the rest of my interfaces remaining in the global VRF providing un-encapsulated WAN access.
      Adam

      Reply

      1. Figured it out. I applied the VRF in the below places. Additional VRF config would also be required for any static routes or route-maps pointing towards the tunnel1 interface. The main problem I had was IOS automatically removed the ip address when the new VRF is applied. For Tunnel1 it issues “no ip address” and will need to be changed back to “ip address negotiated” or you will not get an address from NORD.

         ip vrf VRF_VPN
         interface GigabitEthernet0/1.30
         ip vrf forwarding VRF_VPN
         ip address 192.168.8.1 255.255.255.0
         interface Tunnel1
         ip vrf forwarding VRF_VPN
         ip address negotiated
         ip nat inside source route-map NORD-NAT interface Tunnel1 VRF_VPN overload

         This VRF will show up as the as the ivrf when you issue “#show crypto ikev2 sa”. The fvrf is the ipsec encapsulated traffic and is none (global vrf) by default. These can also both be set in the ikev2 profile and checked using “#show crypto ikev2 profile”.

         Reply

8. For people who are wondering how to get the HEX:

   wget https://downloads.nordvpn.com/certificates/root.der
   xxd -pu root.der

   Reply

9. Does any else have their tunnel interface go UP and DOWN every hour when the IPSEC lifetime of 3600s expires? I expected to see new security associations be generated before the lifetime expires. This results in a 1min outage every hour. Possibly related is immediately after the tunnel is up, my router tries to negotiate a 2nd session that doesn’t receive an address from NordVPN and never result in any inbound/outbound esp sas.

   R0#debug crypto ikev2 packet
   *TIMESTAMP (just after first set of esp sas): IPSEC:(SESSION ID = 1) (key_engine) request timer fired: count = 1,
   (identity) local= A.A.A.A:0, remote= B.B.B.B:0,
   local_proxy= 0.0.0.0/0.0.0.0/256/0,
   remote_proxy= 0.0.0.0/0.0.0.0/256/0

   R0#show crypto ipsec sa
   interface: Tunnel2
   Crypto map tag: Tunnel2-head-0, local addr A.A.A.A

   protected vrf: VPN
   local ident (addr/mask/prot/port): (10.6.0.37/255.255.255.255/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer B.B.B.B port 500
   PERMIT, flags={}
   #pkts encaps: 166, #pkts encrypt: 166, #pkts digest: 166
   #pkts decaps: 125, #pkts decrypt: 125, #pkts verify: 125
   #pkts compressed: 0, #pkts decompressed: 0
   #pkts not compressed: 0, #pkts compr. failed: 0
   #pkts not decompressed: 0, #pkts decompress failed: 0
   #send errors 0, #recv errors 0

   local crypto endpt.: A.A.A.A, remote crypto endpt.: B.B.B.B
   plaintext mtu 1422, path mtu 1492, ip mtu 1492, ip mtu idb Dialer1
   current outbound spi: 0xCCDDD042(3437088834)
   PFS (Y/N): N, DH group: none

   inbound esp sas:
   spi: 0x87A38EB4(2275643060)
   transform: esp-256-aes esp-sha-hmac ,
   in use settings ={Tunnel, }
   conn id: 2252, flow_id: Onboard VPN:252, sibling_flags 80000040, crypto map: Tunnel2-head-0
   sa timing: remaining key lifetime (k/sec): (4153267/3527)
   IV size: 16 bytes
   replay detection support: Y
   Status: ACTIVE(ACTIVE)
   inbound ah sas:
   inbound pcp sas:
   outbound esp sas:
   spi: 0xCCDDD042(3437088834)
   transform: esp-256-aes esp-sha-hmac ,
   in use settings ={Tunnel, }
   conn id: 2251, flow_id: Onboard VPN:251, sibling_flags 80000040, crypto map: Tunnel2-head-0
   sa timing: remaining key lifetime (k/sec): (4153266/3527)
   IV size: 16 bytes
   replay detection support: Y
   Status: ACTIVE(ACTIVE)
   outbound ah sas:
   outbound pcp sas:

   protected vrf: VPN
   local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer B.B.B.B port 500
   PERMIT, flags={origin_is_acl,}
   #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
   #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
   #pkts compressed: 0, #pkts decompressed: 0
   #pkts not compressed: 0, #pkts compr. failed: 0
   #pkts not decompressed: 0, #pkts decompress failed: 0
   #send errors 0, #recv errors 0

   local crypto endpt.: A.A.A.A, remote crypto endpt.: B.B.B.B
   plaintext mtu 1492, path mtu 1492, ip mtu 1492, ip mtu idb Dialer1
   current outbound spi: 0x0(0)
   PFS (Y/N): N, DH group: none

   inbound esp sas:
   inbound ah sas:
   inbound pcp sas:
   outbound esp sas:
   outbound ah sas:
   outbound pcp sas:

   Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.