Beispiel eines erfolgreichen IPSec-Verbindungsaufbaus

Ein IPSec-Verbindungsaufbau durchläuft zwei Phasen. In der ersten Phase authentifizieren sich die Kommunikationspartner und ein sicherer Kommunikationskanal wird eingerichtet. In der zweiten Phase werden die eigentlichen VPN-Tunnel ausgehandelt. Mit dem erfolgreichen Abschluss der zweiten Phase ist die IPSec-Verbindung hergestellt. Nun können Nutzdaten übertragen werden. Bei L2TP-over-IPSec werden die Nutzdaten nicht direkt sondern innerhalb von L2TP-Paketen übertragen. Entsprechend wird innerhalb der IPSec-Verbindung zunächst noch eine L2TP-Verbindung ausgehandelt. Dieser Schritt hat jedoch mit der IPSec-Verbindung als solches nichts weiter zu tun.

Das folgende Beispiel zeigt einen Auszug aus dem DEFENDO VPN-Log. Dargestellt ist der Verbindungsaufbau einer L2TP-over-IPSec-Verbindung. Als Client dient Windows XP mit Authentifizierung über Zertifikat. Zeitstempel, Prozess-Informationen und der interne Verbindungsname wurden zugunsten der Übersichtlichkeit weggelassen.

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}

Da es sich im Beispiel um eine L2TP-over-IPSec-Verbindung handelt, würde nun der Aufbau einer L2TP-Verbindung folgen. L2TP nutzt ein PPP-Protokoll. Dieser Prozess lässt sich im PPP-Log beobachten.

Der Vollständigkeit halber noch die Meldungen die beim Abbau der VPN-Verbindung durch die Gegenstelle protokolliert werden:

#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}