Perfect Forward Secrecy (PFS)

Enhanced Security

Perfect Forward Secrecy ensures that if long-term keys are compromised, past session keys remain secure. Each session uses unique, ephemeral keys.

PFS Fundamentals

Perfect Forward Secrecy is achieved by using ephemeral Diffie-Hellman key exchange for each IPsec session. This ensures that:

With PFS

  • Each session has unique keys
  • Key compromise affects only current session
  • Past communications remain secure
  • Future sessions are protected
  • Enhanced long-term security

Without PFS

  • Keys may be reused across sessions
  • Key compromise affects multiple sessions
  • Past traffic can be decrypted
  • Retroactive vulnerability
  • Reduced security over time

PFS Implementation in IPsec

Phase Key Exchange PFS Benefit Configuration
IKE Phase 1 Always uses DH IKE SA keys are ephemeral Automatic in IKE
IKE Phase 2 Optional DH exchange IPsec SA keys are ephemeral Must be explicitly enabled

Cisco PFS Configuration

# Enable PFS in Crypto Map
crypto map OUTSIDE-MAP 10 ipsec-ikev2
 set peer 203.0.113.1
 set ikev2 ipsec-proposal ESP-AES256-SHA256
 match address SITE-TO-SITE-ACL
 set pfs group14

# Enable PFS in IPsec Profile (for VTI)
crypto ipsec profile VTI-PROFILE
 set ikev2 ipsec-proposal ESP-AES256-SHA256
 set pfs group14

# IKEv2 Policy with Strong DH Group
crypto ikev2 policy 10
 encryption aes-256
 integrity sha256
 group 14
 prf sha256

DH Group Selection for PFS

Group 14 (2048-bit)
Recommended

Security Level: 112-bit

Performance: Good

Use Case: Standard deployments

Group 19 (P-256)
Recommended

Security Level: 128-bit

Performance: Excellent

Use Case: Modern implementations

Group 20 (P-384)
High Security

Security Level: 192-bit

Performance: Good

Use Case: High-security environments

Next: Dead Peer Detection

Dead Peer Detection (DPD)

Tunnel Health Monitoring

Dead Peer Detection is a keepalive mechanism that detects when an IPsec peer becomes unreachable and triggers tunnel recovery.

DPD Operation

DPD works by sending periodic Hello messages between IPsec peers. If a peer doesn't respond within the configured timeout, the tunnel is considered down.

DPD Message Flow

1. Normal Operation: Both peers exchange data regularly
2. Idle Period: No traffic for DPD idle timeout (default: 10 seconds)
3. DPD Hello: Peer A sends DPD Hello message to Peer B
4. DPD Reply: Peer B responds with DPD Reply (if alive)
5. Failure: If no reply within retry timeout, peer is considered dead

DPD Configuration Parameters

Parameter Description Default Value Recommended
DPD Delay Time between DPD messages 10 seconds 10-30 seconds
DPD Retry Timeout for DPD response 5 seconds 5-10 seconds
DPD Max Failures Failed attempts before declaring peer dead 3 3-5
DPD Action Action when peer is detected as dead Clear Restart or Clear

Cisco DPD Configuration

# IKEv2 Profile with DPD
crypto ikev2 profile DPD-PROFILE
 match identity remote address 203.0.113.1 255.255.255.255
 identity local address 10.1.1.1
 authentication remote pre-share key MySecretKey123
 authentication local pre-share key MySecretKey123
 dpd 10 5 on-demand

# Alternative: Always-on DPD
crypto ikev2 profile DPD-PROFILE-ALWAYS
 match identity remote address 203.0.113.1 255.255.255.255
 dpd 30 10 periodic

# Group Policy for AnyConnect with DPD
group-policy DPD_POLICY internal
group-policy DPD_POLICY attributes
 vpn-idle-timeout 60
 vpn-session-timeout 480
 split-tunnel-policy tunnelspecified

DPD vs Other Keepalive Mechanisms

Mechanism Layer Overhead Detection Time Use Case
DPD IKE Low Fast (seconds) IPsec tunnel monitoring
TCP Keepalive TCP Medium Slow (minutes) Application-level detection
ICMP Ping IP Low Customizable Basic reachability
BFD UDP Medium Very Fast (ms) Routing protocol failover
Previous: Perfect Forward Secrecy Next: NAT Traversal

NAT Traversal (NAT-T)

NAT Challenges

Network Address Translation (NAT) breaks IPsec by modifying IP headers and ports. NAT Traversal solves this by encapsulating IPsec in UDP.

Why NAT Breaks IPsec

ESP Issues with NAT

  • No Port Information: ESP has no TCP/UDP ports for NAT translation
  • Integrity Checks: AH authenticates IP header, fails when NAT changes it
  • Multiple Clients: NAT can't distinguish between multiple IPsec clients
  • Embedded IP Addresses: IKE payloads contain IP addresses that NAT doesn't translate

NAT-T Solutions

  • UDP Encapsulation: Wraps ESP in UDP on port 4500
  • NAT Detection: Detects NAT presence during IKE negotiation
  • Keep-alive: Maintains NAT mappings with periodic packets
  • Port Floating: Switches from port 500 to 4500 when NAT detected

NAT-T Operation Flow

1. IKE Negotiation: IKE starts on UDP port 500
2. NAT Detection: Peers exchange NAT Detection payloads
3. NAT Found: Hash of IP:Port differs, indicating NAT presence
4. Port Floating: Switch to UDP port 4500 for subsequent messages
5. UDP Encapsulation: ESP packets wrapped in UDP headers
6. Keep-alive: Periodic NAT-T keep-alive packets maintain mappings

NAT-T Packet Format

Normal ESP Packet:
[IP Header][ESP Header][Payload][ESP Trailer][ESP Auth]

NAT-T ESP Packet:
[IP Header][UDP Header][ESP Header][Payload][ESP Trailer][ESP Auth]

UDP Header Details:
- Source Port: 4500
- Destination Port: 4500
- Length: ESP packet length + 8
- Checksum: Standard UDP checksum

Cisco NAT-T Configuration

# Enable NAT-T globally (usually enabled by default)
crypto isakmp nat-traversal 20

# IKEv2 with NAT-T support
crypto ikev2 policy 10
 encryption aes-256
 integrity sha256
 group 14
 prf sha256

# Group Policy with NAT-T settings
group-policy NAT_TRAVERSAL_POLICY internal
group-policy NAT_TRAVERSAL_POLICY attributes
 vpn-tunnel-protocol ikev2
 split-tunnel-policy tunnelspecified
 address-pools value VPN_POOL

# For site-to-site behind NAT
crypto ikev2 profile NAT-T-PROFILE
 match identity remote any
 identity local address 192.168.1.1
 authentication remote pre-share key MySecretKey123
 authentication local pre-share key MySecretKey123
 dpd 30 10 on-demand

NAT-T Troubleshooting

Issue Symptom Cause Solution
IKE Fails Phase 1 doesn't complete UDP 500/4500 blocked Open firewall ports
Tunnel Drops Frequent disconnections NAT mapping timeout Enable NAT-T keep-alive
Multiple Clients Only one client works NAT port collision Use different client ports
Performance Issues Slow throughput UDP overhead/fragmentation Adjust MTU/MSS
Previous: Dead Peer Detection Next: High Availability

High Availability (HA)

Business Continuity

High Availability ensures VPN services remain operational even when primary systems fail, providing redundancy and minimizing downtime.

HA Design Principles

Redundancy

  • Multiple VPN gateways
  • Diverse network paths
  • Backup power systems
  • Geographic distribution

Failover

  • Automatic detection
  • Fast convergence
  • State synchronization
  • Seamless transition

Load Distribution

  • Active-active clusters
  • Load balancing
  • Resource optimization
  • Scalability

HA Deployment Models

Model Configuration Failover Time Resource Usage Cost
Active-Standby Primary + Backup 30-60 seconds 50% utilization Lower
Active-Active Load balanced No failover needed 100% utilization Higher
Cluster Multiple nodes 5-15 seconds N-1 redundancy Highest
Geographic Multi-site 60-180 seconds Variable Very high

Cisco ASA Active-Standby Failover

# Primary ASA Configuration
failover
failover lan unit primary
failover lan interface failover GigabitEthernet0/3
failover replication http
failover link failover GigabitEthernet0/3
failover interface ip failover 192.168.99.1 255.255.255.0 standby 192.168.99.2

# Interface configuration with standby IPs
interface outside
 ip address 10.1.1.1 255.255.255.0 standby 10.1.1.2
 security-level 0

interface inside
 ip address 192.168.1.1 255.255.255.0 standby 192.168.1.2
 security-level 100

# Monitoring interfaces for failover
monitor-interface outside
monitor-interface inside

# Failover criteria
failover polltime unit 3 holdtime 9
failover polltime interface 5 holdtime 15

Load Balancing with Multiple VPN Gateways

# DNS-based load balancing
# Configure multiple A records for vpn.company.com:
# vpn.company.com.  300  IN  A  10.1.1.1
# vpn.company.com.  300  IN  A  10.1.1.2
# vpn.company.com.  300  IN  A  10.1.1.3

# Client will randomly select one of the IPs

# For site-to-site, use routing-based failover:
# Primary route
ip route 192.168.2.0 255.255.255.0 tunnel1 1

# Backup route with higher administrative distance
ip route 192.168.2.0 255.255.255.0 tunnel2 10

# SLA monitoring for intelligent failover
ip sla 1
 icmp-echo 192.168.2.1 source-interface tunnel1
 frequency 10
ip sla schedule 1 life forever start-time now

track 1 ip sla 1 reachability
ip route 192.168.2.0 255.255.255.0 tunnel1 1 track 1

HA Monitoring and Alerting

Key Metrics to Monitor

  • Tunnel Status: Up/down state of IPsec tunnels
  • Throughput: Bandwidth utilization
  • Latency: Round-trip time through tunnels
  • Packet Loss: Dropped or retransmitted packets
  • CPU/Memory: Resource utilization
  • Connection Count: Active VPN sessions

Alerting Thresholds

  • Critical: Primary gateway down
  • Warning: >80% CPU or memory usage
  • Info: Tunnel rekeying events
  • Warning: >5% packet loss
  • Critical: >50ms latency increase
  • Warning: >90% of licensed connections

Best Practices for HA IPsec

Implementation Tips

  • Test Regularly: Perform planned failover tests quarterly
  • Document Procedures: Maintain clear runbooks for failover scenarios
  • Monitor Dependencies: Track external services (DNS, RADIUS, CA)
  • Capacity Planning: Ensure backup systems can handle full load
  • Geographic Diversity: Place backup systems in different locations
  • Version Consistency: Keep firmware/software versions synchronized
Previous: NAT Traversal Next: Chapter 7 - Troubleshooting