Cisco ASA Site-to-Site VPN Best Practices (2026 Update)
If you are deploying a site-to-site VPN on Cisco ASA in 2026, the first design decision is not IKEv1 versus IKEv2. It is whether the tunnel should be policy-based or route-based.
Both models can be secure when configured properly, but they solve different problems. Policy-based VPNs are still common for straightforward site-to-site connections. Route-based VPNs are usually the better choice when you need simpler routing, cloud connectivity, or a design that can grow without turning the crypto map into a maintenance problem.
For both models, the modern baseline is the same: use IKEv2, prefer AES-GCM-256, use ECDH groups 19, 20, or 21, and keep group 14 only as a compatibility fallback.
Modern Crypto Baseline
| Setting | Preferred | Fallback | Notes |
|---|---|---|---|
| IKE Version | IKEv2 | IKEv1 only if required | Use IKEv2 for all new deployments. |
| Encryption | AES-GCM-256 | AES-256 | Use AES-GCM first. Keep AES-256 for compatibility where needed. |
| Integrity | null | SHA-384 / SHA-256 | AES-GCM includes authentication, so integrity is null there. |
| PRF | SHA-512 / SHA-384 / SHA-256 | SHA-384 / SHA-256 | List strongest to weakest. |
| DH Group | 21 / 20 / 19 | 14 | Prefer ECDH. Keep group 14 only for compatibility. |
| PFS | Enabled | Enabled | Use group 19, 20, or 21 where possible. |
| IKE Lifetime | 86400 | 86400 | 24 hours remains standard. |
| IPsec Lifetime | 3600 | 3600 | 1 hour remains common. |
Policy-Based VPN
A policy-based VPN is the classic ASA model built around a crypto map and an ACL that defines interesting traffic.
This is still a valid design when the tunnel is simple, the local and remote subnets are static, and you do not need dynamic routing over the VPN.
When Policy-Based VPN Makes Sense
- One or a few static local and remote networks
- Traditional ASA-to-ASA or ASA-to-third-party site-to-site VPNs
- No requirement for dynamic routing across the tunnel
- You want a familiar, widely supported design
Policy-Based VPN Baseline
| Component | Recommended Setting | Notes |
|---|---|---|
| IKE Policy | IKEv2 with AES-GCM-256 | Prefer ECDH groups 21, 20, 19. |
| Traffic Selection | Crypto ACL | Explicitly defines protected subnets. |
| Deployment Model | Crypto Map | Attached to the outside interface. |
| Best Use Case | Simple static site-to-site VPN | Lower operational complexity for small deployments. |
Policy-Based VPN Example
Interesting Traffic ACL
access-list VPN-TRAFFIC extended permit ip 10.10.10.0 255.255.255.0 10.20.20.0 255.255.255.0
IKEv2 Policy
crypto ikev2 policy 10 encryption aes-gcm-256 integrity null group 21 20 19 prf sha512 sha384 sha256 lifetime seconds 86400
IPsec Proposal
crypto ipsec ikev2 ipsec-proposal ESP-AES-GCM-256 protocol esp encryption aes-gcm-256 protocol esp integrity null
Crypto Map
crypto map outside_map 10 match address VPN-TRAFFIC crypto map outside_map 10 set peer 203.0.113.10 crypto map outside_map 10 set ikev2 ipsec-proposal ESP-AES-GCM-256 crypto map outside_map 10 set security-association lifetime seconds 3600 crypto map outside_map 10 set pfs group19 crypto map outside_map interface outside
Tunnel Group
tunnel-group 203.0.113.10 type ipsec-l2l tunnel-group 203.0.113.10 ipsec-attributes ikev2 remote-authentication pre-shared-key YOUR_SHARED_SECRET ikev2 local-authentication pre-shared-key YOUR_SHARED_SECRET
Route-Based VPN
A route-based VPN uses a Virtual Tunnel Interface instead of relying on a crypto ACL to identify traffic. This is usually the better design when you need cleaner routing, cloud connectivity, or the ability to scale the tunnel design without repeatedly editing crypto ACLs.
When Route-Based VPN Makes Sense
- Multiple local or remote networks
- Dynamic routing over the tunnel
- Cloud connectivity such as AWS or Azure patterns
- Designs expected to grow over time
- You want routing decisions separated from crypto policy logic
Route-Based VPN Baseline
| Component | Recommended Setting | Notes |
|---|---|---|
| IKE Policy | IKEv2 with AES-GCM-256 | Same crypto baseline as policy-based. |
| Traffic Selection | Routing table | Traffic is routed into the tunnel interface. |
| Deployment Model | VTI | Cleaner for larger or cloud-heavy designs. |
| Best Use Case | Scalable or dynamic routing environments | Usually easier to operate over time. |
Route-Based VPN Example
IKEv2 Policy
crypto ikev2 policy 10 encryption aes-gcm-256 integrity null group 21 20 19 prf sha512 sha384 sha256 lifetime seconds 86400
IPsec Proposal
crypto ipsec ikev2 ipsec-proposal ESP-AES-GCM-256 protocol esp encryption aes-gcm-256 protocol esp integrity null
IPsec Profile
crypto ipsec profile IPSEC-VTI-PROFILE set ikev2 ipsec-proposal ESP-AES-GCM-256 set pfs group19 set security-association lifetime seconds 3600
Tunnel Interface
interface Tunnel10 nameif AWS-VTI ip address 169.254.10.1 255.255.255.252 tunnel source interface outside tunnel destination 203.0.113.10 tunnel mode ipsec ipv4 tunnel protection ipsec profile IPSEC-VTI-PROFILE
Tunnel Group
tunnel-group 203.0.113.10 type ipsec-l2l tunnel-group 203.0.113.10 ipsec-attributes ikev2 remote-authentication pre-shared-key YOUR_SHARED_SECRET ikev2 local-authentication pre-shared-key YOUR_SHARED_SECRET
Static Route Example
route AWS-VTI 10.20.20.0 255.255.255.0 169.254.10.2
Policy-Based vs Route-Based
| Feature | Policy-Based | Route-Based |
|---|---|---|
| Traffic Selection | Crypto ACL | Routing table |
| Primary ASA Construct | Crypto Map | Tunnel Interface (VTI) |
| Best For | Simple static site-to-site tunnels | Scalable and routed designs |
| Operational Complexity | Lower at small scale | Lower at larger scale |
| Dynamic Routing | Limited / awkward | Natural fit |
| Cloud VPN Patterns | Less flexible | Usually preferred |
Final Recommendation
If you just need a straightforward tunnel between two static sites, policy-based VPN is still perfectly valid. If you expect the design to grow, need cleaner routing, or are integrating with cloud environments, route-based VPN is usually the better long-term choice.
Either way, the crypto guidance is the same: use IKEv2, prefer AES-GCM-256, use ECDH groups 19 through 21, enable PFS, and stop carrying old DH5 and SHA-1 defaults forward into new deployments.