HowToFixMe
Cisco Real World Problems

How to configure IPsec site to site IKEv2 cert on FMC

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

Why this matters on a FMC

How do I bring up an IKEv2 cert-based site-to-site tunnel without re-inventing the wheel each time? On a Firepower Management Center (FMC), the answer is rarely "copy a vendor template and ship it." The central manager / orchestrator 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 certificate authentication bug for three days that boiled down to a wrong assumption about the FMC's role in the path. We'll skip that detour here.

Quick cost framing before we touch CLI: FMCv VPN licence is around ₹3.4L / $4,100 a year; physical FMC 1700 lists near ₹14L / $16,800. 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)

Last March, ESS Bengaluru hauled me into a war-room call at 2 a.m. because their Firepower Management Center (FMC) refused to renegotiate an IKEv2 SA after the upstream CA rotated. The peer was a Palo Alto PA-3260 at the Chennai DR site. The tunnel had been up for 312 days, the cert hit its expiry window, and the SA died silently. Putty 0.78 showed only %CRYPTO-5-IKMP_INVAL_CERT and a stuck IKEv2 phase. We pulled a Wireshark 4.2 capture on the WAN, IKE_AUTH was returning AUTHENTICATION_FAILED because the SCEP enrolment had cached an old root. I purged crypto pki trustpoint TP-CHENNAI, re-enrolled, and the tunnel came back in 47 seconds. Bill: 1 hour of after-hours pay (₹4,500 / $54) versus a site-down outage that would have stopped 380 GeM order acknowledgements before 9 a.m.

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. OpenSSL 3.2 for CSR generation, Cisco DNA Center for posture, Putty 0.78 + SecureCRT 9.4 for console, Wireshark 4.2 for IKE_AUTH capture. 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 FMC so I'm not chasing the wrong sysguide.

Step-by-step

  1. Confirm the role. The FMC is being used as the central manager / orchestrator. 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 certificate authentication config. Use the block below. Adjust addressing and naming for the specific FMC 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)

! Trustpoint + enrolment
crypto pki trustpoint TP-DC-ROOT
 enrollment url http://scep.howtofixme.local:80/scep
 subject-name CN=site-blr01.howtofixme.local
 revocation-check crl
 rsakeypair RSA-BLR01-2048 2048
!
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 203.0.113.18 255.255.255.255
 identity local dn
 authentication local rsa-sig
 authentication remote rsa-sig
 pki trustpoint TP-DC-ROOT
!
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 Tunnel10
 ip address 10.250.0.1 255.255.255.252
 tunnel source GigabitEthernet0/0/0
 tunnel destination 203.0.113.18
 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 detail
show crypto ipsec sa peer 203.0.113.18
show crypto pki certificates TP-DC-ROOT
show crypto pki crls
show crypto session detail

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 FMC 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_CERT, %IKEv2-3-NEG_ABORT, %PKI-3-CRL_FETCH_FAIL, 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 FMC: 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 FMC 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 FMC?

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?

FMCv VPN licence is around ₹3.4L / $4,100 a year; physical FMC 1700 lists near ₹14L / $16,800. 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: