13
SSL VPN Datendurchsatz Watchguard Firebox M390
Hallo zusammen,
derzeit haben wir eine Firebox M390 im Einsatz. Hierzu habe ich 2 kurze Fragen, bei denen mir hoffentlich jemand weiterhelfen kann. Ich möchte allerdings anmerken, dass sich diese Fragen nicht unmittelbar auf die Firebox beziehen, sondern vermutlich eher genereller Natur sind. Zumindest sind die beschriebenen Zahlen/Umstände auch bei unseren vorherigen Modellen schon so gewesen (alles Fireboxen von Watchguard).
1. Wieviel Bandbreite ist mit der M390 bei einer SSL-VPN Verbindung zu erwarten?
Ich habe auf den Spec-Sheets der M390 dazu keine klare Angabe gefunden, ich ging bisher davon aus, dass es da keine Einschränkung auf dem Gerät pro VPN-Kanal gäbe, abgesehen natürlich von der Bandbreite, die der Firebox und dem jeweiligen Client zur Verfügung steht.
So wie ich das verstehe, ist SSL-VPN nicht für seine enorme Geschwindigkeit bekannt, einige unserer Nutzer berichten allerdings von Übertragungsraten von 30 – 150 KB/s. Die Firma ist mit 500 Mbps Up/Down angebunden. Bei mir zu Hause kann ich relativ konstant mit ca. 10 Mbps Daten zwischen Firma und Heimanschluss hin und her kopieren (sowohl zu Stoßzeiten, als auch mitten in der Nacht). Mein Anschluss gibt allerdings ~250 Mbps Download (15 Mbps Up) her und erreicht diese für gewöhnlich auch. Beim Upload hätte ich also durchaus Verständnis für die Geschwindigkeit, beim Download habe ich mir da andere Zahlen vorgestellt. Diese Werte decken sich auch mit einem Großteil der Kollegen.
Nicht erklären kann ich mir hierbei die starken Schwankungen der Transferraten. Beim Kopieren einer 1 GB ISO aus dem Firmennetz springen die Werte sehr häufig von 1-10 Mbps hin und her. Bei durchschnittlich ~5-10 (+/-) simultanen VPN-Verbindungen tagsüber erscheinen mir die erreichten Werte relativ wenig. Besonders zu Zeiten, in denen sonst niemand via VPN verbunden ist, hätte ich mehr erwartet. Warum skaliert der VPN-Durchsatz nicht mit der verfügbaren Bandbreite (wenig Nutzer = hohe Geschwindigkeit, viele Nutzer = niedrige Geschwindigkeit)?
2. Wie sieht das „Best Practice“ zum Thema VPN-Verbindung aus?
Während für die Arbeit mit Remote-Desktop 10 Mbps ausreichen mögen, wird jeder Kopiervorgang zur Qual. Bei Benutzern, die nur auf einige KB/s kommen bricht selbst Remotedesktop regelmäßig ab. Da Homeoffice ja mittlerweile ein größeres Thema ist, interessiert mich, wie andere Firmen das handhaben. Was gibt es hier für Alternativen zu der SSL-Variante? Ich habe bereits mit IKEv2 rumprobiert und komme da auf etwas bessere Zahlen, so ca. 15 – 30 Mbps. Hier habe ich allerdings noch keine Vergleichswerte von anderen Kollegen, außerdem schwanken die Werte auch hier gefühlt sehr stark.
Kann es sein, das hier irgendwo ein Flaschenhals konfiguriert ist, oder habe ich einfach nur falsche Vorstellungen von VPN-Geschwindigkeiten? Tipps werden dankbar angenommen.
Viele Grüße
Erik
derzeit haben wir eine Firebox M390 im Einsatz. Hierzu habe ich 2 kurze Fragen, bei denen mir hoffentlich jemand weiterhelfen kann. Ich möchte allerdings anmerken, dass sich diese Fragen nicht unmittelbar auf die Firebox beziehen, sondern vermutlich eher genereller Natur sind. Zumindest sind die beschriebenen Zahlen/Umstände auch bei unseren vorherigen Modellen schon so gewesen (alles Fireboxen von Watchguard).
1. Wieviel Bandbreite ist mit der M390 bei einer SSL-VPN Verbindung zu erwarten?
Ich habe auf den Spec-Sheets der M390 dazu keine klare Angabe gefunden, ich ging bisher davon aus, dass es da keine Einschränkung auf dem Gerät pro VPN-Kanal gäbe, abgesehen natürlich von der Bandbreite, die der Firebox und dem jeweiligen Client zur Verfügung steht.
So wie ich das verstehe, ist SSL-VPN nicht für seine enorme Geschwindigkeit bekannt, einige unserer Nutzer berichten allerdings von Übertragungsraten von 30 – 150 KB/s. Die Firma ist mit 500 Mbps Up/Down angebunden. Bei mir zu Hause kann ich relativ konstant mit ca. 10 Mbps Daten zwischen Firma und Heimanschluss hin und her kopieren (sowohl zu Stoßzeiten, als auch mitten in der Nacht). Mein Anschluss gibt allerdings ~250 Mbps Download (15 Mbps Up) her und erreicht diese für gewöhnlich auch. Beim Upload hätte ich also durchaus Verständnis für die Geschwindigkeit, beim Download habe ich mir da andere Zahlen vorgestellt. Diese Werte decken sich auch mit einem Großteil der Kollegen.
Nicht erklären kann ich mir hierbei die starken Schwankungen der Transferraten. Beim Kopieren einer 1 GB ISO aus dem Firmennetz springen die Werte sehr häufig von 1-10 Mbps hin und her. Bei durchschnittlich ~5-10 (+/-) simultanen VPN-Verbindungen tagsüber erscheinen mir die erreichten Werte relativ wenig. Besonders zu Zeiten, in denen sonst niemand via VPN verbunden ist, hätte ich mehr erwartet. Warum skaliert der VPN-Durchsatz nicht mit der verfügbaren Bandbreite (wenig Nutzer = hohe Geschwindigkeit, viele Nutzer = niedrige Geschwindigkeit)?
2. Wie sieht das „Best Practice“ zum Thema VPN-Verbindung aus?
Während für die Arbeit mit Remote-Desktop 10 Mbps ausreichen mögen, wird jeder Kopiervorgang zur Qual. Bei Benutzern, die nur auf einige KB/s kommen bricht selbst Remotedesktop regelmäßig ab. Da Homeoffice ja mittlerweile ein größeres Thema ist, interessiert mich, wie andere Firmen das handhaben. Was gibt es hier für Alternativen zu der SSL-Variante? Ich habe bereits mit IKEv2 rumprobiert und komme da auf etwas bessere Zahlen, so ca. 15 – 30 Mbps. Hier habe ich allerdings noch keine Vergleichswerte von anderen Kollegen, außerdem schwanken die Werte auch hier gefühlt sehr stark.
Kann es sein, das hier irgendwo ein Flaschenhals konfiguriert ist, oder habe ich einfach nur falsche Vorstellungen von VPN-Geschwindigkeiten? Tipps werden dankbar angenommen.
Viele Grüße
Erik
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6345671538
Url: https://administrator.de/contentid/6345671538
Ausgedruckt am: 22.11.2024 um 04:11 Uhr
13 Kommentare
Neuester Kommentar
ist SSL-VPN nicht für seine enorme Geschwindigkeit bekannt
Sagt wer?? Wireguard ist ja bekanntlich auch ein SSL basiertes VPN und sogar eine alterschwache FritzBox schafft damit in beide Richtungen leicht und locker 50 Mbit/s VPN Durchsatz:https://www.heise.de/news/Neues-FritzOS-Mehr-VPN-Tempo-fuer-alte-Fritzbo ...
So wirklich scheint also an deiner Theorie nichts dran zu sein?! Im Vergleich zur ollen FritzBox ist dein Durchsatz dann eher mehr als mickrig. Fragt sich auch woher solche Weisheiten kommen...?
IPsec hat nahezu identische Durchsatzraten und sogar das schwache OpenVPN (ebenfalls SSL) kann da noch einigermaßen mithalten mit deutlich besserer Performance als du sie erziehlst.
Wenn man AES-NI fähige CPUs hat und TSO und LRO fähige NICs wie z.B. Intel 82579LM, Intel I218LM usw. sind übliche Werte bei 1Gig eher sowas:
Möglich auch das deine Fehler ganz woanders liegen, an falsch konfigurierten MSS Werten und daraus resultierender Fragementierung im VPN Tunnel, an überbuchten Anschlüssen der Heimnetz Nutzer, Heimnetz Provider die VPN Traffic drosseln um teuren Business Anschlüssen Vorrang zu gewähren oder durch eine belastete Firmenanbindung usw. usw.
Auch dazu machst du leider keinerlei hilfreiche Angaben. Ebenso was an Grundlast auf dem 500 Mbit/s Anschluss zur Messzeit anlag und ggf. zusätzlich belastet hat.
Unter diesen Messvoraussetzungen kann man natürlich keine belastbare Aussage zu der ganzen Thematik treffen was dir sicher auch klar ist. Dazu sind da einfach zu viele Unbekannte drin. Eben Kristallkugel...
Wenn, dann setze ein dediziertes Testszenario auf und messe mit verlässlichen Tools wie iPerf3 usw. was die HW wirklich schafft. Nur so bekommst du doch überhaupt erstmal einen belastbaren Vergleichswert!
Jeder renomierte FW Hersteller hat auch VPN Durchsatzzahlen abhängig von der Paketgröße an die man über Sales Partner oder die Distribution immer rankommt.
Wie bei allen Whitepapers ist die Angabe des Throughput SSL mit Vorsicht zu genießen. Die Hersteller sind immer sehr optimistisch.
Wir machen den Großteil der Clients mit Allways on VPN. SSL VPN ist eine Nische geworden.
Wir haben eine eigene Fassung basierend auf Tailscale entwickelt, welches den Direktzugriff auf die unzähligen Endpoints ermöglicht. Das hat uns sehr nach vorne gebracht.
S2S im Kern IPSec und bei ein paar Spielzeugen mit WG.
SSL VPN hat zu viele Nachteile.
Wir machen den Großteil der Clients mit Allways on VPN. SSL VPN ist eine Nische geworden.
Wir haben eine eigene Fassung basierend auf Tailscale entwickelt, welches den Direktzugriff auf die unzähligen Endpoints ermöglicht. Das hat uns sehr nach vorne gebracht.
S2S im Kern IPSec und bei ein paar Spielzeugen mit WG.
SSL VPN hat zu viele Nachteile.
SSL VPN hat zu viele Nachteile.
Nein. Die sog. "UTM"-Mogelpackungen sind es, die zu viele Nachteile haben.Da werden Features ohne Ende in ein kleines Gehäuse gepackt, in dem eine mehr oder weniger schwache Hardware werkelt. Hauptsache, man kann auch dem KU noch eine Subscription überhelfen. Wenn dann noch kleinere oder größere Konfigurationsfehler hinzu kommen, tröpfelt der Datenfluss.
Ein ordentlich konfiguriertes Wireguard oder IPsec ist flott und auf angemessener (in PC-Kategorien: Unterklasse-)Hardware in der Lage, Deine DSL-Verbindung auszureizen. OpenVPN (was häufig als SSL-VPN bezeichnet wird) ist langsamer, aber kann immer noch recht flott sein. Da genügt schon ein Raspberry Pi für bessere Werte, als Du hast.
In Deinem Fall würde ich aber auch auf Konfigurationsmängel tippen. Wenn Du über das VPN auch noch alle Security-Scanner laufen lässt, wird das dem Gerät sicher zu viel. Hier muss man selektiv entscheiden, was wann wofür eingesetzt wird.
Wenn Du die Watchguard liebst und behalten möchtest, nimm ihr das VPN weg und hänge in einen dafür abgetrennten Netzbereich ein VPN-Gateway mit einem Gerät, dass das kann. Das kann ein Router, eine Firewall oder auch nur ein Rechner (vorzugsweise Linux) sein, der diese Aufgabe übernimmt. Entscheidend ist, dass dieser nicht vergessen wird, sondern stets up to date ist, sonst wird es unsicher. Es gibt auch Fertigkisten, die sich VPN-Gateway nennen, aber auch da ist manches eher Mogelpackung.
Wenn Du auf den "UTM" verzichten magst/darfst gibt es auch schöne Töchter bei PfSense, OPNsense - da hat man die Hardware besser in der Hand, spart viel Geld und hat das Gerät direkt am Perimeter (worüber der Kollege @aqui immer glücklich ist
)Viele Grüße, commodity
Wir setzen seit zwei Zyklen auf Sonicwall. Hatten vorher Palo Alto.
Watchguard kommt für uns nicht in Betracht, wegen KO-Kriterien. Ein Kriterium hat etwas mit dem SSL-VPN auf nicht Windows Systemen zu tun.
Außerdem ist der Zug SSL-VPN eh abgefahren, weil wir auf unseren Fork von Tailscale für alles "Fremde" setzen und perspektiv damit 90+% erreichen werden.
Sensen machen für uns gar keinen Sinn, weil in dem Umfang wie wir Client-VPN machen, ich in der Frühschicht eine Vollzeitstelle dauerhaft bräuchte. Und einen Netzwerker setzen wir nicht zur Unterhaltung von Client-VPN ein.
Wir können auch auf UTM nicht verzichten, weil wir Regulatorien haben und diese müssen international sich handhaben lassen.
Und nein, es sind keine Konfigurationsmängel.
Ich würde in deinem Fall darauf tippen, dass Du noch nie ein großes internationales Unternehmen von innen gesehen hast, dass vollautomatische Produktionsstätten hatten mit internationalen Zulieferern.
Watchguard kommt für uns nicht in Betracht, wegen KO-Kriterien. Ein Kriterium hat etwas mit dem SSL-VPN auf nicht Windows Systemen zu tun.
Außerdem ist der Zug SSL-VPN eh abgefahren, weil wir auf unseren Fork von Tailscale für alles "Fremde" setzen und perspektiv damit 90+% erreichen werden.
Sensen machen für uns gar keinen Sinn, weil in dem Umfang wie wir Client-VPN machen, ich in der Frühschicht eine Vollzeitstelle dauerhaft bräuchte. Und einen Netzwerker setzen wir nicht zur Unterhaltung von Client-VPN ein.
Wir können auch auf UTM nicht verzichten, weil wir Regulatorien haben und diese müssen international sich handhaben lassen.
Und nein, es sind keine Konfigurationsmängel.
Ich würde in deinem Fall darauf tippen, dass Du noch nie ein großes internationales Unternehmen von innen gesehen hast, dass vollautomatische Produktionsstätten hatten mit internationalen Zulieferern.
Zitat von @2423392070:
Sensen machen für uns gar keinen Sinn, weil in dem Umfang wie wir Client-VPN machen, ich in der Frühschicht eine Vollzeitstelle dauerhaft bräuchte. Und einen Netzwerker setzen wir nicht zur Unterhaltung von Client-VPN ein.
also den punkt kann ich nicht verstehen, wir haben das bei uns automatisiert (OpenVPN Konfiguration wird bis zum benutzer auf das Notebook ausgerollt) man muss nur ein wenig scripten können
Noch einfacher ohne Scripting (und vor allem deutlich performanter) wäre es mit den Winblows onboard VPN Clients:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Rede ich gegen die Wand?
Unsere Leute haben in der Regel Allways on VPN. Das heißt unsere Geräte sind eh immer zu Hause.
Apu ausm Kwik-E-Mart-SPS-Coder, der nur zwei SPSen in einer Anlage erreichen soll, wobei er ein Sub ist und sein Auftraggeber und unser Partner ganze Subnetze erreichen können muss, können wir schlecht mit OpenVPN und etwas Scripting bekommen. Wer soll das pflegen? Und wo soll das gepflegt werden? In der Sense? Oder im zugehörigen Radius? Ich bitte dich.
Spätestens ab 50 VPN-Zugängen und mindestens genauso vielen Einschränkungen an Zugriffsmöglichkeiten ist OpenVPN der Sensen ein Hindernis und keine Bereicherung.
Unsere Leute haben in der Regel Allways on VPN. Das heißt unsere Geräte sind eh immer zu Hause.
Apu ausm Kwik-E-Mart-SPS-Coder, der nur zwei SPSen in einer Anlage erreichen soll, wobei er ein Sub ist und sein Auftraggeber und unser Partner ganze Subnetze erreichen können muss, können wir schlecht mit OpenVPN und etwas Scripting bekommen. Wer soll das pflegen? Und wo soll das gepflegt werden? In der Sense? Oder im zugehörigen Radius? Ich bitte dich.
Spätestens ab 50 VPN-Zugängen und mindestens genauso vielen Einschränkungen an Zugriffsmöglichkeiten ist OpenVPN der Sensen ein Hindernis und keine Bereicherung.
Lieber Kollege @2423392070,
hier freuen sich sicher alle mit Dir über Deinen so erfolgreichen beruflichen Werdegang - ebenso wie sie sich an Deiner statt (fremd-)schämen, wenn Du hier immer wieder Deine wirklich bedauernswerten und nach Hilfe schreienden Komplexe auslebst. Mein Mitgefühl hast Du.
Aber: All das hat nichts, überhaupt nichts, mit dem Problem des TO zu tun. Mit ein bisschen weniger egoorientierter Aufmerksamkeit bei der Lektüre wäre Dir vielleicht nicht entgangen, was jedem anderen hier offen ins Auge springt: Dass sich sowohl mein Beitrag, als auch der des Kollegen @aqui nicht auf Deine einmal mehr vorzügliche Darstellung Deiner bestimmt noch viel vorzüglicheren und sehr begrüßenswerten beruflichen Situation und ihrer Anforderungen sowie Deine sich daraus ergebenden, schier unermesslich scheinenden Kompetenzen bezog (sorry dafür!), sondern - leider viel zu schlicht, als dass es sich Deiner Wahrnehmung eröffnen könnte und unserem selbstredend weitaus weniger bedeutsamen Daseinszustand folgend - auf die Problemstellung dieses Threads. Ja, so simpel liegen die Dinge manchmal.
Auch wenn Dir jeder Deiner Beiträge verständlicher Weise persönlich besonders bedeutsam und erörterungswürdig erscheint und Du Dich naturgemäß ach so gern über Deine Stellung austauschen möchtest, sieh einfach großmütig darüber hinweg, dass wir uns zuweilen auch mit den in diesem Forum gestellten Fragen auseinandersetzen, ohne Deiner Weisheit angemessen zu huldigen, die sich uns ohnehin in viel zu geringem Maße erschließt. Ich persönliche freue mich immer über Ausführungen aus der Großkonzern-Administration (die ich in der Tat nicht kenne) und schätze auch wirklich Deine (leider viel zu wenigen) sachbezogenen und dann auch Kompetenzen zum Ausdruck bringenden Beiträge, die eben dann noch weitaus nachhaltiger wären, wenn sie zu Fragestellungen ergehen würden, die zu Deinen Anworten passen.
Viele Grüße, commodity
P.S.: Sorry für den Exkurs, @Erix83 - um auf Dein Problem zurückzukommen: Ich denke nicht, dass die Watchguard so schlecht ist, dass die beschriebenen Werte das Maximum darstellen. Ich gehe weiter von Konfigurationsfehlern aus. Gehe mal schrittweise durch, was die Verbindung verlangsamen könnte, was läuft da an "UTM"-Snakeoil, was lässt sich abschalten? Wenn Du jedes Bit auf Layer 7 untersuchst, wird es natürlich lahm. Die Kunst am Firewalling ist es, sich auf das Wesentliche (sinnvolle) zu beschränken. Jedenfalls, wenn man nicht "Großkonzerner" ist und das Budget noch dicker als die Hose
hier freuen sich sicher alle mit Dir über Deinen so erfolgreichen beruflichen Werdegang - ebenso wie sie sich an Deiner statt (fremd-)schämen, wenn Du hier immer wieder Deine wirklich bedauernswerten und nach Hilfe schreienden Komplexe auslebst. Mein Mitgefühl hast Du.
Aber: All das hat nichts, überhaupt nichts, mit dem Problem des TO zu tun. Mit ein bisschen weniger egoorientierter Aufmerksamkeit bei der Lektüre wäre Dir vielleicht nicht entgangen, was jedem anderen hier offen ins Auge springt: Dass sich sowohl mein Beitrag, als auch der des Kollegen @aqui nicht auf Deine einmal mehr vorzügliche Darstellung Deiner bestimmt noch viel vorzüglicheren und sehr begrüßenswerten beruflichen Situation und ihrer Anforderungen sowie Deine sich daraus ergebenden, schier unermesslich scheinenden Kompetenzen bezog (sorry dafür!), sondern - leider viel zu schlicht, als dass es sich Deiner Wahrnehmung eröffnen könnte und unserem selbstredend weitaus weniger bedeutsamen Daseinszustand folgend - auf die Problemstellung dieses Threads. Ja, so simpel liegen die Dinge manchmal.
Auch wenn Dir jeder Deiner Beiträge verständlicher Weise persönlich besonders bedeutsam und erörterungswürdig erscheint und Du Dich naturgemäß ach so gern über Deine Stellung austauschen möchtest, sieh einfach großmütig darüber hinweg, dass wir uns zuweilen auch mit den in diesem Forum gestellten Fragen auseinandersetzen, ohne Deiner Weisheit angemessen zu huldigen, die sich uns ohnehin in viel zu geringem Maße erschließt. Ich persönliche freue mich immer über Ausführungen aus der Großkonzern-Administration (die ich in der Tat nicht kenne) und schätze auch wirklich Deine (leider viel zu wenigen) sachbezogenen und dann auch Kompetenzen zum Ausdruck bringenden Beiträge, die eben dann noch weitaus nachhaltiger wären, wenn sie zu Fragestellungen ergehen würden, die zu Deinen Anworten passen.
Viele Grüße, commodity
P.S.: Sorry für den Exkurs, @Erix83 - um auf Dein Problem zurückzukommen: Ich denke nicht, dass die Watchguard so schlecht ist, dass die beschriebenen Werte das Maximum darstellen. Ich gehe weiter von Konfigurationsfehlern aus. Gehe mal schrittweise durch, was die Verbindung verlangsamen könnte, was läuft da an "UTM"-Snakeoil, was lässt sich abschalten? Wenn Du jedes Bit auf Layer 7 untersuchst, wird es natürlich lahm. Die Kunst am Firewalling ist es, sich auf das Wesentliche (sinnvolle) zu beschränken. Jedenfalls, wenn man nicht "Großkonzerner" ist und das Budget noch dicker als die Hose
2
Guten Morgen,
ehrlich verstehe ich in letzter Zeit immer weniger warum in diesem Forum immer wieder so ein Geschwafel aufkommt .... Darum antworte ich auch weniger .....
Wer von euch betreut eine Watchguard mit VPN-Einwahl?
Wir haben zwei M470 als Cluster auch für die VPN-Einwahl, darum nur kurz die Lehren aus der Corona Homeoffice Zeit:
- Fehler und lahme Verbindung liegen zu 98% auf der Client Seite, gerade Kabelanschlüsse machen immer wieder Spaß
- SSL VPN würde ich nicht machen, mach IKEv2, die WG macht das mit dem nativen Windows Client. Die WG spuckt dir ein Script aus, das installierst und verteilst du und gut. Das geht auch als Pre-Logon bei Windows. Wichtig ist das Zertifikat!
- Kopiere keine großen Dateien, arbeite mit RDP/Citrix Workspace/VMware Horizon ....Notfals per RDP auf den Rechner im Büro
- Jetzt was GANZ WICHTIGES!!! Bei DSLite Anschlüssen bricht dir die Performance total zusammen und IKEv2 per IPv6 kann die WG immer noch nicht (Case ist lange offen), darum dort die MTU der VPN-Verbindung auf 1280 herunterdrehen und alles ist gut
Weitere Fragen beantworte ich gerne
VG
Deepsys
ehrlich verstehe ich in letzter Zeit immer weniger warum in diesem Forum immer wieder so ein Geschwafel aufkommt .... Darum antworte ich auch weniger .....
Wer von euch betreut eine Watchguard mit VPN-Einwahl?
Wir haben zwei M470 als Cluster auch für die VPN-Einwahl, darum nur kurz die Lehren aus der Corona Homeoffice Zeit:
- Fehler und lahme Verbindung liegen zu 98% auf der Client Seite, gerade Kabelanschlüsse machen immer wieder Spaß
- SSL VPN würde ich nicht machen, mach IKEv2, die WG macht das mit dem nativen Windows Client. Die WG spuckt dir ein Script aus, das installierst und verteilst du und gut. Das geht auch als Pre-Logon bei Windows. Wichtig ist das Zertifikat!
- Kopiere keine großen Dateien, arbeite mit RDP/Citrix Workspace/VMware Horizon ....Notfals per RDP auf den Rechner im Büro
- Jetzt was GANZ WICHTIGES!!! Bei DSLite Anschlüssen bricht dir die Performance total zusammen und IKEv2 per IPv6 kann die WG immer noch nicht (Case ist lange offen), darum dort die MTU der VPN-Verbindung auf 1280 herunterdrehen und alles ist gut
Weitere Fragen beantworte ich gerne
VG
Deepsys
2
Was auch regelmäßig Probleme macht ist, wenn der Client unzählige Cliensoftwares installiert hat für unzählige Kunden.
Dann wird es arbeitsintensiv, weil dann sogar Bluescreens häufig auftreten.
Arbeitsteilige Welt mit vielen Externen die per VPN ran müssen, hat für viel Arbeit bei den Betreibern der Endpoints gesorgt. Wir hatten Zeiten, da sind ganze Schichten für ein VPN Problem draufgegangen.
Wir hatten sogar schon gerechnet, was es bedeutet den Lieferanten Field-PGs aus unserer Domain auszuhändigen. Nützt nur wenig, wenn der wichtige Coder international sich bewegt.
Im Bereich IPv6 ist WG immer noch nicht state of the art?
Und ja, unsere Kollegen Zuhause hinter Kabel Anschlüssen und manche Glasfasern waren sehr lästig während der Corona Anfänge.
Dann wird es arbeitsintensiv, weil dann sogar Bluescreens häufig auftreten.
Arbeitsteilige Welt mit vielen Externen die per VPN ran müssen, hat für viel Arbeit bei den Betreibern der Endpoints gesorgt. Wir hatten Zeiten, da sind ganze Schichten für ein VPN Problem draufgegangen.
Wir hatten sogar schon gerechnet, was es bedeutet den Lieferanten Field-PGs aus unserer Domain auszuhändigen. Nützt nur wenig, wenn der wichtige Coder international sich bewegt.
Im Bereich IPv6 ist WG immer noch nicht state of the art?
Und ja, unsere Kollegen Zuhause hinter Kabel Anschlüssen und manche Glasfasern waren sehr lästig während der Corona Anfänge.
Zuerst ein großes Danke für euer Feedback.!
Derzeit gibt es leider noch andere Projekte, die meine Aufmerksamkeit erfordern, daher hatte ich bisher noch keine Gelegenheit, mich erneut mit der Sache zu beschäftigen.
Ich habe noch das hier gefunden, habe es aber noch nicht angeschaut:
https://www.watchguard.com/help/video-tutorials/Optimize_Mobile_VPN_with ...
Vielleicht hilft es.
Ich melde mich Mitte nächster Woche erneut, bis dahin werfe ich mal einen Blick auf die UTM-Thematik, vielleicht sind die Std.-Einstellungen da wirklich ein bisschen zu "ehrgeizig".
Danke auch an @Deepsys - auf dein Angebot komme ich gerne zurück.
Gruß
Erik
Derzeit gibt es leider noch andere Projekte, die meine Aufmerksamkeit erfordern, daher hatte ich bisher noch keine Gelegenheit, mich erneut mit der Sache zu beschäftigen.
Ich habe noch das hier gefunden, habe es aber noch nicht angeschaut:
https://www.watchguard.com/help/video-tutorials/Optimize_Mobile_VPN_with ...
Vielleicht hilft es.
Ich melde mich Mitte nächster Woche erneut, bis dahin werfe ich mal einen Blick auf die UTM-Thematik, vielleicht sind die Std.-Einstellungen da wirklich ein bisschen zu "ehrgeizig".
Danke auch an @Deepsys - auf dein Angebot komme ich gerne zurück.
Gruß
Erik
Vielleicht hilft es.
Nicht wirklich. Das Split Tunneling Lösung performanter sind als Gateway Redirect ist eine Binsenweisheit. Ebenso die Verwendung von GCM Ciphers und UDP Encapsulation. Hilft nicht wirklich weil eben die anderen Fakten von oben weiter fehlen. Zum Rest hat Kollege @Deepsys ja schon alles gesagt...
Wenns das denn nun war bitte deinen Thread hier dann auch als erledigt markieren!
