Konstruktive Kritik zu den derzeitigen Diensten

[UPhmWgXe33g9]

Hallo,

ich bin erst vor kurzem zu PP gewechselt und neben bisher sehr positiven Erfahrungen habe ich jedoch auch einige Kritiken an den allgemein angebotenen Diensten.

Ich habe in den letzten Jahren wirklich etliche VPN-Anbieter genutzt um "den richtigen" für mich zu finden. Der Ruf von PP hat mich trotz des doch etwas "gehobenen Preismodells" dann hierher geführt.

Ich bitte dies gänzlich als konstruktive Kritik aufzunehmen.

Neben all den positiven Aspekten, welche ich bisher erfahren konnte gibt es jedoch in einigen Bereichen mMn gewisse Friktionen, die eigentlich nicht in das Bild von PP passen.
Sprich, auf der einen Seite extrem gute Services...auf der anderen Seite jedoch *ploppen" mir bisher immer einige Dinge entgegen, die so gar nicht zu den restlichen Services passen.

Und (bitte nicht schimpfen) da zieht man schon mal die ein oder andere Augenbraue hoch, wenn man für "Premium"-Service einen "Premium"-Preis bezahlt und dann Dinge nicht gehen, die eigentlich gehen sollten.

Sprich, die "besten" VPN-Server und die beste Technik und die besten Umsetzungen von Sicherheitsmaßnahmen bringen mir nichts...wenn die Services um diese Dienste anständig zu nutzen, unzureichend umgesetzt sind.

Das erste, was der Neukunde wahrnimmt, ist nicht der performante, dedizierte Server im RZ, sondern die App oder das Programm oder die Einrichtung des Zugangs zu einem Server.

IPSec und Android mit Always-On:
Eine Always-On-Verbindung funktioniert nicht, zumindest augenscheinlich nicht bei Android 7.x., teilweise wohl auch bei Android 6.x
Und ich kann nicht alle X Server durchtesten um einen zu finden, der das von PP vorgegebene IPSec Xauth PSK dann auch umsetzt und die Verbindung herstellt. Bzw. ob der Verbindungsaufbau überhaupt mit meiner Android-Version des Smartphones funktioniert.

Eine Always-On Verbindung per IP und DNS nach Schema 0-8-1-5 muss einfach funktionieren.

Diese Problematik wurde aber hier im Forum (soweit ich mich erinnere) bereits angerissen.

Android-App:
Die Android App ist extrem grausig
Diese scheint übrigens unter Android 7.x keine Funktion zu besitzen, da man zwar die Login-Daten eingeben kann, aber die App reagiert sonst auf keine Eingaben.
Man kann "drücken" wohin man will, die Tastendrücke werden von der App ignoriert = Funktionalität leider so genau mal Null.
Auch andere Services, wie bspw. "Autostart" oder "Autoconnect",etc. sind nicht vorhanden.
Die App wirkt laienhaft entwickelt um "überhaupt irgendwas für Android zu haben".
Auch hier bitte nicht böse nehmen, aber wenn man sich hier leider andere VPN-Anbieter anschaut dann ist bei euch der erste Gedanke zur App einfach nur "Das ist jetzt nicht euer Ernst,oder?"

Wechsel des Ciphers bei OpenVPN:
Ihr bietet unterschiedliche Arten der Verschlüsselung in Punkto Cipher bei OpenVPN an.
Bspw. habe ich die Wahl - bzw. es wird sogar explizit im Downloadbereich vorgeschlagen und ist vorausgewählt -, dass ich für mobile Verbindungen und Router den AES-128-CBC nehme.

Dies ist auch nachvollziehbar, da AES-128-CBC bei weiterhin sicherer Verschlüsselung deutlich weniger CPU-Last verursacht und somit den Akku auf Smartphones und die CPU bei Routern,Raspis,etc. schont.
Das schafft vor allem bei Routern (die i.d.R. relativ schwache CPU besitzen) nochmals einen Batzen mehr Performance und Bandbreite.

Jetzt habe ich nur auf dem Smartphone, einem Windows-PC sowie Linux folgendes festgestellt. Dies sieht man jedoch nur, wenn man sich explizit den Connection-Log ansieht.
Bei einer ausgewählten bzw. runtergeladenen OpenVPN Konfiguration bei AES-128-CBC wirft der Log bei allen von mir getesteten Servern (bspw. auch Frankfurt) unter anderem folgendes aus:

warning: 'cipher' is used inconsistently, local='cipher aes-128-cbc', remote='cipher aes-256-cbc'

Das bedeutet: Der Client möchte (wie auch ja so gewollt) eine AES-128-CBC, der Server möchte aber AES-256-CBC....es findet ein Fallback auf die Vorgabe vom Server statt: AES-256-CBC.
Das bekommt der Nutzer aber nicht mit (wenn er sich nicht die Logs anschaut), der denkt er wäre mit der gewollten AES-128-CBC unterwegs...ist es aber gar nicht.

Was bringt mir also die Wahl der Cipher Verschlüsselung im Downloadbereich, wenn die Server dies so in dem Umfang augenscheinlich gar nicht unterstützen?

Performance:
Folgendes ist meinerseits völlig wertfrei und eine reine neutrale Beobachtung, die ich einfach mal dahingestellt lasse:
PP nutzt bspw. in Nürnberg den selben Hoster wie auch andere VPN-Betreiber an diesem Standort. Ich werfe mal die CoreBackbone GmbH in den Raum.
Ich hatte mir beim Wechsel zu PP wirklich "high-Performance" versprochen.
Wenn aber ein "nachgeschmissen" VPN-Anbieter X,Y und Z am selben Standort und selben Hoster eine markant höhere Bandbreite erbringen als PP...ziehe ich auch hier eine Augenbraue hoch.
Wenn ich vom exakt selben Heimstandort auf einer 50K-Leitung mit OpenVPN (UPD) auf AES-256 mit den "Billiganbietern" in Nürnberg beim selben Hoster +-44MBit durch die Leitung bekomme...bei PP aber grundsätzlich nur +-30MBit...seltsam. An anderen Standorten sieht es (zumindest in Deutschland) nicht viel anders aus.
Jedoch, hier muss man ehrlich sein, die reine Latenz seitens PP ist abartig gut.

Ich wiederhole mich nochmal: Bitte nicht böse nehmen.

Aber mein Eindruck bisher:
-Die technische Umsetzung und Absicherung der Server sind exorbitant löblich
-Der Mitgliederbereich samt Anleitungen und allem was dazugehört ebenfalls sehr löblich
-Downloadbereich absolut löblich
...aber der "Rest" wirkt eher nach "2 Jahre für 60€"-Anbieter...und selbst die haben meist bessere Apps und Programme in Petto.

Ich bin momentan wirklich etwas Zwiegespalten, weil PP hat im Prinzip einen sehr guten Ruf und man erwartet ja eigentlich das "Rundum-Sorglos-High-Performance"-Paket das einfach fluppt...

 

[PP Frank]

IPSec und Android mit Always-On:
Eine Always-On-Verbindung funktioniert nicht, zumindest augenscheinlich nicht bei Android 7.x., teilweise wohl auch bei Android 6.x

Soweit mir bekannt, liegt das an Android. Ob das nur in Komnbination mit verschiedenen Herstellern ist, kann ich dir jetzt nicht sagen. Ist ja bei Android wo so ziemlich jeder drin rum frickelt leider nichts Neues.

Die Android App ist extrem grausig

Kann ich nachvollziehen. Wir geben natürlich unser Bestes auch verschiedene OS in Zukunft mit Clienten abzudecken. Android hat da aber erstmal keine Priorität, sondern eher MacOS und danach das normale Linux.

Wechsel des Ciphers bei OpenVPN:

Zu dem Problem kann ich nichts sagen, habe das aber mal weiter geleitet. Könnte auch an der verwendeten OpenVPN Version liegen, die das nicht unterstützt. Aber wie gesagt: Habe ich weiter geleitet.

PP nutzt bspw. in Nürnberg den selben Hoster wie auch andere VPN-Betreiber an diesem Standort. Ich werfe mal die CoreBackbone GmbH in den Raum.
Ich hatte mir beim Wechsel zu PP wirklich "high-Performance" versprochen.

Core-Backbone ist mit Sicherheit einer der guten Anbieter. Das da auch andere Anbieter mal drauf kommen, ist ja irgendwie logisch. Was du mit High-Performance sagen willst, erschliesst sich mir nicht. Der Speed der Server ist jedenfalls laut meinen Tests top und es gibt keinen Grund diese Server zu kritisieren. Im Normalfall liefern so ziemlich alle Server das Maximale was mit OpenVPN geht. OpenVPN packt eben keine 200 MBit oder so, da ist bei 90 meist Schluss. Wer mehr will, kann IPSec in unserem Manager versuchen.

Wenn aber ein "nachgeschmissen" VPN-Anbieter X,Y und Z am selben Standort und selben Hoster eine markant höhere Bandbreite erbringen als PP...ziehe ich auch hier eine Augenbraue hoch.
Wenn ich vom exakt selben Heimstandort auf einer 50K-Leitung mit OpenVPN (UPD) auf AES-256 mit den "Billiganbietern" in Nürnberg beim selben Hoster +-44MBit durch die Leitung bekomme...bei PP aber grundsätzlich nur +-30MBit...seltsam. An anderen Standorten sieht es (zumindest in Deutschland) nicht viel anders aus.

Tschuldigung, aber das ist wirklich echt Blödsinn. 1. Ist Core-Backbone kein Billiganbieter. Ganz im Gegenteil. 2. Wenn du bei einer 50iger Leitung nur 30 MBit durchbekommst, kann das auch an deinem Routing liegen. Es bringt auch nix da VPN Anbieter zu vergleichen, die mit ganz anderen Configs arbeiten. Ist ja nicht nur AES256 was eine Rolle spielt, sondern auch noch HMAC und andere Details. Dann sollte man eventuell einfach andere Stationen nutzen. Dafür haben wir schliesslich so viele, damit eben jeder einen oder zwei Server findet, wo er das Maximum herausholen kann. Viele Leute sind Beispielsweise von Bucharest begeistert, weil der angeblich wirklich was weg schiebt. Was aber nicht heisst heisst das es alle betrifft. Bei mir ist der zum Beispiel ziemlich lahm und bei vielen anderen auch. Die meisten Leute gehen über Amsterdam, gibt aber auch welche die dort kaum was durchbekommen. So ist das nunmal.

 

[PP Frank]

Anwort vom Kollegen:

Das ist weil OpenVPN erst in der letzten Version die art und weise geändert hat wie das cipher ausgehandelt wird. Und da wir auch clients < openvpn 2.4 unterstützen müssen haben wir die neue und die alte config art serverseitig konfiguriert. Das ist von OpenVPN auch so vorgesehen.
Siehe: https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
Serverseitig ist "cipher = AES-256-CBC" konfiguriert, und zusätzlich mit "ncp-ciphers" die liste der alternativen aushandelbaren cipher. D.h. clients < 2.4 die keine cipher negotiation unterstützen müssen AES-256-CBC benutzen, client > 2.4 können die negotation benutzen, sehen dafür aber die cipher inconsistent warnung.
Er sollte ein paar Zeilen weiter unten sehen, welcher Cipher ausgehandelt wurde

 

[rsa4096]

Das Problem mit der Aushandlung des Ciphers habe ich bereits in diesem Thread geschrieben: https://board.perfect-privacy.com/t...auf-aususwrt-by-merlin.1482/page-2#post-17352

Auf meinem Router wird leider auch immer AES-256-GMC ausgehandelt:

Apr 24 15:26:31 openvpn[15427]: WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher AES-256-CBC'
Apr 24 15:26:31 openvpn[15427]: WARNING: 'keysize' is used inconsistently, local='keysize 128', remote='keysize 256'
Apr 24 15:26:31 openvpn[15427]: Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Apr 24 15:26:31 openvpn[15427]: Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key

Es wäre schön eine Empfehlung zu bekommen mit welcher Konfiguration man AES-128-CBC erzwingen könnte.

Firmware: ASUSWRT Merlin 380.65_2
OpenVPN: 2.4.0

 

[PP Frank]

@rsa4096
Steht ja im Post über dir
Welche OpenVPN Version ist denn auf dem Router? Vermutlich irgendwas unter 2.4. oder?

 

[Nytro87]

Kein Wunder du suchst immer Server auf die voller sind. Wenn man Speed will geht man logischerweise auf Server wo weniger los ist. Also meist Frankreich Server, Prague oder Oslo die haben eine Super-Anbindung sind leerer. Und Core Backbone ist überhaupt kein Billiganbieter, die sind sogar eher sehr teuer! Und vergiss nicht, viele andere VPN Anbieter haben nur VPS Maschinen, die sind natürlich viel günstiger und bieten aber 0 Schutz. Ist den Anbietern aber meist sowieso egal weil sowieso alles geloggt wird. Das sind dann meist diese 30 € / 1 Jahr VPNs.

So wie ich das verstanden hab macht PP ausschließlich nur Housing oder wie das heißt. Die bezahlen da nur für eine Standleitung und stellen ihren eigene Hardware (die auch PP selbst gehört) in die Rechenzentren.

 

[PP Frank]

So wie ich das verstanden hab macht PP ausschließlich nur Housing oder wie das heißt. Die bezahlen da nur für eine Standleitung und stellen ihren eigene Hardware (die auch PP selbst gehört) in die Rechenzentren.

Das ist so nicht korrekt. Wir mieten direkt die Hardware im RZ: Eigene Hardware(also housing) ins RZ zu stellen würde keinen Sinn ergeben. Linux stellt alle Mittel zur Verfügung, um die Hardware auch via Terminal zu checken. Man kann da jede Tastatur abfragen die dran hängt. Sprich kostenmässig und auch von der Sicherheit, würde Housing definitiv Null Vorteile bringen. Wäre ein teuerer Spass für Null Vorteile.
Wir setzen aber ausschliesslich auf dedicated Hardware, da man dort eben auch prüfen kann was dran hängt. VPS kann ja alles sein. Sowas würden wir nicht holen. Auch wenn die Preise für VPS nur ein Zehntel betragen....
Ich habs auch schon gehabt, das ioch vom gleichen Standort über einen Server gegangen bin mit ISP A und Fullspeed hatte und mit dem anderen ISP auf dem gleichen Server, am gleichen Standort ging da nicht viel.

Und Core Backbone ist überhaupt kein Billiganbieter, die sind sogar eher sehr teuer!

Sehr teuer... Soweit würde ich dann auch nicht gehen. Die bewegen sich im normalen Bereich, vielleicht ein wenig teurer als andere, aber nicht so viel. Für die meisten anderen Stationen bezahlen wir nicht weniger.
Anbieter wie Webtropia in Düsseldorf, das war billig. Aber was dabei rum kam, das haben hier ja viele noch in Erinnerung Man hats mal probiert und dann besser gelassen

 

[Nytro87]

Okay, interessant zu hören, danke Frank

 

[rsa4096]

@rsa4096
Steht ja im Post über dir
Welche OpenVPN Version ist denn auf dem Router? Vermutlich irgendwas unter 2.4. oder?

Wie ich oben schon geschrieben habe, verwende ich die Version 2.4.0

Wenn ich meine Konfiguration komplett auf NCP mit 128bit umstelle, wird kein Tunnel aufgebaut und ich behalte meine ISP-Adresse.
Im Syslog sehe ich die folgenden Fehlermeldungen:

Apr 26 20:47:01 openvpn[990]: Error: pushed cipher not allowed - AES-256-GCM not in BF-CBC or AES-128-GCM:AES-128-CBC
Apr 26 20:47:01 openvpn[990]: OPTIONS ERROR: failed to import crypto options
Apr 26 20:47:01 openvpn[990]: ERROR: Failed to apply push options
Apr 26 20:47:01 openvpn[990]: Failed to open tun/tap interface
Apr 26 20:47:08 openvpn[990]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1590', remote='link-mtu 1606'
Apr 26 20:47:08 openvpn[990]: WARNING: 'cipher' is used inconsistently, local='cipher BF-CBC', remote='cipher AES-256-CBC'
Apr 26 20:47:08 openvpn[990]: WARNING: 'keysize' is used inconsistently, local='keysize 128', remote='keysize 256'

Vielleicht könnt ihr ja eine OpenVPN 2.4.0 128bit für Router bereitstellen.
Das wäre echt klasse. Denn je nach Versuch behalte ich meine ISP-Adresse oder es die Cipher hat 256bit.

 

[UPhmWgXe33g9]

Ich muss nochmal zurück zu meinem Eingangsthema bzgl. der Kritik:

Ich nehme alles zurück und behaupt bei fast allen Punkten das Gegenteil. Wie Eingangs erwähnt, erfolgte mein Wechsel erst vor kurzem und ich habe wohl zu schnell geurteilt.
Jetzt hier keine Richtigstellung darzulegen wäre meiner Meinung nach nicht fair.

Bzgl. der Android Thematik: Nach Recherche liegt es tatsächlich an einem Bug in Android, der in Konstellation mit gewissen IPSec-Konfigurationen auftritt. Entsprechende Bug-Reports gibt es schon länger, hier bleibt nur Abwarten.
Je nach Update-Politik der Hersteller wird im Rahmen von Patches wohl (irgendwann) behoben.

Das mit Cipher und der "Inkonsistenz"...ich habe mich ebenfalls nochmals eingelesen. Die Inkonsistenz führ nicht zu einem Fallback auf die 256-Bit, sondern der gewählte Cipher wird trotz Warnung genutzt.

Bzgl. Performance:
Ich habe mich hier auf diverse Speedtests gestützt. Und meine Aussage mit "Billiganbieter" war nicht auf CoreBackbone bezogen, sondern auf einen "VPN-Billiganbieter".
Bei Speedtests war ich es bei VPN-Servern aus vorherigen Erfahrungen gewohnt, dass mir (auch bei mehreren Tests unmittelbar hintereinander) immer pi mal Daumen die selbe Bandbreite angezeigt wurde.
Bei PP ist dies (warum auch sei dahingestellt) in meinem Fall zumindest etwas anders: Wenn ich bspw. 5 Speedtests zu einem Server meiner Wahl unmittelbar hintereinander laufen lasse, so habe ich eine erhebliche Fluktuation.
Da ist von 20 - 38 MBit alles drin, jeder Speedtest unmittelbar hintereinander zeigt teils markante Unterschiede auf.. Das habe ich aber erst im Nachgang festgestellt.
Im Rahmen von regulären Downloads (bspw. eine Linux-ISO-File) wird eine dem DSL-Anschluss entsprechende, vernünftige Bandbreite geliefert.

Das bedeutet: Ich entschulde mich in aller Form und auch im Namen meiner Familie ;-)

 

[PP Frank]

Da ist von 20 - 38 MBit alles drin, jeder Speedtest unmittelbar hintereinander zeigt teils markante Unterschiede auf.. Das habe ich aber erst im Nachgang festgestellt.

Welchen Speedtest hattest du genutzt? Vielleicht ist der auch nur grütze? Kann ja sein....

Bzgl. der Android Thematik: Nach Recherche liegt es tatsächlich an einem Bug in Android, der in Konstellation mit gewissen IPSec-Konfigurationen auftritt. Entsprechende Bug-Reports gibt es schon länger, hier bleibt nur Abwarten.
Je nach Update-Politik der Hersteller wird im Rahmen von Patches wohl (irgendwann) behoben.

Naja, da muss man ja leider damit rechnen, dass dies erst beim nächsten Telefon läuft Im Endeffekt ist das eigentlich traurig das man im Smartphone Markt nur die Wahl zwischen iOS und Android hat und der Rest schon mangels Apps nahezu unbrauchbar ist....

Das bedeutet: Ich entschulde mich in aller Form und auch im Namen meiner Familie ;-)

Und wasn mit deinem Hund und Katze und der Maus im Garten?