1
KNX-Zugang über VPN, kein Unicast
Die Frage ist insofern problematisch, dass vermutlich wenige Admins Erfahrungen mit KNX-Gebäudeautomatisierung haben und andererseits die Leute im KNX-Forum nicht die große Netzwerk-Spezis sind ...
Folgend Situation:
a) Laptop öffnet VPN-Verbindung (PPTP) übers Internet, diese endet im fremden Netz in einem Dell-Rackserver (Windows 7 Enterprise 64 Bit) als "eingehende Verbindung". Diese eingehende Verbindung ist "geteilt", so dass ich darüber problemlos alle anderen Netzwerkgeräte und Dienste erreichen kann (HTML, VNC, RDP, SMB ...) Dabei erhält der Laptop eine IP-Adresse aus dem fremden Netz. Firewall auf Laptop und Server ist AUS.
Anfangspunkt VPN=Laptop, Endpunkt VPN ist Dell-Server
b) um mittels spezieller Software (ETS3f) vom Laptop auf das KNX-Bussystem (früher EIB) zugreifen zu können, bedarf es eines speziellen Interfaces IP-zu-KNX, meist als Hutschienen-Modul im Schaltschrank und mit einem Ethernetanschluss. Im konkreten Fall wird ein Busch-Jäger Komfortpanel (11-Zoll Touch-Tablet zur Wandmontage) benutzt, dass ebenfalls diese Funktion bietet. Alle Funktionen dieses Tablets sind über VPN erreichbar.
c) in dieser KNX-Software ist eine Testfunktion drin, die prüft Ping, IP-Adresse und einen sog. "Unicast-Test".
Eben jener letzte Test schlägt bei Fernzugriff fehl, womit die Software nicht nutzbar ist. Befinde ich mich mit dem Laptop vor Ort direkt im Netz, klappt es. Also wird diese Unicast-Verbindung irgendwie von meiner ja eigentlich transparenten VPN-Verbindung nicht durchgelassen.
Alle anderen Dienste (HTML, VNC, RDP, SMB usw.) funktionieren sowohl über VPN als auch lokal problemlos, nur dieser blö... Unicast-Test nicht.
Nun habe ich mich bisher nicht so detailiert mit Multi- und Unicast befasst und verstehe nicht ganz, wo ich da eigentlich zu suchen beginnen soll ... ich vermute also, dass die "eingehende Verbindung" auf dem Dell-Server das Problem mit dem Unicast-Test verursacht. Warum?
a) Laptop öffnet VPN-Verbindung (PPTP) übers Internet, diese endet im fremden Netz in einem Dell-Rackserver (Windows 7 Enterprise 64 Bit) als "eingehende Verbindung". Diese eingehende Verbindung ist "geteilt", so dass ich darüber problemlos alle anderen Netzwerkgeräte und Dienste erreichen kann (HTML, VNC, RDP, SMB ...) Dabei erhält der Laptop eine IP-Adresse aus dem fremden Netz. Firewall auf Laptop und Server ist AUS.
Anfangspunkt VPN=Laptop, Endpunkt VPN ist Dell-Server
b) um mittels spezieller Software (ETS3f) vom Laptop auf das KNX-Bussystem (früher EIB) zugreifen zu können, bedarf es eines speziellen Interfaces IP-zu-KNX, meist als Hutschienen-Modul im Schaltschrank und mit einem Ethernetanschluss. Im konkreten Fall wird ein Busch-Jäger Komfortpanel (11-Zoll Touch-Tablet zur Wandmontage) benutzt, dass ebenfalls diese Funktion bietet. Alle Funktionen dieses Tablets sind über VPN erreichbar.
c) in dieser KNX-Software ist eine Testfunktion drin, die prüft Ping, IP-Adresse und einen sog. "Unicast-Test".
Eben jener letzte Test schlägt bei Fernzugriff fehl, womit die Software nicht nutzbar ist. Befinde ich mich mit dem Laptop vor Ort direkt im Netz, klappt es. Also wird diese Unicast-Verbindung irgendwie von meiner ja eigentlich transparenten VPN-Verbindung nicht durchgelassen.
Alle anderen Dienste (HTML, VNC, RDP, SMB usw.) funktionieren sowohl über VPN als auch lokal problemlos, nur dieser blö... Unicast-Test nicht.
Nun habe ich mich bisher nicht so detailiert mit Multi- und Unicast befasst und verstehe nicht ganz, wo ich da eigentlich zu suchen beginnen soll ... ich vermute also, dass die "eingehende Verbindung" auf dem Dell-Server das Problem mit dem Unicast-Test verursacht. Warum?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 176889
Url: https://administrator.de/contentid/176889
Printed on: April 24, 2024 at 07:04 o'clock
1 Comment
Alles was nicht Multicast und Broadcast ist, ist ein Unicast.
Dazu gehören auch ping, HTTP, VNC, RDP, usw.
Interessanter wäre, auf welcher Protokollebene das Teil arbeitet.
Dazu gehören auch ping, HTTP, VNC, RDP, usw.
Interessanter wäre, auf welcher Protokollebene das Teil arbeitet.
