VPN Performance bei S2S
-
@NOCling
Setzt aber voraus, dass man die Formel kennt. -
@slu hi ja pppoe ist im Spiel !
-
Hallo SLU - wie beschrieben - PPPoE ist im Spiel - aber das macht nicht die Pfsense Box sondern ein vorgeschalteter Router
Was gibt es in diesem Bezug zu beachten ?
-
@gtrdriver said in VPN Performance bei S2S:
PPPoE ist im Spiel - aber das macht nicht die Pfsense Box sondern ein vorgeschalteter Router
Dann kann die Kombination PPPoE auf der pfSense kein Problem sein. Der Router davor bringt die Leistung?
-
@slu
Hallo SLU - ja der vorgeschaltete Router bringt die Leistung (gemietet vom Anbieter) - aber ja die Tests bestätigen dass dieser nicht der Flaschenhals ist. -
Das kannst du nicht vergleichen da hier Protokolle im Einsatz sind die die MTU/MSS selbständig aushandeln.
Das musst du bei VPN halt selber sauber umsetzten und die MSS von 1328 ist die die immer funktioniert, weil selbst PPPoE und DS-Lite groß genug ist das die Pakete sauber durch laufen ohne Fragmentierung. -
@gtrdriver said in VPN Performance bei S2S:
Ich habe jetzt noch versuche unternommen mit OpenVpn und Wireguard - beides Site2Site und hier ist die Performance eher mau - openvpn - 50-70mbit - wireguard 60-100mbit.
Dann wird es vermutlich eher eine Geschichte Richtung MSS/MTU sein, die greift auch bei OVPN/WG. Genau die gleiche Diskussion, die jetzt mit IPsec losgetreten wurde, gilt genauso für andere VPNs. Plus dass OVPN wenigstens die Chance hat, auf TCP auszuweichen, was bei IPsec/WG nicht geht.
Daher würde ich bei OVPN mit DCO bleiben, das korrekt mit GCM aufsetzen (und checken, dass die Enden auch saubere Crypto Beschleunigung an haben etc.) und dann mal die MTU/MSS absenken. 1400, 1360, 1320, 1280, 1240... muss man sehen. Je nachdem was zwischen den beiden Enden sich abspielt, kann die MTU da in die Verbindung stark reinhauen.
Gestern erst mit einem Kunden eine IPsec Verbindung geprüft - ohne VPN ~200-250Mbps, mit VPN nur 50. MTU angepasst, gings direkt auf 150-200 hoch und alle waren mehr als happy.
Somit liegt das meistens SEHR wenig am VPN sondern mehr an den zusätzlichen Einstellungen.
Cheers
-
@JeGr Hi - das klingt interessant ... - du passt die MTU in den OpenVPN Custom Options an - richtig ?
Welche Verschlüsselungsverfahren verwendest du in diesem genannten fall ?
Verbindung via UDP oder TCP ?Grüße
-
@gtrdriver said in VPN Performance bei S2S:
Die Rechner auf denen PFSENSE läuft sind recht peformant ich kann mir nicht vorstellen dass die CPU hier das begrenzende element ist.
Kannst du mal bitte trotzdem die genauen daten der eingesetzten Hardware nennen, hat die Hardware Realtek NICs?
Ich haben 2 x Netgate 6100 an GLAS 1 Gbit/s symmetrisch und die macht das ordentlich mit OpenVPN (habe jetzt keinen iperf, deshalb kann ich keine werte liefern). Privat habe ich meine Netgate 6100 und die macht an meinem Internet Zugang mit PPPoE auch einen guten job.
-
Servus - klar gerne ...
Auf der Glasfaser Seite:
Glasfaser Router <Kupfer > 10G Switch auf VLAN < In House Glasfser> 10G Switch VLAN <Glasfaer> AMD EPYC Server mit 10G Modul
Client Seite:
KABEL/DSL Router <Kupfer> - HP-Thin Client (AMD Ryzen Embedded V1756B mit Quad BCM5719 Broadcom NIC)
-
Hallo zusammen
so - ich habe heute den halben tag damit verbracht verschiedene Test Szenarien durchzuspielen....
Szenario1:
Ich hab nen Server in einem Rechenzentrum stehen darauf ne pfsense - normalerweise mit Openvpn an einem Standort mit Wodafone Kabel angebunden.
Hier ergeben sich werte von 50-90mbit/s bei einem single Transfer
Bei 10 gleichzeitigen Transfers maximal 190mb/sHier habe ich jetzt mal IPSEC eingesetzt und nen IPSEC tunnel gemacht. und ja - Wow ...
Single Transfer 150mbit/s
Transfer mit 10 Parallelen Requestes - 890mbit/sSzenario2:
Am Standort mit der Glasfaser Nur den router des Anbieters und dahinter eine Hardware starke Pfsense - die gleichen Tests zum VF Kabel anschluss und zu 2 Telekom DSL Anschlüssen
Openvpn single 28-32mbit/s
Openvpn Multi - 60-75mbit/sIpsec single 30-32mbit/s
Ipsec Multi 62-70mbit/sIch habe dann noch mit der im Thread genannten MSS experimentiert - jedoch kaum einen Unterschied festgestellt.
Es dreht sich mir langsam aber sicher der Gedanke auf dass ich hier einsetzten kann was ich will - da Limitiert irgendwas am Anschluss / Anbieter des Glasfaser Anschlusses ....
Hat noch irgendwer eine Idee ?
-
Klingt dann ja nach einem Problem im Peering bei einem der Provider.
-
Hallo zusammen
ich hab jetzt mehr aus Verzweiflung mal ne Fritzbox an den ONT des Glasfaser Anschlusses angeschlossen und Wireguard VPN Verbindung für ein Einzelgerät erstellt.
Auf der Seite mit dem VF Kabel dann an einem WIN PC den Wireguard Client installiert die Verbindung importiert und mit iperf getestet ...
Mit iperf und ner single Verbindung sofort 70-80Mbit bei 4 Parallelen Verbindungen 180mbit bei 9 ist wohl irgendwo die Deadline mit 220mbit.
Das zeigt mir ganz klar dass der Glasfaser Anschluss mehr auf dem Kasten hat als ich ihm bisher zugetraut habe und dass der Flaschenhals irgendwo anders liegt....
Momentan fehlt mir der Ansatz wo ...
-
Hallo zusammen
ich bin jetzt einen ganz großen Schritt weiter gekommen und sehr sehr erleichtert...
Mit dem beschriebenen Setup habe ich jetzt mal alle unwägbarkeiten ausgeschlossen und mit einem Cleanen setup experimentiert.
IPSec hab ich jetzt mal ausgeschlossen und mich auf Wireguard und OpenVPN konzentriert.
Mit Openvpn bekomme ich jetzt im Glasfaser Upstream zu VF Kabel 180 -200Mbit.
WAs mir auffällt ist dass die Datenraten hier relativ stark schwanken - aber immerhin mehr als die bisherigen 40-60Mbit...Mit Wireguard geht die Post ab - Im Bei einer einzelnen TCP Verbindung sind es stabil 72Mbit/s - bei 12 Parallelen Verbindungen bis zu 650Mbit/s.
Damit werde ich wohl mit WG weiter machen - ist etwas aufwändiger zu Konfigurieren und ich hab auch noch nicht alles am laufen - aber wie gesagt - ein riesiger Schritt nach Vorne !!!
Wenn jemand Interesse hat - ich hab mich an den Video orientiert:
https://www.youtube.com/watch?v=7_gLPyipFkk&t=1693s
BTW: Bei Wireguard muss man in den Interfaces die MTU manuell setzten - am stabilsten läuft das bei mir mit 1400.
Bei OpenVpn habe ich ebenfalls mit der MTU experimientiert - aber es scheint als wenn da der derfault wert optimal gewählt ist ...Grüße
GTR -
@gtrdriver said in VPN Performance bei S2S:
Bei OpenVpn habe ich ebenfalls mit der MTU experimientiert - aber es scheint als wenn da der derfault wert optimal gewählt ist ...
Nö. Definitiv nicht. Haben wir ständig, dass die MSS/MTU angepasst werden muss. Zudem weiß man nie, was die ISPs am Anschluß rumfummeln. Wir hatten UDP Verbindungen die liefen super schnell, andere waren sacklangsam und umgestellt auf TCP waren sie plötzlich (trotz overhead) schneller. Teils hatten wir schon Einbrüche um 50% der Leistung als der Provider gewechselt wurde. Frankreich bspw. auf Orange gewechselt - bäm, lahm. Auf TCP geswitcht weil am schnellsten machbar -> fast wieder auf alten Werten. Am MSS/MTU geschraubt (das muss bei OpenVPN IN der Config mit Parametern gemacht werden, nicht irgendwo am Interface) und auch da dann plötzlich bessere Werte gehabt.
Gleiches Phänomen kürzlich beim Kunden mit VPN Tunnel via IPsec nach Hause. Nur so ~50Mbps bekommen. Trotz potenterer Hardware (N150) und guter Leitung, die 200-250 zulassen sollte. Auch bei IPsec am MTU gedreht (advanced settings) und bei 1328 dann plötzlich 150-180Mbps durch bekommen. Kunde verwirrt, denn er hatte vorher von Firma zu anderer Firma/RZ getestet und da liefs ohne Änderung mit Bombendurchsatz.
Fazit: Hat meistens nicht oder nur sehr wenig mit dem verwendeten VPN zu tun und tatsächlich mehr mit den Einstellungen wie MTU/MSS, die die Verbindung stark beeinflussen können.
Edit(h): Hoppla, fast vergessen. Die Parameter in OpenVPN, die das stark beeinflussen sind bspw.
tun-mtuodermssfix. Meist genügt es, bspw.mssfix <Wert>in die advanced options Textbox auf Clientseite zu packen und die Verbindung neu zu starten. In unserem letzten Versuch mit ausländischen Verbindungen über mehrere Provider und Peerings hatte hier bspw. "mssfix 1320" auch sehr große Unterschiede gebracht zu vorher. Der tatsächliche Wert wird aber wahrscheinlich abweichen, man kann sich da aber ganz gut von bspw. 1240/1280 in 20er oder 40er Schrittchen nach oben arbeiten.Cheers
-
@JeGr Hi JeGr
erstmal danke für die Hinweise - in dem Zusammenhang hätte nich noch ein paar Fragen:
1: ist es korrekt dass es reicht die MTU mittels mssfix oder tun-mtu nur auf der client Seite anzupassen ? - Die Server Seite bleibt unberührt in der config ?
2: Welche Durchsätze hast du in der Praxis mit OpenVPN erzielt wenn die MTU gut angepasst ist ?
3: Spricht aus deiner Sicht irgendwas gegen oder für wireguard ?
Grüße !
-
@gtrdriver wir haben an einer Dark Fiber im Office Netgate 6100 und im Office Dell Server mit Intel(R) Xeon(R) Silver 4309Y CPU @ 2.80GHz im Einsatz.
Wir kommen an die 1Gbits/s voll verschlüsselt (hier ist die Netgate 6100 der Flaschenhals). -
@micneu
Hi und iHr nutzt hier openvpn ?ich habe gestern 2 Stunden lang mit Openvpn und der MTU rumgespielt - sowohl mit mssfix als auch mit tun-mtu - wie vorgeschlagen sogar in 10er schritten - ich komme maximal - auf 200mbit/s
Da ich nicht genug "Kisten" da habe beide Pfsense viritualisiert auf AMD Epyc Servern...
Habe dann nochmals nen Versuch mit Wireguard unternommen und erreiche hier realistische 900Mbit/s - aber auch erst nach Anpassung der MTU - dann aber sehr stabil....
-
@gtrdriver said in VPN Performance bei S2S:
1: ist es korrekt dass es reicht die MTU mittels mssfix oder tun-mtu nur auf der client Seite anzupassen ? - Die Server Seite bleibt unberührt in der config ?
Man kann es an beiden Seiten ändern, wenn der Server es ändert, dann gilt das aber gleich für alle Clients. Bei S2S Tunneln kein großes Thema wenn da ein Server pro Tunnel läuft, für Roadwarrior eher suboptimal, weil da jeder was anderes gern hat. Daher ändern wir das meist testweise auf Clientseite und arbeiten uns da Stück für Stück ran, ob es was bringt.
@gtrdriver said in VPN Performance bei S2S:
2: Welche Durchsätze hast du in der Praxis mit OpenVPN erzielt wenn die MTU gut angepasst ist ?
Wenn keine seltsamen Sachen am Start sind, die zwischen den zwei Providern Streß machen, haben wir je nach Hardware schon mehr als ordentliche multi-hundert-Megabit Strecken gehabt. Ja mit OpenVPN. Nein, kein Wireguard. Ja, das ist machbar :) Aber eben stark abhängig zwischen den Standorten und was da an Peering, Providern und sonstwas dazwischen quer hängt.
Wie gesagt, wir hatten das schon, dass ein Providerwechsel auf Clientseite die ganze Tunnelperformance gekillt hat. Erst nach Switch auf TCP und kleinere MSS war das wieder halbwegs hinnehmbar. Da weiß man leider nicht, was die da treiben, ob die mit irgendwelcher BlackMagic(TM)-Detection-BS irgendwelches Shaping oder dePriorisierung machen oder oder oder.@gtrdriver said in VPN Performance bei S2S:
3: Spricht aus deiner Sicht irgendwas gegen oder für wireguard ?
Hängt STARK vom Einsatzzweck ab. Zwei Seiten mit lediglich einer Sense am jeweiligen Ende? Hab Spaß :)
Für Homelab/daheim? Hab Spaß oder versuchs ruhig, kein Ding.Für Cluster oder Business? Meh. Wireguard schwebt abgehoben irgendwo im Kernel über den Interfaces und lässt sich nur schwer auf eine bestimmte IP quetschen. Das ist räudig. Wenn man also gezielte Steuerung des Tunnels haben will auf einem bestimmten WAN oder mit einer bestimmten Adresse ist WG mitunter das Werkzeug aus dem 7. Kreis der Vorhölle. Wird dran gebastelt, aber aktuell gibts da nichts wirklich schönes außer mit vielen Regeln und Co den Empfang/Senden zu verbieten, eher nicht so geil.
Oder wenn du eindeutige User-Auth machen möchtest von Benutzern bei der Einwahl in ein VPN. WG kennt keine User. Nur Peers. Gegenstellen. Geräte. Das ist KEINE User Authentifizierung, sondern Geräte die sich anmelden. Ob es der User ist - keine Ahnung. Das wäre äquivalent zu OpenVPN mit Zert ohne User+Pass mit Auto-Einwahl. Wird auch nur das Gerät authentifiziert, aber keine Details vom Benutzer. Anbindung an sowas wie LDAP, AD, Radius o.ä. ist auch nicht drin, daher nett, aber im Unternehmenskontext einfach schwierig bis nicht sinnvoll direkt einzusetzen.Neue ZeroTrustAccess VPNs die darauf aufsetzen, wie Netbird, Tailscale etc. sind dann wieder ne andere Sache, denn da übernimmt eben die ZTA Schicht drüber (Control Plane von NB/TS bspw.) die Auth und die Geräte IDs und kann damit dann direkt umgehen, MFA machen, etc. etc.
Also als Technik: fein. Als VPN: in Maßen, je nach Einsatzzweck OK. Als Unterbau für ZTAs: sehr cool.
Cheers
