VPN Tunnel in VPN Tunnel?
 

Geht sowas?

Ich mein damit, man hat einen zum Provider (ADSL) und baut dann innerhalb dieses Tunnels noch einen 2. zu irgendeinem anderen Server auf.
Hab zwar schon ein paar Leute gefragt, aber die haben gmeint geht nicht, waren sich aber nicht sicher.

hallo...

unter win98 gehts nicht, da du auf einmal nur eine vpn-verbindung öffnen kannst....

unter win2k oder winxp hab ich das noch nicht probiert, soll aber laut kollegen von mir funktionieren....

eine weitere möglichkeit ist, die adsl-verbindung mit einem router herstellen zu lassen und mit dem rechner dann die gewünschte vpn-verbindung....

@LLR stimmt, aber man kann es aber umgehen. Welches VPN willst du tunneln?

ja, das geht...

wir haben bei einem kunden altavista tunnel über adsl um von extern aufs firmennetzwerk zugreifen zu können...

das funzt einwandfrei, auch wenn ich sagen würde, die altavista tunnelsw is a leichter krampf, aber es funzt....

weiß nicht, war nur mal so eine Idee. :) Ob ich mir zB einen Tunnel zu unserem Schulserver machen könnte oder sowas in der Art halt.

@valo: ich nehm amal an, Altavista is a Zusatzsoftware- und net zu Suchmaschine. ;)

Hi!

Mit ipsec geht's sicher!

Grüße

Manx

jo, wenn eh nur so...

Weil es sind nur Win2k Rechner daran beteiligt.

geht recht einfach, zb mit adsl und der checkpoint client sw. (damit fagst halt ned viel an ohne checkpoint fw ;) )

1x vpn => adsl
1x vpn => cp client zur firmen fw

was hat den dein Schulserver für ne VPN Software oben ?

Ich verwende in der Firma auch VPN. Ich habe ca 50 Partnerfirmen die sich über VPN bei uns Files / Mails und SQL Daten holen. Es verwenden eigentlich fast alle FWZ. Bei mir ist die Firewall (Checkpoint NG) der VPN Server.

Hier ein Auszug aus dem Technischen Anforderungsblatt das wir den ISPs unserer Partner schicken:

Notwendige IP Services und Protokolle, die für ein einwandfreies Funktionieren benötigt werden:


Es stehen drei verschiedene VPN Schemata zur Verfügung:
· FWZ (CheckPoint)
· IKE (IPSec DES/3DES/AES)
· PPTP

FWZ

Firewall: CheckPoint NG FP-1, 3DES/AES128-256
Verschlüsselung: FWZ Verschlüsselung, FZW-1 Alg, RC5
Client: CheckPoint SecuRemote Client, NG FP-1, Build 51057
3DES or AES128-256, for Win2K
Windows 2000 Professional, SP2, SRP-1 inkl. akt. HotFixes

Der von CheckPoint verwendete Verschlüsselungsalg. FWZ-1 ist ein von CheckPoint selbstentwickelter proprietärer symmetrischer Algorithmus, der das Reliable Datagram Protocol (UDP Port 259) verwendet, um das VPN Session Key Management abzuwickeln. Es ist eine sog. In-Place Encryption, d.h., es wird nur der Datenanteil in den IP-Paketen verschlüsselt, nicht der Header (im Gegensatz zu AH bzw ESP); der Header bleibt unverändert. Da jedoch das Paket auch encapsulated wird und der Header authentifiziert, ist es somit auch über NAT und andere Adress-Translation-Mechanismen bzw. in reserved IP Ranges nicht verwendbar. Diese FWZ-Encapsulation verwendet Pakete mit der GRE (Generic Routing Encapsulation) - Generic Type Definition (Pre Match Code: ip_p=0x5e (= dez. 94)).

Um ein VPN über FWZ zu ermöglichen, müssten sowohl RDP Pakete (UDP Port 259) als auch Generic IP Packages mit dem Pre Match Code: ip_p=0x5e (= dez. 94) transportierbar sein. Ohne dies funktioniert ein VPN-Tunnel mit einer CheckPoint FireWall-1 auf Basis von FWZ nicht. Der Kunde wird zwar auch wahlweise IKE mit 3DES und in näherer Zukunft AES verwenden, dies kann momentan aber noch nicht verwendet bzw. getestet werden, weswegen die VPN-Variante über FWZ momentan unabdingbar ist.

IKE (IPSec) – Variante 1

Firewall: CheckPoint NG FP-1
Verschlüsselung: IKE (ISAKMP/Oakley)
Encryption: CAST, DES, 3DES, AES-128, AES-256
Data Integrity: MD5, SHA-1
Client: CheckPoint SecuRemote Client, NG FP-1, Build 51057
for Windows 2000 Professional, SP2, SRP-1 inkl. HotFixes

IKE (IPSec) – Variante 2

Firewall: F-Secure Distributed FireWall
Verschlüsselung: IKE (ISAKMP/Oakley)
Encryption: CAST, DES, 3DES, Blowfish-128
Data Integrity: MD5, SHA-1
Client: F-Secure Distributed FW Client, for Win2K
Windows 2000 Professional, SP2, SRP-1 inkl. HotFixes

IKE steht für das Verschlüsselungsschema ISAKMP/Oakley, wobei ISAKMP für den Schlüssel- und Security-Association-Austausch zuständig ist; Oakley ist der verschlüsselnde Teil des Protokolles. Es gibt zwei Möglichkeiten: nur Header Verschlüsselung (AH) und Header und Daten Verschlüsselung (ESP). Es ist eine sog. Tunneling-Encryption, bei der auch der Header mit einem Hash im verschlüsselten Paket integriert wird, wodurch ein Einsatz über eine Strecke, auf welcher Adressübersetzungstechnologien wie Proxiing oder NAT verwendet werden, nicht einsetzbar ist. Rein theoretisch könnten ESP-Pakete übersetzt werden, AH jedoch nicht – undalle gängigen IPSec –Implementationen verwenden sowohl AH als auch ESP. IPSec kann daher nur geroutet werden, benötigt clientseitig offizielle IP-Adressen. IPSEC verwendet für AH den Generic Type Pre Match Code: ip_p=0x33 (= dez. 51) und für ESP den Pre Match Code: ip_p=0x32 (= dez. 50). Diese generic IP Services müssen freigeschalten sein. Zusätzlich wird der Port 500 für UDP und TCP in beide Richtungen benötigt (für ISAKMP/Oakley = IKE).

PPTP

Das Point to Point Tunneling Protocol ist durch Micrsoft populär geworden, verwenden nicht die Algorithmen DES/3DES/AES zur Verschlüsselung, sondern RC4 von Ron Rivest. Die verwendete Schlüsselstärke ist 128bit, was ab dem Service Pack 2 von Windows 2000 obligat ist. Es verwendet das TCP Service 1723 und das Generic IP Service ip_p=47 (GRE = Generic Routing Encapsulation), jeweils in beide Richtungen. Eine Adressübersetzungstechnologie zwischen den beiden Verschlüsselungspartnern ist nicht möglich, da zwar ein Portforwarding des TCP Services möglich ist, aber ein Forwarding der GRE Pakete wird zur Zeit von Windows 2000 nicht unterstützt.

Zusammenfassung der benötigten Services:

FWZ: UDP Port 259
gen. IP Services ip_p = 94

IKE: UDP/TCP Port 500
gen. IP Services ESP (ip_p =50)
gen. IP Service AH (ip_p=51)

PPTP: TCP Port 1723
gen. IP Services GRE (ip_p =47)

Um ein ordnungsgemässes Funktionieren zu gewährleisten, müssen von Seiten des ISP offizielle IP Adrressen zugewiesen werden und es düefen keine Portfilter bzgl. der oben verwendeten Protokolle bestehen. Es versteht sich von selbst, dass die im allgemeinen Internet-Usus verwendeten L3-Protokolle ebenfalls uneingeschränkt verwendet werden können.


Um jetzt mit ADSL arbeiten zu können musst du das L3 Paket in ein UDP Paket einkapseln, damit dir der 2. Tunnnel nicht das Paket zerstört.

Ich hoffe das war jetzt nicht zu viel auf einmal ;)
Atlan

:confused:

Hab' Dich nicht verstanden.
Deine Frage war ob man durch den ADSL-PPTP-VPN Tunnel noch einen zweiten VPN Tunnel legen könnte.

Gibt ja verschiedene Möglichkeiten zu tunneln.
Einen gepatchten Freeswan Server und Roadwarrior mit X.509 Zertifikaten über ipsec ist wahrscheinlich die beste Lösung.

Könntest ja auch über ssh tunneln.

Manx

Btw. hat schon wer unter Linux einen VPN Server eingerichtet (FreeS/WAN, Win2k Clients) ?

Eigentlich wollt ich einen Tunnel direkt zum Win2k RRAS aufbauen. Ohne 3rd party Software.

Müsste aber eigentlich auch funktionieren - oder? ;)

Falls wer Websites zu dem Thema mit Zertifikaten usw usf. kennt (am besten auch noch zu Win2k) dann bitte posten. Ich spiel mich auch grad daheim mit dem Klumpat. :D

Ajo passt zwar nicht 100% zum Thema (obwohls um IPSec geht ;)), hab aber trotzdem eine Frage zu Certification unter Win2k: hab mir jetzt einen Certification Authority Server aufgesetzt, der als Stand-Alone CA fungiert. (ist mitglied einer Domäne)
Jetzt hätt ich gern einen anderen Server (der das ADS hält), dass er diesem Rechner "traut". Wenn ich mir über das Webinterface (http://server/certsrv) unter Retrieve the CA certificate or certificate revocation list und dann unter "Install this CA certification path" eine Vertrauensstellung hol, bekomm ich die immer nur unter Certificates - Current User/Trusted Root Certification Athorities - aber nicht für Local Computer. (mit Certificates mein ich das Snap-in in der MMC)

Ich nehm aber an, wenn ich bei IPSec (Snap-in IP Security Policies) unter einer Properties seite, von einer der Default-Policies eine zusätzliche Security Rule definieren will (also add...) dort dann bei Authentication Method "Use a certificate from Certificae Authority" auswähle, hätt ich gern meinen CA dabei.
Ist er aber nicht. Ich weiß, ich könnt auch mit Kerberos 5 da herum werkeln - will das aber so machen, wie es schön in der MS Mappe beschrieben is, die so vor mir herumkugelt.

So ich hoff ich hab die Leser jetzt nicht zu sehr mit meinen Angaben verwirrt und vielleicht kann mir einer ja auch noch ein bissi weiterhelfen und durchschaut, das was ich gerne hätte. Weil ich hab langsam keinen Durchblick mehr, bei den ganzen Zertifikatsgschichten in Win2k - was ich wie wo wann krieg und benutzen kann. ;)

Ja, auf den Clients "SSH-Sentinel", obwohl's mit Windows Boardmitteln auch gehen sollte, nur halt ich von dem wenig :)

Grüße

Manx

im Prinzip hast ja schon einen Tunnel mitn ADSL.
Und in diesem Tunnel kann einen weitern machen ... geht sicher.

Hab in der Firma eine Netscreen 5XP stehen und zu Hause ADSL.
Also ADSL-Tunnel PPTP und dann Tunnel ich ins Firmennetzwerk nocheinmal.
Protokoll 3DES und MD5 zur Verständigung ...
Kannst natürlich auch IPSec verwenden ...
Also lt. deiner Frage muss man mit JA anworten ... ;)

Eigentlich baust du 2 gleichzeitige nebeneinanderliegende Tunnel auf.
Das der 1. Tunnel des ISP den 2. Tunnel deiner Firma beinhaltet ist glaub ich technisch gesehen nicht korrekt.


PPTP Connection kapselt ja nicht nochmal eine PPTP Connection ein?

Viel eher könnte (könnte!)es sein, dass du Dir damit 2 autonome PPTP Connections aufbaust, welche Dir dann je eine der 2 IP Verbindungen tunneln.

Ob das stimmt kann ich nicht bestätigen, erscheint mir aber logisch.

glaub ich nicht. Weil der erste Tunnel fahrt amal zum Provider. Und der is fix - anders gehts nicht. Und jeder andere Traffic muss durch diesen Tunnel. Das is meine Meinung

Von mir aus müsste es eigentlich gehen. Weil wenn ich von Standard Windows Komponenten nicht 2 Tunnel gleichezeit auf einer Maschine haben kann - fahr ich einfach von einer anderen Maschine durch den Tunnel auf den Schulserver.
Ich hoffe ICS unterstützt das.

Aso, ja stimmt, du hast ja automatisch eine VPN Verbindung vom ISP bekommen.
Hat jetzt zwar mit der direkten Lösung zu tun, ich schreibs aber trotzdem:

Was ich aber meine ist dass der Tunnel nicht noch einen Tunnel haben kann.
Es ist ev. ein einziger Tunnel der in deinem Fall per PPTP gekapselt wird (Provider), und bereits alle Information zu der Route ISP + Schule enthält.Schaut so aus: (Ip Header,GRE Header,dann der Body mit den eigentlichen verschlüsselten Protokoll)
Ob aber wirklich eine Kapselung in der Kapselung gemacht wird, also PPTP PPTP kapseln kann weiss ich nicht, konnte auch nirgends was lesen wo dies beschrieben wird.
KAnn aber leicht sein, da PPTP PPP kapseln kann.

So, jetzt hör ich aber schon damit auf. :-)

Adios.

Also vom Protokoll her isses kein Problem.
Wenns eine saubere Kapselung ist kannst du in einem Tunnel übertragen was du willst, auch beliebige andere Tunnelprotokolle. Es erhöht sich nur der Overhead...
Irgendwann mal hast du halt so viele Header das die Performance im Keller ist oder du Probleme mit Fragmentierung kriegst...


Ich hab schon mal ppp über ssh in einem ip over http-tunnel über einen http-proxy betrieben. War zwar langsam, aber kein problem...

Der Fantasie sind keine Grenzen gesetzt ;)

mfg
Clystron