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.
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.
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.
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.
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.
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.
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.
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.
Ä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>
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.
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.
