Example of a successful IPSec negotiation

An IPSec connection is established in two phases. In phase 1 the peers authenticate and a secure communication channel is established. The actual VPN tunnels are negotiated in the second phase. As soon as phase 2 completed successfully the connection is established and data can be transmitted. For L2TP-over-IPSec VPNs there's still the L2TP layer to be negotiated. This negotiation as well as the L2TP data transport is protected by the IPSec tunnel. The L2TP negotiation is completely independent of the IPSec connection.

The following example shows an excerpt of a DEFENDO VPN log. It shows the IPSec negotiation of an L2TP-over-IPSec connection authenticated by certificate. The client is Windows XP. Timestamp, process information and the internal connection name have been stripped to reduce the log's line length.

packet from 169.254.1.200:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
packet from 169.254.1.200:500: ignoring Vendor ID payload [FRAGMENTATION]
packet from 169.254.1.200:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
packet from 169.254.1.200:500: ignoring Vendor ID payload [Vid-Initial-Contact]
#1: responding to Main Mode from unknown peer 169.254.1.200
#1: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
#1: STATE_MAIN_R1: sent MR1, expecting MI2
#1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected
#1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
#1: STATE_MAIN_R2: sent MR2, expecting MI3
#1: Main mode peer ID is ID_DER_ASN1_DN: 'C=de, CN=test'
#1: no crl from issuer "C=de, CN=defendo.de CA" found (strict=no)
#1: I am sending my cert
#1: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
#1: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp2048}

#1: the peer proposed: 169.254.1.100/32:17/1701 -> 169.254.1.200/32:17/1701
#2: responding to Quick Mode proposal {msgid:89d11c6a}
#2: us: 169.254.1.100[C=de, CN=training1.defendo.de,+S=C]:17/1701
#2: them: 169.254.1.200[C=de, CN=test,+S=C]:17/1701
#2: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
#2: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
#2: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
#2: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0xebcf82f8 <0xc7a67764 xfrm=3DES_0-HMAC_MD5 NATOA=none NATD=none DPD=none}

As this example refers to an L2TP-over-IPSec connections the L2TP negotiation would follow now. L2TP is based on PPP. A detailed description of PPP can be found in the PPP log.

For completeness the following logfile excerpt shows the termination of the VPN connections triggered by the peer:

#1: received Delete SA(0xebcf82f8) payload: deleting IPSEC State #2
#1: received and ignored informational message
#1: received Delete SA payload: deleting ISAKMP State #1
deleting connection "l2tp_0-L2TP_1701_gw-sn_defaultroute-0.0.0.0_0" instance with peer 169.254.1.200 {isakmp=#0/ipsec=#0}