OpenVPN vs. TincVPN vs. SoftEther

[pangu]

Hallo miteinander,

ich würde gerne mal eure Meinungen hören, bzw. softwarebasierten VPN-Lösungen und zwar:

• [1] OpenVPN
• Tinc VPN
• SoftEther

Ich selbst kenne eben nur OpenVPN und mich würde brennend interessieren, ob jemand von euch auch mit den andren zwei genannten Lösungen Erfahrungen sammeln konnte und etwas darüber berichten kann. Was sind eurer Meinung nach die Vor-/Nachteile, wann man es Sinn, wie ist der Konfigurationsaufwand und warum habt ihr euch für die eine oder andere Lösung entschieden?

Freue mich auf eure Meinungen.

Cheers,
Pangu.

[1] http://www.heise.de/netze/artikel/Dezen ... 85436.html

[pangu]

Keiner, der auch mit softether oder tinc gearbeitet hat, und mit Openvpn vergleichen konnte? dumdideldum.... la la la....

[ThorstenS]

softether ist kein Aprilscherz, oder? Das liest sich ja phänomenal - boah!
Die GUI Komponente des Servers gibt ja anscheinend für alle relevanten Plattformen.
Wenn das Marketing der site stimmt, habe ich einen openvpn Ablöser gefunden.

[pangu]

Mich haben ja beide beeindruckt. Gehört hatte ich erstmals davon vor ca. ner Woche, als (ich glaube) Cae das im Chat in den Raum geworfen hatte. Deshalb würde ich gerne Erfahrungswerte einholen von usern, die das evtl. schonmal genutzt haben und Erfahrung damit haben.

[wanne]

Zu SoftEther kann ich nichts sagen.
Aber wenn man mal Tinc benutzt hat, will man eigentlich kein Openvpn mehr nehmen.
Das Fängt damit an, dass OpnVPN Serverbasiert ist. Wenn ClientA mit ClientB redet, dann sendet erstmal Client A an den Server und der Server dann an ClientB.
Als nächstes ist da die Konfiguration. Typisches OpenVPN hat mindestens 30 Zeilen konfigurationsfile pro Client, für die man erstmal ein Tutorial lesen muss, damit man versteht was sie machen.
Bei tinc hat man typischerweise 4.
Einaml die tinc.conf

Code: Alles auswählen

Device = /dev/net/tun
Name = [NAME]

Und dann einen jeden host unter hosts/[NAME]
nochmal einen file spezifisch jeden host im netz

Code: Alles auswählen

Address = [IPoder Domainname des Host]
Subnet = [Internes Subnet]

Danach generiert man mit tincd -K den einen Key und dann muss man den hostspezifischen File auf irgen einen Knoten der bereits im Netz ist kopieren. Fertig. TINC Baut dann automatisch direkte Verbindungen in alle Richtungen auf und untertunnelt auch gleich die Firewalls. Gleichzeitig fummelt es nicht in der Netzwerkkonfiguration rum sondern lässt die, wie sie ist (bzw man darf die mit den ganz normalen tools ip/ifconfig anpassen, wie man will).
Vergelich das mal mit OpenVPN oder so: http://wiki.ubuntuusers.de/OpenVPN
Ähnliches Projekt ist peervpn

[ThorstenS]

unter woody haben wir noch mit ipsec (StrongSWAN) und selbst gepatchten kernel gearbeitet. Dagegen ist openVPN Kinderka%$§ vom Aufwand her gewesen. Es ist also immer eine Frage was man gewohnt ist bzw. wieviel man an Arbeit einbringen möchte.
OpenVPN ist super dokumentiert und as Netz ist voll von configs.

[wanne]

Nur weil's noch schlimmer geht muss das nciht gut sein. Im übrigen finde ich StrongSWAN gar nicht so schlimm. Der Hauptvorteil von OpenVPN ist vor allem, dass es da hunderte von wikis gibt, die das beschreiben.

[dirk11]

unter woody haben wir noch mit ipsec (StrongSWAN) und selbst gepatchten kernel gearbeitet. Dagegen ist openVPN Kinderka%$§ vom Aufwand her gewesen. Es ist also immer eine Frage was man gewohnt ist bzw. wieviel man an Arbeit einbringen möchte.
OpenVPN ist super dokumentiert und as Netz ist voll von configs.

Nee, es ist eine Frage der Entwicklung. Unter Woody oder dem Nachfolger war Vollverschlüsselung ein komplizierter und gefährlicher Krampf, denn es hat irgendwie nie richtig funktioniert. Der Wheezy-Installer hingegen macht das so einfach und logisch, zumindest seit diesem gibt es keinen Grund mehr, auf Vollverschlüsselung zu verzichten (ausser Hardware, die nicht performant genug ist) auf PCs.

Der Hauptvorteil von OpenVPN ist vor allem, dass es da hunderte von wikis gibt, die das beschreiben.

Das ist aber auch gleichzeitig sein größter Nachteil, denn viele davon stimmen nicht, sind veraltet oder beides. Ich hab mir ne Woche mindestens nen Wolf gesucht, warum openVPN bei mir um's Verrecken nicht laufen wollte. Es hat sich dann herauskristallisiert, dass das easy-vpn-Wiki von Debian sehr einfach gestaltet ist und vor allem funktioniert! Alle anderen Varianten, welche direkt mit openssl arbeiten, haben bei mir nicht funktioniert - warum auch immer.

[dufty2]

Wenn es um Sicherheit geht, würde ich "einfache" Lösungen bevorzugen (sofern sie den Anwendungsfall erfüllen):
Less code less bugs!

Das gleiche mit den Einstellungen: Weniger "Knöpfe" zu rumschrauben, weniger Sachen die ich als user verkonfigurieren kann.

[Colttt]

Ich weiss nicht wie es bei den anderen aussieht, aber openvpn hat den vorteil das es für jeden user gegen etwas anderes authentifizieren kann (LDAP,passwd,SQL,etc).. Und es ist erprobt auch in großen Umgebungen erprobt, Bsp Charité Berlin..

[dufty2]

Ich weiss nicht wie es bei den anderen aussieht, aber openvpn hat den vorteil das es für jeden user gegen etwas anderes authentifizieren kann (LDAP,passwd,SQL,etc).. Und es ist erprobt auch in großen Umgebungen erprobt, Bsp Charité Berlin..

Aber pangu ist - vermutlich - nicht mit der Charité vergleichbar.

OpenVPN teilt mit tinc den Nachteil, dass dessen traffic zwar ssl aber nicht genau https-Traffic entspricht und daher unterscheidbar ist. Dies soll bei tinc mal in Version 2.0 gefixed werden.

[wanne]

OpenVPN teilt mit tinc den Nachteil, dass dessen traffic zwar ssl aber nicht genau https-Traffic entspricht und daher unterscheidbar ist. Dies soll bei tinc mal in Version 2.0 gefixed werden.

Ich hoffe, doch dass sie das nicht generell "fixen"... tcp over tcp ist grauenhaft und da macht man nicht. Das hat schon seinen Sinn, dass die alle standardmäßig udp machen.

[dufty2]

OpenVPN teilt mit tinc den Nachteil, dass dessen traffic zwar ssl aber nicht genau https-Traffic entspricht und daher unterscheidbar ist. Dies soll bei tinc mal in Version 2.0 gefixed werden.

Ich hoffe, doch dass sie das nicht generell "fixen"... tcp over tcp ist grauenhaft und da macht man nicht. Das hat schon seinen Sinn, dass die alle standardmäßig udp machen.

Ein VPN-tunnel, welcher nicht durch eine (Firmen-)Firewall kommt, macht auch keinen Sinn

Es soll wohl mehrere 'Modi' mal geben:

Tinc 1.x uses its own protocols to set up tunnels to other tinc daemons. ...
It also is better to use a well-established protocol such as SSH or TLS instead of our own. Also, it is not necessary at all to use the same protocol for all the connections in a single VPN. Tinc should therefore allow tunnel backends as plugins, and allow other peers to be reached via URLs such as ssh://some.server.org or https://another.server.net:4443.

[wanne]

Ein VPN-tunnel, welcher nicht durch eine (Firmen-)Firewall kommt, macht auch keinen Sinn

Dann muss man wohl die Firmenfirewall fixen. (Was TINC releativ gut macht. Dank UDP-Holepunching kommt TINC vermutlich durch deutlich mehr Firewalls als irgend ein TCP-VPN. Und wenn die Firmenfirewall DPI macht sollte man wohl kein VPN aufmachen, wenn einem sein Job lieb ist.
Vor allem ist zuerst DPI und dann aber TLS zulassen total inkonsequent. Ich denke, dass die aller meisten Admins sich dessen bewusst sind und auf DPI oder TLS verzichten.

[dufty2]

Ich denke, dass die aller meisten Admins sich dessen bewusst sind und auf DPI oder TLS verzichten.

Ja, in "kleinen Klitschen" mag das angehen, das der Admin die policy entscheiden kann,
in größeren Entitäten entscheidet darüber die "Gouvernance" und der Admin resp. der Dienstleister befolgt jene resp. setzt sie um.

[wanne]

in größeren Entitäten entscheidet darüber die "Gouvernance" und der Admin resp. der Dienstleister befolgt jene resp. setzt sie um.

Ja, da kommen teilweise recht komische Entscheidungen zusammen. Aber für gewöhnlich keine harte Whitelist DPI.

[r4pt0r]

Ich hatte bis vor ca 2 Monaten OpenVPN und seitdem Tinc im Einsatz zur Standortvernetzung (gesamt ca 40 Clients in 3 Standorten, ~50GB/Woche durchsatz im VPN-Netz)
Grund für den Wechsel: Server an 2 Standorten, daher war eine reine Server/Client Konfiguration mit einem VPN-Master unpraktisch.

OpenVPN hat IMHO eine schön strukturierte "klassische" Konfiguration, dadurch sind auch komplexe variationen je client möglich ohne dass man den Überblick verliert.
Forward secrecy ist recht simpel einzurichten, auch durch die klar strukturierte Konfiguration und da man alles Zentral einrichten kann. Änderungen sind damit schneller durchgeführt.
Tinc ist da im Vergleich etwas "wirr" durch seine dezentrale Konfiguration. Zudem scheint es alles gleich out of the box zu machen/machen zu wollen - was es IMHO etwas undurchsichtig macht.
Tinc ist dafür aber auch in 5min eingerichtet und läuft - solange ein Teilnehmer von aussen für die anderen erreichbar ist baut sich das mesh-netzwerk auch auf. Praktisch wenn man an einem Standort gezwungen ist einen "dummen" NAT-Router zu nutzen (und keine Portforwardings einrichten darf!)...

Geschwindigkeit/Nutzbandbreite ist praktisch identisch - mit der Ausnahme dass der Verkehr ggf eben nicht "ums Eck" über den VPN-Master laufen muss.
Ansonsten waren aber keine Unterschiede zu OpenVPN messbar (jeweils mit&ohne Kompression)

Stabilität: OpenVPN machte nie Probleme. TINC muss sich bereits einen "Schluckauf" anrechnen lassen - nach ausfall der DSL-Leitung an einem Standort wollte sich der Server an dem Standort nicht mehr automatisch ins VPN einklinken - Dienst mustse einmal durchgestartet werden, dann liefs wieder. Anschließender Test ("Steck doch mal kurz das DSL-Modem aus") verlief aber problemlos...




SoftEther kannte ich noch nicht - klingt aber genial, werde ich mir definitiv genauer anschauen!

[ThorstenS]

Wie sieht dein Ré­su­mé nach bald zwei Jahren mit Tinc aus? Läuft es so stabil, wie du es brauchst?
Ich setze nach wie vor openvpn ein - die config steht ja.

[r4pt0r]

Tinc war die absolut richtige Wahl. Seit einem Jahr läuft noch ein zusätzliches Tinc-VPN im bridge-modus zur vernetzung einer neuen Telefonanlage. Das geroutete VPN schaufelt mittlerweile monatlich summiert über alle Standorte ~1TB weg! (ca 50% davon austausch von offsite-backups, dazu ein Testcluster mit Apache Cassandra + Spark)

Selbst ein temporäres Setup an einem Standort mit DSL+LTE, selektivem routing und fallback per selbsgebauten shellscripten lief absolut Problemlos. Eine ständig wegbrechende Verbindung entpuppte sich als miserabler LTE-Empfang, tinc baute aber immer sofort wieder alle Verbindungen auf (>300x am Tag über ein verlängertes WE ).

Die Performance speziell im bridge-modus ist sehr gut, die zusätzliche Latenz ist extrem niedrig, was im gerouteten Setup unser Hauptproblem mit der TK-Anlage war, speziell an den DSL-Anschlüssen (deutliche echos, Lautstärke ging bis ins unhörbare nach unten bis hin zu kompletten abbrüchen und ständigen neustarts der Satelliten). OpenVPN war hier noch schlechter, da hier alles durch den Master geroutet werden musste - Gespräche zwischen den Satelliten waren praktisch nicht möglich.

Auch meine Server zuhause und extern wurden per tinc vernetzt - für Monitoring, Backup und was sonst so alles anfällt. Das Notebook tunnelt von Unterwegs aus unsicheren Netzen ebenfalls alles durch tinc. Da das Setup so schön schnell erledigt ist, kann man praktisch für jeden Zweck ein eigenes "wegwerf-VPN" einrichten.


Tinc ist für mich mittlerweile ein absolutes "fire & forget"-Tool - einmal eingerichtet verrichtet es absolut klaglos und stabil seinen Dienst (wie geschrieben: selbst Monitoring läuft durchs tinc-VPN).
Da das setup auch noch sehr schnell ist (<5min je host), kann man auch kurz mal für tests oder einzelne Anwendungsfälle ein eigenes VPN zwischen mehreren Rechnern aufbauen - solange einer davon ne feste/bekannte IP hat, können (direkte!) Verbindungen zwischen allen Teilnehmern aufgebaut werden.

[ThorstenS]

boah, danke dir. Das hört sich ja super an!
Dann werde ich mich doch mal einlesen und es für den remote-Zugriff in die 4ma einsetzen. (ein bridging meines Laptops in das vlan an eth0.xx sollte ja möglich sein).

[r4pt0r]

Bridging direkt auf ein physisches Interface ist kein Problem - so habe ich die TK-Anlage vernetzt.

Einzige "besonderheit" in der tinc-konfiguration ist das "tinc-up" script, in dem das von tinc erstellte interface (tunN) an die bridge gekoppelt wird, an der bereits das physische interface hängt.

Sieht bei mir z.B. so aus:

/etc/network/interfaces

Code: Alles auswählen

auto eth4
iface eth4 inet manual

auto bridge0
iface bridge0 inet manual
        address 172.16.0.1
        netmask 255.255.255.0
        bridge_ports eth4
        bridge_stp on
        bridge_fd 0

tinc-up

Code: Alles auswählen

#!/bin/sh
ifconfig $INTERFACE 0.0.0.0
brctl addif bridge0 $INTERFACE
ifconfig bridge0 172.16.0.1 netmask 255.255.255.0
ifconfig $INTERFACE up

In der tinc.conf wird dann noch "mode = switch" gesetzt, damit wird tinc völlig transparent und die Geräte an den ethX-interfaces sind miteinander verbunden als würden sie gemeinsam an nem switch hängen. Es findet also kein routing/firewalling durch den host statt (=> niedrige latenzen) und auch ICMP wird transparent durchgereicht - also vorsicht wenn man ganze Netze/-segmente damit verbindet!
Wenn man nicht über die tinc-server/gateways in das Netz zugreifen muss, kann man auch die IP-konfiguration (address, netmask) für die bridge weglassen - dann sind wirklich nur die Geräte die an die ethX-interfaces angeschlossen werden miteinander verbunden.

Um ein Laptop transparent ins LAN zu holen müsste das gateway dann das tun-interface von tinc in eine bridge mit dem LAN-interface werfen. Ich wüsste aber nicht wozu man diesen "Aufwand" betreiben sollte - ein standardsetup (geroutet) ist da einfacher...

[ThorstenS]

Klasse, danke für deine detailierte Antwort.

Den Aufwand möchte ich treiben, weil ich gelegentlich mit tools hantieren muß, die darauf angewiesen sind in der gleichen broadcast-domain zu sein, wie die Hardware, die sie managen sollen (z.B. v2 netgear Switche und ein DVD Vervielfältiger). Wenn ich mich mit einem neuen tool beschäftige, dann soll es auch gleich einen deutlichen Mehrwert bringen

[debi14]

Hi!

So hier noch meinen Senf zu dem Thema: Wir nutzen hier seit knapp 12 Monaten OpenVPN und sind sehr zufrieden.

Umgebung:
Standleitung: 50Mbit symmetrisch
2x Server (T. Krenn) mit Intel Xeon im HA Verbund > Es wird also per "random" entschieden auf welchen Server sich ein Client verbindet.
OS: Debian jessie
Darüber arbeiten 50 User (Road Warrior), davon sind min. 30 gleichzeitig online.

Outlook lokal, div. Anwendungen wie ELO DMS, CRM etc im Browser, der Rest über Terminalserver.

Wir hatten bisher noch keine Probleme, die beiden Server laufen nun seit einem Jahr ohne Neustart etc

Im Vorfeld haben wir mit iperf und Co die Geschwindigkeit getestet und konnten von Beginn an ohne "tweaks" die volle Geschwindigkeit rausholen.

Aktuell wüssten wir nicht was man(n) an OpenVPN besser machen könnte