DE60311898T2

DE60311898T2 - Verfahren, um ein Paket von einem ersten IPSeC Klienten zu einem zweiten IPSec Klienten über einen L2TP Tunnel zu übertragen

Info

Publication number: DE60311898T2
Application number: DE60311898T
Authority: DE
Inventors: Sandra Lynn Santa Clara County Carrico; Philippe San Francisco Hebrais
Original assignee: AT&T Corp
Current assignee: AT&T Corp
Priority date: 2002-01-11
Filing date: 2003-01-09
Publication date: 2007-11-15
Anticipated expiration: 2023-01-10
Also published as: IL153821A0; EP1328105B1; EP1328105A1; DE60311898D1; US20030135616A1; CA2415527C; CA2415527A1

Description

TECHNISCHES GEBIET
Diese Erfindung stellt eine Technik für die Herstellung einer sicheren Internet-Kommunikation zwischen zwei Entitäten bereit.
HINTERGRUND TECHNIK
Das IPsec (Internet-Sicherheitsprotokoll) ist ein von dem Internet Engineering Taskforce (ITEF) veröffentlichtes Protokoll für die Herstellung von Sicherheit in der Netzwerk(Paket)-Verarbeitungsschicht. Gegenwärtig ist das IPsec-Protokoll vielversprechend in Bezug auf das Virtuelle Private Netzwerk und entfernte Anwendungen für Verbindungsaufbau. Ein Benutzer, der das IPsec-Protokoll verwendet, gerät jedoch für gewöhnlich in Schwierigkeiten bei der Überquerung von Vorrichtungen für Netzwerk-Adressumwandlung (NAT) und Firewalls, für die der Benutzer über keine Steuerung verfügt. Derartige Schwierigkeiten setzen den Verwendungswert des IPsec-Protokolls sehr stark herab. Aus diesem Grund haben die meisten Verkäufer von Hardware/Software für IPsec-Sicherheit proprietäre Tunnel-Protokolle für den Transport von IPsec-Paketen in dem Bestreben entwickelt, dieses Problem zu bewältigen.
Die Verwendung eines proprietären Tunnel-Protokolls zieht gewisse Nachteile im Vergleich zu der Verwendung eines offenen (nicht-proprietären) Tunnel-Protokolls nach sich. Im Gegensatz zu einem offenen Tunnel-Protokoll, dessen Spezifikation weit verbreitet ist, bleiben die mit proprietären Tunnel-Protokollen assoziierten Details für gewöhnlich vertraulich, was weniger Zuversicht in die Sicherheitseigenschaften der Protokolle gewährt. Somit hat bei den meisten proprietären Tunnel-Protokollen der assoziierte Quellcode keine gleichrangige Bewertung genossen und die begleitende Identifizierung von Fehlern kann durch Hacker ausgenutzt werden. Außerdem verfügen offene Tunnel-Protokolle im Allgemeinen über keine Lizenzeinschränkungen im Gegensatz zu proprietären Tunnel-Protokollen.
Die US 2001/0020273 A1 (D1) lehrt ein Verfahren der Kommunikation für ein virtuelles privates Netzwerk (VPN), das es einem Sender, z. B. einem Personalcomputer (PC), außerhalb eines lokalen Netzwerkes (LAN) gestattet, über ein weites Netzwerk (WAN) auf einen Empfänger, z. B. einem Endgerät, auf dem LAN zuzugreifen. Der äußere Sender wird somit virtuell als ein Endgerät auf dem LAN betrachtet. Gemäß dem Verfahren, das durch D1 offenbart wird, erzeugt der äußere Sender ein Paket für die Übertragung zu dem LAN-Empfänger und überträgt dieses Paket zu einem Mittler, z. B. einem Sicherheits-Gateway. Der Mittler (Sicherheits-Gateway) empfängt das Paket und hüllt das Paket gemäß der Information ein, die über eine frühere Internet-Schlüsselaustausch(IKE)-Kommunikation mit dem LAN-Empfänger ausgetauscht wurde. Der Sicherheits-Gateway fügt ferner eine Authentifizierungsinformation hinzu und verschlüsselt das Paket und sendet anschließend das Paket zu dem LAN-Empfänger, der die in dem Paket enthaltene Information wiedergewinnt und verarbeitet.
Die WO 01/15396 A1 beschreibt einen Circuit-Emulator-Dienst über ein Internetprotokoll(IP)-Netzwerk, in dem ein IPSec-Header optional mit einem L2TP-Header verwendet wird.
Somit ist ein Bedarf nach einem offenen Tunnel-Protokoll für den Transport von IPsec-Paketen vorhanden, das die Nachteile des Standes der Technik überwindet.
KURZE ZUSAMMENFASSUNG DER ERFINDUNG
Die Erfindung sieht ein Verfahren vor, das wie in Anspruch 1 bestimmt ist. Kurz gesagt wird gemäß einer ersten bevorzugten Ausführungsform der Erfindung eine Technik zum Senden eines IPsec-Pakets von einem ersten IPsec-Client zu einem zweiten IPsec-Client bereitgestellt, so dass das Paket bei dem Ereignis der Überquerung einer Firewall und/oder einer Vorrichtung für Netzwerk-Adressumwandlung (NAT) unberührt bleibt. Um eine derartige Übertragung eines IPsec-Pakets zu bewerkstelligen, wird das IPsec-Paket in ein offenes (z. B. nicht-proprietäres) Tunnel-Protokoll-Format verpackt, wie z. B. das Layer-2-Tunneling-Protokoll-(L2TP)-Format, und wird von dem ersten IPSec-Client an einem L2TP-Netzwerkserver in einem Kommunikations-Netzwerk empfangen. Der L2TP-Netzwerkserver erstellt einen L2TP-Tunnel zu dem zweiten IPSec-Client und stellt dann eine Sicherheitsverbindung zwischen den IPsec-Clients her. Danach sendet der L2TP-Netzwerkserver das Paket zu dem zweiten IPsec-Client, so dass das Paket bei dem Ereignis der Überquerung einer Firewall und/oder einer Vorrichtung für Netzwerk-Adressumwandlung unberührt bleibt.
Das L2TP kann L2TP-formatierte Pakete von dem ersten IPsec-Client über eine zugeordnete Verbindung (z. B. einen Tunnel) empfangen, die von dem ersten IPsec-Client geöffnet wurde. Alternativ kann der erste IPsec-Client auf den L2TP-Netzwerkserver über das öffentliche Internet unter der Voraussetzung zugreifen, dass die Firewall-Richtlinien des L2TP-Netzwerkservers öffentlich gerouteten Verkehr zulassen. Falls eine oder mehrere NAT-Vorrichtungen den ersten und zweiten IPsec-Client separieren, können beide Clients eine Kommunikationssitzung beginnen, indem jeder einen Tunnel zu dem L2TP-Netzwerkserver öffnet, wodurch es den Clients gestattet wird, miteinander zu kommunizieren, während sie eine beliebige NAT-Vorrichtung umgehen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 stellt eine erste Ausführungsform einer Netzwerk-Architektur zur Befähigung eines ersten IPsec-Clients für die Korrespondenz eines IPsec-formatierten Pakets zu einem zweiten IPsec-Client dar;
2 stellt eine zweite Ausführungsform einer Netzwerk-Architektur zur Befähigung eines ersten IPsec-Clients für die Korrespondenz eines IPsec-formatierten Pakets zu einem zweiten IPsec-Client dar; und
3 stellt eine Ausführungsform einer Netzwerk-Architektur zur Befähigung eines ersten IPsec-Clients für die Korrespondenz eines IPsec-formatierten Pakets zu einem zweiten Client dar.
DETAILLIERTE BESCHREIBUNG
Die 1 zeigt eine erste Netzwerk-Architektur 10 zur Befähigung eines ersten IPsec-Clients, dargestellt durch den IPsec-Gateway 12, für die zuverlässige Sendung von ein oder mehreren IPsec-formatierten Paketen zu einem zweiten IPsec-Client 14 (z. B. eine IPsec-Sicherheitsvorrichtung, die mit einem Personalcomputer 15 verbunden ist), und zwar ohne jegliche schädliche Auswirkungen, die mit der Überquerung von (einer) beliebigen Vorrichtung(en) für Netzwerk-Adressumwandlung und/oder Firewalls verbunden sind. Das Netzwerk 10 schließt einen offenen (nicht-proprietären) Format-Tunneling-Protokollnetzwerkserver ein, wie z. B. einen Layer-2-Tunneling-Protokoll-(L2TP)-Netzwerkserver 16. In der dargestellten Ausführungsform der 1 ist der L2TP-Netzwerkserver 16 direkt mit dem IPsec-Gateway 12 über ein herkömmliches lokales Netzwerk (LAN) gekoppelt, das als ein Ethernet-LAN 18 gezeigt ist. Auf diese Weise kann der L2TP-Netzwerkserver 16 direkt mit dem IP-Gateway 12 kommunizieren, ohne jegliche Firewalls zu überqueren, wie z. B. die Firewall 20, die das Netzwerk 18 schützt.
Der L2TP-Netzwerkserver 16 fungiert, um individuelle L2TP-Tunnel in dem Netzwerk 10 zu verschiedenen Endpunkten zu erstellen, so dass die von dem Tunnel getragenen L2TP-formatierten Pakete bei dem Übergang durch jegliche Vorrichtungen für Netzwerk-Adressumwandlung (NAT) und/oder Firewalls nicht berührt werden. Somit kann zum Beispiel der L2TP-Netzwerkserver 16 einen Tunnel 21 zu einem Internet-Dienstanbieter-Netzwerk 26 erstellen, das dem IPsec-Client 14 derart dient, dass die von dem Tunnel getragenen L2TP-formatierten Pakete von der NAT-Vorrichtung 22 unberührt bleiben.
Um ein Paket zu dem IPsec-Client 14 über den L2TP-Netzwerkserver 16 zu senden, erhält der erste IPsec-Client (d. h. der IPsec-Gateway 12 der 1) eine private Realm-Adresse für den IPsec-Client 14 von dem ISP-Netzwerk 26. Die private Realm-Adresse unterliegt typischerweise der Adressumwandlung durch das NAT 22 und der genauen Untersuchung durch die Firewall des ISP (ist nicht gezeigt). Sollte der IPsec-Gateway 12 ein IPsec-formatiertes Paket zu der privaten Realm-Adresse durch Routen des Pakets über den Router 25, dem öffentlichen Internet 24, dem NAT 22 und dem ISP-Netzwerk 26 senden, würden sich somit wahrscheinlich Übertragungsschwierigkeiten ergeben.
Um derartige Schwierigkeiten zu vermeiden, beginnt die Datenübertragung gemäß der Erfindung, indem der IPsec-Gateway 12 einen L2TP-Tunnel 28 mit dem L2TP-Netzwerkserver 16 öffnet. Nach dem Öffnen des Tunnels erhält der IPsec-Gateway 12 eine Adresse, die mit dem Ende des Tunnels 28 an dem L2TP-Netzwerkserver 16 assoziiert ist. Bei einem dem L2TP-Netzwerkserver 16 nun offenen Tunnel verpackt der IPsec-Gateway 12 jedes IPsec-Paket in ein L2TP-Format, und zwar typischerweise durch Einhüllen des IPsec-Pakets in eine L2TP-Schale für die Übertragung zu dem L2TP-Netzwerkserver unter Verwendung der Adresse, die mit dem Ende des Tunnels 28 assoziiert ist, der mit dem Server endet.
Nach Empfang des L2TP-formatierten Pakets, das das IPsec-Paket enthält, gestattet es dann der L2TP-Netzwerkserver 16 dem IPsec-Gateway 12 (der erste IPsec-Client), eine Sicherheit, die mit dem IPsec-Client 14 assoziiert ist, über den Tunnel 21 herzustellen. Sobald die Sicherheitsverbindung hergestellt ist, sendet der L2TP-Netzwerkserver 16 jedes von dem IPsec-Gateway 12 empfangene L2TP-verpackte IPsec-Paket über den Tunnel 21 zu dem IPsec-Client 14.
Um die Paketübertragung in der beschriebenen Art und Weise zu erleichtern, kann der L2TP-Netzwerkserver 16 dem IPsec-Gateway 12 virtuell eine beliebige Adresse, die für das Ende des Tunnels 28 bestimmt ist, unter der Voraussetzung zuteilen, dass eine derartige Adresse sich nicht mit der privaten Realm-Adresse für das ISP-Netzwerk 26 im Konflikt befindet. Aus diesem Grund sollte der L2TP-Netzwerkserver 16 vorzugsweise separate private Realm-Adressen zuteilen, um die Reservierung einer großen Auswahl von potenziellen Adressen zu vermeiden, die mit dem Ende des Tunnels 28 assoziiert sind. In einem solchen Fall muss (müssen) die Routing-Tabelle(n) des IPsec-Gateways 12 entsprechend angepasst sein. Um die derartige Paketübertragung zu erleichtern sollte ferner die Firewall des L2TP-Netzwerkservers 16 einen IPsec- und IKE-Verkehr von dem IPsec-Gateway 12 zulassen und sollte auch einen L2TP-Verkehr zwischen sich selbst und dem öffentlichen Internet 24 zulassen, während anderer Verkehr nicht zugelassen wird.
Die 2 zeigt eine zweite Ausführungsform einer Netzwerk-Architektur 100 für die Übertragung von IPsec-Paketen gemäß der Erfindung. Die Architektur 100 verwendet Elemente, die mit der Architektur 10 der 1 gemeinsam sind, und deshalb bezeichnen ähnliche Bezugsziffern ähnliche Elemente. Die Architektur 100 der 2 unterscheidet sich von der Architektur 10 der 1 in einer Haupthinsicht. In der Netzwerk-Architektur 100 der 2 genießt der L2TP-Netzwerkserver 16 keine zugeordnete Verbindung mit einem bestimmten IPsec-Gateway, wie z. B. über den Tunnel 28 in der Netzwerk-Architektur 10 der 1. Mit der Netzwerk-Architektur 100 der 2 kann an Stelle davon der L2TP-Netzwerkserver 16 auf einen beliebigen IPsec-Client zugreifen, wie z. B. den IPsec-Gateway 12 der 2, der auf dem öffentlichen Internet 24 sichtbar ist. (In der Netzwerk-Architektur 100 der 2 genießen sowohl der IPsec-Gateway 12 als auch der L2TP-Netzwerkserver 16 eine Verbindung mit demselben Router (d. h. Router 25), so dass der Server L2TP-verpackte IPsec-Pakete von dem IPsec-Gateway 12 über den Router 25 ohne eine tatsächliche Verbindung mit dem öffentlichen Internet 24 empfangen kann.)
Um die Übertragung von IPsec-Paketen zu erleichtern, muss der L2TP-Netzwerkserver 16 der 2 den IPsec-Clients, wie z. B. dem IPsec-Gateway 12 der 2, öffentlich routfähige Adressen zuteilen. Ansonsten könnte der IPsec-Gateway der 2 mit dem L2TP-Netzwerkserver 16 nicht betriebsbereit kommunizieren. Ferner muss der L2TP-Netzwerkserver 16 über ausreichend aufgelockerte Firewall-Richtlinien verfügen, um IPsec- und IKE-Verkehr von einer beliebigen IP-Adresse zuzulassen.
Der Zugriff auf den L2TP-Netzwerkserver 16 über das öffentliche Internet 24 liefert eine Flexibilität, zieht aber die Möglichkeit einer Verzögerung nach sich, weil Pakete zuerst über das öffentliche Internet 24 zu dem Server (oder in dem Fall der 2 über den Router 25 zu dem L2TP-Server) und dann schließlich von dem Server zu dem Bestimmungsort geroutet werden. Im Vergleich vermeidet die Netzwerk-Architektur 10 der 1 diese mögliche Schwierigkeit, weil sich der L2TP-Netzwerkserver 16 als auch der IPsec-Gateway 12 auf demselben lokalen Netzwerk befinden.
Die 3 stellt eine dritte Netzwerk-Architektur 1000 zur Erleichterung einer Opportunist-Verschlüsselung zwischen dem ersten und zweiten IPsec-Client 120 und 140 dar, wobei jeder typischerweise eine IP-Sicherheitsvorrichtung umfasst, die jeweils einem entsprechenden der Computer 150₁ und 150₂ dient. In der Ausführungsform der 3 verfügt jeder der IPsec-Clients 120 und 140 über eine Verbindung über jeweils ein separates der ISP-Netzwerke 260₁ und 260₂ und der NAT-Vorrichtungen 250₁ und 250₂ mit dem öffentlichen Internet 240.
Um IPsec-Pakete sicher auszutauschen, öffnet jeder der IPsec-Clients 120 und 140 jeweils einen separaten der L2TP-Tunnel 280₁ und 280₂ zu einem L2TP-Netzwerkserver 160, der auf dieselbe Art und Weise wie der L2TP-Netzwerkserver 16 der 1 und 2 konfiguriert ist. Mit den für die IPsec-Clients 120 bzw. 140 geöffneten Tunneln 280₁ und 280₂ gestattet es der L2TP-Netzwerkserver 160 den zwei IPsec-Clients, eine Sicherheitsverbindung herzustellen. Nachdem eine Sicherheitsverbindung zueinander hergestellt wurde, kann jeder IPsec-Client ein IPsec-Paket zu dem anderen über den L2TP-Netzwerkserver 160 senden. Mit den für die IPsec-Clients 120 bzw. 140 geöffneten Tunneln 280₁ und 280₂ kann der L2TP-Netzwerkserver 160 das L2TP-verpackte IPsec-Paket von einem IPsec-Client zu einem anderen korrespondieren, während jegliche Übertragungsschwierigkeiten über jede der NAT-Vorrichtungen 250₁ und 250₂ vermieden werden.
Die Netzwerk-Architektur 1000 der 3 zeigt einen einzelnen L2TP-Netzwerkserver 160, der beiden IPsec-Clients 120 und 140 dient. Unter solchen Umständen würde der L2TP-Netzwerkserver jedem IPsec-Client eine den Server identifizierende private Realm-Adresse zuteilen, um es jedem IPsec-Client zu gestatten, mit dem Server zu kommunizieren, damit für jeden IPsec-Client ein entsprechender der Tunnel 280₁ und 280₂ geöffnet wird. In dem Fall von mehreren L2TP-Netzwerkservern müsste jeder eine öffentlich routfähige Adresse für den IPsec-Client zuteilen, der von jedem Server bedient wird.
Die Implementierung des Übertragungsverfahrens von IPsec-Paketen der Erfindung setzt einige Anforderungen an den IPsec-Gateway 12 der 1 und 2. In der öffentlichen Implementierung der 2 muss sich der IPsec-Gateway 12 tatsächlich nicht einmal dessen bewusst sein, dass irgendetwas spezielles stattfindet. Die einzigen Anforderungen sind die üblichen Anforderungen an einen IPsec-Gateway: dass er auf dem öffentlichen Internet 24 sichtbar ist, dass er den L2TP-Netzwerkserver 16 sieht und dass er den öffentlichen Teil der von den IPsec-Clients, wie z. B. dem IPsec-Client 14, verwendeten Schlüssel während der Authentifizierung kennt.
In dem Fall, wo der L2TP-Netzwerkserver 16 der 1 und 2 private Realm-Adressen den IPsec-Clients zuteilt, wie z. B. dem IPsec-Client 14, muss der IPsec-Gateway über Routing-Tabellen-Eingaben verfügen, um Pakete für diese Adressen entsprechend über den L2TP-Netzwerkserver zu routen.
Die Anforderungen für den L2TP-Netzwerkserver 16 und 160 unterscheiden sich für unterschiedliche Implementierungsszenarios. In sämtlichen Fällen muss der L2TP-Netzwerkserver für die IPsec-Clients sichtbar sein. Zusätzlich sollte der L2TP-Netzwerkserver 16 den Authentifizierungsmechanismus in sowohl dem L2TP als auch PPP verwenden und er sollte die Paket-Komprimierung abschalten. Die Sicherheitsmechanismen des L2TP und PPP sind rudimentär und nicht ausreichend, um gegen Denial-of-Service-Angriffe zu schützen, aber sie erschweren die Arbeit der Hacker tatsächlich. Die Komprimierung ist hier nutzlos, weil die Pakete verschlüsselt werden, bevor sie an das PPP für die Komprimierung übertragen werden. In Abhängigkeit von dem Szenario teilt der L2TP-Netzwerkserver private Realm- oder öffentliche Realm-Adressen den IPsec-Clients zu und muss somit eine geeignete Auswahl von zuzuteilenden Adressen aufweisen.
Weil der L2TP-Netzwerkserver Routing-Verzögerungen und mögliche Denial-of-Service-Angriffe einbringt, sollte er nur verwendet werden, wenn eine NAT-Vorrichtung oder eine inkompatible Firewall mit dem IPsec-Verkehr wechselwirkt. Der IPsec-Client muss deshalb über einen Zugriff auf einen 'NAT-Feststellungsdienst' verfügen, der ihm zu bestimmen hilft, ob der L2TP-Tunnel benötigt wird. Dieser Dienst kann viele Formen annehmen aber die einfachste Form ist ausreichend, und zwar ein UDP-Dienst, der die Adresse und den Port der Quelle wiedergibt, von dem er die Anfrage kommen sieht. Das Platzieren von diesem NAT-Feststellungsdienst auf derselben Maschine wie das LNS erscheint am einfachsten und am effektivsten. In der Ausführungsform der 1 sind das LNS und der IPsec-Gateway miteinander gekoppelt und es könnte sich somit als nützlich erweisen, diese Verbindung durch die Verwendung von zugehörigen Domain-Namen zu reflektieren, wie z. B. ipsec.corporate.domain.net und 12tp.corporate.domain.net. Das würde die Aufgabe des IPsec-Clients erleichtern, einen geeigneten L2TP-Server für einen gegebenen IPsec-Gateway zu lokalisieren.
Die Implementierung des Übertragungsverfahrens für IPsec-Pakete der Erfindung erfordert, dass jeder IPsec-Client den L2TP-Netzwerkserver in dem Client-Modus als auch IPsec unterstützt. In beiden Fällen muss der Client für das gewählte Szenario (öffentliche und private Schlüssel, Kenntnis des IPsec-Gateways und der LNS-Adressen, usw.) natürlich entsprechend konfiguriert sein. Zusätzlich muss die Herstellung der Netzwerkverbindung modifiziert sein, um die NAT-Feststellung durchzuführen und, falls angebracht, den L2TP-Tunnel vor dem Herstellen der IPsec-Sicherheitsverbindung zu öffnen.
Die oben beschriebenen Ausführungsformen stellen lediglich die Prinzipien der Erfindung dar. Der Fachmann kann verschiedene Modifikationen und Änderungen vornehmen, die die Prinzipien der Erfindung verkörpern und unter den Schutzumfang davon fallen.
Dort, wo technische Merkmale, die in irgendeinem Anspruch erwähnt sind, von Bezugsziffern gefolgt werden, sind diese Bezugsziffern für den alleinigen Zweck der Steigerung der Verständlichkeit der Ansprüche eingefügt worden, und dementsprechend besitzen derartige Bezugsziffern keine beschränkende Wirkung auf den Schutzumfang von jedem Element, das von derartigen Bezugsziffern beispielhaft identifiziert wird.

Claims

Ein Verfahren zum Senden eines Pakets von einem ersten IPSec-Client (12; 120) zu einem zweiten IPSec-Client (14; 140), das die folgenden Schritte umfasst: Empfangen an einem nicht-proprietären Format-Tunneling-Protokollserver (16; 160) von dem ersten IPSec-Client (12; 120) eines IPSec-Pakets, das in dem nicht-proprietären Tunnel-Format verpackt ist; Erstellen eines nicht-proprietären Format-Tunneling-Protokolltunnels (21; 280₂ ) zu dem zweiten IPSec-Client (14; 140) über den nicht-proprietären Format-Tunneling-Protokollserver (16; 160); Herstellen einer Sicherheitsverbindung zwischen dem ersten und zweiten IPSec-Client (12, 14; 120, 140) über den nicht-proprietären Format-Tunneling-Protokollserver (16; 160); und Senden des Pakets über das nicht-proprietäre Format-Tunneling-Protokolltunnel (21; 280₂ ) zu dem zweiten IPSec-Client (14; 140), wobei das Paket von jeglicher Adressumwandlung oder Firewall-Überquerung, die sich während der Sendung ereignen können, unberührt bleibt.
Das Verfahren gemäß Anspruch 1, wobei das nicht-proprietäre Tunneling-Protokoll ein Layer-2-Tunneling-Protokoll-(L2TP)-Protokoll umfasst.
Das Verfahren gemäß Anspruch 2, wobei der Empfangsschritt die folgenden Schritte einschließt: Öffnen eines L2TP-Tunnels (28; 280₁ ) zwischen dem ersten IPSec-Client (12; 120) und dem Server (16; 160); und Übertragen eines IPSec-Pakets, das in einem L2TP-Format verpackt ist, zu dem Server (16; 160).
Das Verfahren gemäß Anspruch 2, wobei der Empfangs schritt den Schritt des Routens eines IPSec-Pakets, das in einem L2TP-Format verpackt ist, zu dem Server (16) über eine öffentliche Adresse einschließt.
Das Verfahren gemäß Anspruch 4, wobei die öffentliche Adresse von dem Server (16) zu dem ersten IPSec-Client (12) geliefert wird.
Das Verfahren gemäß einem oder mehreren der Ansprüche 1–5, wobei der Schritt des Erstellens des nicht-proprietären Format-Tunneling-Protokolltunnels (21; 280₂ ) zu dem zweiten IPSec-Client (14; 140) den Schritt des Bereitstellens einer öffentlichen Adresse für den zweiten Client (14; 140) einschließt, die den Server (16; 160) identifiziert.