Archiv verlassen und diese Seite im Standarddesign anzeigen : Welche VPN-Implementierung nutzt ihr?
Hallo @all,
mich würde interessieren welche Art von VPN-Implementierung ihr @work oder @home nutzt.
Ich für meinen Teil habe bisher IPSEC genutzt:
IPCop als VPN-Gateway für IPSEC und auf den Windows-Roadwarriors das IPSEC-Tool von Markus Müller. Authentifizierung über x509 Zertifikate die mit TinyCA erstellt werden.
Momentan arbeite ich an diesem Projekt:
IPCop als VPN-Gateway mit OpenVPN und auf den Clients (Linux, BSD, Mac OS X, Windows) auch OpenVPN. Die Authentisierung läuft über SSL-Zertifikate die die User über einen Wizard beantragen können - hat den Vorteil das der private Schlüssel beim User verbleibt und er nur den Antrag auf ein Zertifikat zu mir senden muß (Ist einfacher Text und kann daher per Email versendet werden).
mfg
cane
Ich persönlich setze auf OpenVPN. Es ist schnell, einfach und sicher. Läuft dazu auf vielen Plattformen.
IPSec - notgedrungen. Weil die SnapGear/CyberGuard Router die wir einsetzen OpenVPN meines Wissen nicht berherrschen. Ich hab privat und in der FH mit OpenVPN experimentiert- gefiel mir deutlich besser als IPSec - zumal IPSec imo zickig ist...
IPSec - notgedrungen. Weil die SnapGear/CyberGuard Router die wir einsetzen OpenVPN meines Wissen nicht berherrschen. Ich hab privat und in der FH mit OpenVPN experimentiert- gefiel mir deutlich besser als IPSec - zumal IPSec imo zickig ist...
Ja, IPSEC ist natürlich wesentlich weit verbreiteter. Wobei es Probleme gibt wenn die verschiedenen Hersteller nur eine Teilmenge der Algorithmen implementieren und man deshalb oft von Hand ändern muß.
OpenVPN ist wesentlich komfortabler und einfacher enzurichten - ich kann mich noch gut an meine ersten Erfahrungen mit den Degub-Ausgaben von IPSEC erinnern :ugly:
mfg
cane
Ich verstehe nicht warum manche Personen immer noch das unsichere PPTP verwenden anstatt zumindest L2TP oder besser noch OpenVPn zu nutzen :confused:
mfg
cane
Ich verstehe nicht warum manche Personen immer noch das unsichere PPTP verwenden anstatt zumindest L2TP oder besser noch OpenVPn zu nutzen :confused:
mfg
cane
ich muss zu meiner schande gestehen, dass ich einer der leute bin :ugly:
ich nutze pptp nicht wirklich, der pptpd ist bei mir einfach nur installiert, wird aber nicht genutzt ;)
sollte ich irgendwann mal das verlangen haben, mich von außerhalb bei mir einzuloggen, werde ich natürlich den pptpd auch ablösen...
derRichard
08.04.05, 14:53
hallo!
einige idotenkunden verlangen ausdrücklich pptp.
die wollen nichts anders.
ansonsten verwenden wir openvpn.
//richard
hallo!
einige idotenkunden verlangen ausdrücklich pptp.
die wollen nichts anders.
ansonsten verwenden wir openvpn.
//richard
Ja, das kommt mir bekannt vor - Was der Bauer nicht kennt...
mfg
cane
IPSec - notgedrungen. Weil die SnapGear/CyberGuard Router die wir einsetzen OpenVPN meines Wissen nicht berherrschen. Ich hab privat und in der FH mit OpenVPN experimentiert- gefiel mir deutlich besser als IPSec - zumal IPSec imo zickig ist...
OpenVPN nicht beherrschen? - einen UDP (zur Not TCP) Port aufmachen sollte doch mit jedem Bratzenrouter gehen - oder?
Ich denke mal er setzt den Router als VPN-Gateway ein...
mfg
cane
Ich denke mal er setzt den Router als VPN-Gateway ein...
mfg
cane
Hm ... achso.
So zu Hause habe ich kein VPN aber in der Firma
Wir verwenden eine Neoteris SSL-Gateway. Da kann man sicher per HTTPS einloggen und Terminalssession auf Server oder SSH-Session auf die Server machen.
Für Windows können Portst über den Secureapplication Manager durchgeleitet werden. Es gibt auch ein IP-Connect Plugin das ähnliche wie IP-Sec funktioniert.
http://www.juniper.net/products/ssl/
r2k
Hätte nicht gedacht das OpenVPN schon so bekannt und beliebt ist!
Aus diesem Grund hier mal einen Auszug meiner Bookmarks:
http://www.newbie-net.de/anleitung_wlan_vpn.html
http://openvpn.se/
http://openvpn.se/bb/
http://openvpn.net/
http://babylon.vtlink.com/modules.php?name=News&file=article&sid=30
http://babylon.vtlink.com/modules.php?name=News&file=print&sid=32
http://www.vpnforum.de/
http://www2.uni-klu.ac.at/support/ZidConnectWireless#head-de4d2bbf8cdc9a8c5dbe79922379ded6ac5a7642
http://rechenknecht.net/
http://openvpn.se/files/howto/openvpn-howto_roll_your_own_installation_package-Rev1.1.html
http://openvpn.se/files/howto/openvpn-howto_run_openvpn_as_nonadmin-Rev1.1.html
http://sweb.cz/mycert/
http://openvpn.net/articles.html
http://www.nwfusion.com/news/2004/122004cheapvpn.html
http://www.pavelec.net/adam/openvpn/bridge/
http://www.mertech.com.au/?=OpenVPNStatusViewer
http://linuxforen.de/forums/showthread.php?t=53048&highlight=open+vpn
http://www.vpnforum.de/viewtopic.php?t=150&highlight=statisch
Viel Spaß beim Lesen!
mfg
cane
@all
Wer mehr / andere / bessere Links hat postet diese bitte :)
mfg
cane
Ja, das kommt mir bekannt vor - Was der Bauer nicht kennt...
mfg
cane
jo, da is was dran, aber pptp is halt auch easy going, windows boardmittel und auf ner linux auch schnell installiert und konfiguriert. und es ist ja noch nicht soweit das die pakete im klartext rueberfliegen :)
jo, da is was dran, aber pptp is halt auch easy going, windows boardmittel und auf ner linux auch schnell installiert und konfiguriert. und es ist ja noch nicht soweit das die pakete im klartext rueberfliegen :)
OpenVPN ist genauso schnell implementiert, wesentlich sicherer und läuft auf mehr Plattformen.
Wo soll da der Vorteil von PPTP sein?
mfg
cane
Was mich zudem interessieren würde:
Wie sehen eure VPN-Szenarien aus:
Roadwarrior oder Net2Net?
PSK, Schlüssel oder Zertifikate?
Nutzt ihr CRLs?
Welche Algorithmen verwendet ihr?
Nutzt ihr bei OpenVPN chroot, läuft der dienst als User nobody, verwendet ihr zusätzlich auth_tls?
Wie erzeugt ihr eure Zertifikate?
mfg
cane
Mein IPSEc-Szenario:
http://daniel-halbe.de/vpn.pdf
WLAN-Roadwarrior-Umgebung mit x509 Zertifikaten, erzeugt von einem seperaten Debian system mt TinyCA. Win-Clients mit dem Tool von Markus Müller eingerichtet. Keine CRLs implementiert. VPN Gateway ist IPCop.
Umgebung wird gerade von mir auf OpenVPN migriert, wird in etwa so aussehen:
VPN-Gateway IPCop mit installiertwn, statisch kompilierten OpenVPN.
Wenn möglich OpenVPN in chroot und als User noboda.
x509 Zertifikate - Erzeugung per openssl oder einer GUI.
Verwendung von tls_auth noch unklar.
Crypt-Algorithmus Blowfish
Hash Algorithmus MD5 oder SHA1 - muß ich noch vergleichen...
HowTo erhältlich? In drei Wochen hier :)
mfg
cane
Wer Interesse hat an einem Portal zu OpenVPN mitzuwirken der kann sich übrigens gerne per Posting oder PN melden. Ich bereite ein solches momentan vor um einen zuerst deutschen, später auch englischen Anlaufpunkt für Fragen, Links etc. zu schaffen. :)
Realisiert werden soll:
HowTo-Bereich
Geordnete, sortierte Linkliste
Online-Konfigurator für eine openvpn.conf
mfg
cane
Hi!
Ich verstehe nicht warum manche Personen immer noch das unsichere PPTP verwenden anstatt zumindest L2TP oder besser noch OpenVPn zu nutzen :confused:
Könnte auch daran liegen, dass einige DSL-Anbieter (z.B. in Österreich) PPTP als Zugangsprotokoll verwenden. :ugly:
Gruß
fuffy
ich nutze openvpn.
es läuft auf meinem fli4l und ich nutze es als road-warrior-konfig für meinen laptop der über wlan am netzwerk hängt.
es läuft mit zertifikaten (normal mit openvpn erstellt) und in ner chroot.
mit acls etc hab ich mich nicht beschäftigt, da ich sowohl einziger nuzter der vpn bin wie auch router-admin :-D
Hi,
ich nutze zur Zeit eine IPSec Tunnel (Site-to-Site) zwischen zwei Netgear FVS318 Routern mit einem Bekannten von mir.
Vorher hatten wir ein OpenVPN Tunnel.
Grüße
DaGrrr
Hi,
ich (und einige Kunden) nutze selbst OpenVPN und IPSEC. Letzteres immer noch wegen der besseren Plattform-Interoperabilität. Ersteres aus Gründen der doch recht einfachen Konfiguration.
Ebenso habe ich hier und da noch CIPE im Einsatz (das fehlte mir in der Auswahl). CIPE ist mehr aus historischen Gründen im Einsatz, denn das gab es als VPN-Produkt schon lange, bevor unter Linux die ersten IPSEC-Implementationen auf dem Markt kamen - naja und OpenVPN ist ja sowieso der jüngste Sproß unter den hier aufgeführten VPNs.
ups: Habe ich mich jetzt als Oldie geoutet? :D
Harry
bei mir laeuft u.a. ein konzentrator mit ipsec (freeswan) mit 70 clients (net2net, cisco 836 und soho) und zusaetzlich n pptpd fuer die einzelnen clients
Hi,
ich (und einige Kunden) nutze selbst OpenVPN und IPSEC. Letzteres immer noch wegen der besseren Plattform-Interoperabilität.
Hallo Harry,
ich vermute Du meinst mit Interoperabilität die anbindung an diverse Hardware-Router? Denn OpenVPN unterstützen ja die meisten betriebssysteme...
Ebenso habe ich hier und da noch CIPE im Einsatz (das fehlte mir in der Auswahl).]
Ich hatte zuerst überlegt Cipe und Tinc mit aufzunehmen habe den gedanken aber verworfen da die Verbreitung meiner meinung nach recht gering ist und beide Protokolle meines Wissens nicht auf ein durchgetestetes Protokoll wie SSL/TLS aufsetzen. (linux-magazin)
Stimmst Du mir da zu oder bist Du anderer Meinung?
mfg
cane
bei mir laeuft u.a. ein konzentrator mit ipsec (freeswan)
Lief die Anbindung an den Cisco ohne Probleme oder musstest Du diei verschlüsselungsalgorithem ändern?
mfg
cane
noe, gab keine probleme, werden aber PSK's eingesetzt:
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
lifetime 28800
crypto isakmp key <PSK> address <peer ip>
!
crypto ipsec security-association lifetime seconds 28800
!
crypto ipsec transform-set 3des-md5 esp-3des esp-md5-hmac
!
crypto map VPN 10 ipsec-isakmp
set peer <peer ip>
set transform-set 3des-md5
set pfs group2
match address 100
dann halt noch in der access list die netze festlegen und nem if zuordnen. super easy ...
encr 3des
hash md5
Okay, 3DES ist ja auch der "schwächste" Algorithmus und wohl in allen IPSEC-Routern implementiert.
Aber reichen sollte er auch und günstiger als ein zweiter Cisco ist's allemale ;)
Was mich stört ist die Komplexität von IPSEC. Früher habe ich auch IPSEC genutzt aber bis ich die verschiedenen Modi des Protokolls verstanden hab und alle Patches zur Nutzung von x509 und NAT-Traversal eingespielt hatte war ich zwar auf dem besten Weg zum VPN-Guru ,-) und habe SuperFreeswan genutzt in dem alle Patches integriert sind aber es gibt noch mehr Kritikpunkte meinerseits:
Die vielen verschiedenen Implementierungen machen IPSEC komplex:
Freeswan (eingestellt), SuperFreeswan, StrongSwan, OpenSwan, KAME, IPSEC in 2.6 und mehr...
IPSEC arbeitet im Kernel- und Userspace. Das wiederspricht der ringarchitektur des Kernels, macht das ganze wiederum komplexund führt dazu das man nicht "schnell mal den Kernel updaten" kann.
Die unübersichtlichen Debugausgaben kosteten anfangs eine Menge Nerven. Viele Meldungen waren zu allgemein und vor allem bei Verwendung von x509 Zertifikaten war es anfangs recht mühsam den Fehler zu finden.
Das es anderen ähnlich geht belegen die zahlreichen Topics zu IPSEC-Problemen.
Ich werde soweit möglich nur noch openVPN einsetzen und IPSEC nur dann verwenden wenn HardwareRouter angebunden werden müssen und keine Mittel für einen zusätzlichen OpenVPN-Gateway bereitstehen.
Ein nettes Zitat aus "OpenVPN and the SSL Revolution" (http://www.sans.org/rr/whitepapers/vpns/1459.php) von Charlie Hosner (08.08.2004):
Security´s worst enemy ist complexity and OpenVPN defeats this enemy.
Das Paper ist sehr lesenswert!
Seit ihr gleicher oder anderer Meinung?
mfg
cane
Hi Cane,
Hallo Harry,
ich vermute Du meinst mit Interoperabilität die anbindung an diverse Hardware-Router? Denn OpenVPN unterstützen ja die meisten betriebssysteme...
Ja - ich meine die Anbindung an diverse "Hardware"-Router (hmmm gibt es auch "Software"-Router? ;)), wie beispielsweise die von Cisco/Linksys oder anderen Herstellern.
Ich hatte zuerst überlegt Cipe und Tinc mit aufzunehmen habe den gedanken aber verworfen da die Verbreitung meiner meinung nach recht gering ist und beide Protokolle meines Wissens nicht auf ein durchgetestetes Protokoll wie SSL/TLS aufsetzen. (linux-magazin)
Stimmst Du mir da zu oder bist Du anderer Meinung?
Du kennst mich sonst würdest Du nicht fragen ;)
Ja - ich habe da eine etwas andere Meinung: Zwar nicht zur Verbreitung von CIPE und Tinc; ich denke, die Quantitäten im Einsatz dieser beiden Produkte sind (fast) vernachlässigbar.
Aber dass SSL/TLS ein durchgetestetes Protokoll ist, das bezweifle ich an dieser Stelle mal :D
Denn:
1. SSL/TLS ist kein Protokoll sondern nur die Beschreibung von diversen Protokollfamilien, die zum sicheren und authentifizierten Datenaustausch genutzt werden
2. Solltest Du die Protokolle innerhalb der Familien meinen, dann gilt in erster Linie für die asymmetrischen (aber auch für die komplexeren symmetrischen) Algorithmen, dass man die Sicherheit nicht feststellen kann. Vielmehr kann man irgendwann nur die Unsicherheit oder Schwäche der Algorithmen nachweisen oder - falls diese noch nicht nach Jahren des Einsatzes nachgewiesen wurde - vertraut man halt mehr oder weniger diesen Verfahren.
Bestes Beispiel für ehemals vertrauenswürdige kryptologische Algorithmen sind MD5 (Hashalgorithmus) und SHA-1 (Verschlüsselungsalgorithmus). Beide haben Schwächungen erfahren, so dass sie für den Einsatz in Hochsicherheitsumgebungen aktuell genauer hinterfragt werden müssen und vielleicht sogar ausgeschlossen werden.
Zurück zu CIPE: Wenn Du Dir die verwendeten Algorithmen bei CIPE z.B. anschaust, dann wirst Du feststellen, dass CIPE bei der Verschlüsselung auf IDEA oder Blowfish (mit festen Schlüssellängen) aufsetzt. Dies sind letztlich Algorithmen, die auch bei SSL/TLS Verwendung finden. Und mit pkcipe steht auch ein Frontend für die asymmetrische Authentifizierung und für den dynamischen Schlüsselaustausch zur Verfügung.
Somit gilt für die Sicherheit grundsätzlich dasselbe wie bei anderen Produkten, die in die Familie SSL/TLS einzuordnen sind.
Harry
Hi Cane,
Okay, 3DES ist ja auch der "schwächste" Algorithmus und wohl in allen IPSEC-Routern implementiert.
Aber reichen sollte er auch und günstiger als ein zweiter Cisco ist's allemale ;)
soso - 3DES ist also der "schwächste" Algorithmus? Das war mir neu :D
Mit 168bit Schlüssellänge ist er stärker als viele andere Algorithmen und er hat dazu noch den Vortei schnell und bisher auch nichtl geschwächt oder gebrochen zu sein, ganz im Gegensatz zu SHA-1. Darüber hinaus ist er seit über 20 Jahren in der Praxis erprobt. Welcher der anderen Algorithmen kann da mithalten? :D
Was mich stört ist die Komplexität von IPSEC.
...
Das es anderen ähnlich geht belegen die zahlreichen Topics zu IPSEC-Problemen.
Tja - das ist halt das leidige Problem mit der Sicherheit. Es steht eben nirgends geschrieben, dass Sicherheit = Einfachheit bedeutet. Und "mal eben schnell" was sicheres aufbauen, ohne sich gut auszukennen, geht sowieso meist nach hinten los.
Man liest aber immer wieder von Leuten, die Menschen kennen, die im Fernsehen von anderen Menschen gehört haben, die versucht haben, mal eben fix ohne solide Kenntnisse sowas aufzubauen - und das ist eben nach hinten los gegangen. Und dann liest man dazu die verzweifelten Postings nach dem Motto "so ein Sch... Produkt - das geht nicht - dann nehm ich halt was einfacheres und sichereres" ... ahja! :ugly:
Ich werde soweit möglich nur noch openVPN einsetzen und IPSEC nur dann verwenden wenn HardwareRouter angebunden werden müssen und keine Mittel für einen zusätzlichen OpenVPN-Gateway bereitstehen.
Ja - soweit OpenVPN auf beiden Seiten zur Verfügung steht, ist es ja auch ideal.
Ein nettes Zitat aus "OpenVPN and the SSL Revolution" (http://www.sans.org/rr/whitepapers/vpns/1459.php) von Charlie Hosner (08.08.2004):
Security´s worst enemy ist complexity and OpenVPN defeats this enemy.
Ich lese das Zitat etwas anders: "Mit OpenVPN haben wir viel an Flexibilität in der Konfiguration von VPNs eingebüsst." ;)
Es ist nunmal ein Vorteil von IPSEC, dass ich bestimmen kann, welche Algorithmen zur Authentifizierung eingesetzt werden, welche zur Verschlüsselung, wie lange Schlüssel leben dürfen, wann die erneuert werden müssen etcpp. Sobald eines der eingesetzten Protokolle eine Schwächung erfährt, kann ich darauf umgehend reagieren und eine alternative Konfiguration aufsetzen. Das geht bei OpenVPN eben nur sehr eingeschränkt.
PS: Das ist nur _meine_persönliche_ Meinung :D
Harry
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.