Forum: PC Hard- und Software Verschiedene VPN Verbindungen Bereitstellen VPN-"Server"/Router


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von GerdS (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von pittiplatsch (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> dass man z.B. für jeden VPN-Client eine virtuelle Maschine in der Firma hat

Z.B: VMware Horizon

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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".

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hmmm (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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...

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
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
von Markus M. (adrock)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von GerdS (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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?

von GerdS (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von pittiplatsch (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Markus M. (adrock)


Bewertung
0 lesenswert
nicht lesenswert
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.

von GerdS (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke für Eure Hilfe.

Ich werde das mit dem VM VPN-Router wohl so an den Nagel hängen.

von Jan H. (j_hansen)


Bewertung
0 lesenswert
nicht lesenswert
Ä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>

von Profilösung (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stell den Kunden einen VPN-Router hin.

von Markus M. (adrock)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Profilösung (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Profilösung (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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...

von Markus M. (adrock)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.