ENA lieferbar

[NilsS]

Naja, über sich nach aussen verbindende VPNs oder UMTS Modems wird der Admin nicht wirklich viel glücklicher sein.

[Tru]

Welcher Typ VPN

Ich kann nur die Sicht des Admins schildern dem es lieber ist wenn keine Ports nach außen offen sein müssen.

Bin selber Admin und stimme dir grundsätzlich auch zu. Aber nach meinem technischen Verständnis ist das "Reverse-VPN" vom Kunden zum SI wie hier verschiedentlich angesprochen kaum sinnvoll umsetzbar. Ich möchte das gerne ausführen und wenn ich mich irgendwo täusche, dann lasse ich mich gerne eines Besseren belehren.

Also: nach meinem Verständnis bildet die ENA den VPN-Gateway beim Kunden für ein Remote-Access-VPN. Der VPN-Client wird auf dem Rechner des SI gestartet und erhält nach dem Aufbau des VPN-Tunnels vollen Zugriff auf das LAN des Kunden. Damit die Kommunikation mit jedem LAN-Gerät klappen kann muss der VPN-Client eigentlich mit der lokalen IP der ENA (d.h. NAT) auftreten, denn nur so gehen die Antwort-Pakete wieder zurück zur ENA, für jede andere IP ausserhalb des LAN hingegen gemäss der Default-Route Richtung Internet. Dabei gehe ich davon aus, dass die ENA selbst nicht der Default-Router sein kann.

Bei einer theoretischen Möglichkeit eines Reverse-VPN müsste die ENA beim Kunden einen Site-to-Site-Tunnel zum SI aufbauen. Nur so könnte dann der SI durch den Tunnel auf die LAN-Geräte des Kunden zugreifen. Dieses Modell hat aus meiner Sicht Einschränkungen, welche dieses Verfahren nahe an die Sinnlosigkeit bringen:

• Die ENA beim Kunden muss im Routing-Pfad liegen. Damit führt dann das Routing ins Internet immer über die ENA, welche dann sinnvollerweise ICMP-Redirects machen müsste. Dafür müssste der eigentliche Internet-Router in der ENA eingetragen sein. Der DHCP Server müsste die ENA als Defaultrouter angeben und auf allen LAN-Geräten mit fixen IPs muss die ENA eingetragen sein.
• Auf der Seite des SI ergibt das grundsätzlich die gleichen Umstände wie beim Kunden (Routing). Mal abgesehen davon, dass damit jeder Kunde vollen Zugriff auf das ganze Netz des SI bekommt, ergeben sich für den SI Konflikte mit den verschiedenen Kundennetzen, weil diese typischerweise die gleichen IP-Adressbereiche nutzen. Ich gehe ja nicht davon aus, dass der SI jedem Kunden einen anderen Adressbereich zuordnen kann, damit vielleicht 2 SIs gleichzeitig bei Kunden Wartung vornehmen können.

Aus meiner Sicht macht somit aus rein routing-technischen Gründen nur das Konzept Sinn wo die ENA beim Kunden steht und der SI mit Remote-Access-VPN darauf zugreift. Gut fände ich folgende kompensierende Massnahmen:

• Port-Forwarding aktiv nur wenn nötig. Dazu würde es auch reichen den Port-Listener auf der ENA On-Demand zu aktivieren.
• Authentifizierung des Clients mittels Client-Zertifikat. Der SI müsste somit bei der Installation der ENA beim Kunden auch sein Client-Zertifikat hinterlegen.

In der gleichen Konfiguration könnte so die ENA dem Kunden auch als Remote-Access-VPN für seine eigenen Zugriffe von unterwegs dienen.

BTW: ein VPN-Gateway via Port-Forwarding hinter einem Internet-Router ist doch genau so sicher wie ein VPN-Gateway auf dem Internet-Router selbst, oder?


Othmar

[salixer]

• Port-Forwarding aktiv nur wenn nötig. Dazu würde es auch reichen den Port-Listener auf der ENA On-Demand zu aktivieren.

Das Port-Forwarding kann der Admin ja einrichten, wie er lustig ist. Möchte er es nur bei Bedarf aktivieren, dann kann er das gerne so handhaben.
Zudem kann aber auch ein einfacher Nutzer den kompletten OpenVPN-Server durch einen Taster deaktivieren. Oder eben nur den Zugang einzelner Nutzer deaktivieren. Des weiteren kann auch über eine Status-LED eine Rückmeldung an den Nutzer gegeben werden, ob gerade jemand über das VPN eingeloggt ist.

• Authentifizierung des Clients mittels Client-Zertifikat. Der SI müsste somit bei der Installation der ENA beim Kunden auch sein Client-Zertifikat hinterlegen.

Alle Clients authentifizieren sich über ein passwortgeschütztes Clientzertifikat bei der ENA. Die Zertifikate werden direkt von der ENA heruntergeladen. Ohne Zertifikat und Passwort hat meine keinen Zugriff.

In der gleichen Konfiguration könnte so die ENA dem Kunden auch als Remote-Access-VPN für seine eigenen Zugriffe von unterwegs dienen.

Genau das ist ja möglich und gewollt. Der Kunde kann unterwegs über das VPN auf seine Visu, sein NAS oder sonst was zugreifen. Mit einem iOS Device geht das on demand, der Kunde muss also nichts weiter tun, das VPN baut sich automatisch auf. Mit Android ist on demand leider nicht möglich, hier muss man das VPN manuell starten. In beiden Fällen muss man aber nur eine Konfigurationsdatei von der ENA laden und im Gerät importieren. Fertig.

BTW: ein VPN-Gateway via Port-Forwarding hinter einem Internet-Router ist doch genau so sicher wie ein VPN-Gateway auf dem Internet-Router selbst, oder?

Das sehe ich auch so.

[salixer]

hab ich nirgends gesagt, meine Kritik betrifft closed Source SSL Implementationen.

Es wird Open Source SSL Software benutzt, und zwar OpenVPN mit OpenSSL. Der Reverse Proxy setzt auf PolarSSL. Das entsprechende SSL Labs Ranking des Reverse Proxys hast du ja hier im Thread gesehen.

Und die war ja auch nicht an dich oder sonstige Nutzer der ENA gerichtet. ABER bei einem Sicherheitssystem darf die einfache Bedieninung NIEMALS der Sicherheit übergeordnet sein.

Das sehe ich auch so, aber die Einrichtung kann trotzdem so weit wie möglich vereinfacht werden.

Die SSL Bugs wie Heartbleed und Poodle mögen ja vielleicht an dir vorbei gegangen sein - in kurz ... ohne SSL wäre da sicherer als mit.

Softwarebugs wird es immer geben, jeder kocht nur mit Wasser. Von den genannten Sicherheitslücken waren auch zig Lösungen von verschiedenen Herstellern betroffen. Man muss hier einfach immer am Ball bleiben. Völlig unerheblich ob man eine ENA, eine Fritzbox oder Gerät XYZ als VPN Server einsetzt.

Unterstützt der ENA wirklich noch SSL ? SSL ist doch tot. Eigentlich sollte man nichts unter TLS v1.2 nutzen.

Sowohl Reverse Proxy als auch OpenVPN setzen mindestens TLS voraus.

[NilsS]

<3

dann ist alles im Lot.

Es hörte sich zwischenzeitlich nämlich wie SSL Eigenbau an.

EDIT: warum habt ihr den Reverseproxy gegen polarSSL und openVPN gegen OpenSSL compiliert?

[NilsS]

übringends. Was spricht eigentlich dagegen, einen eigenen DynDNS Dienst auf Basis von rfc2136 gleich mit zu integrieren/bereitzustellen?

[salixer]

<3

dann ist alles im Lot.

Es hörte sich zwischenzeitlich nämlich wie SSL Eigenbau an.

EDIT: warum habt ihr den Reverseproxy gegen polarSSL und openVPN gegen OpenSSL compiliert?

Der Reverse Proxy unterstützt nur PolarSSL, kein OpenSSL.
OpenVPN kann mit PolarSSL nicht mit PKCS#12-Dateien umgehen.

[snooopy]

Reverse VPN

Wenn ich das so lese dann kann ich absolut verstehen keinen "Reverse VPN" zu machen wie dieser von ein paar Leuten gewünscht ist....

Ich hätte keine Lust dass eine Firma die theoretische Möglichkeit hätte auf mein Netzwerk zugreifen zu können.....

https://knx-user-forum.de/wiregate/4...tml#post464913

Kann man nur hoffen dass ENA so bleibt wie sie ist...........

[NilsS]

Ich glaube das hast du falsche verstanden, selbes was dort gilt gilt natürlich auch bei einem "normalen" VPN.

Wenn das aber über GA (oder anderes) abschaltbar ist, besteht da doch kein Problem.

[StefanW]

Ich denke auch, dass snoopy da etwas falsch verstanden hat.... Wir haben für das Wartungs-VPN ein reverse-VPN was NUR von INNEN und NUR vom Nutzer zu betätigen ist.

Wie wir (als Hersteller) da nun unkontrolliert drauf kommen sollen magst Du dann auch bitte erklären... im dortigen Thread, weil hier geht es um die ENA und nicht um das WireGate...

Stefan

[snooopy]

Ich denke auch, dass snoopy da etwas falsch verstanden hat.... Wir haben für das Wartungs-VPN ein reverse-VPN was NUR von INNEN und NUR vom Nutzer zu betätigen ist.

Wie wir (als Hersteller) da nun unkontrolliert drauf kommen sollen magst Du dann auch bitte erklären... im dortigen Thread, weil hier geht es um die ENA und nicht um das WireGate...

Stefan

ist mir schon klar dass es hier um die ENA geht.
Ich bin der Meinung dass eine Reverse Möglichkeit nicht so einfach als Funktion zu Verfügung stehen sollte.
Sind wir uns ehrlich "Stefan" hat ein Kunde seinen Wartungs VPN offen könntet ihr "theoretisch" nur mal "kucken" und mit dem "kucken" hätte ich einfach einen Schmerz.

Ich will es nur auf den Punkt bringen dass ein Reverse VPN / Nachhause Telefonieren mit einer Gewissen Gefahr verbunden ist. Mehr wollte ich nicht zum Ausdruck bringen.

[NilsS]

Ja aber das genau kann man doch eben (jetzt beim WG) nur dann, wenn du das Wartungsvpn aktivierst. Das schaltest du ja nach der Wartung sofort wieder aus.

Oder siehst du das Problem während der Wartung? Dann hast du das Problem aber genauso wenn du einen VPN-Server zur Verfügung stellst, egal auf welcher Appliance.

Du könntest ansonsten ein eigenes VLAN(LAN) Segmenet für diese Geräte machen. Dann wäre ein Zugriff in dein internes Netz nicht möglich.

[hleber]

Sehe da auch kein Problem und kenne das von anderen Systemen. Im Zweifel kann ja der "Wartende" nach Abschluss der Arbeiten den Kanal ebenfalls schliessen. In jedem Fall hilfreich dem Kunden eine einfache Option zur Verfügung zu stellen, Wartung anzufordern und auch zu verwalten.

[salixer]

Das liegt nun mal in der Natur der Sache: öffnet man für Wartung einen Kanal ins Heimnetz, dann ist eben ein Kanal ins Heimnetz offen Ohne Zugriff nun mal keine Wartung.

Der Punkt ist ja eben, dass man den Kanal geschlossen halten kann und nur bei Bedarf öffnen (Ein/Aus-GA vorhanden). Außerdem kann man mit der ENA auch sehen, dass gerade eben jemand über den Wartungszugang eingeloggt ist (Status-GA vorhanden).

[ITler]

Das ist das alte Problem mit dem Remote-Access:

Niemand möchte dass irgendjemand Zugriff auf sein Netzwerk hat.
Genauso wenig möchte man aber für jede Änderung 50 Euro Anfahrt bezahlen.

Ich denke ein gewisses Vertrauen zu seinem Dienstleister muss man schon aufbringen. Ansonsten muss man sich ein wenig mit dem Thema Netzwerk-Segmentierung befassen und seine KNX-Installation gegen das eigentliche Netzwerk abschotten.