Hallo Zusammen, wir benötigen öfter VPN Verbindungen zu unseren Kunden, um auf unsere dort eingesetzte IPV4 Hardware zugreifen zu können. Problematisch ist bei uns die Anzahl der verschiedenen VPN-Clients und eingesetzten Endgeräte. Wir müssten auf jedem unserer Endgeräte alle möglichen eingesetzten VPN Clients installieren und testen. Irgendwann vertragen sich aber z.B. 10 VPN Clients, welche sich gleichzeitig auf einem Win10 System befinden, nicht mehr. U.a. eingesetzte Clients Citrix Access, OpenVPN, Barracuda VPN Connector, Cisco AnyConnect, Global Protect, etc... Kurze Frage: Gibt es eine Möglichkeit, dass man z.B. für jeden VPN-Client eine virtuelle Maschine in der Firma hat, welche die Verbindung herstellt, und dann diese im Firmennetzwerk bereitstellt? Oder gibt es evtl. die Möglichkeit das am lokalen PC über VirtualBox zu machen? Besten Dank für Eure Ideen schon mal im Voraus.
> dass man z.B. für jeden VPN-Client eine virtuelle Maschine in der Firma hat
Z.B: VMware Horizon
Oder, wenn man bisher keine Virtualisierung einsetzt, ein ganz gewöhnlicher standalone VMware ESXi Server. Dafür tuts so ziemlich der kleinste Server, den man kriegen kann. Das ESXi kostet in dieser Form nichts. Zu beachten: Virtualisiertes Windows kostet (meist) genauso Geld, wie welches auf Blech.
:
Bearbeitet durch User
GerdS schrieb: > Irgendwann vertragen sich aber z.B. 10 VPN Clients, welche sich > gleichzeitig auf einem Win10 System befinden, nicht mehr. Viele davon dürften unter der Haube normales IPSEC sprechen, so dass sich die Anzahl immerhin reduzieren lassen sollte. GerdS schrieb: > Oder gibt es evtl. die Möglichkeit das am lokalen PC über VirtualBox zu > machen? Ja, z.B. eine VM mit einer Grundinstallation ohne VPN-Client aufsetzen und davon Linked Clones erstellen, die jeweils einen anderen VPN-Client bekommen. Ob Du das lokal auf dem PC oder zentral auf einem Server machst, ist technisch relativ egal, das hängt eher von euren Anforderungen (Anzahl der Mitarbeiter, die das benötigen, Nutzung von unterwegs etc.) ab.
Hmmm schrieb: > Viele davon dürften unter der Haube normales IPSEC sprechen Hier gehts bisher offensichlich um nicht-statische individuelle VPN-Clients mit persönlicher Authentifizierung. Um generisches IPsec sinnvoll einzusetzen, müsste man auf statisch definierte Netzkopplung per VPN raus. Das ist dann eine völlig andere Baustelle, an der beide Seiten mitwirken müssen.
:
Bearbeitet durch User
A. K. schrieb: > Hier gehts bisher offensichlich um nicht-statische individuelle > VPN-Clients mit persönlicher Authentifizierung. Um generisches IPsec > sinnvoll einzusetzen, müsste man auf statisch definierte Netzkopplung > per VPN raus. Nicht zwingend, IPSec mit XAuth kann man mit einem generischen Client nutzen, auch die dynamische SA-Aushandlung ist kein Thema. Sehr flexibel ist z.B. "TheGreenBow VPN Client".
Hmmm schrieb: > Nicht zwingend, IPSec mit XAuth kann man mit einem generischen Client > nutzen, auch die dynamische SA-Aushandlung ist kein Thema. Mit 2FA? Ausserdem ist derjenige, der das einrichtet, der Arsch vom Dienst, wenns mal nicht funktioniert. Da hältst du dich lieber an die Regeln. Wenn der Admin der Palo Alto mal eben von IPsec auf SSL umstellt, weils mit SSL besser funktioniert, ist das den Global Protect Clients egal. Wer dafür allerdings einen nonstd-Client nutzte, der guckt dumm aus der Wäsche.
:
Bearbeitet durch User
A. K. schrieb: > Mit 2FA? Meines Wissens nicht, hatte aber schon länger nichts mehr mit exotischeren VPNs zu tun. A. K. schrieb: > Ausserdem ist derjenige, der das einrichtet, der Arsch vom Dienst, wenns > mal nicht funktioniert. Da hältst du dich lieber an die Regeln. Klar, trivial ist das nicht. Aber möglicherweise besser zu warten als ein Haufen VMs mit VPN-Clients, die sich untereinander nicht vertragen. Ich würde dem Host-System einen generischen Client spendieren und alles, was damit nicht läuft, in eine VM packen.
Hmmm schrieb: > Klar, trivial ist das nicht. Aber möglicherweise besser zu warten als > ein Haufen VMs mit VPN-Clients, die sich untereinander nicht vertragen Sinnvollerweise wird jede VM exakt einen VPN-Client beherbergen. Wo sollte es da Unverträglichkeiten geben? Im Gegenteil: Bei einer zentralen Lösung für alle VPNs kann sich jeder Update davon auf alle VPNs auswirken. Getrennte VMs kann man getrennt pflegen, und auch mal daneben eine neue Version aufziehen ohne die alte zu behindern.
Hmmm schrieb: > Meines Wissens nicht, hatte aber schon länger nichts mehr mit > exotischeren VPNs zu tun. 2FA ist heute nicht mehr exotisch, sondern obligatorisch.
A. K. schrieb: > Hmmm schrieb: >> Klar, trivial ist das nicht. Aber möglicherweise besser zu warten als >> ein Haufen VMs mit VPN-Clients, die sich untereinander nicht vertragen > > Sinnvollerweise wird jede VM exakt einen VPN-Client beherbergen. Wo > sollte es da Unverträglichkeiten geben? Es geht in diesem gesamten Thread darum, VPN-Clients auf VMs zu verteilen, weil sie sich auf einem gemeinsamen (!) System nicht vertragen. In diesem Kontext sollte mein zitierter Satz eigentlich eindeutig genug gewesen sein, um nicht davon ausgehen zu müssen, dass bei mir eine spontane Demenz eingesetzt hat. A. K. schrieb: > 2FA ist heute nicht mehr exotisch, sondern obligatorisch. Nö. Und exotisch war natürlich in Bezug auf generisches IPSEC zu verstehen, wo ich eben nicht weiss, ob die Clients inzwischen mit 2FA-Erweiterungen klarkommen. Aber ich bin raus. Es wurde alles Relevante gesagt, jetzt setzen die forentypischen inhaltsarmen Diskussionen ein.
GerdS schrieb: > Gibt es eine Möglichkeit, dass man z.B. für jeden VPN-Client eine > virtuelle Maschine in der Firma hat, welche die Verbindung herstellt, > und dann diese im Firmennetzwerk bereitstellt? Leider in vielen Fällen nicht. Auch wenn in den meisten Fällen letztlich IPSEC oder SSLVPN(AKA: OpenVPN) die Basis der verwendeten VPN-Lösung ist, werden von kommerziellen VPN-Lösungen oft noch weitere "Sicherungsschichten" (lach...) hinzugefügt. Die machen die Sache natürlich nicht wirklich sicherer, verhindern aber in aller Regel, dass du einfach tuen kannst, was dir vorschwebt... Aus der Sicht des Betreibers des jeweiligen VPN ist das ein (zumindest scheinbarer) Gewinn an Sicherheit, aber der hat keine Ahnung, sonst würde er diesen Scheiß nicht einsetzen. Und die Anbieter der Lösung werden den Teufel tun, bloß nicht über die wahren Sachverhalte aufklären. Die wollen ihren Scheiß verkaufen und brauchen Argumente dafür...
VPN-Clients mögen auf Standardprotokollen wie IPsec oder SSL basieren. Bei solchen Clients steht im Vordergrund, auf Client-Seite möglichst leicht von jedem nutzbar zu sein, der einen PC einschalten kann. Das steht ziemlich diametral in Widerspruch zu nacktem IPsec. Wenn Anbieter solcher VPN-Lösungen, z.B. Firewall-Anbieter wie Checkpoint, Palo Alto, Fortinet, Cisco, ... proprietäre Clients anbieten, dann auch damit der Anwender damit zurecht kommt. So ein Anwender hat sehr oft keinerlei Bezug zu IT. Weitere Sicherheitsfeatures können in unterschiedlichem Umfang hinzu kommen. So arbeiten manche VPN-Clients mindestens in aktivem Zustand als Firewall auf dem Client-PC. Beispielsweise um zu verhindern, dass dieser Client quasi als Router für Dritte ins Firmennetz genutzt wird. Lachhaft ist das nicht. Eine völlig andere Baustelle ist IPsec als Site-2-Site Verbindung. Da sitzen dem Ansatz nach auf beiden Seiten ITler. Oder es wird so abstrahiert wie bei den Fritzboxen, mit stark eingeschränkter oder umständlicher Möglichkeit, spezifisch zu konfigurieren.
:
Bearbeitet durch User
A. K. schrieb: > Weitere Sicherheitsfeatures können in unterschiedlichem Umfang hinzu > kommen. So arbeiten manche VPN-Clients mindestens in aktivem Zustand als > Firewall auf dem Client-PC. Beispielsweise um zu verhindern, dass dieser > Client quasi als Router für Dritte ins Firmennetz genutzt wird. Lachhaft > ist das nicht. Ganz genau, hinzu kommen noch spezifische Tests ob z.B. auf dem PC ein aktueller Virenschutz ist etc.... "Endpoint Security" ist das Buzzword. > Eine völlig andere Baustelle ist IPsec als Site-2-Site Verbindung. Da > sitzen dem Ansatz nach auf beiden Seiten ITler. Oder es wird so Selbst das ist oft immer noch mit viel Aufwand verbunden, weil oft die andere Seite die Parameter nur halbherzig implementiert ("Ach! Sie wollten PFS?! IKEv2? Nein, ich habe V1 konfiguriert. DHGroup14? Nein, das steht auf DHGroup5. Welches VPN-Datenblatt?!?!"). Das Problem mit den VPN-Clients haben wir bei uns in $Firma auch. Die meisten Kollegen haben lokale VMs, aber das geht natürlich nur bis zu einer gewissen Anzahl an Permutationen Kunde/VPN-Client gut. Bliebe tatsächlich nur eine zentrale Lösung, wobei es eine sein muss, die dem Client auf dem normalen Arbeits-PC eine Console zur Verfügung stellt, denn viele VPN-Clients blocken je nach Konfiguration lokale Netzwerkverbindungen, somit fällt dann RDP oder SSH vom PC zur VM weg.
Markus M. schrieb: > denn viele VPN-Clients blocken je nach Konfiguration lokale > Netzwerkverbindungen, somit fällt dann RDP oder SSH vom PC zur VM weg. Weshalb ich oben ESXi erwähnte. Dessen Remote-Console verbindet über den Host, nicht die VM, benötigt also kein Netzwerk der VM.
:
Bearbeitet durch User
Vielen Dank an alle!
Also untern Strich, verstehe ich das so.
Kann gehen, es gibt aber keine Garantie, dass es mit jedem VPN-Client
geht, da div. Clients lokale Netzwerkverbindungen blockieren/maskieren
etc...
Das bedeutet für mich, ich würde es gerne probieren, um zumindest ein
paar Verbindungen nutzen zu können.
Nur habe ich keine Ahnung, wie ich die Verbindung aus der VM auf dem
lokalen PC bereit stellen kann.
Es gab mal was wie eine Netzwerkbrücke...
Oder eine virtuelle Netzwerkkarte?
Per RDP auf eine VM ist für uns zu umständlich, da wir mit Siemens TIA
arbeiten. Wür müssen dann auf ca. 10 virtuellen Maschinen V13, V14, V15,
V15.1 und V16 installieren.
Das benötigt enorm viel Zeit >8h und auch auch einiges an Speicher
>100GB. Pro VM.
GerdS schrieb: > Nur habe ich keine Ahnung, wie ich die Verbindung aus der VM auf dem > lokalen PC bereit stellen kann. Kannst du das Szenario etwas besser beschreiben?
Ich möchte die VPN Verbindung aus einer virtuellen Maschine extern nutzen wollen. Beispiel: 1. Kunde 1 verwendet die VPN Lösung "GlobalProtect - Palo Alto Networks". 2. Ich starte z.B. meine Windows 7 - VM "#5-GlobalProtect-Router" mit VirtualBox. 3. Dort starte ich die VPN Einwahl zum Kunden. 4. Sobald die Verbindung zustande gekommen ist, möchte ich im Win10 Host-System über die in der VM hergestellte Verbindung auf unsere IP-Cliens zugreifen können. 1. Kunde 5 verwendet die VPN Lösung "Barracuda SSL VPN". 2. Ich starte z.B. meine Windows 7 - VM "#3-Barracuda-Router" mit VirtualBox. Und hier mache ich wie oben bei Punkt 3 dann weiter. Sollte mit irgenein VPN-Client das externe Nutzen der IP Verbindung unterbinden, dann ist es halt so. Aber ich würde gerne versuchen, so viel wie möglich VPN Clients mit dieser Lösung zu verwenden.
> Ich möchte die VPN Verbindung aus einer virtuellen Maschine extern > nutzen wollen. Das ist genau das, was die VPN-Clients unterbinden, wenn sie connected sind. Finde dich damit ab.
GerdS schrieb: > 2. Ich starte z.B. meine Windows 7 - VM "#5-GlobalProtect-Router" mit > VirtualBox. Global Protect ist kein Router. Solche VPN-Clients sollen nur von dem Gerät aus genutzt werden, auf dem der Client läuft. Es soll damit nicht das komplette Netz von euch mit dem kompletten Netz des Kunden verbunden werden.
:
Bearbeitet durch User
Das wird so nicht funktionieren. Entweder ihr installiert die notwendige (Client-)Software in jeder kundenspezifischen VM mit, dann kann sie wirklich gekapselt funktionieren, oder ihr setzt eine wirklich zentrale Lösung auf und macht site-to-site VPNs mit euren Kunden. Oder eure Kunden müssen die Software / Workstation bei sich vorhalten und ihr benutzt dann eine der zahlreichen Fernsteuerungslösungen für den Zugriff.
Danke für Eure Hilfe. Ich werde das mit dem VM VPN-Router wohl so an den Nagel hängen.
Ähnliches Szenario hier - habe ich noch nicht zum Laufen gebracht. Eventuell geht das mit NAT32.com, habe ich aber noch nicht probiert. Was bei mir allerdings funktioniert ist eine Portweiterleitung einzurichten. Das ist bei mehreren anzusprechenden Server umständlich und durch das Port- und IP-Mapping kann es auch je nach Anwendung das eine oder andere Problem geben. Aber für ein paar Verbindungen durchaus brauchbar und praktisch. Unter Windows am "VPN-Server": netsh interface portproxy add v4tov4 listenaddress=<LAN-IP> listenport=<PORT NACH LUST> connectaddress=<REMOTE-IP> connectport=<REMOTE-PORT>
Stell den Kunden einen VPN-Router hin.
Profilösung schrieb: > Stell den Kunden einen VPN-Router hin. Das gibt Diskussionen bei den Kunden und ist auch nur dann machbar, wenn das zu managende Gerät einen dedizierten Netzwerkanschluss für's Management hat oder sonstige Infrastruktur für die Trennung auf L2/L3 bereits beim Kunden vorhanden ist. Die Kunden werden sicher keinen fremdem VPN-Router mit ihrem internen LAN Verbinden.
Markus M. schrieb: > Die Kunden werden sicher keinen fremdem VPN-Router mit ihrem internen > LAN Verbinden. Aber obskure VPN Software auf einer Windowskiste frisst der Kunde? Merkwürdiges Risikomanagement und Sicherheitsmanagement was deine Kunden da haben. Markus M. schrieb: > Das gibt Diskussionen bei den Kunden und ist auch nur dann machbar, wenn > das zu managende Gerät einen dedizierten Netzwerkanschluss für's > Management hat oder sonstige Infrastruktur für die Trennung auf L2/L3 > bereits beim Kunden vorhanden ist. Und warum benötigt die Windowskiste beim Kunden diese Merkmale nicht?
Profilösung schrieb: > Aber obskure VPN Software auf einer Windowskiste frisst der Kunde? Ich hatte das umgekehrt verstanden. Die Kunden haben VPN-Server, Firewalls wie PaloAlto, oder bieten Citrix-Zugang, und er hat bei sich das Problem mit einem Zoo aus den diversen verschiedenen Clients für diese Zugänge. In solchen Szenarien definiert oft der Kunde die Art des Zugangs, und er, der Supporter, muss sehen, wie er die Vielfalt handhabt.
:
Bearbeitet durch User
A. K. schrieb: > In solchen Szenarien definiert oft der Kunde die Art des Zugangs, und > er, der Supporter, muss sehen, wie er die Vielfalt handhabt. Als ich in den Nuller Jahren so was noch gemacht habe hat eigentlich immer der Größere mit seiner Lösung gewonnen.
A. K. schrieb: > Ich hatte das umgekehrt verstanden. Ich ebenfalls. > In solchen Szenarien definiert oft der Kunde die Art des Zugangs, und > er, der Supporter, muss sehen, wie er die Vielfalt handhabt. So isses. Leider... Wäre allein ja noch über eine VM pro Kunde handhabbar, in der halt der jeweilige proprietäre Client installiert wird. Massiv verschärft wird das Problem aber durch die Lizenzpolitik der Softwarelieferanten. Angefangen von Wixdos von Winzigweich, über den TIA-Dreck von Siemens bis... Jeder dieser gierigen Ärsche will für jede VM Extra-Lizenzkohle sehen. Weiter verschärft wird es durch die immer mehr um sich greifende Politik der Zwangsupdates. Früher(tm) hat man sich halt die VM einmal eingerichtet (und "nur" über die anfallenden Lizenzkosten gekotzt), heute will sich der Scheiß in der VM zwangsweise updaten und ist danach oft nicht mehr fähig, korrekt mit der "alten" Installation beim Kunden zu kommunizieren, weil irgendwelche Wichser bei Wizigweich oder Siemens mal wieder irgendeins ihrer Altwerke schlicht aus dem Fokus verloren haben oder einfach gesagt haben: das supporten wir jetzt einfach mal nicht mehr. Insgesamt wird dieser ganze Scheiß über kurz oder lang die gesamte Industrie in den Abgrund führen. Ich warte eigentlich nur darauf...
Profilösung schrieb: > Markus M. schrieb: >> Die Kunden werden sicher keinen fremdem VPN-Router mit ihrem internen >> LAN Verbinden. > > Aber obskure VPN Software auf einer Windowskiste frisst der Kunde? > Merkwürdiges Risikomanagement und Sicherheitsmanagement was deine Kunden > da haben. Nein, weil das eine IHRE Lösung ist, die SIE managen. Die VPN-Clients können ja bis ins kleinste Detail über die Firewall / Mgmt-Software gesteuert werden. Da ist es dann egal was auf der Windowskiste abgeht, wenn man die Firewall entsprechend abdichtet. Wenn Du einen VPN-Router in das Kundennetz stellst, haben sie keine Möglichkeit das zu kontrollieren was da durch geht. Den VPN-Router muss der Kunde dann in eine extra DMZ stellen. Und da kommen sie dann gerne mit dem Aufwandsargument oder "es geht nicht". Es geht um die KONTROLLE der Lösung.
Markus M. schrieb: > Wenn Du einen VPN-Router in das Kundennetz stellst, haben sie keine > Möglichkeit das zu kontrollieren was da durch geht. Kann man die durch eine andere Firma zu wartenden Geräte in ein eigenes per Firewall abgetrenntes Netz stellen, kann man u.U. auch mit VPN-Routern leben, die von der Wartungsfirma dort platziert werden. Je nach Umständen ist das realistisch und sowieso sinnvoll, oder nicht machbar.
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.