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 a preshared key. The client is Windows XP. Timestamp, process information and the internal connection name
have been stripped to reduce the log's line length.
Phase 1
#4: responding to Main Mode from unknown peer 169.254.1.1
#4: only OAKLEY_GROUP_MODP1024 and OAKLEY_GROUP_MODP1536 supported. Attribute OAKLEY_GROUP_DESCRIPTION
#4: transition from state (null) to state STATE_MAIN_R1
packet from 169.254.1.1:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
packet from 169.254.1.1:500: ignoring Vendor ID payload [FRAGMENTATION]
packet from 169.254.1.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
#4: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected
#4: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
#4: Peer ID is ID_IPV4_ADDR: '169.254.1.1'
#4: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
#4: sent MR3, ISAKMP SA established
#4: only OAKLEY_GROUP_MODP1024 and OAKLEY_GROUP_MODP1536 supported. Attribute OAKLEY_GROUP_DESCRIPTION
#4: transition from state (null) to state STATE_MAIN_R1
packet from 169.254.1.1:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
packet from 169.254.1.1:500: ignoring Vendor ID payload [FRAGMENTATION]
packet from 169.254.1.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
#4: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected
#4: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
#4: Peer ID is ID_IPV4_ADDR: '169.254.1.1'
#4: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
#4: sent MR3, ISAKMP SA established
Phase 2
#5: responding to Quick Mode
#5: transition from state (null) to state STATE_QUICK_R1
#5: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
#5: IPsec SA established {ESP=>0x4b8c06a4 <0x2d923407}
#5: transition from state (null) to state STATE_QUICK_R1
#5: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
#5: IPsec SA established {ESP=>0x4b8c06a4 <0x2d923407}
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 debug log.
For completeness the following logfile excerpt shows the termination of the VPN connections triggered by the peer:
#4: received Delete SA(0x4b8c06a4) payload: deleting IPSEC State #5
#4: received Delete SA payload: deleting ISAKMP State #4
#4: received Delete SA payload: deleting ISAKMP State #4