Was ist der Vorteil von L2TP/IpSEC ?

Was ist der Vorteil von L2TP/IpSEC ? (23 Beiträge, 616 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Nachdem ich gerade daran verzweifelt bin:

Der Laie stellt sich vor, dass jemand beispielsweise IPSEC verwendet um sichere Kommunikation über unsichere Netze zu ermöglichen.

Wie es aussieht, bevorzugt ja Micro$oft - und dadurch auch andere - dass man zwar die Sicherheit über IPSEC realisiert, nachher aber in die IPSEC-Packerl L2TP-Frames wirft.

Und genau das ist mir unklar. Was gewinnt man durch L2TP innert von IPSEC ???

Hallo !

Weil L2TP nicht verschlüsselt ist wird es mit IPSEC kombiniert. (wird ab Win 2003 verwendet)
Dies wird verwendet um NAT zu verwenden. (Port VPN 1701)

Die neueste MS-Errungeschaft ist aber eigentlich SSTP. (damit kannst auch VPN Verbindungen über den 443 Port machen - damit muss man nicht NATen - !!!)

Momentale:

Bei L2TP/IPSec ist IPSec unten und L2TP drin.
Den Port 1701 kannst und sollst du ja auf dem äußeren Interface sperren, wenn du L2TP/IPSec verwendest...

Der Vorteil von IPSec ist mir klar. Nur warum ich L2TP da drin transportiere, bleibt mir unklar.

Momentale:Bei L2TP/IPSec ist IPSec unten und L2TP drin. Den Port 1701
kannst und sollst du ja auf dem äußeren Interface sperren, wenn du
L2TP/IPSec verwendest...Der Vorteil von IPSec ist mir klar. Nur warum ich
L2TP da drin transportiere, bleibt mir unklar.

Du transportiert den IPSEC drinnen und aussen ist der L2TP.

Wie willst du etwas an entsprechende Stellen transportieren wenn du verheimlichst an wen es gehen soll ? Du darfst den Port nicht verschlüsseln !
Ohne Adresse bist dicht.

aus http://www.isaserver.org/articles/IPSec_Passthrough.html

oder von MS selber : http://technet.microsoft.com/de-de/magazine/cc135901.aspx

PS:IPSEC und alles steht still !!!

28.02.2011, 11:38 Uhr - Editiert von King_Uli, alte Version: hier

Ahem... Danke, aber IPSec kannte ich schon

? Du darfst den Port nicht verschlüsseln !

Wie verschlüsselt man einen Port ?

Wichtig ist, dass man den L2TP-Port _nicht_ nach aussen freigibt, sonst hast ein massives Sicherheitsproblem (Dann kann einer "an Ipsec vorbei" L2TP-Packerl an dich schicken).

Deine Falschannahmen beruhen auf deiner falschen Prämisse:

Du transportiert den IPSEC drinnen und aussen ist der L2TP.

Aber lies nach:
http://de.wikipedia.org/wiki/Layer_2_Tunneling_Protocol

Eine Verschlüsselung ist in L2TP direkt nicht enthalten. Dies muss von Protokollen der unteren Schichten übernommen werden. L2TP wird deshalb oft in Kombination mit IPSec verwendet. (RFC 3193 – "Securing L2TP using IPSec")

http://tools.ietf.org/html/rfc3193

  This document proposes use of the IPsec protocol suite for protecting
   L2TP traffic over IP networks, and discusses how IPsec and L2TP
   should be used together.

[Wenn L2TP unten wäre, könnten die Frames nicht durch Ipsec geschützt werden]

http://en.wikipedia.org/wiki/Layer_2_Tunneling_Protocol

L2TP/IPsec

Because of the lack of confidentiality inherent in the L2TP protocol, it is often implemented along with IPsec. This is referred to as L2TP/IPsec, and is standardized in IETF RFC 3193. The process of setting up an L2TP/IPsec VPN is as follows:

       1. Negotiation of IPsec security association (SA), typically through Internet key exchange (IKE). This is carried out over UDP port 500, and commonly uses either a shared password (so-called "pre-shared keys"), public keys, or X.509 certificates on both ends, although other keying methods exist.
       2. Establishment of Encapsulating Security Payload (ESP) communication in transport mode. The IP protocol number for ESP is 50 (compare TCP's 6 and UDP's 17). At this point, a secure channel has been established, but no tunneling is taking place.
       3. Negotiation and establishment of L2TP tunnel between the SA endpoints. The actual negotiation of parameters takes place over the SA's secure channel, within the IPsec encryption. L2TP uses UDP port 1701.

usw...

Wie gesagt: Jede Linux-IPSec-Konfiguration empfiehlt genau deshalb, dass man 1701 für Zugriff von aussen sperrt...

besser gefragt wäre "was gewinnt man durch IPSec"?

die Sicherheit.

IPSec wird in dem Fall verwendet um das L2TP zu sichern, da dieses ja keine Sicherung selbst kann.

RFC: http://tools.ietf.org/html/rfc3193
-----------------------------------
x-x-o
o-x-o
o-o-x ... and the winner is x

28.02.2011, 11:26 Uhr - Editiert von blitzfreak, alte Version: hier

Gut ausgedrückt !

Ja Aber IPSEC kennt doch schon Tunnel und Transport-Mode - und kann selbst gut mit Road Warriors umgehen.

Meine These ist, dass IPSec [fast] alles kann, was L2TP kann - und mehr.
Wenn ich also schon IPSec verwende, brauche ich kein L2TP mehr.

Eine einzige Ausnahme würde mir einfallen:
IPSec kann glaublich nur IP transportieren, L2TP auch anderes.
Sollte es echt _darum_ gehen ? Was verschiebt denn M$ so alles ausserhalb von IP ?

Ja Aber IPSEC kennt doch schon Tunnel und Transport-Mode - und kann selbst
gut mit Road Warriors umgehen.Meine These ist, dass IPSec [fast] alles kann,
was L2TP kann - und mehr. Wenn ich also schon IPSec verwende, brauche ich kein
L2TP mehr.Eine einzige Ausnahme würde mir einfallen:IPSec kann glaublich nur
IP transportieren, L2TP auch anderes.Sollte es echt _darum_ gehen ? Was
verschiebt denn M$ so alles ausserhalb von IP ?

Nocheinmal ein Bild welches alles erlären sollte:

Das was du da gezeichnet hast, ist _NICHT_ "L2TP/IPSEC" sondern "L2TP/IPSEC mit NAT-T".

Nat-Traversal gab es auch schon bei "plain IPSEC" - dazu braucht man kein L2TP.
Was man aber aus deiner Skizze sehen kann ist, dass eben L2TP im IPSEC ist - und daher folgerichtig der L2TP-Port _nicht_ am externen Interface freigegeben sein muss... Wie ich ja sagte.

Wie willst du verschlüsselte Daten durch den Router schicken - also Daten die er nicht lesen kann ? - > also NAT-T.

Wenn du es lokal benutzen willst ok ansonsten gibts einfach keine Kommunikation und deshalb wird das auch nicht verwendet.

entweder NUR IPSEC - also im LAN
oder L2TP/IPSEC mit NAT - im WAN

ARGL.

IPSEC war übrigens IMHO nie nur für LAN gedacht...

Aber zurück zu meiner Frage:

Wieso siehst Du nur die 2 Varianten und nicht IPSEC mit NAT-T, wie es scheinbar die ganze Welt ausser M$ kann ???

http://tools.ietf.org/html/rfc3715

WAs heiist ich sehe nur 2 Varianten.

Du wolltest doch wissen was L2TP macht ?

SSTP bzw IKEv2 gibts klarerweise auch.

Ich wollte nicht wissen, was L2TP macht.
Ich wollte wissen, welchen Vorteil man hat, L2TP in IPSEC zu werfen, wenn man eh schon IPSEC hat.

da steht unten eh alles drinnen.

http://www.elektronik-kompendium.de/sites/net/0906191.htm

jo, und IPSec kann zb auch keine Multicasts

_________________________________________________________________
There are 10 types of people. Those who understand binary and those who don't

Eine einzige Ausnahme würde mir einfallen:
IPSec kann glaublich nur IP transportieren, L2TP auch anderes.
Sollte es echt _darum_ gehen ? Was verschiebt denn M$ so alles ausserhalb von
IP ?

was meinst du wofür "L2" steht? IPsec ist ein L3 Protokoll, wenn ein Tunnelprotokoll nun Layer2 beherrscht, kann es auch zB original NetBEUI, IPX/SPX, HDLC, ATM uvm. tunneln.

All das wird heutzutage halt nur mehr selten benötigt, aber die Welt besteht nicht nur aus Consumer-Anwendungen.

btw ... M$ war damals so ziemlich das letzte OS, das TCP/IP nicht serienmässig beherrscht hat (man erinnere sich an die Krücken mit Win32s und MS-TCP unter 3.11/WfW, ehe dann doch Win95 raus war)

Das könnte eine Erklärung sein.

Wieso Devices wie ein Android zwar IPSEC/L2TP aber nicht "plain" IPSEC anbieten, entzieht sich trotzdem meiner Vorstellungskraft

Wieso Devices wie ein Android zwar IPSEC/L2TP aber nicht "plain" IPSEC
anbieten, entzieht sich trotzdem meiner Vorstellungskraft

mag sein, daß L2TP für einige andere Features im Gerät gebraucht wird, sei es GSM-seitig (Market, Updates, location-based services) oder vielleicht für ADB.

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung