Why Your Phase 1 Never Stays Up
ISAKMP on Cisco is the part that negotiates the keying material before any encrypted traffic actually flows. Most people treat it like a checkbox. It isn't one. The tunnel either works or it sits in a permanent INIT state and you spend three hours checking policies. I recently had a site-to-site between two ISR 4300s where the peers kept flapping every 7200 seconds. The logs showed normal Phase 1 teardowns with no failure reason from either side. What turned out to be the problem was the rekey timer on the ISAKMP profile. One peer had lifetime set to 86400 and the other to 3600. They negotiated fine, but each side tried to rekey at wildly different intervals, which eventually desynchronized the SAs. I added isakmp sa lifetime 3600 under the profile on both sides and the flapping stopped. Don't rely on defaults. Verify them on both ends every time.
Unlock The Secrets Of Ipsec Isakmp On Cisco Devices A Comprehensive Guide
The core idea behind IPSec and ISAKMP is that they do two completely different jobs. ISAKMP handles the key exchange and the security association setup. IPSec handles the actual data encryption and tunneling. Confusing them in your head leads to misconfigurations like putting the encryption transform under the ISAKMP policy instead of under the crypto IPSEC transform-set. Here is the practical sequence that actually works on Cisco IOS and IOS-XE when you are configuring a site-to-site tunnel.
The Configuration, Step By Step
You start with the ISAKMP policy. This defines how Phase 1 negotiation happens. The order of the commands matters because the policy number determines priority. crypto isakmp policy 10 encryption aes-256
Get the Full Details
hash sha256 authentication pre-share group 14
lifetime 86400 Most beginners skip the lifetime or leave it at the default. The default is usually 86400 seconds, but on some platform versions it differs. If the two peers disagree on the lifetime during negotiation, the tunnel won't come up. Always set it explicitly on both sides. Next you configure the pre-shared key. This is under the isakmp key command and it applies globally unless you scope it to a peer.
crypto isakmp key MYSECRETKEY address 192.0.2.6 There is a common trap here. If you use the scoped version on one peer but the global version on the other, it still works. But if one side has the key scoped to a specific address and the other side does not have that address in its key table at all, Phase 1 will fail with a PSK mismatch. I have seen this on mergers where someone migrated one router and forgot to copy the key to the replacement. Now the crypto IPSEC transform-set. This is where the actual encryption algorithm for Phase 2 lives.
crypto ipsec transform-set MY-TSET esp-aes-256 esp-sha256-hmac Do not put the transform-set under the ISAKMP policy. They are separate objects. ISAKMP negotiates keys. The transform-set tells IPSec which encryption to use once the keys exist. Then you need a crypto ACL. This is what defines the interesting traffic. Traffic that matches the ACL gets encrypted. Everything else goes plain.
access-list 100 permit ip 10.1.0.0 0.0.255.255 10.2.0.0 0.0.255.255 The ACL range matters. A common mistake is making it too narrow and wondering why only some hosts can communicate through the tunnel. If your internal network is 10.1.0.0/16, the wildcard should cover the whole subnet, not just a single host. Finally, you apply everything to the tunnel interface or the crypto map. Here is the tunnel interface method, which is cleaner on modern IOS.
interface Tunnel10 ip address 169.254.0.1 255.255.255.252 tunnel source 203.0.113.1
tunnel destination 203.0.113.6 tunnel mode ipsec ipv4 crypto ipsec security-association lifetime seconds 3600
crypto ipsec security-association lifetime kilobytes 4608 crypto ipsec transform-set MY-TSET integrity-algorithm sha256
The kilobytes rekey threshold is often overlooked. If you have a high-throughput link and only set the seconds timer, the SA will rekey frequently but that is fine. If you set a very high kilobytes value on a low-traffic link, the SA will stay up until the timer expires, which is also fine. The problem comes when both timers are mismatched and the peers try to rekey at different points in the data stream. It rarely breaks the tunnel outright, but it causes brief blackholes during rekey.
What Actually Breaks In Production
The most common failure point is not the algorithm choice. It is the NAT traversal setup. If either peer sits behind NAT, you must enable NAT-T on both sides. On Cisco, this is automatic if you have crypto isakmp nat-traversal 20 enabled, which is the default on IOS 15.x and later. But on older builds, especially 12.4, it was sometimes disabled by default and you would see the tunnel come up on the LAN side and then drop as soon as actual traffic flowed. The fix was simply enabling nat-traversal on both endpoints and verifying with show crypto isakmp sa that the NAT-TRAV state appeared. Another thing people miss is the direction of the crypto map or tunnel interface configuration. The source and destination addresses must match reality. If your public IP changes due to a DHCP pool on the WAN interface, the tunnel will break permanently until you update the destination. I once had a branch office with a dynamic IP where the headquarters router had a static host route pointing to an old IP. The tunnel sat in INIT for two weeks. The workaround was to replace the static destination with a dynamic DNS entry and use a route-map with a tracking object so the tunnel would rebuild on IP change.
Verification Commands That Actually Matter
show crypto isakmp sa Look for ACTIVE state. If you see INIT or RESYNC, something is wrong with the policy, the key, or the NAT setup. The output shows the local and remote addresses, the proposed and negotiated transform, and the rekey timers. If the proposed and negotiated values differ, one side has a mismatched policy. show crypto ipsec sa
This shows the Phase 2 SAs. The bytes encrypted and packet counters are useful for confirming traffic is actually flowing. If Phase 1 is UP but Phase 2 shows no traffic, the crypto ACL is likely wrong. Double-check that the ACL permits the exact source and destination subnets on both sides. debug crypto isakmp Use this sparingly. It generates a lot of output. But when a tunnel refuses to come up, it is the fastest way to see exactly where the negotiation fails. Look for messages like ISAKMP INFO exchange followed by an error code. The error code tells you whether it is a policy mismatch, a key mismatch, or an authentication failure.
The Things No One Tells You About ISAKMP On Cisco
First, ISAKMP uses UDP port 500. IKEv2 uses UDP port 4500 for both the initial exchange and NAT-T encapsulation. If you are migrating from IKEv1 to IKEv2, do not assume the firewall rules will carry over automatically. You need to open port 4500 as well, not just port 500. Second, the crypto isakmp keepalive 20 command sends DPD-like packets every 20 seconds. This is valuable on links with stateful firewalls that drop idle connections. Without it, the firewall may tear down the ISAKMP SA while both routers still think the tunnel is up. The result is a tunnel that passes control traffic but fails data traffic. I add this to every tunnel that crosses a managed firewall. It adds negligible overhead and saves a lot of debugging time. Third, Cisco's implementation of ISAKMP main mode sends six messages. Aggressive mode sends three. Aggressive mode is faster but exposes the identity payload in clear text during the first exchange. Do not use aggressive mode unless you have a specific reason, such as a non-Cisco peer that only supports it. Main mode is the default for a reason.
There is also a subtle issue with multiple crypto maps on the same interface. If you have more than one map applied, the order matters. The first matching entry wins. This can cause traffic to take an unexpected path through a tunnel you did not intend. I have seen this happen when a new crypto map entry was added above an existing one without adjusting the sequence numbers. Always verify with show crypto map and check the sequence numbers. One more thing that trips people up: the difference between crypto ipsec security-association lifetime under the tunnel interface and the lifetime under the ISAKMP policy. These control different timers. The ISAKMP policy lifetime controls how long the Phase 1 SA lasts. The security-association lifetime controls how long the Phase 2 SA lasts. They do not need to match, but if they are wildly different, you will see repeated Phase 1 renegotiations that are unnecessary, or Phase 2 rekeys that happen while Phase 1 is still healthy. A reasonable ratio is Phase 1 lifetime at least four times the Phase 2 lifetime. That gives you headroom for rekey without forcing a full Phase 1 rebuild. The real takeaway is that ISAKMP on Cisco is straightforward when the fundamentals align. The problem is that fundamentals rarely align perfectly in production. Policies drift, IPs change, NAT devices appear where they were not planned, and firmware updates silently change defaults. The best approach is to document the expected state on both peers, verify it weekly with the show commands above, and treat any deviation as an active issue rather than a minor inconsistency.
