Der kommende Linux-Kernel 2.6 wird IPsec enthalten, und zwar nicht mit Freeswan-Patches, sondern mit einer neuen Implementierung. Dazu gesellen sich spezielle Userspace-Tools. Dieser Artikel zeigt, wie damit sichere IP-Transportwege entstehen.

Wer zwei weit voneinander entfernte Netzwerke verbinden muss, setzt dafür immer häufiger virtuelle private Netze (VPN) ein – Grund sind vor allem niedrige Kosten: Es sind keine Standleitungen nötig, eine normale Internetverbindung reicht. Auch ihre Sicherheit spricht für VPNs mit IPsec (Internet Protocol Security). Das Freeswan-Projekt[1] bietet seit einigen Jahren die Möglichkeit, IPsec mit IP-Version 4 auf einem Linux-Kernel 2.2 oder 2.4 zu betreiben.

Aus mehreren Gründen wurde dieser Code nie in den Linux-Kernel aufgenommen, sodass auch heute noch Kernel-Patchen nötig ist. Waren es zu Beginn die Exportbeschränkungen der USA für starke Kryptographie, die eine feste Aufnahme in den Kernel verhinderten, so sind es heute in erster Linie Zweifel an der Qualität des Code. Kernelentwickler wie Stephen Tweedie forderten daher mehrfach die Entwicklung einer alternativen IPsec-Implementierung.

Sogar einige Freeswan-Entwickler teilen offenbar diese Auffassung. Henry Spencer schrieb am 8. November 2002 auf der Freeswan-Design-Mailingliste: “And, in fairness, KLIPS is the ugliest and least maintainable part of Freeswan, and deserves to be supplanted.” Anlass war die Aufnahme von IPsec in Kernel 2.5.45.

Neuer Code

Seit dem Entwicklerkernel 2.5.45 befindet sich nun diese neue IPsec-Implementierung im Linux-Kernel. Sie wurde von Dave Miller und Alexey Kuznetsov implementiert. Ihre Arbeit basiert stark auf den Projekten USAGI (IPv6 und IPsec für Linux[2]), KAME (IPv6 und IPsec für mehrere BSD-Varianten[3]) und WIDE (Widely Integrated Distributed Environment[4]).

Für die kryptographischen Berechnungen (zum Beispiel Message Authentication Code und Verschlüsselung) greift der neue IPsec-Code auf das ebenfalls neue Crypto-API von James Morris zu. Es implementiert die wichtigsten Algorithmen zur Authentifizierung und Verschlüsselung. Kernelentwickler können damit leicht zusätzliche Algorithmen integrieren.

Sichere Kommunikation

Die hohe Sicherheit der IPsec-geschützten Kommunikation hat ihren Preis: Sie benötigt zusätzliche Konfiguration. Die Partner authentifizieren sich beim AH-Protokoll und schicken bei ESP die Daten verschlüsselt (siehe Kasten “Die IPsec-Protokolle”). Dazu müssen sie jedoch mehr voneinander wissen als nur ihre IP-Adresse oder ihren DNS-Namen. Dieses Wissen entscheidet, ob die Pakete wirklich vom angeblichen Absender stammen, und es stellt sicher, dass nur der richtige Empfänger die Daten entschlüsseln kann.

Die Konfiguration legt zunächst die Verschlüsselungsalgorithmen und die Schlüssel fest. Um diese den einzelnen Absendern und Empfängern korrekt zuordnen zu können, sind zusätzlich Security Parameter Indices nötig (SPI). Die kompletten Angaben werden als Security Association (SA) bezeichnet und in der Security Association Database (SAD) gespeichert. Die Security Policy (SP) definiert, wann der Kernel welche Security Association einsetzen muss, um IP-Pakete zu senden. Die Security Policies werden in der Security Policy Database (SPD) gespeichert.

Das Erzeugen der Security Associations stellt den Administrator eines VPN vor ein klassisches Henne-Ei-Problem: Die SA definiert die zu verwendenden Algorithmen und Schlüssel. Da IPsec für die Verschlüsselung und die Authentifizierung symmetrische Verfahren einsetzt, müssen beide Kommunikationspartner auf die identischen Schlüssel zugreifen. Sie müssen sich ihre Schlüssel also gegenseitig bekannt machen. Die vertrauliche Übertragung der Schlüssel ist jedoch nicht möglich, da die Voraussetzungen für eine Verschlüsselung noch nicht gegeben sind: Der Kommunikationspartner verfügt noch nicht über die zum Entschlüsseln notwendigen Informationen.

Abbildung 1: Das AH-Protokoll (Authentication Header) sichert die Integrität des Pakets mit einem Message Authentication Code (MAC). Der Paketinhalt bleibt im Klartext lesbar, aber der Empfänger kann jede Änderung entdecken.

Abbildung 2: Das ESP-Protokoll (Encapsulating Security Payload) verschlüsselt das Paket und stellt damit die Vertraulichkeit sicher. Ein Paket-Sniffer kann den Inhalt nicht mehr entziffern.

Schlüssel austauschen

Im einfachsten Fall greift der Admin ein und überträgt die Schlüssel von Hand, etwa per Diskette oder mit SSH. Eleganter und bequemer ist das IKE-Protokoll (Internet Key Exchange). Es ist kein eigenständiges IP-Protokoll, sondern ein normales Applikationsprotokoll, das UDP (Port 500) benutzt. IKE authentifiziert zunächst den Kommunikationspartner und erzeugt anschließend in einem Diffie-Hellmann-Schlüsselaustausch die symmetrischen Sitzungsschlüssel, die zur Verschlüsselung und Authentifizierung der IPsec-Pakete dienen. Bei diesem Schlüsselaustausch handelt es sich um ein Public-Key-Verfahren, bei dem die gesamte Übertragung unverschlüsselt erfolgt. Dennoch einigen sich die Kommunikationspartner auf einen geheimen, nur ihnen bekannten Schlüssel (siehe Kasten “Diffie-Hellmann-Schlüsselaustausch”).

Beim Internet Key Exchange handeln beide IKE-Instanzen zunächst eine ISAKMP-Security-Association aus (Internet Security Association Key Management Protocol). Auf Basis der ISAKMP-SA ermitteln sie dann die IPsec-SA, die der IPsec-Protokoll-Stack für das Verschlüsseln und Authentifizieren der Pakete einsetzt. In beiden Fällen gilt, dass sich in der SA die Kommunikationspartner auf Algorithmen, Schlüssel und deren Lebensdauer einigen.

Das IKE-Protokoll erneuert die Sitzungsschlüssel in regelmäßigen Abständen und beugt so einer Kompromittierung der Schlüssel vor. Selbst wenn ein Angreifer doch einen Sitzungsschlüssel erfahren sollte, kann er damit nur den kurzen Ausschnitt der Kommunikation decodieren, der mit diesem Schlüssel gesichert war. Die restlichen Daten bleiben ihm verborgen. Ohne dieses Re-Keying könnte der Angreifer im Nachhinein alle von ihm aufgezeichnete Daten entschlüsseln.

Die folgenden Beispiele setzen einen aktuellen Linux-Kernel ab Version 2.5.47 voraus. In der Kernelkonfiguration müssen die in Abbildung 4 und 5 angegebenen Optionen ausgewählt sein. Bei einigen Kernelversionen ist zusätzlich das IPv6-Modul nötig, da sonst der Kernel nicht einwandfrei kompiliert.

Manuell oder automatisch verschlüsselt

Es gibt zwei Techniken, um mit IPsec verschlüsselte Verbindungen aufzubauen. Bei der manuell verschlüsselten Variante gibt der Administrator die Algorithmen und Schlüssel fest vor. Er spezifiziert die gesamte IPsec-Security-Association, die kommunizierenden Rechner verzichten auf das IKE-Protokoll. In diesem einfachen Verfahren lässt sich eine IPsec-Verbindung schnell und fehlerfrei implementieren.

Bei einer automatisch verschlüsselten Verbindung ist das IKE-Protokoll für die Authentifizierung der Kommunikationspartner, die Wahl der Algorithmen und den Austausch der Schlüssel zuständig. IPsec-Verbindungen mit dem IKE-Protokoll sind sicherer, da sie die Sitzungsschlüssel während der Verbindung regelmäßig wechseln (Re-Keying).

Im Gegensatz zu Freeswan enthält der Linux-Kernel ab Version 2.5.47 eine echte Security Association Database (SAD) sowie eine Security Policy Database (SPD). Der Admin greift mit dem Kommando »setkey« direkt auf diese Datenbanken zu und kann dann ihren Inhalt anpassen. Dieses Kommando stammt ursprünglich aus dem KAME-Projekt; Alexey Kuznetsov hat »setkey« und »racoon« auf Linux portiert. Ein Sourcepaket steht unter[6] zur Verfügung.

Das Übersetzen ist jedoch nicht ganz problemlos (siehe Kasten “IPutils übersetzen”). Daher stellt Bert Hubert (bekannt durch sein Linux Advanced Routing and Traffic Control Howto[5]) unter[7] eine fertig kompilierte Version zur Verfügung. Wer lieber RPM-Pakete einsetzt, wird auf der Homepage des Autors fündig[8].

Abbildung 3: Beim Tunnelmodus mit dem AH-Protokoll erhält das Paket einen neuen zusätzlichen IP-Header. Absender- und Empfängeradresse können in beiden IP-Headern unterschiedlich sein.

Security Associations …

Die SAD enthält die IPsec-Security-Associations, sie spezifizieren, wie IPsec die IP-Pakete verschlüsseln und authentifizieren soll. Die SA enthält die Quell- und Ziel-IP-Adresse, das IPsec-Protokoll (AH oder ESP), den Security Parameter Index (SPI), die benutzten Algorithmen und den geheimen Schlüssel. Für die erfolgreiche Kommunikation müssen diese Informationen auf beiden Seiten der Verbindung übereinstimmen, die Systeme verwenden also identische Schlüssel, Algorithmen und SPIs.

… und Security Policies in eigenen Datenbanken

Die SPD speichert alle Security Policies. Eine Security Policy weist den Kernel an, wann und wie er welche Security Association einsetzen soll. Die Policies müssen spiegelbildlich auf den Rechnern an beiden Enden einer Verbindung zusammenpassen, um die IP-Pakete auch wieder korrekt auspacken zu können.

Eine mit »setkey« erzeugte Security Policy enthält die IP-Adressen der kommunizierenden Rechner, den Modus (Tunnel- oder Transportmodus), das zu verschlüsselnde IP-Protokoll und den Port, das IPsec-Protokoll (ESP oder AH) und schließlich die Richtung, für die die Policy gelten soll.

Das »setkey«-Programm liest die erforderlichen Angaben aus einer Datei (siehe Listing 1) und trägt sie in die entsprechenden Kernel-Datenbanken ein. Die Datei enthält verschiedene Setkey-Kommandos, sie nehmen – durch Leerzeichen getrennt – Parameter entgegen und werden mit einem Strichpunkt abgeschlossen.

Abbildung 4: Für IPsec muss die Kernelkonfiguration in den Netzwerkoptionen die Module AH, ESP und das IPsec-Userspace-Interface einbinden.

Abbildung 5: IPsec benötigt einige kryptographische Funktionen aus der Crypto-API. Mindestens HMAC, MD5, SHA-1, DES und Triple-DES müssen aktiviert sein.

Schlüssel und Policy mit Setkey festlegen

»flush« und »spdflush« löschen zunächst die SAD und die SPD. Anschließend erzeugt der Befehl »add« die Security Associations in der SAD und »spdadd« legt die Security Policies in der SPD an. Das »add«-Kommando hat folgende Parameter, die es in der angegebenen Reihenfolge erwartet:

• Quell-IP-Adresse
• Ziel-IP-Adresse
• IPsec-Protokoll (»ah« oder »esp«)
• Security Parameter Index (als Dezimal- oder
  Hexadezimalwert)
• Optional einige Erweiterungen (etwa »-m
  Modus« für Transport- oder Tunnelmodus)
• Algorithmus und Schlüssel: Authentifizierung mit »-A
  Algorithmus Schlüssel«, Verschlüsselung mit
  »-E Algorithmus Schlüssel«

Wann welche Security Association zum Einsatz kommt, wird von der Policy festgelegt. Hierzu dient der Befehl »spdadd«. Er kennt folgende Parameter:

• Quelle als IP-Adresse oder Netzwerk
• Ziel als IP-Adresse oder Netzwerk
• Upper Layer Protocol: Die Protokolle aus
  »/etc/protocols«, zusätzlich sind
  »icmp6«, »ip4« und »any«
  zulässig
• Richtung der Verbindung: »-P in« oder »-P
  out«
• Danach das Schlüsselwort »ipsec«
• Gefolgt von einer oder mehreren Policy-Spezifikationen

Bei »spdadd« sind die IP-Adressen der tatsächlich kommunizierenden Rechner anzugeben – wichtig ist das bei VPN-Gateways, die den Verkehr stellvertretend für die kommunizierenden Hosts schützen. Die IP-Adresse kann als Host »192.168.0.4« beziehungsweise als Netzwerk »192.168.0.0/24« spezifiziert werden. Die Angabe eines Ports in eckigen Klammern schränkt die Policy weiter ein: »192.168.0.4[80]« schützt zum Beispiel nur HTTP (Port 80).

Der Admin kann die Regeln der Security Policy sehr detailliert festlegen. So ist es möglich, nur bestimmte Netzwerkverbindungen mit IPsec zu sichern. Die meisten IPsec-Implementierungen, die einen direkten Zugriff auf die SAD und die SPD ermöglichen, erlauben diese Einstellungen. Freeswan erhält jedoch erst mit den neuesten X.509-Patches diese Fähigkeit – sie nennt sich dort Port- und Protokollselektor.

#include <net/route.h>

Exakte Regeln

Eine Policy-Spezifikation besteht aus vier Teilen, die durch Schrägstriche voneinander getrennt sind: » Protokoll/Modus/Src-Dst/Level«. Das Protokoll kann »ah« oder »esp« lauten, der Modus ist »transport« oder »tunnel«. Beim Tunnelmodus ist zusätzlich » Src-Dst« nötig, das sind die IP-Adressen der Tunnel-Endpunkte. Ist der Level auf »require« gesetzt, verlangt der Kernel eine gültige SA, wenn er ein Paket versenden soll, auf das die Policy passt. Bei »use« würde er auf ungeschützten IP-Verkehr ausweichen, wenn keine SA passt.

Die Konfigurationsdatei ist auf beiden kommunizierenden Rechner erforderlich. Es darf sich jedoch nicht nur um eine Kopie des gleichen Files handeln. Die Richtungen der Security Policies sind jeweils aus der Blickrichtung des Rechners anzupassen.

Abbildung 6: Beim Testaufbau für den Transportmodus kommunizieren zwei Rechner direkt miteinander. IPsec verschlüsselt und authentifiziert die IP-Pakete beider Computer.

Direkte Verbindung im Transportmodus

Im Beispiel aus Listing 1 kommunizieren zwei Rechner (IP-Adresse 10.0.1.5 und 10.0.2.5) miteinander (siehe Abbildung 6). Jeder Admin sollte die Verbindung zunächst unverschlüsselt testen, denn mit Verschlüsselung ist die Fehlersuche wesentlich schwieriger.

Nachdem der Admin auf beiden Rechnern »setkey -f /etc/ipsec.conf« aufgerufen hat, sollten alle Pakete zwischen ihnen IPsec-verschlüsselt sein. Das lässt sich mit Ping und Tcpdump überprüfen: Der Befehl »tcpdump« zeichnet den in Listing 2 dargestellten Verkehr auf. Die manuell verschlüsselten Verbindungen sind bei entsprechender Konfiguration interoperabel mit anderen Implementierungen, etwa mit Freeswan.

Manuell verschlüsselte Verbindungen werden in der Praxis wahrscheinlich selten genutzt, da sie statische Sitzungsschlüssel verwenden und daher weniger sicher sind als die üblichen, automatisch verschlüsselten Verbindungen. Bei Letzteren übernimmt ein IKE-Daemon den Schlüsselaustausch.

01 #!/usr/sbin/setkey -f
02 #
03 # /etc/ipsec.conf
04 # Manuell verschlüsselte Verbindung im Transportmodus
05 
06 # Lösche die SAD und SPD
07 flush;
08 spdflush;
09 
10 # Manuelle Parameter für AH-SAs mit 128-Bit-Schlüssel für MD5
11 add 10.0.1.5 10.0.2.5 ah 0x200 -A hmac-md5 0xdf84cd88405b8faed89031e4118e6cf6;
12 add 10.0.2.5 10.0.1.5 ah 0x300 -A hmac-md5 0xdf84cd88405b8faed89031e4118e6cf6;
13 # Manuelle Parameter für ESP-SAs mit 192-Bit-Schlüssel für 3DES (168 + 24)
14 add 10.0.1.5 10.0.2.5 esp 0x201 -E 3des-cbc 0x78bab1a6380fa764e4be09da2e13d65076d503cf3089ea82;
15 add 10.0.2.5 10.0.1.5 esp 0x301 -E 3des-cbc 0x78bab1a6380fa764e4be09da2e13d65076d503cf3089ea82;
16 
17 # Richtlinien zur Verwendung der SAs (Security Policies)
18 spdadd 10.0.1.5 10.0.2.5 any -P out ipsec
19            esp/transport//require
20            ah/transport//require;
21 
22 spdadd 10.0.2.5 10.0.1.5 any -P in ipsec
23            esp/transport//require
24            ah/transport//require;

Automatisch verschlüsselt dank IKE-Daemon

Der Linux-Kernel ist nicht in der Lage, das IKE-Protokoll selbst zu nutzen. Kernel-Rechte sind dazu auch nicht nötig, ein externer IKE-Daemon genügt. Er authentifiziert zunächst den Kommunikationspartner mit Hilfe von Preshared Keys (PSK), RSA-Schlüssel, PGP-Schlüssel oder X.509-Zertifikaten.

Dann erzeugt der Daemon eine ISAKMP-Security-Association. Diese bidirektionale SA steuert den Austausch der Sitzungsschlüssel für die Authentifizierung und Verschlüsselung der IP-Pakete. Auf Basis der ISAKMP-SA einigen sich die Kommunikationspartner über die Algorithmen, mit denen sie Pakete verschlüsseln und authentifizieren, die Verfahren, mit denen sie die Sitzungsschlüssel erzeugen und deren Lebensdauer.

Klassische IKE-Daemons sind »pluto« (Freeswan), »isakmpd« (OpenBSD) und »racoon« (KAME-Projekt). Für die hier gezeigte Linux-Implementierung eignen sich »racoon« und »isakmpd« (mit einem Patch[9]). Racoon ist im Moment jedoch mehr zu empfehlen.

Die Konfiguration von Racoon ist recht einfach. Als Beispiel dient ein Tunnel, dessen Enden sich mit Preshared Keys (PSK) authentifizieren. Abbildung 7 zeigt den Aufbau: Die Rechner 10.0.1.5 und 10.0.2.5 dienen als Gateways für die Netze 192.168.1.0/24 und 192.168.2.0/24. Durch den Tunnel können die Teilnehmer verschlüsselt miteinander kommunizieren. Listing 3 zeigt die Konfigurationsdatei »/etc/racoon.conf« für das linke VPN-Gateway 10.0.1.5.

Diese Konfigurationsdatei weist Racoon an, einen Tunnel vom IP-Netzwerk 192.168.1.0/24 ausgehend zum Netzwerk 192.168.2.0/24 aufzubauen. Der Admin muss dazu einige Parameter festlegen und ein Proposal angeben (Vorschlag für die Parameter einer SA). Das Proposal enthält den Verschlüsselungs-, den Authentifizierungs- und den Kompressionsalgorithmus sowie die Diffie-Hellmann-Gruppe. Im Gegensatz zu Racoon wählt Freeswan automatisch diese Parameter und überlässt dem Admin nur in wenigen Fällen die Kontrolle.

Freeswan unterstützt ohne Patches lediglich den IKE-Exchange-Mode »main«, die Verschlüsselung mit Triple-DES und die Hash-Algorithmen MD5 und SHA-1 sowie die Diffie-Hellmann-Gruppen 2 (»modp1024«) und 5 (»modp1536«).

Abbildung 7: Im Tunnel-Testaufbau kommunizieren die Rechner zweier Netzwerke sicher über ein IPsec-VPN. Der IKE-Daemon Racoon sorgt für den Schlüsselaustausch.

Flexibel dank Racoon

Racoon unterstützt wesentlich mehr Modi, Algorithmen und DH-Gruppen. Es kennt die Modi »main«, »aggressive« und »base« in der Phase 1. Die Verschlüsselung und Authentifizierung ist mit jedem Algorithmus möglich, den der Kernel unterstützt. Die Racoon-Manpage nennt alle unterstützten Methoden.

Racoon soll sich im Testaufbau mit Preshared Keys authentifizieren. Der VPN-Admin speichert dazu den Schlüssel in »/etc/psk.txt«:

# IP-Adresse des Partners    PSK
10.0.2.5                     einfacher PSK

Dabei muss er die Vertraulichkeit des Schlüssels gewährleisten: »chmod 400 /etc/psk.txt«. Diese Datei entspricht bei Freeswan »/etc/ipsec.secrets«. E

Racoon baut den Tunnel nicht selbstständig auf, auch wenn beide Rechner korrekt konfiguriert sind. Hierfür ist erst eine Aufforderung durch den Linux-Kernel nötig, Freeswan verhält sich anders, es stellt den Tunnel dauerhaft zur Verfügung. Um Racoon bei Bedarf zu informieren, benötigt der Linux-Kernel eine entsprechende Security Policy. Sobald er ein Paket verschlüsseln muss, aber keine passende Security Association findet, beauftragt der Kernel den IKE-Daemon damit, die SA auszuhandeln. Das Beispiel in Abbildung 7 benötigt die Konfiguration aus Listing 4. Die Syslog-Meldungen eines erfolgreichen Tunnel-Aufbaus sind in Listing 5 zu sehen.

Fazit

Der Artikel zeigt, dass VPNs mit dem aktuellen Linux-Kernel 2.5 bereits recht einfach zu realisieren sind. Der Code wird in den nächsten Wochen und Monaten bis zur Freigabe des Kernels 2.6 noch weiter reifen. Racoon hat seine Interoperabilität als IKE-Daemon bereits im Rahmen des KAME-Projektes mehrfach bewiesen und bietet eine sehr ausgereifte Implementierung.

Der neue IPsec-Code bedeutet nicht automatisch das Ende des Freeswan-Projekts, es wird weiterhin seinen Stellenwert als IPsec-Implementierung für Kernel 2.2 und 2.4 behalten. Außerdem haben die Freeswan-Entwickler auf ihrer Mailingliste bereits mehrfach die Portierung der Freeswan-Userspace-Werkzeuge auf den neuen IPsec-Code besprochen und angekündigt. Mit ersten Versionen ist zum Erscheinen des Linux-Kernels 2.6 zu rechnen.

VPN-Admins haben dann die Wahl, ihre bestehende Konfiguration zu übernehmen oder auf die neuen Tools umzusteigen. In beiden Fällen ist der neue IPsec-Code eine solide Basis. (fjl)

01 12:47:21.334805 10.0.1.5 > 10.0.2.5: AH(spi=0x00000200,seq=0x1): ESP(spi=0x00000201,seq=0x1) (DF)
02 12:47:21.473836 10.0.2.5 > 10.0.1.5: AH(spi=0x00000300,seq=0x1): ESP(spi=0x00000301,seq=0x1)

01 path pre_shared_key "/etc/psk.txt";
02 
03 remote 10.0.2.5 {
04         exchange_mode main;
05         proposal {
06                 encryption_algorithm 3des;
07                 hash_algorithm md5;
08                 authentication_method pre_shared_key;
09                 dh_group modp1024;
10         }
11 }
12 
13 sainfo address 192.168.1.0/24 any  address 192.168.2.0/24 any {
14         pfs_group modp1024;
15         encryption_algorithm 3des;
16         authentication_algorithm hmac_md5;
17         compression_algorithm deflate;
18 }

01 #!/usr/sbin/setkey -f
02 #
03 # /etc/ipsec.conf
04 # Automatisch verschlüsselte Verbindung im Tunnelmodus
05 
06 flush;
07 spdflush;
08 
09 # Richtlinien zum Aufruf von Racoon
10 spdadd 192.168.1.0/24 192.168.2.0/24 any  -P out ipsec
11            esp/tunnel/10.0.1.5-10.0.2.5/require;
12 
13 spdadd 192.168.2.0/24 192.168.1.0/24 any -P in ipsec
14            esp/tunnel/10.0.2.5-10.0.1.5/require;

01 2003-01-21 21:11:17: INFO: main.c:170:main(): @(#)racoon 20001216 20001216 sakane@kame.net
02 2003-01-21 21:11:17: INFO: main.c:171:main(): @(#)This product linked OpenSSL 0.9.6b [engine] 9 Jul 2001 (http://www.openssl.org/)
03 2003-01-21 21:11:17: INFO: isakmp.c:1365:isakmp_open(): 127.0.0.1[500] used as isakmp port (fd=7)
04 2003-01-21 21:11:17: INFO: isakmp.c:1365:isakmp_open(): 10.0.1.1[500] used as isakmp port (fd=8)
05 2003-01-21 21:11:17: INFO: isakmp.c:1365:isakmp_open(): 10.0.1.5[500] used as isakmp port (fd=9)
06 2003-01-21 21:11:37: INFO: isakmp.c:1689:isakmp_post_acquire(): IPsec-SA request for 10.0.2.5 queued due to no phase1 found.
07 2003-01-21 21:11:37: INFO: isakmp.c:794:isakmp_ph1begin_i(): initiate new phase 1 negotiation: 192.168.1.5[500]<=>192.168.2.5[500]
08 2003-01-21 21:11:37: INFO: isakmp.c:799:isakmp_ph1begin_i(): begin Identity Protection mode.
09 2003-01-21 21:11:37: INFO: vendorid.c:128:check_vendorid(): received Vendor ID: KAME/racoon
10 2003-01-21 21:11:37: INFO: vendorid.c:128:check_vendorid(): received Vendor ID: KAME/racoon
11 2003-01-21 21:11:38: INFO: isakmp.c:2417:log_ph1established(): ISAKMP-SA established 10.0.1.5[500]-10.0.2.5[500] spi:6a01ea039be7bac2:bd288ff60eed54d0
12 2003-01-21 21:11:39: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new phase 2 negotiation: 10.0.1.5[0]<=>10.0.2.5[0]
13 2003-01-21 21:11:39: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA established: ESP/Tunnel 10.0.2.5->10.0.1.5 spi=68291959(0x4120d77)
14 2003-01-21 21:11:39: INFO: pfkey.c:1321:pk_recvadd(): IPsec-SA established: ESP/Tunnel 10.0.1.5->10.0.2.5 spi=223693870(0xd554c2e)