IKEv2 site to site VPN, the best practice config

ikev1 is basically that one coworker still using internet explorer

if you've got a site to site vpn running ikev1 right now, it still works, sure. but it's end of life, it's built on weaker crypto assumptions, and every vendor advisory for the last several years has been quietly nudging everyone toward ikev2. this post walks through what a solid ikev2 lan to lan build looks like on cisco asa, and more importantly, why each piece matters so you can actually audit your own config instead of copy pasting something from a forum in 2014.

why ikev1 is the problem child

ikev1 has known structural weaknesses in how it handles negotiation and aggressive mode, and it's a much smaller, less flexible protocol overall. it doesn't support things like eap authentication or built in nat traversal improvements the way ikev2 does. it's also just slower to reconnect after a drop. if you're a defender responsible for a site to site tunnel, the fact that it "still works" isn't the bar. the bar is whether it's resilient and using crypto that isn't showing its age. ikev2 is the current best practice for a reason, not because it's trendy.

the ikev2 policy, your crypto foundation

this is where you set the actual math the tunnel negotiation will use. a strong baseline looks like this:

crypto ikev2 policy 10
 encryption aes-256
 integrity sha256
 group 14
 prf sha256
 lifetime seconds 86400

aes-256 is your encryption algorithm, strong and widely supported without a performance nightmare. sha-256 handles integrity checking so nobody's quietly tampering with packets in transit. dh group 14 is your diffie-hellman group for key exchange, 2048 bit, which is the realistic minimum you want in 2024 and beyond. if you see group 1, 2, or 5 anywhere in your existing config, that's a red flag worth fixing today, not next quarter.

turning ikev2 on and setting up the tunnel group

enabling it on the outside interface is step one:

crypto ikev2 enable outside

then you build a tunnel group for the peer, type ipsec-l2l, with a pre-shared key:

tunnel-group 203.0.113.5 type ipsec-l2l
tunnel-group 203.0.113.5 ipsec-attributes
 ikev2 remote-authentication pre-shared-key YourStrongKeyHere
 ikev2 local-authentication pre-shared-key YourStrongKeyHere

a quick defensive note here, pre-shared keys are fine for a lot of setups but they're only as strong as the string you actually use. "cisco123" is not a pre-shared key, it's an invitation. use something long and random, and if you're managing multiple site to site tunnels, don't reuse the same key across peers. treat it like a password because that's exactly what it is.

the ipsec proposal and crypto map, matching the policy

your ipsec proposal defines the actual encryption used on the data once the tunnel is up:

crypto ipsec ikev2 ipsec-proposal STRONG
 protocol esp encryption aes-256
 protocol esp integrity sha-256

esp is the encapsulating security payload, the part that actually wraps and encrypts your traffic. then the crypto map ties it all together, matching the peer, applying the proposal, and binding to the outside interface:

crypto map OUTSIDE_MAP 10 match address VPN-TRAFFIC
crypto map OUTSIDE_MAP 10 set peer 203.0.113.5
crypto map OUTSIDE_MAP 10 set ikev2 ipsec-proposal STRONG
crypto map OUTSIDE_MAP interface outside

one mismatch here, say your local proposal says aes-256 sha-256 but the remote peer is still offering aes-128 sha-1, and the tunnel either fails to negotiate or worse, silently falls back to the weaker option if you've left legacy proposals enabled. check both ends. this is a two party handshake, not a solo project.

the takeaway

if you're auditing your own asa right now, pull up show run crypto ikev2 and show run crypto ipsec and actually read what's in there. look for weak dh groups, sha-1, aes-128, or anything still riding on ikev1 policies. upgrading to ikev2 with strong crypto isn't a huge lift, it's mostly making deliberate choices instead of inheriting whatever config got copied forward from a decade ago. your vpn tunnel is one of the few places where your traffic is fully exposed to the internet in transit, so it's worth the twenty minutes to get it right.