LogoفارسیFA

IPsec VPN Fundamentals: Securing Traffic Across Untrusted Networks

Connecting two sites across the public internet exposes traffic to interception unless it is properly encrypted, and IPsec provides the standard framework for building secure, authenticated tunnels between sites. This article explains the two-phase IKE negotiation process, covers the distinction between AH and ESP protocols, walks through configuring a basic site-to-site IPsec VPN, and covers essential verification commands.

IPsec VPNIKE Phase 1 and 2Site-to-Site VPN Configuration

~6 min read · Updated Sep 12, 2026

Why Site-to-Site Connectivity Needs Encryption

Connecting two office sites across the public internet, rather than a dedicated private circuit like the MPLS connectivity discussed earlier in this series, means traffic travels across infrastructure controlled by third parties and potentially observable by anyone along that path. IPsec (IP Security) provides a standard framework for encrypting and authenticating this traffic, making a public internet connection safe to carry sensitive site-to-site communication.

The Two-Phase IKE Negotiation Process

Before any actual data can be encrypted and sent, two VPN endpoints must first securely negotiate the cryptographic parameters they will use -- this negotiation is handled by IKE (Internet Key Exchange), occurring in two distinct phases.

IKE Phase 1: establishes a secure, authenticated
  management channel between the two VPN peers
  themselves -- this channel is used only to
  protect the negotiation process itself, not
  yet the actual data traffic

IKE Phase 2: uses the secure channel established
  in Phase 1 to negotiate the actual parameters
  that will protect real data traffic --
  establishing what is called an IPsec Security
  Association (SA) for the actual traffic

Configuring IKE Phase 1

Router(config)# crypto isakmp policy 10
Router(config-isakmp)# encryption aes 256
Router(config-isakmp)# hash sha256
Router(config-isakmp)# authentication pre-share
Router(config-isakmp)# group 14
Router(config-isakmp)# lifetime 86400

Router(config)# crypto isakmp key MySharedSecret address 203.0.113.2

-- ISAKMP (Internet Security Association and
-- Key Management Protocol) is the framework IKE
-- operates within -- Phase 1 policy parameters
-- must match exactly on both VPN peers, similar
-- in principle to the neighbor requirement
-- matching discussed earlier in this series
-- regarding OSPF and EIGRP neighbor formation

The group 14 setting specifies the Diffie-Hellman group used for the initial key exchange -- a higher group number generally provides stronger security at the cost of additional computational overhead during the negotiation itself, though this cost is paid only once per tunnel establishment, not per packet.

Configuring IKE Phase 2 (IPsec Transform Set)

Router(config)# crypto ipsec transform-set MY-TRANSFORM esp-aes 256 esp-sha256-hmac

Router(config)# crypto map VPN-MAP 10 ipsec-isakmp
Router(config-crypto-map)# set peer 203.0.113.2
Router(config-crypto-map)# set transform-set MY-TRANSFORM
Router(config-crypto-map)# match address VPN-TRAFFIC

Router(config)# interface gigabitethernet 0/0
Router(config-if)# crypto map VPN-MAP

The match address VPN-TRAFFIC line references an access list, discussed earlier in this series, that defines exactly which traffic should be sent through the encrypted tunnel -- traffic matching this ACL gets encrypted and sent through the VPN, while traffic not matching it is forwarded normally in the clear, based on the standard routing table.

AH Versus ESP: The Two IPsec Protocols

AH (Authentication Header):
  Provides authentication and integrity checking
  (confirming data has not been tampered with
  and genuinely came from the claimed sender)
  Does NOT provide encryption -- data remains
  readable to anyone intercepting it
  Rarely used alone in modern deployments

ESP (Encapsulating Security Payload):
  Provides both authentication/integrity AND
  encryption (confirming both that data is
  unmodified and keeping its contents
  confidential from interception)
  The dominant protocol used in virtually all
  modern IPsec VPN deployments, since
  confidentiality is almost always required

Since ESP alone already provides both the integrity checking and confidentiality most deployments actually need, AH is rarely configured independently in practice -- the transform-set configuration shown above uses esp-aes and esp-sha256-hmac, both explicitly ESP-based, reflecting this near-universal preference.

Tunnel Mode Versus Transport Mode

Tunnel Mode: the ENTIRE original IP packet
  (including its original header) is encrypted
  and encapsulated within a new IP packet --
  used for site-to-site VPNs, where an entire
  private network's traffic needs to be
  protected as it crosses the public internet

Transport Mode: only the payload of the original
  packet is encrypted, while the original IP
  header remains visible -- used for host-to-host
  communication where both endpoints already
  have public, routable addresses and only the
  data itself needs protection

Site-to-site VPNs, the most common enterprise IPsec use case, virtually always use tunnel mode, since private internal addresses, discussed earlier in this series regarding IPv4 addressing, need to be completely hidden and protected as traffic crosses the public internet between sites.

Verifying IKE Phase 1 and Phase 2 Status

Router# show crypto isakmp sa

dst             src             state          conn-id
203.0.113.2     203.0.113.1     QM_IDLE        1001

-- "QM_IDLE" confirms Phase 1 completed
-- successfully and the management channel
-- is stable and idle, ready to support
-- Phase 2 negotiations as needed

Router# show crypto ipsec sa

  local  ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
  remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0)
    #pkts encaps: 1204, #pkts encrypt: 1204
    #pkts decaps: 1198, #pkts decrypt: 1198

The packet counters in show crypto ipsec sa confirm traffic is actually flowing through the tunnel in both directions -- a common troubleshooting pattern is a Phase 1 SA in the correct idle state but zero packet counts in Phase 2, indicating traffic matching the configured interesting traffic ACL has simply never actually been sent, rather than a cryptographic negotiation failure.

Diagnosing a Common Failure: Phase 1 Never Establishing

Common causes when Phase 1 fails to establish:

- Mismatched ISAKMP policy parameters between
  peers (encryption, hash, DH group, or
  authentication method must all match exactly)
- Mismatched pre-shared key
- A firewall or NAT device blocking UDP port 500
  (used by IKE) somewhere along the path between
  the two peers

Why IPsec VPNs Remain a Foundational Enterprise Technology

Even as SD-WAN, discussed earlier in this series, increasingly automates and abstracts away much of this manual configuration complexity, IPsec's underlying cryptographic framework remains the actual security mechanism operating beneath most modern site-to-site connectivity solutions, including SD-WAN implementations themselves. Understanding the two-phase IKE negotiation process, the distinction between AH and ESP, and how to read Phase 1 and Phase 2 security association status is essential foundational knowledge for troubleshooting any VPN technology built on top of this widely deployed standard.

Written & researched by Dr. Shahin Siami

Related Articles

Systematic Network Troubleshooting: A Methodology Tying Everything Together

Every protocol and technology covered throughout this series is only useful if a problem involving it can actually be diagnosed and fixed efficiently under real-world pressure. This article presents a systematic troubleshooting methodology built around the OSI layers, walks through applying it to a realistic connectivity problem, and shows how the specific verification commands covered throughout this entire series fit into a structured diagnostic process.

Continue

NETCONF, YANG, and Python: Programmatic Network Configuration at Scale

The REST APIs and JSON/YAML formats covered earlier in this series represent one approach to network automation, but NETCONF and YANG provide a more structured, standards-based alternative purpose-built for network device configuration. This article explains what distinguishes NETCONF from a simple REST API, covers how YANG models define exactly what configuration data looks like, and walks through using Python to programmatically interact with network devices.

Continue

MPLS Fundamentals: Label Switching Explained

Traditional IP routing requires every router along a path to perform a full routing table lookup on every packet, but MPLS takes a fundamentally different approach by making that forwarding decision once and attaching a simple label that every subsequent router can use instead. This article explains the core label-switching concept, walks through how the Label Distribution Protocol builds the label forwarding tables that make this possible, and covers the practical benefits MPLS provides in real provider networks.

Continue

BGP Route Reflectors and Confederations: Scaling iBGP Beyond Full Mesh

The iBGP full-mesh requirement, briefly mentioned earlier in this series, becomes a serious scaling problem as an autonomous system grows, requiring a number of sessions that increases quadratically with router count. This article explains exactly why full mesh does not scale, walks through how route reflectors solve this by relaxing BGP's normal route-propagation rules, and covers confederations as an alternative approach that divides a single AS into smaller sub-autonomous systems.

Continue

OSPF Area Types Deep Dive: Stub, Totally Stubby, and NSSA

Multi-area OSPF, covered earlier in this series, already reduces database size by separating a network into areas, but OSPF offers further specialized area types that reduce routing table size even more aggressively by filtering out unnecessary external routes entirely. This article explains the LSA types that must be suppressed to create each specialized area type, walks through configuring stub, totally stubby, and not-so-stubby areas, and covers the specific trade-offs each design choice involves.

Continue

BGP Path Manipulation: Route Maps and Communities for Traffic Engineering

The basic BGP path selection process, covered earlier in this series, follows a fixed order of attributes, but real networks need to actively influence which path gets chosen rather than passively accepting the default outcome. This article explains how route maps filter and modify BGP routing information, covers Local Preference and MED as the two primary levers for influencing path selection, and introduces BGP communities as a flexible tagging mechanism for coordinating policy across an entire network.

Continue
Previous ArticleNext Article