Cisco to Palo Alto IKEv2 VPN: Step-by-Step Guide

Cisco to Palo Alto IKEv2 VPN

Configuring an IKEv2 IPsec tunnel between a Cisco ISR and a Palo Alto firewall is one of those tasks that looks simple on paper but will quietly ruin an afternoon if you get the details wrong. Both platforms are capable, well-documented, and widely deployed — but their IPsec terminology, configuration structure, and default behaviours differ just enough to produce mismatches that are genuinely frustrating to debug.

This guide covers the full configuration on both sides, explains what each setting is actually doing, and gives you the exact debug commands you need when something does not work. Every troubleshooting scenario below comes from a real failure engineers hit with this exact setup.

Before You Start — What IKEv2 Requires That IKEv1 Did Not

If you have configured IKEv1 tunnels between Cisco and third-party devices, there are a few important differences with IKEv2 that catch engineers off guard.

IKEv2 is not backwards compatible with IKEv1. Both sides must explicitly use IKEv2. A Cisco ISR default crypto map configuration may attempt IKEv1 unless you explicitly specify IKEv2 in the profile.

IKEv2 uses asymmetric authentication. Each peer can authenticate differently — local and remote authentication are configured separately. This is more flexible than IKEv1 but also means there are twice as many places to misconfigure a pre-shared key.

Traffic selectors work differently. Palo Alto uses Proxy IDs to define interesting traffic. Cisco uses crypto ACLs. Both define what subnets should be encrypted, but they must mirror each other exactly — including subnet masks. A mismatch causes Phase 2 to fail even when Phase 1 comes up cleanly.

IKEv2 does not use Main Mode or Aggressive Mode. It uses IKE_SA_INIT and IKE_AUTH exchanges. When reading debug output you will see these exchange names instead of the Phase 1 / Phase 2 language from IKEv1.

Lab Topology for This Guide

[Branch — Cisco ISR]                    [HQ — Palo Alto NGFW]
WAN IP: 203.0.113.10                    WAN IP: 198.51.100.20
LAN:    10.10.10.0/24                   LAN:    10.20.20.0/24
IOS-XE 17.x                             PAN-OS 11.1.x

Tunnel goal: All traffic between 10.10.10.0/24 (Cisco side) and 10.20.20.0/24 (Palo Alto side) should be encrypted through the IKEv2 IPsec tunnel.

Part 1 — Palo Alto Configuration

The Palo Alto side is configured through the GUI. Build it in this logical order: IKE Crypto Profile → IPsec Crypto Profile → IKE Gateway → IPsec Tunnel → Tunnel Interface → Static Route → Security Policy.

Step 1 — Create an IKE Crypto Profile (Phase 1 Parameters)

Navigate to: Network → Network Profiles → IKE Crypto → Add

Note on DH group naming: Palo Alto labels groups as group2, group5, group14, group19, group20. Cisco IOS-XE calls them group 14, group 19, group 20. These refer to identical groups — the naming convention just differs between platforms. Group 14 (2048-bit MODP) is the minimum recommended for any production deployment.

Step 2 — Create an IPsec Crypto Profile (Phase 2 Parameters)

Navigate to: Network → Network Profiles → IPsec Crypto → Add

On PFS (Perfect Forward Secrecy): This is optional but strongly recommended. If PFS is enabled on Palo Alto, it must also be configured on the Cisco side (set pfs group14 in the IPsec profile). If you do not want PFS, disable it on both sides. A PFS mismatch causes Phase 2 to fail after Phase 1 succeeds cleanly — one of the more confusing failure modes you will encounter.

Step 3 — Create the IKE Gateway

Navigate to: Network → Network Profiles → IKE Gateways → Add

General tab:

Critical: Select “IKEv2 only mode” — not “IKEv1” and not “IKEv2 preferred”. Leaving it on IKEv2 preferred means Palo Alto may attempt IKEv1 with some peers, causing negotiation delays and potential fallback issues. In production, always lock it to IKEv2 only.

Advanced tab:

On Dead Peer Detection (DPD): Without DPD, if the Cisco ISR reboots or its WAN link drops, Palo Alto will not detect the failure until the IKE SA lifetime expires — potentially 8 hours later. With DPD enabled at 10s / 3 retries, the failure is detected within 30 seconds.

Step 4 — Create the IPsec Tunnel

Navigate to: Network → IPsec Tunnels → Add

General tab:

Proxy IDs tab — this is where most engineers make a mistake:

Click Add and create a Proxy ID entry:

The Local/Remote fields here are from Palo Alto’s own perspective. Local = subnets behind Palo Alto. Remote = subnets behind the Cisco ISR. This is the opposite of how Cisco’s crypto ACL is written — Cisco’s ACL has its own LAN as source and Palo Alto’s LAN as destination. The two sides are mirrors of each other, not copies.

If these do not match exactly, Phase 1 will come up successfully but Phase 2 will fail with a TS_UNACCEPTABLE (Traffic Selector Unacceptable) error. This is the single most common failure mode in Cisco-to-Palo-Alto VPN deployments.

Step 5 — Create the Tunnel Interface

Navigate to: Network → Interfaces → Tunnel → Add

Use a dedicated security zone for VPN tunnels rather than placing them in your internal zone. This gives you proper granular security policy control over what VPN-connected traffic can access.

Step 6 — Add a Static Route

Navigate to: Network → Virtual Routers → default → Static Routes → Add

Step 7 — Security Policy

Navigate to: Policies → Security → Add

Create two rules — one in each direction:

Rule 1 — Branch to HQ (traffic arriving from Cisco side):

Rule 2 — HQ to Branch (traffic originating from Palo Alto side):

Click Commit after completing all Palo Alto configuration.

Part 2 — Cisco ISR Configuration (IOS-XE)

Cisco’s IKEv2 configuration is built in layers: IKEv2 Proposal → IKEv2 Policy → IKEv2 Keyring → IKEv2 Profile → IPsec Transform Set → IPsec Profile → Tunnel Interface.

! ============================================================
! Step 1 — IKEv2 Proposal (Phase 1 encryption parameters)
! ============================================================
crypto ikev2 proposal PROP-PALO-ALTO
 encryption aes-cbc-256
 integrity sha256
 group 14
!

! ============================================================
! Step 2 — IKEv2 Policy (binds the proposal)
! ============================================================
crypto ikev2 policy POL-PALO-ALTO
 proposal PROP-PALO-ALTO
!

! ============================================================
! Step 3 — IKEv2 Keyring (stores the pre-shared key)
! ============================================================
crypto ikev2 keyring KR-PALO-ALTO
 peer PALO-ALTO-HQ
  address 198.51.100.20
  pre-shared-key YourStrongPreSharedKey123!
 !
!

! ============================================================
! Step 4 — IKEv2 Profile (ties keyring + authentication)
! ============================================================
crypto ikev2 profile PROF-PALO-ALTO
 match identity remote address 198.51.100.20 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local KR-PALO-ALTO
 lifetime 28800
 dpd 10 3 periodic
!

! ============================================================
! Step 5 — IPsec Transform Set (Phase 2 encryption)
! ============================================================
crypto ipsec transform-set TS-PALO-ALTO esp-aes 256 esp-sha256-hmac
 mode tunnel
!

! ============================================================
! Step 6 — IPsec Profile (binds transform set + IKEv2 profile)
! ============================================================
crypto ipsec profile IPSEC-PROF-PALO-ALTO
 set transform-set TS-PALO-ALTO
 set ikev2-profile PROF-PALO-ALTO
 set pfs group14
!

! ============================================================
! Step 7 — Tunnel Interface
! ============================================================
interface Tunnel0
 description IPsec to Palo Alto HQ
 ip address 169.254.0.1 255.255.255.252
 tunnel source GigabitEthernet0/0/0
 tunnel destination 198.51.100.20
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC-PROF-PALO-ALTO
!

! ============================================================
! Step 8 — Static Route over tunnel
! ============================================================
ip route 10.20.20.0 255.255.255.0 Tunnel0
!

Notes on the Cisco configuration

Keyring peer address must be exact. The address in the keyring and the match identity remote address in the IKEv2 profile must both reference Palo Alto’s WAN IP with a /32 host mask (255.255.255.255). Using a subnet here causes Cisco to match multiple peers against this profile, which creates unexpected behaviour in any multi-tunnel environment.

Lifetime must match. The lifetime 28800 in the IKEv2 profile must match the Key Lifetime in Palo Alto’s IKE Crypto Profile. Cisco is less tolerant of lifetime mismatches than Palo Alto — set them to identical values explicitly.

PFS must match on both sides. If set pfs group14 is present in the Cisco IPsec profile, Palo Alto’s IPsec Crypto Profile must also have group14 selected for PFS. Mismatch on PFS = Phase 2 failure.

Tunnel interface IP. The 169.254.0.1 address assigned to the tunnel interface is a link-local address used to keep the tunnel interface operational — it is not your interesting traffic subnet. Any /30 from the 169.254.0.0/16 range works. Palo Alto tunnel interfaces do not require an IP address but you can optionally assign one.

Verifying the Tunnel

Palo Alto Verification

Check IKE SA status from the GUI:

Network → IPsec Tunnels → Status column

Green = tunnel up. Orange = negotiating. Red = tunnel down.

Check IKE SA from CLI:

> show vpn ike-sa gateway IKE-GW-Cisco-ISR

Expected output when the tunnel is healthy:

GwName             Peer-Address    State    Algo     LifeSec
IKE-GW-Cisco-ISR   203.0.113.10   active   AES256   27143

Check IPsec SA:

> show vpn ipsec-sa tunnel IPSEC-TUN-Cisco-ISR

Check Proxy IDs negotiated:

> show vpn ipsec-sa

Look at the inner-if column and the traffic selector fields to confirm your proxy IDs were accepted.

Check tunnel traffic counters:

> show vpn flow tunnel-id <id>

Cisco ISR Verification

Check IKEv2 SA:

# show crypto ikev2 sa

Expected output when Phase 1 is up:

IPv4 Crypto IKEv2  SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         203.0.113.10/500      198.51.100.20/500      none/none            READY
      Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:14,
      Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 28800/582 sec

Check IPsec SA:

# show crypto ipsec sa peer 198.51.100.20

Watch the pkts encaps and pkts decaps counters — these must be incrementing for traffic to actually be flowing through the tunnel, not just the SA being present.

Check the tunnel interface:

# show interface Tunnel0

Should show: Tunnel0 is up, line protocol is up

Send test traffic:

# ping 10.20.20.1 source 10.10.10.1 repeat 5

Troubleshooting — Common Failures

Problem 1 — Phase 1 Won’t Come Up (IKE_SA_INIT Fails)

Symptoms: Tunnel stays down. Cisco debug shows IKEv2-ERROR: A supplied parameter is incorrect.

Most common causes:

1. Encryption / hash / DH group mismatch. Go through each parameter one by one — encryption algorithm, key size, integrity algorithm, and DH group must match exactly between the Cisco IKEv2 proposal and the Palo Alto IKE Crypto Profile.

2. Cisco defaulting to IKEv1. If you used a legacy crypto map style config alongside the IKEv2 profile, Cisco may still be sending IKEv1 proposals. Verify with:

# debug crypto ikev2 error
# debug crypto ikev2 packet

Check the IKE version field in the debug output.

3. UDP 500 or 4500 blocked. Verify that UDP 500 (IKE) and UDP 4500 (NAT-T) are permitted in both directions. On Palo Alto, check that your Security Policy allows these from the branch WAN IP to the untrust zone.

Palo Alto IKE debug:

> debug ike global on debug
> view-pcap follow yes mgmt-pcap-dump ike_debug

Problem 2 — Phase 1 Up But Phase 2 Fails (TS_UNACCEPTABLE)

Symptoms: IKE SA shows READY on Cisco, but the IPsec SA never forms. Palo Alto system logs show “ike negotiation failed.”

Cause: Traffic selector / Proxy ID mismatch. This is the most common failure mode in Cisco-to-Palo-Alto IPsec deployments.

Verify the Proxy ID configuration is a mirror image across both sides:

The subnet sizes must match exactly. If Cisco proposes 10.10.10.0/24 and Palo Alto has 10.10.10.0/23 in its Proxy ID, Phase 2 will be rejected with no negotiation possible.

Check what traffic selectors Cisco is proposing:

# debug crypto ikev2 packet

Look for TS_i (Traffic Selector Initiator) and TS_r (Traffic Selector Responder) in the output and compare them against your Palo Alto Proxy ID entries.

Problem 3 — PFS Mismatch

Symptoms: Tunnel comes up initially but fails to rekey after the Phase 2 lifetime expires. Or Phase 2 fails immediately with NO_PROPOSAL_CHOSEN.

Cause: PFS is configured on one side but not the other. The CREATE_CHILD_SA exchange (used during rekeying in IKEv2) will fail if Cisco sends a PFS KE payload and Palo Alto is not expecting one, or vice versa.

Fix: Either enable PFS group14 on both sides, or remove it from both sides. There is no middle ground here.

Problem 4 — Tunnel Is Up But Traffic Is Not Passing

Symptoms: IPsec SA shows encaps/decaps but pings fail. Or the tunnel status shows green but no traffic flows.

Check routing first:

# show ip route 10.20.20.0

This should resolve via Tunnel0. If it shows via a different interface, your static route is not matching or a more specific route is overriding it.

# (Palo Alto)
> show routing route destination 10.10.10.0/24

Check Security Policy on Palo Alto:

Palo Alto requires explicit Security Policy rules to permit traffic between zones. Even if the tunnel is up, traffic will be silently dropped without matching rules between VPN-Zone and Trust. Check the traffic logs:

Monitor → Logs → Traffic

Filter by Source Zone = VPN-Zone. Denied entries confirm a Security Policy gap.

Check for NAT interference:

If an outbound NAT rule is catching VPN traffic and translating it to the outside interface IP, the interesting traffic will no longer match the Proxy IDs and the tunnel will appear up while silently dropping traffic. On Palo Alto, add a no-NAT rule above your outbound NAT rule:

Policies → NAT → Add (position at top of ruleset)
  Source Zone:       Trust
  Destination Zone:  VPN-Zone
  Source Address:    10.20.20.0/24
  Destination Address: 10.10.10.0/24
  Translation Type:  No Source Translation

Problem 5 — Tunnel Keeps Dropping at Regular Intervals

Symptoms: Tunnel comes up, works for a period, then drops and tries to rekey. Cisco logs show ISAKMP_MANUAL_DELETE. This happens on a predictable schedule tied to the SA lifetime.

Cause: IKE SA lifetime mismatch. When the side with the shorter configured lifetime initiates rekeying, if the proposed parameters are not accepted by the peer, the SA fails to renew and the tunnel drops.

Verify IKEv2 profile lifetime on Cisco:

# show crypto ikev2 profile PROF-PALO-ALTO

Verify IKE Crypto Profile on Palo Alto:

Network → Network Profiles → IKE Crypto → IKE-Cisco-ISR

Both sides must show identical Key Lifetime values. Set them to the same explicit number — do not rely on defaults.

Problem 6 — Tunnel Only Comes Up When Palo Alto Initiates

Symptoms: Tunnel works fine when Palo Alto initiates, but fails when Cisco tries to bring it up first.

Check the IKEv2 profile match identity statement:

crypto ikev2 profile PROF-PALO-ALTO
 match identity remote address 198.51.100.20 255.255.255.255

If this match statement does not align with what Palo Alto sends as its identity, the IKEv2 profile will not be selected, the keyring will not be applied, and authentication will fail — but only when Cisco is the initiator.

Also check for half-open SA negotiation:

IKEv2-ERROR: Negotiating limit reached, deny SA request

This means Cisco has a half-open IKEv2 SA negotiation already in progress and hit the platform limit. Clear and retry:

# clear crypto ikev2 sa
# clear crypto session

Problem 7 — Cisco CERM Crypto Throughput Limit

Symptoms: Tunnel is up and traffic flows, but throughput is capped well below your WAN bandwidth. Cisco logs show:

%CERM-4-TX_BW_LIMIT: Maximum Tx Bandwidth limit of 85000 Kbps reached
for Crypto functionality with securityk9 technology package license

Cause: Cisco ISR platforms running with a base Security (securityk9) license are subject to CERM (Crypto Export Restrictions Manager), which enforces a total bidirectional IPsec throughput cap of 170 Mbps (85 Mbps per direction). This is an export control restriction built into IOS-XE, not a hardware limitation. The ISR 4000 series is also affected.

Fix: Install the HSEC-K9 (FL-4330-HSEC-K9 on ISR 4000 series) license on the router. This removes the CERM encryption throughput cap and the 225-tunnel limit. Unlike most IOS licences, HSEC is not a Right-to-Use (RTU) licence — it requires a licence key file to activate.

To check CERM status before hitting the limit:

# show platform software cerm-information

If CERM functionality: ENABLED appears in the output, the cap is active on your platform.

Security Hardening

Once the tunnel is up and passing traffic, take a few minutes to harden the configuration.

On Cisco:

! Remove any legacy IKEv1 policies if present
no crypto isakmp policy 10

! Disable IKEv1 entirely if it is not needed elsewhere
no crypto isakmp enable

On Palo Alto:

Under the IKE Gateway → Advanced tab, set the gateway to “IKEv2 only” — never “IKEv2 preferred” in production. Use a pre-shared key of at least 32 characters. Enable Dead Peer Detection on both sides.

Quick Reference — IKEv2 Parameter Cheat Sheet

FAQ

Q: The tunnel shows “active” on Palo Alto but “not connected” on Cisco — why?

This usually means Palo Alto initiated the tunnel and it came up from its perspective, but Cisco does not have a route sending traffic through the tunnel interface. From Cisco’s perspective there is no active traffic flow and the tunnel is effectively unused. Verify the static route on Cisco points to Tunnel0 and that traffic to 10.20.20.0/24 is hitting that interface.

Q: Can I run multiple IPsec tunnels from the same ISR to Palo Alto?

Yes. Create separate IKEv2 profiles with different match identity remote address statements for each peer, separate keyrings, and separate tunnel interfaces (Tunnel0, Tunnel1, etc.), each with its own IPsec profile and static route.

Q: Does Panorama affect IPsec tunnel configuration?

No. IPsec tunnel configuration is firewall-specific. Panorama can push shared IKE Crypto Profiles and IPsec Crypto Profiles as shared objects, but the IKE Gateway and IPsec Tunnel configurations are managed per device or per device group.

Q: Does Palo Alto support IKEv2 with Cisco routers using certificates instead of PSK?

Yes. On Palo Alto, set Authentication to “RSA-Sig” in the IKE Gateway and import the Cisco router’s certificate. On Cisco, replace authentication remote pre-share and authentication local pre-share with authentication remote rsa-sig and authentication local rsa-sig in the IKEv2 profile, and configure a local keypair and certificate accordingly.

Q: Do Proxy IDs behave differently in IKEv2 versus IKEv1?

Somewhat. In IKEv2 they are called traffic selectors rather than Proxy IDs and are negotiated during the CHILD_SA phase. Palo Alto is technically a route-based VPN platform and will route traffic into the tunnel based on its routing table regardless of traffic selector matching. However, Cisco as the peer operates in a policy-based mode for traffic selection, so your Proxy IDs on the Palo Alto side must still mirror Cisco’s crypto ACL exactly for the CHILD_SA negotiation to succeed.

Summary

Getting IKEv2 IPsec working between a Cisco ISR and Palo Alto comes down to three things: matching your Phase 1 and Phase 2 parameters exactly, getting your traffic selectors right, and making sure your Palo Alto Security Policy actually permits VPN traffic between zones.

The Proxy ID / traffic selector mismatch is by far the most common failure point. Get the mirroring right from the start — Palo Alto’s Local matches Cisco’s destination, Palo Alto’s Remote matches Cisco’s source — and most of the rest falls into place cleanly.

Last verified: June 2026 | Cisco IOS-XE 17.x | PAN-OS 11.1.x Bhardwaj Vishnu — Network Security Engineer

Hit an error not covered here? Use the contact page — include your Cisco debug output and Palo Alto system log and I’ll help troubleshoot.

Read Also:  Fortinet FortiASIC Architecture Deep Dive: NP7, CP9, and SP5 Processors