Produkt X wird teurer weil Produkt X sich nicht mehr selbst finanzieren kann.
Das ist der Irrtum. Es geht nicht um ein einzelnes Produkt, sondern um die Preisgestaltung des Portfolios. Aus betriebswirtschaftlichen Gründen kann es immer mal Sinn machen, Lockangebote mit Verlust zu verkaufen.
Solange wir uns über derartige betriebswirtschaftliche Grundlagen streiten müssen, werden wir hier kein Land sehen.
Ja, Da deutet vieles drauf hin.
Das ändern nichts daran, dass die zugrundeliegende Behauptung man könne die Konditionen nicht einhalten offensichtlich unwahr ist.
Du musst die Konditionen des gesamten Produktportfolios in Betracht ziehen. Dann ist die Aussage richtig. Jedenfalls ist es entschieden zu wenig, im Irreführung anzuführen.
Noch mal die Frage: Hast du ein günstigeres Angebot? Dann wechsel doch einfach.
Bei UDP musst du eine Sollbandbreite angeben, sonst testet er immer nur mit einem MBit/s pro Stream. Aber übertreibe es nicht, das verfälscht die Ergebnisse.
Die Angabe, man könne die Konditionen nicht mehr einhalten ist unwahr da es Neuverträge mit selbigen Konditionen gibt. Punkt aus und Ende.
Sowas nennt man Mischkalkulaion. Das Preisniveau insgesamt hat sich erhöht, sowohl das der regulären Produkte, als auch das der Aktionsprodukte. In Summe über alles genommen steigen die Einnahmen, aber Aktionsprodukte sind immer noch günstiger, als reguläre Produkte.
Hä? Das habe ich doch gar nicht gesagt?
Mit Bezug auf den Produktnamen klang ein gewisser aggressiver Unterton durch. Man konnte daraus durchaus schließen, dass du das Produkt genommen hättest, wenn es WH 1000, 2000 oder 4000 geheißen hätte, aber nicht mit dem Namen Black Comet.
Wie dem auch sei: Du dürftest inzwischen bemerkt haben, dass du die Specs erst erfahren wirst, wenn die Angebote veröffentlicht werden. Da hilft es nicht, sich vorab über den Namen aufzuregen.
Ist am Ende wirklich der Produktname ausschlaggebend? Oder nicht doch eher das Preis-Leistungsverhältnis?
Ggf. musst du für UDP noch Firewallregeln freigeben.
Hat denn irgendjemand mal Preise verglichen und bei anderen Anbietern ein deutlich günstigeres Angebot gefunden (nach der Erföhung)? Mit günstiger meine ich TCO, also inkl. Umzugsschmerzen, Verdienstausfällen, perspektivischer Entwicklung der Kosten etc.
Dann ist es an der Zeit, dir die TCP Parameter des VPS hinter der OPNSense anzusehen.
Grundsätzlich ja. Auf die vertraglich festgelegte Geschwindigkeit. Die physikalische Verbindung des Hosts dürfte schneller sein.
Ich hab mir noch mal die iperf Messungen ohne VPN aus deinem anderen Thread angesehen. Es gibt zwar Schwankungen über die Zeit, aber keinen Einbruch der Geschwindigkeit. Den Einbruch sieht man nur, wenn du Dateien übers VPN auf einen Rechner hinter dem VPS überträgst.
Was du noch mal versuchen könntest, ist ein iperf3 Speedtest ohne VPN auf die öffentlichen IPs, aber mit UDP anstatt TCP. Ich hab schon mal gelesen, dass Kabelanbieter angeblich UDP ausbremsen. Ich glaube es zwar noch nicht so wirklich, aber wir sollten es ausschließen.
Die WG MTU ist 60 (IPv4) oder 80 (IPv6) bit weniger als die WAN MTU.
Vorsicht: Bit und Byte gehen bei dir durcheinander. Die Rechnungen sind so nicht richtig.
Doppelte NAT müssten weitere Abzüge erfordern. Aber sowas machen wir ja nicht...
Nein, bei Doppel-NAT werden Adressen lediglich ausgetauscht, aber nicht hinzugefügt.
Hast du von DS Lite auf DS umstellen lassen? Im Zweifel mal den Support anrufen und um Abschaltung von "DS LIte" bitten.
Das hat ebenfalls keinen Einfluss auf die Performance.
Hint1: Bei einem DSL Anschluss noch einmal 8 bit abziehen.
Das müssen ebenfalls Byte sein.
Site2Site, wo die FW selber routen muss erfordert meistens eine explizite Definition der Gateways.
Da die Verbindung Ende-zu-Ende ja möglich ist, wird das Routensetup stimmen.
Ich bin aber nicht ganz sicher, welche Messung hier Schlussfolgerungen zulassen würde.
Im Zweifel immer die iperf Messungen.
Wenn du auf der WAN Schnittstelle 1432 hast, dann ist 1400 für die VPN Verbindung deutlich zu viel. Geh für den Tunnel mal auf 1300.
Auffällig ist halt, dass die Geschwindigkeit nach ein paar Sekunden einschläft.
Das ist interessant. D.h., es startet schnell und wird dann langsamer? Das hört sich so an, als ob da ein Traffic Shaping oder Congestion Control greift. Wireguard nutzt ja kein TCP, von daher fallen TCP Algorithmen eigentlich raus. Aber ein Traffic Shaping könnte natürlich sein. Hast du da mal was eingerichtet?
Ansonsten sind natürlich MTU Werte noch wichtig. Wie sind die für den Tunnel eingestellt?
Bei Dateioperationen ist ein Einfluss der Massenspeicher natürlich nicht auszuschließen. Wenn die Kopieroperationen allerdings genauso schnell laufen, wie iperf3, dann fällt das für den Test nicht ins Gewicht.
Also, CPU-Auslastung (WCPU) jeweils bei ca. 20 % (mal mehr, mal weniger). Interrupt ist lokal bei max. 1,1 %, bei Netcup max. 0,3 %.
Das hört sich erst mal nicht wirklich schlimm an.
Der Downstream bringt nur gut die Hälfte des zu erwartenden Wertes. Aber er liegt auf Höhe des Tests vom Client in deinem Heimnetz. Sprich: Die OPNSense Home an sich ist nicht das Nadelöhr, da die Datenrate deutlich über der des VPN Tunnels liegt.
Du hattest während des Tests über die VPN Verbindung schon mal die Systemauslastung im Blick behalten, richtig? Wo gabs mehr CPU Last? Auf der OPNsense Netcup oder der OPNsense Home? Behalte nicht nur die CPU Last im Auge, sondern auch die Interrupt Last.
https://iperf.fr/iperf-servers.php
Die aus Frankreich und den Niederlanden sind recht flott. Ist allerdings schon eine Zeitlang her, dass ich die gebraucht habe.
Dazu kann ich noch die hier empfehlen:
Ja, dann können wir festhalten, dass die VPN Verbindung defintiv erst mal optimiert werden muss.
Ein Grund für die Probleme könnte mangelnde CPU Leistung sein, oder auch eine schlechte Netzwerkkonfiguration (MTUs etc). Fangen wir erst mal zu Hause an, die Netcup Seite kommt dann im zweiten Schritt.
OPNsense Home (virtualisiert per ESXi)
Was ist denn da das Host System? Wie ist die Netzwerktopologie auf dem Host und den VMs? Hast du aus der OPNSense Home heraus eine gute Geschwindigkeit zu öffentlichen Servern?
Der Internetprovider spielt mit Sicherheit eine Rolle, im Moment aber wohl noch nicht die entscheidende (wobei wir im weiteren Verlauf durchaus noch dahin kommen können).
Nur, um das noch mal sicherzustellen: Die 192.168.133.1 ist das Ende des VPN Tunnels, richtig? Da ist kein VLAN oder ähnliches involviert? Der VPN Tunnel wird zwischen einem Router bei dir zu Hause und dem VPS bei Netcup aufgebaut, und du hast von einem Endgerät zu Hause (hinter diesem Router) und dem VPS den Speedtest über den VPN Tunnel gemacht, richtig?
