Octet

Build a site-to-site IKEv2 VPN with a static VTI

Cisco IOSWorking

Tasks

  1. Create an IKEv2 proposal and policy on both routers.
  2. Create a keyring and an IKEv2 profile that match the peer's public address.
  3. Create an IPsec transform set and an IPsec profile that uses the IKEv2 profile.
  4. Build Tunnel0 as a static VTI and route the remote LAN into it.
  5. Verify the IKE SA, the IPsec SAs and LAN-to-LAN reachability.

Solution

  1. 1IKEv2 proposal and policyR1
    R1 on Cisco IOS
    crypto ikev2 proposal PROP-AES256
 encryption aes-cbc-256
 integrity sha256
 group 19
!
crypto ikev2 policy POL-AES256
 proposal PROP-AES256

    The policy lists which proposals may be used. Without a match statement it applies to every local address.

  2. 2Keyring and IKEv2 profileR1
    R1 on Cisco IOS
    crypto ikev2 keyring KR-BRANCH
 peer R2
  address 203.0.113.2
  pre-shared-key Branch-Psk-7q4Lz9Xw2Rk8
!
crypto ikev2 profile IKEV2-BRANCH
 match identity remote address 203.0.113.2 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local KR-BRANCH
 dpd 10 3 on-demand

    match identity remote checks the identity the peer sends, which by default is the address of its own interface. If the peer is behind NAT, that is its private address, not the public one.

  3. 3Transform set and IPsec profileR1
    R1 on Cisco IOS
    crypto ipsec transform-set TS-AES256 esp-aes 256 esp-sha256-hmac
 mode tunnel
!
crypto ipsec profile IPSEC-BRANCH
 set transform-set TS-AES256
 set pfs group19
 set ikev2-profile IKEV2-BRANCH

    With IKEv2 the first Child SA has no DH of its own. PFS group 19 is used from the first rekey on, so a PFS mismatch shows up near the end of the default one-hour IPsec lifetime.

  4. 4Tunnel interface and routeR1
    R1 on Cisco IOS
    interface Tunnel0
 ip address 172.16.12.1 255.255.255.252
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/0/0
 tunnel mode ipsec ipv4
 tunnel destination 203.0.113.2
 tunnel protection ipsec profile IPSEC-BRANCH
!
ip route 10.2.0.0 255.255.255.0 Tunnel0

    The tunnel destination is reached through the default route on Gi0/0/0. Never let a route to 203.0.113.2 point into Tunnel0.

  5. 5Mirror configuration on the branchR2
    R2 on Cisco IOS
    crypto ikev2 proposal PROP-AES256
 encryption aes-cbc-256
 integrity sha256
 group 19
!
crypto ikev2 policy POL-AES256
 proposal PROP-AES256
!
crypto ikev2 keyring KR-HQ
 peer R1
  address 198.51.100.1
  pre-shared-key Branch-Psk-7q4Lz9Xw2Rk8
!
crypto ikev2 profile IKEV2-HQ
 match identity remote address 198.51.100.1 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local KR-HQ
 dpd 10 3 on-demand
!
crypto ipsec transform-set TS-AES256 esp-aes 256 esp-sha256-hmac
 mode tunnel
!
crypto ipsec profile IPSEC-HQ
 set transform-set TS-AES256
 set pfs group19
 set ikev2-profile IKEV2-HQ
!
interface Tunnel0
 ip address 172.16.12.2 255.255.255.252
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/0/0
 tunnel mode ipsec ipv4
 tunnel destination 198.51.100.1
 tunnel protection ipsec profile IPSEC-HQ
!
ip route 10.1.0.0 255.255.255.0 Tunnel0

    Object names are local and do not have to match the peer. The algorithms, PSK and PFS group must.

Verify

R1 output
R1# show crypto ikev2 sa
 IPv4 Crypto IKEv2  SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         198.51.100.1/500      203.0.113.2/500       none/none            READY
      Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:19, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/742 sec

 IPv6 Crypto IKEv2  SA

Status READY with the expected algorithms and group 19. Port 500 on both sides means no NAT was detected.

R1 output
R1# show crypto ipsec sa | include interface|ident|pkts encaps|pkts decaps|plaintext|Status
interface: Tunnel0
   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)
    #pkts encaps: 25, #pkts encrypt: 25, #pkts digest: 25
    #pkts decaps: 25, #pkts decrypt: 25, #pkts verify: 25
     plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0/0
        Status: ACTIVE(ACTIVE)
        Status: ACTIVE(ACTIVE)

Any-to-any selectors (a route-based tunnel), encaps and decaps both rising, and one active inbound and one active outbound SA. plaintext mtu 1438 is the largest inner packet ESP can carry on a 1500-byte path; the tunnel's ip mtu 1400 stays below it.

R1 output
R1# show crypto session
Crypto session current status

Interface: Tunnel0
Profile: IKEV2-BRANCH
Session status: UP-ACTIVE
Peer: 203.0.113.2 port 500
  Session ID: 1
  IKEv2 SA: local 198.51.100.1/500 remote 203.0.113.2/500 Active
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
        Active SAs: 2, origin: crypto map

UP-ACTIVE with 2 active SAs. UP-IDLE would mean the IKE SA is up but no IPsec SA exists.

R1 output
R1# ping 10.2.0.1 source GigabitEthernet0/0/1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.0.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 18/19/21 ms

LAN to LAN works. Run show crypto ipsec sa again and the encaps and decaps counters have grown by 5.

Mistakes people make

  • Forgetting the static route (or routing protocol) for the remote LAN. A VTI encrypts only what is routed into it.
  • A match identity remote that does not match what the peer sends, for example the public address when the peer sits behind NAT and identifies with its private address.
  • Mismatched PFS. With IKEv2 the tunnel comes up and then breaks at the first Child SA rekey.
  • Letting a routing protocol over the tunnel advertise the WAN subnets, which causes recursive routing.
  • An outside ACL that blocks UDP 500, UDP 4500 or ESP from the peer.

On other platforms

The branch side on an SRX as a route-based tunnel bound to st0.0. Security policies between the trust and vpn zones are also required.

Junos
set interfaces st0 unit 0 family inet address 172.16.12.2/30
set security ike proposal IKE-AES256 authentication-method pre-shared-keys
set security ike proposal IKE-AES256 dh-group group19
set security ike proposal IKE-AES256 authentication-algorithm sha-256
set security ike proposal IKE-AES256 encryption-algorithm aes-256-cbc
set security ike policy IKE-POL proposals IKE-AES256
set security ike policy IKE-POL pre-shared-key ascii-text "Branch-Psk-7q4Lz9Xw2Rk8"
set security ike gateway GW-HQ ike-policy IKE-POL
set security ike gateway GW-HQ address 198.51.100.1
set security ike gateway GW-HQ external-interface ge-0/0/0.0
set security ike gateway GW-HQ version v2-only
set security ipsec proposal ESP-AES256 protocol esp
set security ipsec proposal ESP-AES256 encryption-algorithm aes-256-cbc
set security ipsec proposal ESP-AES256 authentication-algorithm hmac-sha-256-128
set security ipsec policy IPSEC-POL perfect-forward-secrecy keys group19
set security ipsec policy IPSEC-POL proposals ESP-AES256
set security ipsec vpn VPN-HQ bind-interface st0.0
set security ipsec vpn VPN-HQ ike gateway GW-HQ
set security ipsec vpn VPN-HQ ike ipsec-policy IPSEC-POL
set security ipsec vpn VPN-HQ establish-tunnels immediately
set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services ike
set security zones security-zone vpn interfaces st0.0
set routing-options static route 10.1.0.0/24 next-hop st0.0

Say it in the interview

"IKEv2 needs four objects before the tunnel: a proposal for the algorithms, a policy that offers it, a keyring with the PSK per peer, and a profile that matches the peer's identity and says how both sides authenticate. Then a transform set and an IPsec profile tie ESP to that IKEv2 profile. The VTI is tunnel mode ipsec ipv4 with tunnel protection, and a route into Tunnel0 decides what gets encrypted. I verify with show crypto ikev2 sa for READY, show crypto ipsec sa for counters in both directions, and a ping sourced from the LAN."

Book 8.5 Example Systems