ENA lieferbar

[NilsS]

ooops
blöde Seitenwechsel

[tuxedo]

Wenn ein VPN-Tunnel ein Problem ist macht es keinen Unterschied ob er von außen- oder von innen initiiert wird.

?? Das mag vielleicht in großen Firmen so sein.

Wenn sich ein Admin weigert, einen Port zu deinem KNX-Device weiterzuleiten wird er dem KNX-Device auch untersagen einen VPN-Tunnel zu aufzubauen.

Die wenigsten Hausbauer haben einen Admin der den Verbindungsaufbau von innen nach außen limitiert. Und nicht jeder SI arbeitet für große Firmen mit entsprechender IT.

[seppm]

Wenn ein VPN-Tunnel ein Problem ist macht es keinen Unterschied ob er von außen- oder von innen initiiert wird.

Hi,
Du meinst das die Möglichkeiten über das VPN die gleichen bleiben ob es nun von hier oder von dort startet?
Danke Sepp

[tuxedo]

Hi,
Du meinst das die Möglichkeiten über das VPN die gleichen bleiben ob es nun von hier oder von dort startet?

In der Regel ja. Dem Tunnel ist es wurscht ob er von A nach B oder von B nach A aufgebaut wird.

Es bedeutet für den Kunden aber halt weniger bzw. gar keinen Konfigurationsaufwand wenn man ihm eine Kiste hinstellt, die auf KNX-Zuruf eine VPN Verbindung zum SI aufbaut. In diesem Fall hat der SI den Konfigurationsaufwand mit Portforwarding etc. pp.

Lediglich bei Firmen und Unternehmen die nicht _alles_ was im Netzwerk steht frei ins Internet kommunizieren lassen wird der lokale Admin dem Gerät erlauben müssen "nach draußen" zu kommunizieren. Aber auch der wird damit weniger Probleme haben als in der Firewall für die ganze Welt einen Port zu öffnen.

Kenne das im medizintechnischen Umfeld nicht anders: Viele Kliniken erlauben für Remote-Wartungszugänge keine eingehenden Verbindungen. Ausgehend ist es i.d.R. kein Problem. Erst recht nicht, wenn sie das nur bei Bedarf aktivieren.

Wenn ENA die Sache als VPN-Client beherrscht, dann wäre das für 600EUR und "funktioniert out-of-the-box" eine feine Sache. Mit dem restlichen Featureset der Box wäre der Preis dann auch wieder "okay".

[enertegus]

Wenn ein VPN-Tunnel ein Problem ist macht es keinen Unterschied ob er von außen- oder von innen initiiert wird.

Das haben wir auch intern diskutiert. Das bedeutet aber, Du musst als SI einen OpenVPN Server am Laufen haben, der Zugang muss geöffnet werden, am besten per KNX - ich denke immer online will ja nun auch keiner. Du brauchst einen festen DynDNS Dienst, der sich nie ändert oder eine feste IP. Die eigenen erstellten Zertifikate müssen in die ENA geladen usw...
Da geht's dann schon los: Das ist nichts, was so einfach mal eben gemacht ist. Klar, diejenigen, die hier in einer Stunde mit nem Fingerschnippen alles einrichten, haben damit null Probleme.
Vielleicht fällt uns an dieser Stelle noch was ein, neue Features müssen ja auch noch eingebaut werden, sonst sind die Entwickler arbeitslos und feiern nur den ganzen Tag

[tuxedo]

Das bedeutet aber, Du musst als SI einen OpenVPN Server am Laufen haben, der Zugang muss geöffnet werden, am besten per KNX - ich denke immer online will ja nun auch keiner.

Sehe hier das Problem nicht?! Als Dienstleister sollte man sich doch nicht gleich in die Hose machen wenn es drum geht 24/7 einen einzigen Port bei sich offen zu haben?!

Und streng genommen müsse der Dienst nicht 24/7 laufen. Es reicht wenn die Portfreigabe vorhanden ist und der dahinter liegende Dienst nur bei Bedarf gestartet wird. Aber ich komm gleich nochmal auf dieses Thema zurück.

Da geht's dann schon los: Das ist nichts, was so einfach mal eben gemacht ist. Klar, diejenigen, die hier in einer Stunde mit nem Fingerschnippen alles einrichten, haben damit null Probleme.

Na besser der SI schlägt sich damit genau 1x rum, als dass sich jeder Kunde separat damit herumärgern muss, und der SI bei jedem Fritzbox-Wechsel/Providerwechsel alles nochmal machen darf.

DynDNS braucht man überhaupt nicht. Es gibt für wenig Geld feste IP-Adressen die man sich in sein "Heimwerkwerk" holen kann. Portunity z.B. bietet das an. Da hier ebenfalls OpenVPN zum Zuge kommt, kann man die feste IP sogar von unterwegs aus am Laptop nutzen (und müsste den Dienst nicht 24/7 dauerhaft online haben, sondern nur auf Zuruf des Kunden).

Das einzige was der SI dann noch leisten müsste, ist die Sache mit den Zertifikaten. Aber hey: Das muss es im anderen Fall auch.

[MatthiasS]

Habe ich das falsch verstanden?

Beim Diensleister ist es egal, einen Port offen zu haben, beim Kunden ist identisches ein großes Problem?

Und der Wechsel Fritzbox/Provider/... etc ist genau das ENA usecase. Einfach wieder den Port auf die ENA leiten, fertig.

[EIB-TECH]

Der Tread läuft völlig aus dem Ruder, es geht hier nicht mehr um die ENA als solches sonder nur um zwei Fronten:

- SI's für das Gerät gebaut und entwickelt wurde
- Homeboys die Gründe dafür suchen wo es "schlecht" ist...

Mal zum Thema zurückzukommen wäre nicht verkehrt....

[tuxedo]

Habe ich das falsch verstanden?

Beim Diensleister ist es egal, einen Port offen zu haben, beim Kunden ist identisches ein großes Problem?

Nein, machbar ist das natürlich auch. Aber in 0815 Heimsetup des Kunden hat der Kunde ggf. Sicherheitsbedenken ("Ahh, hilfe, der SI kann sich bei uns einwählen...) und der SI muss ggf. dem Kunden auch noch seine Fritzbox konfigurieren... Kann man sich mit dem ReverseVPN sparen. Als Kunde wäre es mir auch lieber wenn ich mich per Knopfdruck beim SI einwählen kann und nicht umgekehrt.

Und der Wechsel Fritzbox/Provider/... etc ist genau das ENA usecase. Einfach wieder den Port auf die ENA leiten, fertig.

Klar, hast du etwa heute noch keine Fritzbox gegen einen Speedport ausgetauscht?

Nein, im ernst: Ist doch sinnvoll jede Fehlerquelle von vornherein auszuschließen, oder?

Wenn der SI keinen Port bei sich öffnen mag: Hallo? Aber es dem Kunden der noch weniger Ahnung von der Technik hat als der SI ein Einfallstor zumuten? Der SI kriegt das besser gebacken ... just my 5 cent.

[tuxedo]

- SI's für das Gerät gebaut und entwickelt wurde
- Homeboys die Gründe dafür suchen wo es "schlecht" ist...

Bin weder SI noch Homeboy. Bisher sehe ich es mehr als Konstruktive Kritik.

Finde das Teil nicht schlecht, aber man könnte es wohl ohne Hardwareänderung noch attraktiver machen....

[heckmannju]

Mal zum Thema zurückzukommen wäre nicht verkehrt....

Thema war ENA lieferbar... :-) was sollte man den sonst diskutieren ausser das man es braucht oder auch nicht.

[regu]

Habe mir mal eben die Diskussion durchgelesen und als einer von 3
Administratoren eines Mittelständischen Unternehmens mit 270 Angestellten ist
mir jede Portöffnung von außen ein Dorn im Auge.

Besser wäre es wirklich die Verbindung von innen nach außen aufzubauen
anstatt immer ein Port geöffnet zu lassen. Klar das Gerät muss ich auch für das
öffentliche Netz freigeben aber erreichbar von außen wäre es dann nicht.

Zudem wäre auch noch eine Failbackfunktion in Form eines UMTS Moduls sehr
sinnvoll, denn was ist wenn das Netzwerk ausgefallen ist etc. oder im Falle
eines Neubaus noch lange nicht in Betrieb ist?

Ansonsten wäre das schon eine schöne Möglichkeit die Fernwartung Out-of-the-box zu ermöglichen.

[ITler]

Das haben wir auch intern diskutiert. Das bedeutet aber, Du musst als SI einen OpenVPN Server am Laufen haben, der Zugang muss geöffnet werden, am besten per KNX - ich denke immer online will ja nun auch keiner. Du brauchst einen festen DynDNS Dienst, der sich nie ändert oder eine feste IP. Die eigenen erstellten Zertifikate müssen in die ENA geladen usw...
Da geht's dann schon los: Das ist nichts, was so einfach mal eben gemacht ist. Klar, diejenigen, die hier in einer Stunde mit nem Fingerschnippen alles einrichten, haben damit null Probleme.
Vielleicht fällt uns an dieser Stelle noch was ein, neue Features müssen ja auch noch eingebaut werden, sonst sind die Entwickler arbeitslos und feiern nur den ganzen Tag

Genau so macht es unser Heizung und die Lüftungsanlage. Sie baut auf Knopfdruck einen VPN-Tunnel zum Anlagenbetreiber auf.

Genauso könnte es bei der ENA auch laufen. Der Tunnel wird über eine Gruppenadresse aufgebaut und wieder abgebaut. Die Adresse lege ich auf einen Taster, so dass der Kunde kinderleicht die Fernwartung aktivieren und wieder deaktivieren kann.

Ein permanent laufender und extern erreichbarer openVPN-Server ist kein Thema, das ist in den meisten Firmen der Fall (wenn auch nicht unbedingt openVPN). Außerdem muss der Port ja nur offen sein wenn der SI auch eine Wartung erwartet. Ansonsten bleibt die Software zu und fertig. Ein offener Port in der Firewall ist nicht zwingend eine Sicherheitslücke. Die entsteht erst, wenn die Software die auf den Port hört fehlerhaft ist.

DynDNS ist ebenfalls kein Thema, auch wenn sich für einen SI eine feste IP durchaus lohnen könnte. Das ganze muss vom SI ja auch nur einmal erledigt werden, und er kann damit so viele Kunden betreuen wie er möchte. Hier bräuchte man nicht einmal zwingend ein Zertifikat. Ein Passphrase die lang genug ist würde meines Erachtens genügen um den Tunnel sicher genug zu verschlüsseln. Die Einrichtung pro ENA wäre dann mit ein paar Handgriffen erledigt. IP-Adresse des Betreuers und Passwort -> Fertig.

Ich möchte das Produkt keinesfalls schlecht machen. Ihr habt euch sicherlich etwas gedacht als ihr es so umgesetzt habt wie es jetzt ist. Nur weil ich es anders gemacht hätte heißt das noch lang nicht, dass es besser ist :-)

[enertegus]

Ein permanent laufender und extern erreichbarer openVPN-Server ist kein Thema, das ist in den meisten Firmen der Fall (wenn auch nicht unbedingt openVPN).

Für den Admin nicht, aber für den Installateur/SI - der bräuchte das ja.

Außerdem muss der Port ja nur offen sein wenn der SI auch eine Wartung erwartet. Ansonsten bleibt die Software zu und fertig. Ein offener Port in der Firewall ist nicht zwingend eine Sicherheitslücke. Die entsteht erst, wenn die Software die auf den Port hört fehlerhaft ist.

Wenn ein Admin da ist, so würde der SI auch nur dann diesen bitten, den Zugang zu öffnen. Und wenn ein offener Port für die VPN Kommunikation kein Problem darstellt, so trifft das ja auch für die Implementierung zu. Also ist hier nix gewonnen.
Es geht hier dann nur um das Argument:
Ist eine Umleitung am Eingangsmodem des Kunden auf die ENA wenig komfortabel oder ist das machbar? Ist es bequemer sich selbst einen Server einrichten zu müssen (mit allem was dazugehört)? Oder möchte man einen Server über Dritte laufen lassen?
Wir haben uns da nach Rücksprache mit den SIs erstmal für die erste Variante entschieden.

Ihr habt euch sicherlich etwas gedacht als ihr es so umgesetzt habt wie es jetzt ist.

Wie gesagt, der Verkaufsstart bedeutet nicht zwingend einen Entwicklungsstop.

[ITler]

Für den Admin nicht, aber für den Installateur/SI - der bräuchte das ja.

Ich denke wir haben aneinander vorbei geredet. Ich hielt es für einfacher, den Server beim Installateur zu betreiben. So müsste dieser einmalig den Aufwand betreiben, quasi seine Supportbasis zu erstellen und von extern erreichbar zu machen. An den einzelnen ENAs beim Kunden wäre die Konfigurationsarbeit wesentlich geringer. Und in größeren Firmen braucht man ohnehin einen Admin der die Einheit mit Internet versorgt.

Wie gesagt, ich denke ihr habt euch sicherlich was dabei gedacht. Ich kann nur die Sicht des Admins schildern dem es lieber ist wenn keine Ports nach außen offen sein müssen.