The most surprising thing about IPSec is that it doesn’t actually encrypt your data by default; it only authenticates it, proving it came from where it says it did.
Let’s see IPSec in action. Imagine you have two networks, 192.168.1.0/24 (your office) and 192.168.2.0/24 (a remote branch), and you want them to talk securely over the internet.
On your office router (let’s call it office-gw), you’d configure something like this:
# Phase 1 (IKEv2 - establishing the secure channel for negotiation)
crypto isakmp policy 10
encryption aes 256
authentication sha256
group 14
lifetime 86400
#
crypto isakmp client authentication list MY_AUTH_LIST
authentication pre-share
key ascii MY_SECRET_KEY
#
crypto isakmp profile MY_IKE_PROFILE
match identity remote address 1.2.3.4 # IP of the branch router
authentication list MY_AUTH_LIST
#
# Phase 2 (IPSec - defining the actual traffic to protect and how)
crypto ipsec transform-set MY_TRANSFORM_SET esp-aes 256 esp-sha256-hmac
mode tunnel
#
crypto ipsec profile MY_IPSEC_PROFILE
set transform-set MY_TRANSFORM_SET
set ikev2-profile MY_IKE_PROFILE
#
# Applying the IPSec profile to an interface (e.g., WAN interface facing the internet)
interface GigabitEthernet0/0
ip address 1.2.3.4 255.255.255.0
crypto ipsec profile MY_IPSEC_PROFILE
#
# Defining the interesting traffic (what needs to go through the tunnel)
! This is often done via route-maps or access-lists that then point to the crypto map
! For simplicity, let's assume a route-map is applied to the tunnel interface or a virtual template.
! Or, more commonly, a static route for the remote network points to the IPSec profile.
ip route 192.168.2.0 255.255.255.0 1.2.3.4 track 1 # Assuming the remote IP is reachable
On the branch router (branch-gw) at 5.6.7.8, the configuration would mirror this, with 1.2.3.4 and 192.168.1.0/24 swapped.
Tunnel Mode is what we saw above. It encapsulates the entire original IP packet (header and payload) within a new IP packet. The original source and destination IP addresses are hidden, and the new packet has the IPsec tunnel endpoints as its source and destination. This is like putting a whole letter into a new, unmarked envelope to send across the country. The original sender and recipient are obscured from anyone looking at the outer envelope.
Transport Mode, on the other hand, only encrypts and authenticates the payload of the original IP packet. The original IP header remains intact, meaning the original source and destination IPs are still visible. This is useful when you want to secure communication between two hosts on the same network or between two endpoints that are directly connected, but you don’t want to hide their IP addresses. Imagine adding a tamper-evident seal to an existing envelope; the addresses are still there, but you know the contents haven’t been messed with.
IKEv2 (Internet Key Exchange version 2) is the protocol responsible for setting up the secure connection that IPSec uses. It’s a more streamlined and robust successor to IKEv1. IKEv2 handles two main phases:
- Phase 1: Establishes a secure, authenticated channel between the two IPSec peers (the routers in our example). This is where they agree on encryption and authentication algorithms for their control messages, and authenticate each other (using pre-shared keys, certificates, etc.). Our
crypto isakmpconfiguration deals with this. - Phase 2: Uses the secure channel established in Phase 1 to negotiate the security parameters for the actual data traffic. This includes defining which traffic to protect (the "interesting traffic"), the encryption and authentication algorithms for the data itself (e.g., AES-256 for encryption, SHA256 for integrity), and the lifetime of the Security Association (SA) for that data. Our
crypto ipsec transform-setandcrypto ipsec profileconfigurations handle this.
IKEv2 is a stateful protocol, meaning it keeps track of the security associations it has established. This makes it more resilient to network interruptions and simplifies rekeying. It also uses a simpler message exchange (four messages for initial setup) compared to IKEv1.
A key aspect of IPSec SA establishment is the concept of "policy" and "transform-set." The policy (Phase 1) dictates how the peers authenticate and establish the initial secure channel. The transform-set (Phase 2) defines the cryptographic suites used for protecting the actual data. Both must match on both ends for the tunnel to come up.
The most counterintuitive aspect of IPSec, especially for those coming from TLS/SSL, is that the security parameters negotiated in Phase 1 (IKE) are not directly applied to the user data. IKE establishes a secure channel to negotiate the parameters for the data channel. This two-phase approach is crucial for managing the security of potentially millions of data flows without overwhelming the initial negotiation process.
The next hurdle you’ll face is troubleshooting tunnel flapping, where the IPSec tunnel repeatedly establishes and then drops.