HowToFixMe
Cisco Real World Problems

How to configure IPsec site to site IKEv2 PSK on ISE

By Sai Kiran Pandrala · Cisco network engineer · Last verified: 2026-06-05

Why this matters on a ISE

How do I stand up an IKEv2 PSK tunnel that survives an SP failover without a phase-2 flap? On a Identity Services Engine (ISE), the answer is rarely "copy a vendor template and ship it." The AAA + policy decision point role this box plays decides how every knob in the IPsec or IPv6 stack ought to be tuned. Get the role wrong, and even a textbook config will give you flapping SAs, prefix-delegation black holes, or RAs reaching the wrong VLAN. I've watched ESS Bengaluru chase a IPsec site-to-site IKEv2 with pre-shared keys bug for three days that boiled down to a wrong assumption about the ISE's role in the path. We'll skip that detour here.

Quick cost framing before we touch CLI: ISE Plus licence per endpoint is around ₹620 / $7.50 a year; a 3615 appliance lands near ₹11L / $13,300. That number matters because the second a SmartNet escalation comes into play, your weekend just got expensive. The procedure below keeps the work inside the box's existing entitlements.

Field story (why I wrote this guide)

A Redington partner in Comsys Mumbai called me last August because their hub-and-spoke topology on the Identity Services Engine (ISE) was dropping the IKEv2 SA every 8 hours during the lifetime rekey. Twelve branches, all GeM-funded, all critical. The PSK was 18 characters with a special ₹ symbol that vManage had silently URL-encoded, so the peer at the Chennai hub saw a different secret than the branch sent. We rotated to a 32-character ASCII-only PSK using openssl rand -base64 24, pushed it through Ingram Micro's standard change template, and the rekey settled at 86,400 seconds without a flap. Whole thing cost the customer about ₹0 in licences (the PSK swap is free) and saved a renewal-quote conversation that would have run ₹85,000 for SmartNet escalation.

Prereqs before you log in

Tools I keep on the bench

The kit hasn't changed much in two years, and I won't pretend it has just to look fancy. Putty 0.78, SecureCRT 9.4 for console, Wireshark 4.2 for IKE_SA_INIT decode, SolarWinds NCM for config baseline, Cisco DNA Center for posture. On the licensing side, Cisco DNA Center is the single source of truth when this work touches a fabric; Putty 0.78 and SecureCRT 9.4 remain the console clients I trust. For PSIRT and design references, I leave Cisco's documentation tab pinned to the model number for ISE so I'm not chasing the wrong sysguide.

Step-by-step

  1. Confirm the role. The ISE is being used as the AAA + policy decision point. If somebody else has hand-jammed it into another role, stop and fix that first.
  2. Stage a clean session. Connect via Putty 0.78 on COM3 at 9600/8/N/1 for hardware, or SecureCRT 9.4 SSH for the controllers. Enable session logging. Cisco TAC will ask for it.
  3. Snapshot pre-change state. Save the running-config, the relevant crypto / IPv6 show output, and ARP / ND tables. Tag the file with the GeM change ticket number.
  4. Push the IPsec site-to-site IKEv2 with pre-shared keys config. Use the block below. Adjust addressing and naming for the specific ISE you're touching.
  5. Verify with read-only commands. Don't move on until every verification command returns what you expect.
  6. Run a controlled traffic test. For IPsec, ping across the tunnel with explicit source. For IPv6, plug a Wireshark 4.2 capture into the LAN and watch the RA / DHCPv6 dance.
  7. Commit + close. 'write memory', export the new config to the SolarWinds NCM baseline, then re-enable compliance enforcement on Catalyst Center.

CLI block (paste-ready, then adapt)

! Keyring with a clean ASCII PSK
crypto ikev2 keyring KR-DC
 peer DC-MUM-01
  address 198.51.100.4
  pre-shared-key local  R3d1ngton-Mumbai-Hub-2026-AES256!
  pre-shared-key remote R3d1ngton-Mumbai-Hub-2026-AES256!
!
crypto ikev2 proposal PROP-AES256-SHA384
 encryption aes-cbc-256
 integrity  sha384
 group      19
!
crypto ikev2 policy POL-DC
 proposal PROP-AES256-SHA384
!
crypto ikev2 profile PROF-DC
 match identity remote address 198.51.100.4 255.255.255.255
 authentication local pre-share
 authentication remote pre-share
 keyring local KR-DC
 lifetime 28800
!
crypto ipsec transform-set TS-ESP-AES256 esp-aes 256 esp-sha384-hmac
 mode tunnel
!
crypto ipsec profile IPSEC-DC
 set transform-set TS-ESP-AES256
 set ikev2-profile PROF-DC
!
interface Tunnel20
 ip address 10.251.0.1 255.255.255.252
 tunnel source GigabitEthernet0/0/0
 tunnel destination 198.51.100.4
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC-DC

That block assumes you've already added a loopback for management, a default route or BGP-learned next-hop for the tunnel destination, and the WAN interface is up/up. If any of those is missing, everything above will silently no-op.

Verification commands

show crypto ikev2 sa
show crypto ipsec sa peer 198.51.100.4
show crypto session detail
debug crypto ikev2 error
debug crypto ikev2 packet

I keep a small text expander in SecureCRT 9.4 for this block. Saves three minutes per device and, more importantly, stops me from forgetting the 'detail' qualifier on a ISE when I'm tired.

What good logs look like

On a healthy bring-up, expect a tight sequence in syslog. Things you should see: %LINEPROTO-5-UPDOWN on the tunnel interface flipping to up, %SYS-5-CONFIG_I when you commit, and clean IKE_AUTH success messages for IPsec cases. Things that scream trouble: %CRYPTO-5-IKMP_INVAL_KEYSRC, %IKEv2-5-OSAL_DEVICE_OPEN, %CRYPTO-4-IKMP_NO_SA, or the dreaded %SPANTREE-2-RECV_PVID_ERR if you accidentally bled the new SVI into the wrong VLAN. Save the syslog to a SolarWinds / Logstash sink before the rekey timer hits 12 hours, that's when the long-tail bugs surface.

Platform quirks that catch people out

India-specific notes

Rollback plan

Two layers. First, keep a copy of the pre-change running-config in flash:/backup-pre-2026-06-05.cfg so 'configure replace' is one command away. Second, keep a printed copy of the rollback CLI on the desk; if the change kills your SSH path, the printed copy is what stops a panicked drive across town. I'll never forget the time I lost SSH to a Catalyst 9500 in a Mumbai bank vault and had to call security to escort me through three doors at 11 p.m. just to reach the console.

When to escalate to Cisco TAC

Cost tradeoffs and timing

If you're sizing the work for a SOW, my rule of thumb on a ISE: 60 minutes of engineer time for the first device, 25 minutes per device after that, plus 15 minutes per device for documentation. At a Comsys Mumbai bill rate of ₹3,800 / $46 per hour, a 20-device rollout lands around ₹38,000 / $460 in labour. Compare that with the cost of NOT doing it: a single SmartNet escalation for an after-hours sev-2 ticket is ₹85,000+, and a security-finding fine on GeM-tendered infrastructure can be several lakh. The maths favours getting it right the first time.

Frequently asked questions

How long does this take on a ISE the first time?

Plan for 60-90 minutes the first time, 25-30 minutes per subsequent device once you've cached the CLI blocks in SecureCRT 9.4. Catalyst Center workflows add 10-15 minutes per device for the deploy.

Will this affect my Cisco SmartNet warranty?

No. Pushing a supported config via the documented CLI is normal operation. SmartNet covers hardware RMA and TAC access; nothing in this procedure voids it. What WILL void coverage is a non-Cisco optic or a third-party flash card: keep those clear of the gear.

Is this safe to run in production on a ISE?

Yes, inside a maintenance window with a captured pre-change config and a tested rollback. Do not run it during business hours on a single-path box. A 10-minute SA flap during business hours can cost a tendered SLA payout.

Do I need a paid licence for this?

ISE Plus licence per endpoint is around ₹620 / $7.50 a year; a 3615 appliance lands near ₹11L / $13,300. The procedure stays inside that existing entitlement; you're not unlocking anything new. If you do hit a licence-gated feature, the running config will reject the command with %SYS-5-CONFIG_I and a hint about the missing licence, not a silent failure.

What about IPv4-only environments?

For the IPsec topics, the dual-stack notes are optional. For the IPv6 topics, this guide assumes you've already enabled ipv6 unicast-routing and have at least one upstream IPv6 path. If you don't, fix that before any of the steps above will do anything.

How often should I rotate the credentials / certs?

For PSK-based IKEv2, every 12 months is a sensible rhythm, sooner if a contractor with the secret leaves the team. For cert-based IKEv2, follow your CA's renewal cadence. usually 365 or 730 days, and stage the renewal 30 days before expiry. For DHCPv6-PD and SLAAC, there's nothing to rotate, but rebuild the documentation every 6 months because IPv6 plans drift fast.

What to read next

Reference material from production deployments. Validate against your specific Cisco TAC guidance and the running IOS XE / NX-OS release notes before applying to a regulated network.

Related guides worth a look while you sort this one out: