NordVPN IKEv2/IPsec with Cisco IOS

NordVPN IKEv2/IPsec with Cisco IOS

NordVPN is one of the more popular VPN providers. However, I couldn’t find any guides online for using their IKEv2/IPsec with Cisco IOS.

This guide shows how to use EAP MSCHAP and certificate based authentication with NordVPN and IOS. I hope this helps others get their VPN running more quickly than I did.

I had to upgrade the code on my router for this to work. I have this working on a Cisco 1941 running c1900-universalk9-mz.SPA.155-3.M5.bin. On older versions (early version 15 releases) local eap authentication for IKEv2 isn’t supported.

I’d also recommend using some sort of firewall config with this too, this isn’t included in any of the configuration below. Although all traffic will be PATed to your VPN IP, obscurity isn’t security blah blah blah.

 

The VPN Bit

First, import the NordVPN public key into your configuration. The certificate configuration below is taken from the public root.der cert that can be downloaded from the NordVPN website.

https://downloads.nordvpn.com/certificates/root.der

crypto pki trustpoint NORDVPN
 enrollment terminal pem
 revocation-check none
crypto pki certificate chain NORDVPN
 certificate ca 01
  3082050A 308202F2 A0030201 02020101 300D0609 2A864886 F70D0101 0D050030 
  39310B30 09060355 04061302 50413110 300E0603 55040A13 074E6F72 6456504E 
  31183016 06035504 03130F4E 6F726456 504E2052 6F6F7420 4341301E 170D3136 
  30313031 30303030 30305A17 0D333531 32333132 33353935 395A3039 310B3009 
  06035504 06130250 41311030 0E060355 040A1307 4E6F7264 56504E31 18301606 
  03550403 130F4E6F 72645650 4E20526F 6F742043 41308202 22300D06 092A8648 
  86F70D01 01010500 0382020F 00308202 0A028202 0100C92B FC1621CA 8D05DAEA 
  6C20C5F0 0BA42F91 9A6CDCD3 76FDE405 91F4084B 582A9746 9E8EC2AC 127998D0 
  A6A89FCB 990935CF B111F581 03608390 F6822C5D 77598952 F577744D F2F4526B 
  5CCA0391 7742181A 1DBCA272 53A95C7C 4545EBF5 311DC6C1 82E64AF5 4B511D2F 
  5E2589B7 AE92FFE6 1B90302A 695FB914 790F1DA4 2C1DDE22 884EAC1D D59B9D0E 
  AB16694D 2FAB30B6 1F9E48C9 A67FE7F4 E70A4DF5 43550FE8 192C6DBB 91730395 
  B24103B2 6E98A160 E79FF208 CC63989C 5251CD01 F98D3CF7 8F5401BD 122E42E0 
  6EBD491F 871D4513 08706628 2B7315EE 30FF9080 CE7891EC E0CE2254 69970E33 
  6CC5DE5B EBC0CBD7 0CC7CD78 8A09001B FD963C3D EBDC50F1 CCD0094E 65315980 
  DFB96DBF 911CF54E 6166EC24 FFD40ED5 9F9DFEBE 89C749A5 BAB4BC82 70802898 
  306B7932 670E9EE0 567C9982 F8BE9451 84F76F45 35823099 1E078C81 1F287152 
  64D18091 E6E98477 0FA85C14 073D7107 13125FC8 EB4B4C77 3DF71BA9 B43B8DAC 
  42DFFE01 1DD8098F D1BAC595 04907FA8 D4BDE04B 4DB63F22 69E6C241 6D631C08 
  6F1A6148 2D547D97 30F41335 8A1E4BF2 5848E651 54600837 7A35EDDE 151352EF 
  781DBFF0 B79796E8 63249EBB 87B19046 15C55467 F03842C6 CD0C9E43 075852BA 
  332CD708 29FE2675 850D83DF 0CA1EFA5 F7FF90B0 E86ED3C1 7FE2DB72 1E70432F 
  6AB98DBB C5A8F45F 02F28CE9 6DA62493 2D669EFD 0E2F0203 010001A3 1D301B30 
  0C060355 1D130405 30030101 FF300B06 03551D0F 04040302 0106300D 06092A86 
  4886F70D 01010D05 00038202 0100BD7D 42F6B193 F120DDA6 0F7D9578 DC924E06 
  65084755 9A5AB8EF 5A3F6C33 0FE01F20 9D07AC15 1B576366 428ECE74 266EF707 
  62D588BF 6A951126 23ABC4E4 80BC22C4 41252578 71ED5663 1C97AE8E 6B99583F 
  93A6B5D2 B96C6CAF DE83FFC6 1E82710D D5C33A89 0B5129F1 B7B824DD 02A95FA7 
  82761EBB A743EE5A 6FFB5942 50C47D92 0F1B13F6 F07F899A E24C811E FC82E839 
  017402AA 7B020342 70B70B02 66F15D09 17602092 077E55A7 4EAEF9E4 D68C6D3F 
  A724B957 5E2CB46B 70F9F034 0C9A7964 95787AA2 792EAC4C 958BC467 FA8A4C47 
  6809E697 BF640498 DE9D56A8 C3A13028 934B79BB 86115F31 1509F5C0 0B7A1CA6 
  535DB420 3BDB08C5 25C49B7E 27F80520 BC6C3002 4D7B673C 2EE70F45 677592E9 
  F9188D2D E8843619 34A130BE 51575273 E9F69C93 B39022B4 BD8BB401 DB382462 
  01EE0F08 077CF6B7 D2029AC5 AB82785D 35D70E7B 5E418A77 2B180F1A BD0D5C59 
  7B1F20A1 236EB9C4 B8493D6F 98DE97A3 5F1ED3CA A0773D98 3A5174D3 C849E55A 
  C0304CD6 62428677 87B79F4D 87C19A87 BE3E4CCD 6306CC38 7E124FBE 873B02D7 
  20EF8D09 12B6FDD3 89997E42 049A88C2 54F8411D 543D2C70 4074CF2A 148DA444 
  AD08CA73 A601985E C653FF69 3FE4A44B 043F2699 4259C19F 7027D424 73F21D12 
  3C0A4BF0 FCAD8206 0A790991 865E3DF7 EEA32F17 19D887A0 2DFAAAE3 5773223C 
  07C13329 960FB5A4 A20E5688 E958
    quit

Now the crypto config. For match identity remote any you could also match on the FQDN of the specific NordVPN server. The benefit of the any keyword is that the only configuration that needs to be amended to move to a different server is the destination under the tunnel interface configuration.

crypto ikev2 profile NORD-USA
 match identity remote any
 authentication local eap mschapv2 username <nordvpn email address> password <nordvpn password>
 authentication remote rsa-sig
 pki trustpoint NORDVPN verify

crypto ipsec transform-set NORDVPN esp-aes 256 esp-sha-hmac 
 mode tunnel

crypto ipsec profile NORDVPN
 set transform-set NORDVPN 
 set ikev2-profile NORD-USA

Configure a tunnel interface and reference the IPsec profile. Your MTU and TCP MSS may change depending on the MTU of the Internet link. The below currently works for a 1500 byte WAN MTU.

interface Tunnel1
 ip address negotiated
 ip mtu 1438
 ip nat outside
 ip virtual-reassembly in
 ip tcp adjust-mss 1398
 tunnel source <wan interface>
 tunnel mode ipsec ipv4
 tunnel destination <nordvpn server ip>
 tunnel protection ipsec profile NORDVPN

 

How I’m Using it with NAT and PBR

I may look to revise this to use VRF Lite, but at the moment policy based routing is being used.

I have a “VPN” SSID on my AP, which drops into VLAN 30 on my LAN and is picked up on my router. PBR is used to push traffic over the VPN. The interface is marked as a nat inside interface.

interface GigabitEthernet0/1.30
 encapsulation dot1Q 30
 ip address 192.168.8.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 ip policy route-map NORDVPN-TRAFFIC

PBR is configured as follows. The ACL is present so that the same route map can be used on other interfaces and specific IPs can be pushed over the VPN.

ip access-list extended NORDVPN-TRAFFIC
 permit ip 192.168.8.0 0.0.0.255 any

route-map NORDVPN-TRAFFIC permit 10
 match ip address NORDVPN-TRAFFIC
 set interface Tunnel1

NAT also uses route maps so that the PAT address used is based on the egress interface. In the Tunnel1 interface configuration in the VPN section, you can see Tunnel 1 is an outside interface.

ip access-list standard NAT
 permit <inside and inside VPN LAN IPs> <wildcard mask>

route-map NORD-NAT permit 10
 match ip address NAT
 match interface Tunnel1

route-map INTERNET-NAT permit 10
 match ip address NAT
 match interface <wan interface>

ip nat inside source route-map NORD-NAT interface Tunnel1 overload
ip nat inside source route-map INTERNET-NAT interface <wan interface> overload

43 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?

    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.

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

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

    thanks

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

    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.

  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.

    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?

      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

      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.

  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

    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

  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

    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

      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”.

  8. 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:

  9. Hi,

    I’m sorry Adam, only just noticed the request. Way too late of course.

    I have packed up my config and the relevant scripting I did to get the recommended nordvpn servers and put it on my website. This should allow you to automatically select the recommended servers directly from the router (and in the background).

    https://www.reverze.net/nordvpn.tar

    The only thing I’m still noticing is that virtual-fragmentation kicks in every now and then, when receiving packets from NordVPN which seem to be fragmented
    IP_VFR: fragment 0x3E59C180 (sa:178.239.173.159, da:MASKED, id:46986, offset:0, len:1464) in fast path…
    IP_VFR: fragment 0x3E59C180 (sa:178.239.173.159, da:MASKED, id:46986, offset:1464, len:12) in fast path…

    Any thoughts on this would be welcome, as I think I have my MTUs sorted.

    Cheers,

    Michel

  10. I’m sorry Adam, only just noticed the request. Way too late of course.

    I have packed up my config and the relevant scripting I did to get the recommended nordvpn servers and put it on my website. This should allow you to automatically select the recommended servers directly from the router (and in the background).

    https://www.reverze.net/nordvpn.tar

    The only thing I’m still noticing is that virtual-fragmentation kicks in every now and then, when receiving packets from NordVPN which seem to be fragmented
    IP_VFR: fragment 0x3E59C180 (sa:178.239.173.159, da:MASKED, id:46986, offset:0, len:1464) in fast path…
    IP_VFR: fragment 0x3E59C180 (sa:178.239.173.159, da:MASKED, id:46986, offset:1464, len:12) in fast path…

    Any thoughts on this would be welcome, as I think I have my MTUs sorted.

    Cheers,

    Michel

  11. Hi, I’m following your post but I’m struggling to understand what’s going wrong.
    What do you suggest to debug the configuration?
    Also, do you know what is the minimum IOS version required? I’ve got 15.4(3)M6a but not sure if that’s enough for local eap authentication for IKEv2 (how can I check)?

    Thanks

    1. Hi Fabio

      I had problems with earlier versions of IOS, but don’t know the exact version where local eap is supported. 15.5(3)M5 worked fine for me at the time of writing this article.

      I’d start by checking that all of the configuration commands are being accepted.

  12. Finally got round to trying this and it worked with one change in the ikev2 profile where I had to use the fdqn

    match identity remote fqdn uk1916.nordvpn.com

    Thanks again

    1. Hi,

      I’m using IOS 15.7 here, not too sure what local eap requires for software release. Maybe the feature tool on the Cisco site can say that?

      Using the fqhn will work so long as you don’t change servers with some regularity. If you do, matching on nordvpn.com may be better.

      On the VFR messages-
      It seems that NordVPN is using a fixed MTU of 1500 bytes at their end. This is fine in most cases, but since my ISP uses PPPoEoVLAN I lose about 12 bytes in overhead. Enough to cause packets from NordVPN to be fragmented on their way to my router and significantly increase the CPU load.
      I spent over a month debugging this with them, and their solution involved tweaking ip virtual-fragmentation on the interface. Since it’s a detector, that is not a solution, rather a way to circumvent the actual problem- they cannot support varying MTUs on their end. It’s almost like StrongSWAN, which suffers the same drawback (possibly they use this).

  13. i have the vpn on now i have to let all the traffic go on the vpn but i don’t know how to do it can you help me?

  14. i have the vpn on now i have to let all the traffic go on the vpn but i don’t know how to do it can you help me?

    1. Hello Mario,

      either configure a route-map to policy route all traffic from the LAN Eth interface (typically gig0/0 or 0/1) to use the VPN by setting
      access-list 10 permit any
      route-map default 10 permit
      match ip address 10
      set interface TunnelX

      OR, better, put your TunnelX and Gig0/1 in the same VRF, such that the default route for that VRF is via the tunnel

      Check my example configs.

      Regards,

      Michel

      1. I put tunnel and lan in the same vrf but I don’t go on the internet there is no return traffic someone can help me I can pay for the remote session thanks

      2. I put tunnel and lan in the same vrf but I don’t go on the internet there is no return traffic someone can help me I can pay for the remote session thanks

      3. I put tunnel and lan in the same vrf but I don’t go on the internet there is no return traffic someone can help me I can pay for the remote session thanks

  15. Hey, Thanks for the blog post – it’s been a lifesaver! One note as I’ve got bitten by EAP authentication twice. When you say “NordVPN username and password” you might want to specify that those are the service credentials (under “advanced configuration” on https://my.nordaccount.com/dashboard/nordvpn/) and no the standard user/pass to access the web account.

    One question still remains for me – I’m not all familiar with route-maps and NAT and although my tunnel is up, I can’t seem to get the nat right. Where can I learn more about this? Official Cisco documentation is overwhelming on the topic since route-maps can be used in multiple places. All I really want is some docs on best practices for configuring a home/branch router with VDSL access. Any suggestions?

      1. Thank you, I think I’m getting the hang of this now.
        I’ve applied your configuration from the tar file and it all works except for one little thing: the protocol goes down on the interface when the phase2 lifetime has expired. It doesn’t come back up unless I do a shut/no shut on the tunnel interface.
        I get a few SA NULL messages and an ambiguous “Peer index node NULL for peer index 0 when corresponding flow id 0x3400001C was completed”.
        Any idea what can be wrong? I’m using exactly your configuration on the IPsec side so I’m really puzzled!

        1. It looks like the version of IOS I’ve got on the c1921 can’t renegotiate the sa, while IOS-XE 17 on the 4330 has no problem with it… I guess it’s a bug?

  16. Hi everyone,

    Thank to you guys i was able to make a nice config out of this post.
    To help you guys here is 2 config i made in the same equipment (Tunnel150 Canada, Tunnel151 USA in a VRF). NAT and VLAN are not include but if you need them let me know.

    Equipment: C891F-K9
    IOS: c800-universalk9-mz.SPA.158-3.M7.bin
    Internet: Cable DHCP coming on Gi8 in global table
    NOTES:
    – IP MTU and TCP adjust will be tweak for better performance (if you want a 100% working value use 1380/1320 and also adjust it on your vlan)
    – I am still working on the config to see any issue but so far it work great for the last 3 hours
    – I use nordvpn website to get both IP address (https://nordvpn.com/fr/servers/tools/) make sure to look if it support ikev2/ipsec
    !
    ! FW CONFIG MODIFY BASED ON YOUR PREFERENCE
    ip inspect name FWusa http
    ip inspect name FWusa https
    ip inspect name FWusa dns
    ip inspect name FWusa icmp
    ip inspect name FWusa isakmp
    ip inspect name FWTemp http
    ip inspect name FWTemp https
    ip inspect name FWTemp icmp
    !
    crypto pki trustpoint NORDVPN
    enrollment terminal pem
    revocation-check none
    crypto pki certificate chain NORDVPN
    certificate ca 01
    !!!!!!!!!!!
    SAME AS MATT IS INITIAL POST
    !!!!!!!!!!!
    !
    crypto ikev2 proposal NORDVPN_Proposal
    encryption aes-cbc-256
    integrity sha256
    group 14
    !
    crypto ikev2 policy NORDVPN_ikev2_Policy
    proposal NORDVPN_Proposal
    !
    crypto ikev2 profile NORDVPN_ikev2
    match identity remote any
    authentication remote rsa-sig
    authentication local eap mschapv2 username XXXXXXXXXXXXXXXXXXX password XXXXXXXXXXXXXXXXXXX ! CAREFUL THIS IS NOT YOUR USER/PASSWORD THOSE ARE AUTO GENERATED BY NORDVPN (LOGIN AND CHECK ON YOUR PROFILE)
    pki trustpoint NORDVPN verify
    !
    crypto ipsec transform-set NORDVPN_transform esp-aes 256 esp-sha-hmac
    mode tunnel
    !
    crypto ipsec profile NORDVPNca_prof
    set security-association idle-time 120
    set transform-set NORDVPN_transform
    set pfs group15
    set ikev2-profile NORDVPN_ikev2
    !
    crypto ipsec profile NORDVPNusa_prof
    set security-association idle-time 120
    set transform-set NORDVPN_transform
    set pfs group15
    set ikev2-profile NORDVPN_ikev2
    no crypto ipsec profile default
    !
    interface Tunnel150
    description NORDVPN Canada
    ip address negotiated
    ip access-group Outside in ! MAKE SURE YOU PUT SOMETHING TO PREVENT INCOMING COMMUNICATION AND PREVENT SECURITY RISK
    ip mtu 1380
    ip nat outside
    ip inspect FWTemp out ! MAKE SURE YOU HAVE A FW SETUP
    ip virtual-reassembly in
    ip tcp adjust-mss 1360
    tunnel source GigabitEthernet8
    tunnel mode ipsec ipv4
    tunnel destination 139.28.218.195
    tunnel protection ipsec profile NORDVPNca_prof
    end
    !
    interface Tunnel151
    description NORDVPN USA
    ip vrf forwarding internet_usa
    ip address negotiated
    ip access-group Outside in ! MAKE SURE YOU PUT SOMETHING TO PREVENT INCOMING COMMUNICATION AND PREVENT SECURITY RISK
    ip mtu 1380
    ip nat outside
    ip inspect FWusa out ! MAKE SURE YOU HAVE A FW SETUP
    ip virtual-reassembly in
    ip tcp adjust-mss 1360
    tunnel source GigabitEthernet8
    tunnel mode ipsec ipv4
    tunnel destination 45.14.195.100
    tunnel protection ipsec profile NORDVPNusa_prof
    end
    !
    ip route 0.0.0.0 0.0.0.0 Tunnel150 10
    ip route vrf internet_usa 0.0.0.0 0.0.0.0 Tunnel151 10
    ip route 45.14.195.100 255.255.255.255 GigabitEthernet8 dhcp 10
    ip route 139.28.218.195 255.255.255.255 GigabitEthernet8 dhcp 10
    ip route vrf internet_usa 45.14.195.100 255.255.255.255 GigabitEthernet8 dhcp 10
    !
    !
    object-group network NORDVPN_IP
    host 139.28.218.195
    host 45.14.195.100
    !
    ip access-list extended Outside

    permit icmp object-group NORDVPN_IP any echo-reply
    permit udp object-group NORDVPN_IP any eq isakmp
    permit udp object-group NORDVPN_IP any eq non500-isakmp
    deny ip any any

  17. Thank you guys i was able to make a nice config out of this post. I made 2 VPN (Canada in global vrf, USA in a standalone vrf)

    Equipment: C891F-K9
    IOS: c800-universalk9-mz.SPA.158-3.M7.bin
    Internet: Cable DHCP coming on Gi8 in global vrf

    I am still trying to figure it out the lifetime NordVPN setup on there end. At the moment i am using 8hours for phase 2.

      1. phase 1 is right with 28800
        I loose spi when i reach 3600 and get a lost connection. i already tried a 8hours phase 2 and i get the same result so i am assuming its higher than 8hours but at this point i max the phase 2 lifetime and added a little eem with a kron job (Similar to what Michel did) to force it.

        event manager applet NORDVPN_TU150_RST
        event none
        action 0010 cli command “enable”
        action 0020 cli command “conf t”
        action 0030 cli command “int tu 150”
        action 0040 cli command “shut”
        action 0050 wait 5
        action 0060 cli command “no shut”
        action 0070 cli command “no shut”
        action 0080 cli command “end”
        kron policy-list PLtunnels_schedule_RST
        cli event manager run NORDVPN_TU150_RST
        cli event manager run NORDVPN_TU151_RST
        kron occurrence Ktunnels_schedule_RST at 6:00 recurring
        policy-list PLtunnels_schedule_RST
        !

Leave a Reply

Your email address will not be published. Required fields are marked *

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