Jan 04, 2022, updated at 15:52:04 (UTC)

4280

Perfomantes VPN für großes, verteiltes Team mit "Auto-Aktivierung" - ist Wireguard empfehlenswert??

Hallo Zusammen,

ich suche aktuell nach einer VPN-Lösung, die folgendes Merkmale hat.

Anforderungen sind:

#1 VPN Client soll automatisch erkennen, wenn er nicht im Firmennetz ist und den Tunnel automatisch aufbauen.
#2 VPN Client soll beim Hochfahren automatisch starten. Interaktionen mit dem User sind nicht gewünscht. (Optimalerweise soll der User nicht merken, dass ein Tunnel aufgebaut wurde)
#3 Authentifizierung soll via Zertifikat (Rechner-Auth) und manuelles User-Auth möglich sein.
#4 Die Lösung soll auch dann performant genug sein, falls alle Mitarbeiter remote arbeiten. (System soll bis zu 500MA skalierbar sein - ~ca. 500Mbits im Durchschnitt)
#5 die Verwaltung soll serverseitig bei Client-Problemen genug Infos liefern.
#6 IP4 / IP6-Support
#7 VPN Client soll auch bei Usern ohne Admin-Rechte automatisch starten.
#8 bei Bedarf kann QoS für VoIP-Priorisierung aktiviert werden. (nice-to-have)
#9 VPN-Client soll möglichst alle Betriebssysteme unterstützen (Windows, MacOS, Linux, Android, IOS, usw.)
#10 SSL-Lösungen ohne große „Network-Overhead“ werden bevorzugt.
#11 OpenSource-Lösungen mit großem Community-Support werden bevorzugt.

Ich neige aktuell dazu dem Team folgendes Setup zu empfehlen: Wireguard oder ggf. OpenVPN auf einer 4-Core CentOS-VM mit 16GB RAM.
Zumindest Wireguard sollte performancetechnisch OK sein: https://www.wireguard.com/performance/

(Das Team setzt aktuell auf MS Direct Access, was an sich zuverlässig funktioniert.

Es gibt aber die folgenden Probleme mit DA:

- es gibt ältere Anwendungen, die noch IP4 benötigen
- Wenn es Probleme gibt mit einzelnen Clients, gibt es - serverseitig - kaum Infos was die Ursachen sein können.
Das team braucht also eine Lösung mit besseren Verwaltungsmöglichkeiten / Logs. )

Fragen:

1. Haltet ihr den Vorschlag mit WireGuard für sinnvoll oder würdet ihr zu OpenVPN oder eventuell zu einem kommerziellen Produkt wie die Lösung von Fortinet / Cisco?
2. sind solche klassische Client / Server Lösungen noch zeitgemäß oder ergibt es mehr Sinn eher mit SD WAN-Lösungen zu experimentieren, die neben einem Tunnel viel mehr Verwaltungsmöglichkeiten / Flexibilität bieten?

Vielen Dank für eure Meinungen.

Gr. I.

Please also mark the comments that contributed to the solution of the article

Content-Key: 1689117109

Url: https://administrator.de/contentid/1689117109

Printed on: May 2, 2024 at 04:05 o'clock

25 Comments

Latest comment

Es kommen bestimmt noch die Profis hier aber ich würde nicht openvpn nehmen, sondern l2tp, weil es auf all Deinen Clients schon systemweit integriert ist.

Oder Wireguard - da musste jedoch überall Clients installieren. Dafür so stabil und performant, dass das im Prinzip extern und intern einfach durchlaufen könnte und sich beim Rechnerneustart selbst aktiviert. Das klappt erfahrungsgemäß über Monate hinweg stabil.

VG

Vielen Dank Visucius,

die Installation dürfte via GPO kein Problem sein. (ich gehe davon aus, dass wir via GPO auch die generierten Keys und Serverconfigs ausrollen können. Aktuell arbeiten ja 90% der Kollegen remote)

Uns wäre es lediglich wichtig, dass der Client den Tunnel erst dann aufbaut - aber dann automatisch ohne PW-Eingabe - wenn die Notebooks und ggfs. die Handys sich nicht im Firmennetz befinden. (Schwerpunkt sind bei uns aktuell eindeutig die ca. 270 Windows10 Notebooks).

Gr. I.

wenn die Notebooks und ggfs. die Handys sich nicht im Firmennetz befinden.

Da wüsste ich jetzt per se nicht, wie das mit WG-integrierten Mitteln möglich ist. Wenn man von irgendwelchen selbstkreierten Skripten mal absieht. WG ist ja doch noch ziemlich "plain". Haben sie das DHCP-Thema schon gelöst?! Das wäre in Deinem Umfeld ja bestimmt ein Musthave! Meine Setups sind noch manuell handlebar.

Zitat von @Visucius:
Haben sie das DHCP-Thema schon gelöst?! Das wäre in Deinem Umfeld ja bestimmt ein Musthave!

ja, DHCP wäre wirklich ein KO-Kriterium.

Moin,

bin kein Profi in dem Bereich, aber bei deinen Anforderungen sind mir einige Dinge aufgefallen, die ich rein vom Basis-Konzept nicht nachvollziehen kann, bzw. die mir unklar sind.

Zitat von @istike2:
#1 VPN Client soll automatisch erkennen, wenn er nicht im Firmennetz ist und den Tunnel automatisch aufbauen.
#2 VPN Client soll beim Hochfahren automatisch starten. Interaktionen mit dem User sind nicht gewünscht. (Optimalerweise soll der User nicht merken, dass ein Tunnel aufgebaut wurde)

Was passiert, wenn der Tunnel mal abbricht oder der Client abstürzt. Soll der User dann jedes Mal seinen Laptop neu starten? Warum darf/soll der User nicht merken, dass ein Tunnel aufgebaut wurde? Ist doch gut für den User zu wissen, dass er jetzt gesichert mit dem Firmennetz verbunden ist und nicht ungesichert mit der Firma verbunden ist.

#3 Authentifizierung soll via Zertifikat (Rechner-Auth) und manuelles User-Auth möglich sein.

Widerspricht ein manuelles User-Auth nicht deinem Punkt 2?

#4 Die Lösung soll auch dann performant genug sein, falls alle Mitarbeiter remote arbeiten. (System soll bis zu 500MA skalierbar sein - ~ca. 500Mbits im Durchschnitt)

Im Regel Fall geben Hersteller mit an wie viele Parallele VPN-Verbindung deren Geräte verkraften. Beispiel hier:
https://www.boc.de/pub/media/documents/t15/20_Datenblatt-WatchGuard-Fire ...
Egal wie groß deine Bandbreite ist, mehr als 5 geht nicht.

#5 die Verwaltung soll serverseitig bei Client-Problemen genug Infos liefern.

Was sind genug Infos? Was genug ist, kannst nur du nach einem Test entscheiden.

#6 IP4 / IP6-Support
#7 VPN Client soll auch bei Usern ohne Admin-Rechte automatisch starten.

Der VPN Client startet im Regelfall ohnehin nur durch eine Verlinkung ins Autostart. Interessanter (und vermutlich auch gemeint) ist wie bereits oben geschrieben ein automatischer Logon?

#8 bei Bedarf kann QoS für VoIP-Priorisierung aktiviert werden. (nice-to-have)

Soweit ich weiß (lasse mich aber gerne korrigieren) ist ein QOS über einen VPN-Tunnel generell nur sehr schwer möglich. Dadurch, dass die VPN-Verbindung die Pakete verschlüsselt, ist ja gar nicht mehr bekannt um was es sich handelt. Aber wie gesagt: lasse mich gerne korrigieren.

#9 VPN-Client soll möglichst alle Betriebssysteme unterstützen (Windows, MacOS, Linux, Android, IOS, usw.)
#10 SSL-Lösungen ohne große „Network-Overhead“ werden bevorzugt.
#11 OpenSource-Lösungen mit großem Community-Support werden bevorzugt.

Wieso Open-Source mit Community-Support? Was spricht gegen Modelle mit Lizenzvertrag, wo dir im Fehlerfall geholfen wird. Ob du jetzt 3 Arbeitstage investierst um den Fehler zu finden oder ob du einen 30 minütigen Anruf an einen Experten absetzt und der dass dann in 3 Stunden wieder fixt ist kostentechnisch oft das gleiche, nur das deine Umgebung schneller wieder fit ist. Open-Source würde ich persönlich in dieser (wenn da wirklich alle deine 500 MA drüber arbeiten soll) nur einem Experten empfehlen. Der bist du aber in diesem Themenbereich nicht, sonst würdest du hier nicht fragen

Eine geeignete Lösung für dich habe ich dafür leider auch nicht, da ich mich in dem Bereich nur rudimentär auskenne und wir uns an der Stelle von einem Systemhaus unterstützen lassen. Wie gesagt: Da sitzt der Experte der für kleines Geld hilft und ich kann mich um andere Dinge kümmern. VPN hat keine Priorität bei uns.

Gruß
Doskias

Always-On VPN mit einer reinen IKEv2-Konfiguration auf der Perimeter-Firewall. Du bekommst serverseitig dieselben Logs wie bei jedem IPsec-VPN, abhängig von deinem Server, und clientseitig "nahtloser" geht es aus meiner Sicht nicht (ohne Bastelei).

Grüße
Richard

Moin,

Das was du suchst ist das tatsächlich "Always on - VPN" früher "Direct Access".

Gruß
Spirit

Aus Erfahrung rate ich von OpenVPN in dem Szenario ab.
Die haben (Stand Version 2.5) einen einzelnen monolithischen Prozess, der in Dauerschleife die Pakete verteilt - kein Multithreading.
Das skaliert ab einer bestimmten Paketrate nicht mehr und ab dem Moment bekommen alle Teilnehmer hohen Jitter und schlechte Bandbreiten.

Weder Wirguard noch OpenVPN sind sinnvoll bei den obigen Anforderungen. OpenVPN generell wegen der oben schon erwähnten schlechten Skalierbarkeit.
Generell solltest du bei dem genannten Anforderungskatalog niemals auf Lösungen mit 3rd Party Clients gehen sondern dann immer die bordeigenen VPN Clients ALLER Betriebssysteme bevorzugen.
Das sind in der Regel immer die IKEv2 VPN Clients und der am weitesten verbreitete L2TP/IPsec VPN Client. Diesen haben die beste Integration und Managebarkeit im Betriebssystem und dadurch Prinzip bedingt die beste Performance.
Beide lassen sich vollständig zentral automatisieren und steuern nach deinen Anforderungen (Domain Integation, GPO, Scripting usw.) und du ersparst dir die Frickelei mit betriebssystemfremder, externer Software und deren Wartung. Von den Abhängigkeiten der Lieferbarkeit mal gar nicht zu reden.
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Scheitern am IPsec VPN mit MikroTik
Usw. usw. was ja nur einen kleinen Auschnitt von möglichen VPN Servern ist. Bei der o.a. Größenordnung und Anforderungen brauchst du eh mehrere und vermutlich sogar eine PKI mit Zertifikats basierten VPNs. Bei solchen Userzahlen hantiert man i.d.R. nicht mehr mit PSKs.

Moin,

#3 Authentifizierung soll via Zertifikat (Rechner-Auth) und manuelles User-Auth möglich sein.

Zuerst drehst du die Sicherheitsschraube durch die Nutzung von Zertifikaten auf Basis von Computern hoch. Danach drehst du die Schraube aus der Mutter, indem du die Authentifizierung auf Basis von Benutzername + Passwort zulässt. Zumal es mit der Anforderung #2 ein Gegensatz darstellt.

#4 Die Lösung soll auch dann performant genug sein, falls alle Mitarbeiter remote arbeiten. (System soll bis zu 500MA skalierbar sein - ~ca. 500Mbits im Durchschnitt)

Ich hoffe die 500 MA = 500Mbits/s ist eine Rechnung auf dem Papier eines Controllers oder Studenten. Das haut in der Realität niemals hin. Überwache einen Netzwerk Port im lokalen Netzwerk eines Referenz Geräts für eine Woche. Du wirst feststellen, dass es Theorie bleiben wird. Dabei spielt natürlich auch eine Rolle, auf welchen Daten und/oder Anwendungen bei Nutzung von VPN z.B. über RDS zur Verfügung gestellt werden können/sollen/müssen.

#6 IP4 / IP6-Support

Für die VPN-Verbindungsaufbau oder/und für die Verbindungen innerhalb des Tunnels?

#8 bei Bedarf kann QoS für VoIP-Priorisierung aktiviert werden. (nice-to-have)

Setzt voraus, dass auf Transportebene alle Beteiligten ISP und Carrier das Bit nicht verwerfen/ignorieren und weitergeben. Das ist vermutlich für die Katz. Oder geht es dir um QoS im VPN-Tunnel bzw. VPN Endpunkt?

#10 SSL-Lösungen ohne große „Network-Overhead“ werden bevorzugt.

Solange du bei Protokollen wie IKEv1 oder IKEv2 bleibst, hält sich der Overhead in Grenzen.

#11 OpenSource-Lösungen mit großem Community-Support werden bevorzugt.

Open Source heißt nicht automatisch kostenlos. Wenn du/ihr euch nicht ausschließlich von Infrastruktur/VPN/Internet kümmert, kommt ihr meines Ansicht nach nicht um einen Supportvertrag drum rum. Dazu ist die Entwicklung, Abhängigkeiten und Komplexität zu schnell lebig. Abgesehen davon was los ist, wenn 500 Leute nicht arbeiten können? Das überlebst du keine drei Mal.

Ich neige aktuell dazu dem Team folgendes Setup zu empfehlen: Wireguard oder ggf. OpenVPN auf einer 4-Core CentOS-VM mit 16GB RAM.

Kann man machen, aber empfehlen auf keinen Fall. Wie sehen den die bisherigen Überlegungen bezüglich Lastverteilung, Failover bei Ausfall oder Wartungsarbeiten aus?

2. sind solche klassische Client / Server Lösungen noch zeitgemäß oder ergibt es mehr Sinn eher mit SD WAN-Lösungen zu experimentieren, die neben einem Tunnel viel mehr Verwaltungsmöglichkeiten / Flexibilität bieten?

Das kann man ad-hoc nicht sagen. Dazu kennen wir euere Umgebung und das IT Team zu wendig. Sind denn schon Erfahrungen zu SD-WAN vorhanden oder/und im Aufbau für ein anderes Projekt? Wer kann bei Störungen überhaupt noch Troubleshooting durchführen oder ist für jeden Handgriff der Support des Herstellers erforderlich?

1. Haltet ihr den Vorschlag mit WireGuard für sinnvoll oder würdet ihr zu OpenVPN oder eventuell zu einem kommerziellen Produkt wie die Lösung von Fortinet / Cisco

Auf Grund deiner Informationen bleibe ich an Microsoft Always-On VPN in Kombination mit Device Tunnel hängen. Ist allerdings weder OpenSource noch kommst du einfach an Hersteller Support (=Microsoft). Da solltest du dir auf jeden Fall einen qualifizierten IT-Dienstleister an Bord holen. Der Aufbau einer funktionierenden PKI ist auch nicht ohne. Ich kann es daher schwer einschätzen wo Ihr als IT Wissen und Erfahrungen habt und wo Wissen fehlt und aufgebaut werden muss.

Gruß,
Dani

Also mit OPENVPN schaffst man auch 5000 Client , die Frage ist immer wird der ganze Traffic getunnelt oder Split-tunneling etc
Lese hier nach.

https://openvpn.net/vpn-server-resources/openvpn-access-server-system-re ...

Der wichtigste Beitrag ist hier @Dani 's, das würde dir zum Herz legen

Vg

Dece

Herzlichen Dank an Euch alle für die detaillierte Rückmeldungen.

ich werde mit Always On VPN definitiv noch eine Runde laufen.
Im Vergleich zu DA scheint ja die fehlende IP4 Unterstützung kein Problem zu sein.
Auch die mangehalften LOgs können durch die flexible Serverwahl gelöst werden können. (wenn ich es richtig verstehe kann alles als VPN Server eingesetzt werden was IKEv2 unterstützt.)

Ich kläre es mal mit dem Monitoring wie die tatsächlichen VPN-Auslastungen bei der aktuellen HomeOffice-Userzahl aussehen.

Gr. I.

Moin,

Im Vergleich zu DA scheint ja die fehlende IP4 Unterstützung kein Problem zu sein.

Nein, ist es nicht mehr. Dafür gibt es andere Herauforderungen...

Auch die mangehalften LOgs können durch die flexible Serverwahl gelöst werden können.

Was sind mangelhafte Logs?

(wenn ich es richtig verstehe kann alles als VPN Server eingesetzt werden was IKEv2 unterstützt.)

Je nach dem. Einige Hersteller geben an, dass ihre Lösung auf Protokoll xyz basiert, aber Veränderungen vorgenommen worden sind. Je nachdem wie diese ausfallen, sind die Lösungen meistens inkompatibel.

Gruß,
Dani

Zitat von @Dani:
Was sind mangelhafte Logs?

Mein Kollege meinte, dass bei DA die angelegten Logs kaum Info über die Probleme geliefert hatten.
Wenn also ein Client keine Verbindung aufbauen konnte, hatte man keine Ahnung, warum.

Je nach dem. Einige Hersteller geben an, dass ihre Lösung auf Protokoll xyz basiert, aber Veränderungen
vorgenommen worden sind. Je nachdem wie diese ausfallen, sind die Lösungen meistens inkompatibel.

Welches Produkt würdest du als Server empfehlen?

Ich würde einfach StrongSwan auf der am Anfang beschriebenen CentOS VM einrichten.
Wir haben eh unsere VM-Infrastruktur, wo wir Leistung je nach Bedarf skalieren können.

EDIT: soweit ich sehe, werden 3rd Party Server (non Windows Server) nur bei sog. "User Tunnel" unterstützt:
https://www.smartit.ch/blog/always-on-vpn

bei "Device Tunnel" kommt anscheinend nur Windows Server in Frage ...

Always on VPN lässt sich nach meinem letzten stand splitten.
Das handling finde über die Windows Server konfig statt. Unten drunter läuft eh ipsec soweit ich weiß und könnte auch durch irgend eine firewall abgefackelt werden.

Habe es aber noch nicht so konfiguriert.

Hi Dani,

vielen Dank nochmals für deine Inputs.

Zitat von @Dani:

Du hast Recht, User-Auth brauchen wir nicht.

Ich hoffe die 500 MA = 500Mbits/s ist eine Rechnung auf dem Papier eines Controllers oder Studenten. Das haut in der Realität niemals hin.

Die Kollegen meinten, die Lösung soll in der Lage sein bei Bedarf auch mit 1Gbits VPN-Traffic klarzukommen.

Für die VPN-Verbindungsaufbau oder/und für die Verbindungen innerhalb des Tunnels?

Für die Verbindungen innerhalb des Tunnels.

#8 bei Bedarf kann QoS für VoIP-Priorisierung aktiviert werden. (nice-to-have)

Wir können darauf verzichten, nicht wirklich praxisrelevant.

#10 SSL-Lösungen ohne große „Network-Overhead“ werden bevorzugt.

Solange du bei Protokollen wie IKEv1 oder IKEv2 bleibst, hält sich der Overhead in Grenzen.

Ok, ich denke auch, dass außer "Always On" mit IKEv2 werden keine richtig passende Lösung finden.

#11 OpenSource-Lösungen mit großem Community-Support werden bevorzugt.

Open Source heißt nicht automatisch kostenlos. Wenn du/ihr euch nicht ausschließlich von Infrastruktur/VPN

Wir haben schon eine Linux-Abteilung, sie werden also in der Lage sein sich um einen Linux VM und IPSEC zu kümmern. Wir haben auch nichts dagegen ein kommerzielles VPN Appliance zu kaufen, wenn es mit dem geplanten Max-Last (1Gbits) klarkommt und mit Always-On kompatibel ist.

Ich neige aktuell dazu dem Team folgendes Setup zu empfehlen: Wireguard oder ggf. OpenVPN auf einer 4-Core CentOS-VM mit 16GB RAM.

Ich muss noch klären, ob es in der VMWare-Umgebung Lastverteilung oder Failover umgesetzt werden können.

Warum würdest du explizit "Device Tunnel" empfehlen? In diesem Fall müsste der Server zwangsläufig ein Windows Server sein, was nichts schlimmes ist, wir müssen aber klar sehen. Was spricht hier gegen User Tunnels (Tunnel wird erst nach Anmeldung aufgebaut).

===

Für uns ist es generall ganz wichtig, ob "Device Tunnel" wirklich nur mit einem Windows Server geht. Wenn RRAS erforderlich ist, gibt es anscheinend Probleme mit dem Protokollierung der Verbindungen. (der Kollege, der damals Always ON kurz evaluiert hatte, hatte damals damit scheinbar unlösbare Probleme).

Gr. I.

Also mit OPENVPN schaffst man auch 5000 Client

Aber mit einer Performance die dann nichtmal Grasnarben Niveau mehr ist. OVPN ist nicht Multi Threading fähig und aus Skalierungs Sicht ein absolutes NoGo. Kollege @LordGurke hat es oben schon gesagt. Macht kein verantwortungsvoller Netzwerker.

eine Linux-Abteilung, sie werden also in der Lage sein sich um einen Linux VM und IPSEC zu kümmern.

StrongSwan ist dann, wie immer, dein bester Freund !!

Zitat von @aqui:
StrongSwan ist dann, wie immer, dein bester Freund !!

Ja, das war auch meine Überlegung. Wir brauchen aber "Device Tunnel", was aber nur in Verbindung mit einem Windows Server unterstützt wird. Meine letzte Info ist, dass Linux Gateways / oder Firewalls erst dann möglich sind, wenn ein "User Tunnel" (nach User-Auth) aufgebaut wird.

Wer oder was sollen denn diese ominösen "Device Tunnel" sein ?? Etwas Proprietäres ? Definiert MS das irgendwo, weil rein netzwerktechnisch gesehen sowas nicht existiert. MS muss sich ja da auch an weltweite Protokoll Standards halten.

Zitat von @aqui:

Wer oder was sollen denn diese ominösen "Device Tunnel" sein ?? Etwas Proprietäres ? Definiert MS das irgendwo, weil rein netzwerktechnisch gesehen sowas nicht existiert. MS muss sich ja da auch an weltweite Protokoll Standards halten.

Hi, bei Device Tunnel wird die Verbindung VOR der Useranmeldung aufgebaut. Wir brauchen es, u. A. um Passwortänderungen oder Erstanmeldungen via Always On VPN zu ermöglichen.

Hier sind die Unterschiede zw. User und Device Tunnel kurz zusammengefasst:
https://www.smartit.ch/blog/always-on-vpn

Gr. I.

bei Device Tunnel wird die Verbindung auch VOR Useranmeldung aufgebaut.

OK, aber das ist einem VPN Server auf unixoider Basis ja dann ziemlich Wumpe wann der Winblows Client sein VPN Tunnel aufbaut. Solange er sich denn dem Client Standard Konform verhält und IPsec IKE2 verwendet.
Der VPN Server reicht ja den Client Datentraffic einfach nur durch auf den Zielserver.
Wann ein VPN Endgerät im Laufe seines eigenen Bootprozesses oder Anmeldung seinen VPN Tunnel eröffnet ist doch völlig unabhängig vom VPN Server selber.

Ist der Thread hier dann mit deinem neuen Thread jetzt abgeschlossen ?
Wenn ja, dann bitte nicht vergessen den als erledigt zu markieren !
How can I mark a post as solved?

@Spirit-of-Eli

Unten drunter läuft eh ipsec soweit ich weiß und könnte auch durch irgend eine firewall abgefackelt werden.

Das hängt schon alle von Mode ab. User Tunnels können als IKE(v2) oder eben SSLVPN konfiguriert werden. Device Tunnels hingegen unterstützen aktuell ausschließlich IK"(2).

@istike2

Mein Kollege meinte, dass bei DA die angelegten Logs kaum Info über die Probleme geliefert hatten.

Wenn also ein Client keine Verbindung aufbauen konnte, hatte man keine Ahnung, warum.
Okay. Also bei Always-ON VPN sieht man in der Ereignsanzeigen entsprechende Einträge. Über die Konfiguration kann man das Logging noch anpassen. Man muss nur wissen, wo in den Kategorieren man schauen muss. Das ist anfang etwas mühsam.

Ich würde einfach StrongSwan auf der am Anfang beschriebenen CentOS VM einrichten.
Wir haben eh unsere VM-Infrastruktur, wo wir Leistung je nach Bedarf skalieren können.

Du wirst hoffentlich den VPN-Server in die DMZ stellen und nicht direkt ins LAN?!

EDIT: soweit ich sehe, werden 3rd Party Server (non Windows Server) nur bei sog. "User Tunnel" unterstützt:

An welcher Stelle in deinem Link liest du das?

Die Kollegen meinten, die Lösung soll in der Lage sein bei Bedarf auch mit 1Gbits VPN-Traffic klarzukommen.

Ist am Ende immer ein Sizing der Hardware der VM als auch die physkalische Hardware. Bestes Beispiel ist bei Virtualisierung immer die physkalischen Netzwerkkarten und damit verbunden vmnet3 oder Intel Pro. Da können unsere Netzwerker Bücher mit Storys füllen...

Für die Verbindungen innerhalb des Tunnels.

Always-ON VPN kann kein QoS.

Ich muss noch klären, ob es in der VMWare-Umgebung Lastverteilung oder Failover umgesetzt werden können.

Mir geht es um Lastausgleich/Failover auf Layer 7, sprich Applikationsebene. VMware agiert erstmal auf Layer 4.

Erst einmal deine Anforderung (#2). Zudem wird so sichergestellt, dass sofort (sobald eine Internetverbindung besteht, die auch IKE(v2) durchlässt), aller Datenverkehr durch den Tunnel geschickt wird und nicht im Heimnetzwerk oder öffentlicher HotSpot landet. Je nach Anforderung bezüglich Datenschutz, Datensicherheit und Anforderungen.

Für uns ist es generall ganz wichtig, ob "Device Tunnel" wirklich nur mit einem Windows Server geht. Wenn RRAS erforderlich ist, gibt es anscheinend Probleme mit dem Protokollierung der Verbindungen. (der Kollege, der damals Always ON kurz evaluiert hatte, hatte damals damit scheinbar unlösbare Probleme).

Es hängt davon ab, wie man Device Tunnel definiert. Ich meine Cisco und/oder Watchguard bietet in der Richtung noch was an. Aber ich bin schon zu lange aus dem operativen Geschäft raus umd hier verlässlich was dazu sagen zu können.

Was dein Kollege (nicht) getestet hat, ist so nichts zu beurteilen. Ich kann dir sagen wir haben eine größe Anzahl von VPN-Einwahlkonten produktiv im Einsatz. Grundsätzlich wird Always-ON VPN via Device Tunnels genutzt. Und bei uns sind es ein paar Leute mehr als bei euch.

Es gibt natürlich einige Sonderfälle, bei denen zusätzlich User Tunnels auf Basis von SSL-VPN zum Einsatz kommen. Das Ganze läuft seit einem Jahr ohne größe Zwischenfälle. Klar am Anfang war das Sizing, Bandbereiten Management, DNS Routing, Lastverteilung immer wieder eine Herausforderung. Aber mit den Tagen und Wochen hat sich ein stabiler Betrieb etabliert.

Gruß,
Dani

Vielen Dank Dani für deine detaillierte Rückmeldung

Zitat von @aqui:

Also mit OPENVPN schaffst man auch 5000 Client

eine Linux-Abteilung, sie werden also in der Lage sein sich um einen Linux VM und IPSEC zu kümmern.

StrongSwan ist dann, wie immer, dein bester Freund !!

Naja du kannst bei OPENVPN auch mehrere daemon parallel betreiben, sagen wir pro Server 20 openvpn-daemon , pro daemon 25 client macht summa sumarum = 25*20 = 500 Client pro Server und sagen wir haben 8 nodes entspricht dast 4000 Clients

. Ja OPENVPN kein Multi-Threading, aber so umgeht man das und soweit ich das aus den Foren wie reddit und anderen, verteilt der OPENVPNAccess Server (mittels iptables loadbalancing) die Clienten in den verschiedenene Notes und Istanzen

German solved Question Networks

Hotly discussed

End of availability for classic Teams clientDani - 2 Comments

Ubuntu 24.04 LTS Noble Numbat availableFrank

Developer diary: Release 6.1admtech