AdvancedNetwork Configuration 10 min read

How to Configure an IPsec Site-to-Site VPN on Cisco IOS

Configure a production-ready IPsec VPN tunnel on Cisco IOS step by step.

IPsec site-to-site VPNs are a cornerstone of secure enterprise WAN connectivity. This guide walks through configuring a tunnel between two Cisco IOS routers using IKEv2 and IPsec. You will define ISAKMP policies, configure pre-shared keys, set up IPsec transform sets, create crypto maps, and apply them to physical interfaces. Each step includes real CLI commands and verification outputs. This configuration is directly relevant to the CCNA (200-301) and ENCOR (350-401) exams, where VPN technologies are tested in the 'Network Access' and 'Security' domains. By the end, you will have a fully functional encrypted tunnel carrying traffic between two private subnets.

1

Define IKEv2 Proposal and Policy

Start by configuring the IKEv2 proposal and policy on both routers. The proposal defines encryption (AES-256), integrity (SHA-256), and DH group (14). The policy binds the proposal and sets the authentication method to pre-shared key. This matches modern security standards required for ENCOR and CISSP.

Cisco IOS
crypto ikev2 proposal IKEV2-PROPOSAL
 encryption aes-cbc-256
 integrity sha256
 group 14
!
crypto ikev2 policy IKEV2-POLICY
 proposal IKEV2-PROPOSAL
!

Use DH group 14 or higher for forward secrecy. Avoid group 1 or 2 in production.

Ensure both routers use identical IKEv2 proposals, or the tunnel will fail to establish.

2

Configure IKEv2 Keyring and Profile

Create an IKEv2 keyring to store the pre-shared key for the remote peer. Then, create an IKEv2 profile that references the keyring, local identity, and remote peer address. The profile is matched during tunnel negotiation.

Cisco IOS
crypto ikev2 keyring IKEV2-KEYRING
 peer R2
  address 192.168.2.2
  pre-shared-key cisco123
!
crypto ikev2 profile IKEV2-PROFILE
 match identity remote address 192.168.2.2 255.255.255.255
 identity local address 192.168.1.1
 authentication remote pre-share
 authentication local pre-share
 keyring local IKEV2-KEYRING
!

Use a strong, complex pre-shared key. For production, consider certificate-based authentication.

3

Define IPsec Transform Set and Crypto Map

Configure an IPsec transform set with ESP encryption (AES-256) and authentication (SHA-256). Then create a crypto map that ties the IKEv2 profile, transform set, peer IP, and ACL for interesting traffic. Apply the crypto map to the outgoing interface.

Cisco IOS
crypto ipsec transform-set AES256-SHA256 esp-aes 256 esp-sha256-hmac
 mode tunnel
!
crypto map CMAP 10 ipsec-isakmp
 set peer 192.168.2.2
 set transform-set AES256-SHA256
 set ikev2-profile IKEV2-PROFILE
 match address VPN-ACL
!
interface GigabitEthernet0/0
 crypto map CMAP
!

Always use 'mode tunnel' for site-to-site VPNs. Transport mode is for host-to-host.

Do not forget to apply the crypto map to the correct interface. Missing this step is a common exam pitfall.

4

Create Access Control List for Interesting Traffic

Define an extended ACL that matches traffic to be encrypted. Typically, this is traffic between the two private LAN subnets. The ACL is referenced by the crypto map. Only traffic matching permit statements will be encrypted.

Cisco IOS
ip access-list extended VPN-ACL
 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255
!

Use inverse masks (wildcard bits) in ACLs. The example above matches 10.1.1.0/24 to 10.2.2.0/24.

Ensure the ACL is symmetric on both routers. Misconfigured ACLs cause one-way traffic or no encryption.

5

Configure Static Routes for Remote Subnets

Add static routes on each router pointing to the remote LAN via the tunnel interface (or next-hop peer IP). Without routes, the router will not know how to forward traffic to the remote subnet, even if the VPN is up.

Cisco IOS
ip route 10.2.2.0 255.255.255.0 192.168.2.2
!

On the remote router (R2), add a route for 10.1.1.0/24 pointing to 192.168.1.1. Symmetry is critical.

6

Verify the VPN Tunnel Establishment

Use show commands to verify IKEv2 and IPsec security associations. Confirm the tunnel is up and traffic is being encrypted. Common verification commands include 'show crypto ikev2 sa', 'show crypto ipsec sa', and 'ping' across the tunnel.

Cisco IOS
R1# show crypto ikev2 sa
 IPv4 Crypto IKEv2 SA

 dst             src             state          conn-id slot status
192.168.2.2     192.168.1.1     ESTABLISHED     1     0    ACTIVE

R1# show crypto ipsec sa | include encaps|pkts
    #pkts encaps: 42, #pkts decaps: 38

R1# ping 10.2.2.1 source 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5)

If the tunnel does not come up, use 'debug crypto ikev2' and 'debug crypto ipsec' (in a lab only).

Debug commands can overwhelm the router CPU. Use them sparingly and only in maintenance windows.

7

Troubleshoot Common Issues

If the VPN fails, check ACLs, pre-shared keys, and routing. Verify that both routers have matching IKEv2 proposals and transform sets. Use 'show crypto ikev2 sa' to see if phase 1 is up. If phase 1 is up but phase 2 is down, the ACL or transform set mismatch is likely.

Cisco IOS
R1# show crypto ikev2 sa detail
R1# show crypto ipsec sa peer 192.168.2.2
R1# show access-lists VPN-ACL

Always check the ACL hit count. If it is zero, interesting traffic is not being matched.

NAT devices between peers can break IPsec. Ensure UDP 500 and 4500 are allowed through firewalls.

Key tips

  • Always use IKEv2 instead of IKEv1 for better security and performance. IKEv2 is required for ENCOR exam scenarios.

  • Use DH group 14 or 19 for key exchange. Avoid group 1, 2, or 5 in production environments.

  • Enable Dead Peer Detection (DPD) to quickly detect tunnel failures. Configure it under the IKEv2 profile with 'dpd 10 3 retry'.

  • For high availability, use tunnel interfaces with IPsec VTI (Virtual Tunnel Interface) instead of crypto maps. This is a newer, more scalable approach.

  • Always test with a ping from a device behind the router, not from the router itself, to verify end-to-end encryption.

  • Document your crypto map sequence numbers. If you add multiple peers, increment by 10 to allow future insertions.

Frequently asked questions

What is the difference between IKEv1 and IKEv2?

IKEv2 is more efficient and secure than IKEv1. It uses fewer messages to establish a tunnel (4 vs 6), supports built-in NAT traversal, and has better resistance to DoS attacks. Cisco IOS supports both, but IKEv2 is preferred for modern networks and is tested in ENCOR.

Why is my IPsec tunnel up but no traffic passes?

This is usually due to missing or mismatched ACLs for interesting traffic, incorrect static routes, or firewall rules blocking ESP (protocol 50) or UDP 4500. Verify the ACL hit count with 'show access-lists' and ensure routes point to the correct next-hop.

Can I use the same pre-shared key for multiple peers?

Technically yes, but it is a security risk. Each peer should have a unique pre-shared key. In Cisco IOS, you can define multiple peers in the same keyring with different keys. For production, consider certificate-based authentication.

What is the role of the crypto map?

A crypto map binds together the IPsec transform set, peer address, IKEv2 profile, and ACL. It is applied to an interface to enable IPsec encryption on outbound traffic matching the ACL. Without it, the router will not initiate or respond to IPsec negotiations.

How do I verify encryption is actually working?

Use 'show crypto ipsec sa' and look for 'encaps' and 'decaps' packet counts. Non-zero values indicate encrypted traffic. You can also capture packets on the outside interface with 'debug ip packet' (carefully) or an external sniffer to confirm ESP headers.

Related glossary terms

Browse full glossary →

Practice with real exam questions

Apply what you just learned with exam-style practice questions.

Related guides