Skip to content

Cisco IOS XE

Last updated View as MarkdownAgent setup

This tutorial provides a comprehensive configuration example for establishing a secure Internet Protocol Security (IPsec) tunnel between Cisco IOS XE and Cloudflare using Post-Quantum Cryptography (PQC).

Interconnecting your Cisco IOS XE infrastructure with Cloudflare Anycast IPsec tunnels delivers a highly resilient connectivity solution with two primary benefits:

  1. Post-Quantum Encryption: Your connection is protected by ML-KEM post-quantum encryption, protecting data in transit against harvest-now, decrypt-later attacks, to provide long-term confidentiality against emerging quantum-computing threats.
  2. Anycast-Powered Resilience & Global Reach: Cloudflare's distributed Anycast IP network simplifies your architecture by allowing you to interconnect routers that are not physically co-located or directly linked. Traffic is automatically routed to the nearest optimal Cloudflare data center, providing built-in active/active path redundancy, automated failover, and high availability.

This guide covers everything required to deploy this architecture, including Virtual Tunnel Interfaces (VTIs), IKEv2 profiles utilizing quantum-safe parameters, and diagnostic validation.

Test environment

Field Value
Vendor Cisco
Model Cisco Series 8000 Router
Release IOS-XE 26.1.1
Date tested May 2026

IKE/IPsec crypto and relevant settings

Field Value
Traffic Selection Criteria Route-Based VPN
Routing Static
Redundant Tunnels Yes
Tunnel Load Balancing Active/Active
IKE Version IKEv2
Authentication Pre-Shared Key
Anti-Replay Protection Disabled
NAT Traversal (NAT-T) Validated
NAT-T Port 4500/udp
Phase 1 - DH-Group Group 20
Phase 1 - Encryption AES-256-CBC
Phase 1 - Authentication/Integrity SHA-256
Phase 2 - DH-Group Group 20
Phase 2 - Transport ESP
Phase 2 - Encryption AES-256-CBC
Post-Quantum Cryptography ML-KEM 768

Supported platforms

Support for ML-KEM is available on Cisco 8000 Series Secure Routers ↗.

Cloudflare WAN and Cisco IOS XE configuration settings

While following these steps, ensure you update any object names and IP addresses to match your environment. Aligning these elements with your actual naming conventions and network scheme ensures the configuration integrates seamlessly with your production setup. Use Find & Replace on the examples below to update names and addresses, maintaining consistency throughout.

Cloudflare WAN - Tunnel 01 of 02

Attribute Value/Address
Name (required) CF_WAN_TUN_01
Description ---
IPv4 Interface Address (required) 169.254.250.0/31
IPv6 Interface Address ---
Customer Endpoint 203.0.113.100
Cloudflare Endpoint 162.159.135.1
Tunnel health checks True
Rate Medium
Type Request
Direction Bidirectional
Target Default
Turn on replay protection False
Automatic return routing True

IKE Identity and Pre-shared Key (obtained after tunnel creation):

Attribute Value/Address
FQDN ID bf6c493d03REDACTED.ipsec.cloudflare.com
Pre-shared key Cloudflare-WAN-T1-PSK-1234!

Cloudflare WAN - Tunnel 02 of 02

Attribute Value/Address
Name (required) CF_WAN_TUN_02
Description ---
IPv4 Interface Address (required) 169.254.250.2/31
IPv6 Interface Address ---
Customer Endpoint 203.0.113.100
Cloudflare Endpoint 172.64.135.1
Tunnel health checks True
Rate Medium
Type Request
Direction Bidirectional
Target Default
Turn on replay protection False
Automatic return routing True

IKE Identity and Pre-shared Key (obtained after tunnel creation):

Attribute Value/Address
FQDN ID 0287844e9dREDACTED.ipsec.cloudflare.com
Pre-shared key Cloudflare-WAN-T2-PSK-1234!

Customer premise equipment - Cisco IOS XE

WAN Interface Tunnel 01 of 02 Tunnel 02 of 02
WAN Interface GigabitEthernet2 GigabitEthernet2
IP Address 203.0.113.100/24 203.0.113.100/24
Virtual Tunnel Interface (VTI) Tunnel 01 of 02 Tunnel 02 of 02
Tunnel interface Tunnel01 Tunnel02
IP Address 169.254.250.1/31 169.254.250.3/31
LAN Interface Tunnel 01 of 02 Tunnel 02 of 02
LAN Interface ge-0/0/1.0 ge-0/0/1.0
IP Address 192.168.125.1/24 192.168.125.1/24
Security Zone trust trust

Configuration

The process to establish IPsec tunnels on Cisco IOS XE involves the following steps:

  • Virtual Tunnel Interfaces (one per tunnel)
  • IKEv2 Proposal
  • IKEv2 Policy
  • IKEv2 Keyring (one per tunnel)
  • IKEv2 Profile (one per tunnel)
  • IKEv2 Profile with NAT-T Support (optional)
  • IPsec Profile (one per tunnel)
  • Bind IPsec Profiles to Virtual Tunnel Interfaces
  • Policy-Based Routing (recommended)
  • Health Tracking - IP SLA (recommended)

Virtual tunnel interfaces

Add one Virtual Tunnel Interface per IPsec tunnel to facilitate routing to Cloudflare.

Tunnel1

interface Tunnel1
 ip address 169.254.250.1 255.255.255.254
 ip proxy-arp
 ip mtu 1450
 ip tcp adjust-mss 1350
 tunnel source 203.0.113.100
 tunnel mode ipsec ipv4
 tunnel destination 162.159.135.1
 tunnel path-mtu-discovery

Tunnel2

interface Tunnel2
 ip address 169.254.250.3 255.255.255.254
 ip proxy-arp
 ip mtu 1450
 ip tcp adjust-mss 1350
 tunnel source 203.0.113.100
 tunnel mode ipsec ipv4
 tunnel destination 172.64.135.1
 tunnel path-mtu-discovery

IKE - Phase 1

Configure the following to facilitate IKEv2 Phase 1 negotiation:

  • IKEv2 Proposal
  • IKEv2 Policy
  • IKEv2 Keyring (one required per Cloudflare WAN IPsec tunnel)
  • IKEv2 Profile (one required per Cloudflare WAN IPsec tunnel)

IKEv2 Proposal

Define an IKEv2 Proposal as follows:

crypto ikev2 proposal CF_WAN_IKEV2_PROP
 pqc mlkem768
 encryption aes-cbc-256
 prf sha512 sha384 sha256
 group 20
 exit

IKEv2 Policy

Configure one IKEv2 Policy per tunnel:

crypto ikev2 policy CF_WAN_IKEV2_POL
 match fvrf any
 proposal CF_WAN_IKEV2_PROP
 exit

IKEv2 Keyrings

Add one keyring per tunnel:

CF_WAN_TUN_01_IKEV2_PEER
crypto ikev2 keyring CF_WAN_TUN_01_IKEV2_KEYRING
 peer CF_WAN_TUN_01_IKEV2_PEER
  address 162.159.135.1
  pre-shared-key 0 Cloudflare-WAN-T1-PSK-1234!
exit
CF_WAN_TUN_02_IKEV2_PEER
crypto ikev2 keyring CF_WAN_TUN_02_IKEV2_KEYRING
 peer CF_WAN_TUN_02_IKEV2_PEER
  address 172.64.135.1
  pre-shared-key 0 Cloudflare-WAN-T2-PSK-1234!
exit

IKEv2 Profiles

Configure one IKEv2 Profile per tunnel:

CF_WAN_TUN_01_IKEV2_PROF
crypto ikev2 profile CF_WAN_TUN_01_IKEV2_PROF
 match identity remote address 162.159.135.1 255.255.255.255
 identity local fqdn bf6c493d03REDACTED.ipsec.cloudflare.com
 authentication remote pre-share
 authentication local pre-share
 keyring local CF_WAN_TUN_01_IKEV2_KEYRING
 no config-exchange request
 exit
CF_WAN_TUN_02_IKEV2_PROF
crypto ikev2 profile CF_WAN_TUN_02_IKEV2_PROF
 match identity remote address 172.64.135.1 255.255.255.255
 identity local fqdn 0287844e9dREDACTED.ipsec.cloudflare.com
 authentication remote pre-share
 authentication local pre-share
 keyring local CF_WAN_TUN_02_IKEV2_KEYRING
 no config-exchange request
 exit

IKEv2 Profiles with NAT-T support (optional)

If the WAN interface on the Cisco IOS XE device is behind a device performing Network Address Translation (NAT), you can add nat force-encap under crypto ikev2 profile to force IKE Phase 1 to use UDP port 4500.

This is only needed when you want to force encapsulation instead of using the standard NAT-T flow, which starts on UDP port 500 and switches to UDP port 4500 after NAT is detected.

CF_WAN_TUN_01_IKEV2_PROF with NAT-T
crypto ikev2 profile CF_WAN_TUN_01_IKEV2_PROF
 match identity remote address 162.159.135.1 255.255.255.255
 identity local fqdn bf6c493d03REDACTED.ipsec.cloudflare.com
 authentication remote pre-share
 authentication local pre-share
 keyring local CF_WAN_TUN_01_IKEV2_KEYRING
 no config-exchange request
 nat force-encap
 exit
CF_WAN_TUN_02_IKEV2_PROF with NAT-T
crypto ikev2 profile CF_WAN_TUN_02_IKEV2_PROF
 match identity remote address 172.64.135.1 255.255.255.255
 identity local fqdn 0287844e9dREDACTED.ipsec.cloudflare.com
 authentication remote pre-share
 authentication local pre-share
 keyring local CF_WAN_TUN_02_IKEV2_KEYRING
 no config-exchange request
 nat force-encap
 exit

IPsec - Phase 2

IPsec Profile

Add one IPsec Profile per tunnel:

CF_WAN_TUN_01_IPSEC_PROF
crypto ipsec profile CF_WAN_TUN_01_IPSEC_PROF
 set security-association lifetime kilobytes disable
 set security-association replay disable
 set pfs group20
 set ikev2-profile CF_WAN_TUN_01_IKEV2_PROF
 exit
CF_WAN_TUN_02_IPSEC_PROF
crypto ipsec profile CF_WAN_TUN_02_IPSEC_PROF
 set security-association lifetime kilobytes disable
 set security-association replay disable
 set pfs group20
 set ikev2-profile CF_WAN_TUN_02_IKEV2_PROF
 exit

Bind IPsec profiles to tunnel interfaces

Bind the IPsec profiles to the corresponding Virtual Tunnel Interfaces to instantiate the IPsec tunnels:

Tunnel1

interface Tunnel1
 tunnel protection ipsec profile CF_WAN_TUN_01_IPSEC_PROF
 exit

Tunnel2

interface Tunnel2
 tunnel protection ipsec profile CF_WAN_TUN_02_IPSEC_PROF
 exit

Policy-Based Routing

Use this section when the router must keep its existing default route in the global routing table — for example, to preserve IPsec underlay reachability or support other non-LAN traffic. This approach lets you direct only a specific source subnet across both Cloudflare WAN tunnels while keeping the global default route unchanged.

If your deployment can use Cloudflare as the global default route, you can use a simpler design with two equal-cost static default routes in the global table. In that case, this section is not required.

In this example, the router already uses a global-table default route for IPsec underlay reachability and other non-LAN traffic. To send only traffic sourced from 192.168.125.0/24 across Tunnel1 and Tunnel2, configure Policy-Based Routing (PBR) to match that source subnet and forward the matched traffic into a dedicated VRF. Inside that VRF, configure two equal-cost static default routes — one through each tunnel. CEF then performs per-flow load sharing across both tunnels.

Create VRF as local PBR forwarding target

ip vrf CF_WAN_PBR_VRF
exit

Define equal-cost static default routes

ip route vrf CF_WAN_PBR_VRF 0.0.0.0 0.0.0.0 169.254.250.0 global track 1
ip route vrf CF_WAN_PBR_VRF 0.0.0.0 0.0.0.0 169.254.250.2 global track 2

Match traffic to steer to Cloudflare

ip access-list extended CF_WAN_PBR_ALL
 permit ip 192.168.125.0 0.0.0.255 any

Define route map to associate matched traffic to PBR VRF

route-map CF_WAN_PBR_RM permit 10
 match ip address CF_WAN_PBR_ALL
 set vrf CF_WAN_PBR_VRF
 exit

Apply route map to LAN interface

Assuming the IP address assigned to the LAN interface is 192.168.125.1/24:

interface GigabitEthernet1
 description LAN interface
 ip address 192.168.125.1 255.255.255.0
 ip policy route-map CF_WAN_PBR_RM

Configure Cisco Express Forwarding (CEF) for load sharing (universal algorithm)

Set the load-sharing algorithm to universal:

ip cef load-sharing algorithm universal

Health Tracking - IP SLA (recommended)

The PBR and VRF-based ECMP design described above installs both static default routes in CF_WAN_PBR_VRF as long as line protocol is up on the corresponding tunnel interfaces.

On Cisco IOS XE, a Virtual Tunnel Interface (VTI) remains up/up based on its tunnel source and destination configuration, not on the state of the underlying IKE/IPsec security associations. As a result, a tunnel can appear available to the routing table even when its IKE/IPsec SAs have failed. In this condition, CEF can continue to hash traffic toward the failed tunnel, which can silently drop a portion of flows.

To prevent this, configure an IP SLA icmp-echo probe for each tunnel, using the local VTI address as the source and the remote tunnel IP address as the destination. If a probe stops receiving responses, its associated track object changes to down, and the corresponding static route is removed from the VRF forwarding table.

CEF then removes that path from the ECMP set, and all matched traffic shifts to the remaining healthy tunnel. When the failed tunnel recovers, the probe succeeds, the track object returns to up, the route is reinstalled, and traffic is automatically balanced across both tunnels again.

Define IP SLA probes

Instantiate an IP SLA probe (type icmp-echo) with Tunnel1 source IP 169.254.250.1 and destination IP 169.254.250.0 - send a probe every five seconds:

ip sla 1
 icmp-echo 169.254.250.0 source-interface Tunnel1
 frequency 5
ip sla schedule 1 life forever start-time now

Instantiate an IP SLA probe (type icmp-echo) with Tunnel2 source IP 169.254.250.3 and destination IP 169.254.250.2 - send a probe every five seconds:

ip sla 2
 icmp-echo 169.254.250.2 source-interface Tunnel2
 frequency 5
ip sla schedule 2 life forever start-time now

Define track objects

The following track objects dampen short-lived packet loss to avoid route flaps on transient events:

track 1 ip sla 1 reachability
 delay down 3 up 3
track 2 ip sla 2 reachability
 delay down 3 up 3

Troubleshooting

IKEv2/IPsec diagnostics

  • Display IKE (Phase 1) Security Associations detail:
show crypto ikev2 sa detailed
 IPv4 Crypto IKEv2  SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1     203.0.113.100/500     162.159.135.1/500     none/none            READY
      Encr: AES-GCM, keysize: 256, PRF: SHA512, Hash: None, DH Grp:20, Auth sign: PSK, Auth verify: PSK
      PQC Key Exchange: ML-KEM-768
      Life/Active Time: 86400/501 sec
      CE id: 0, Session-id: 3
      Local spi: 9BEA9E397377D9BB       Remote spi: 0830302A3CD0A874
      Status Description: Negotiation done
      Local id: bf6c493d03REDACTED.ipsec.cloudflare.com
      Remote id: 162.159.135.1
      Local req msg id:  3              Remote req msg id:  0
      Local next msg id: 3              Remote next msg id: 0
      Local req queued:  3              Remote req queued:  0
      Local window:      20             Remote window:      1
      DPD configured for 0 seconds, retry 0
      IETF Std Fragmentation  enabled.
      Quantum-safe Encryption using PQC: ML-KEM-768
      Dynamic Route Update: disabled
      IETF Std Fragmentation MTU in use: 1372 bytes.
      Extended Authentication not configured.
      NAT-T is detected inside
      Cisco Trust Security SGT is disabled
      Initiator of SA : Yes
      PEER TYPE: Other
  • Clear security associations:
clear crypto session remote <peer-ip-address>

Another option to restart the IPsec tunnels is to administratively disable and re-enable the tunnel interfaces using shutdown and no shutdown:

int Tunnel1
shutdown

no shutdown
int Tunnel2
shutdown

no shutdown

Policy-based routing

  • Display Route Map details. Ensure the counters increment to confirm whether traffic matches the policy (CF_WAN_PBR_ALL):
show route-map CF_WAN_PBR_RM
route-map CF_WAN_PBR_RM, permit, sequence 10
  Match clauses:
    ip address (access-lists): CF_WAN_PBR_ALL
  Set clauses:
    vrf CF_WAN_PBR_VRF
  Policy routing matches: 12077 packets, 4639582 bytes
  • List routes in the VRF (CF_WAN_PBR_VRF):
show ip route vrf CF_WAN_PBR_VRF

Routing Table: CF_WAN_PBR_VRF
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
       n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       H - NHRP, G - NHRP registered, g - NHRP registration summary
       o - ODR, P - periodic downloaded static route, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR
       & - replicated local route overrides by connected

Gateway of last resort is 169.254.244.6 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 169.254.250.0
                [1/0] via 169.254.250.2
  • List routes matching 0.0.0.0/0 in the CEF table:
show ip cef vrf CF_WAN_PBR_VRF 0.0.0.0/0
0.0.0.0/0
  nexthop 169.254.250.0 Tunnel1
  nexthop 169.254.250.2 Tunnel2

Health tracking - IP SLA

  • Display track object state:
show track brief
Track Type        Instance                   Parameter        State Last Change
1     ip sla      1                          reachability     Up    00:15:13
2     ip sla      2                          reachability     Up    01:16:08
  • Display IP SLA statistics:
show ip sla statistics
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
        Latest RTT: 6 milliseconds
Latest operation start time: 15:23:03 CDT Mon Jun 1 2026
Latest operation return code: OK
Number of successes: 380
Number of failures: 1
Operation time to live: Forever

IPSLA operation id: 2
        Latest RTT: 6 milliseconds
Latest operation start time: 15:23:00 CDT Mon Jun 1 2026
Latest operation return code: OK
Number of successes: 376
Number of failures: 0
Operation time to live: Forever

Validate tunnel failover

To validate failover, administratively shut one tunnel interface or block ICMP across one of the tunnel paths. Within a few seconds the affected track transitions to Down, the corresponding route is removed from CF_WAN_PBR_VRF, and the remaining tunnel carries all LAN traffic. Restoring the tunnel reverses the change automatically.

References

Was this helpful?