Probleme, Geräte über VPN im NAT Modus zu programmieren

[MbM]

Guten Abend

Habe eben eine Lustige, unerklärliche Situation.

Ich bin mit einer fernen KNX Installation über VPN verbunden. Hinter dem VPN Netzwerk ist ein Netgear Router Installiert, da die Netzwerkspezialisten nicht fähig sind, auf den Layer 3 Switch das Multicast freizugeben. Am Netgear Router sind Eisbär Hi Server 1.3.0.0 und KNX Schnittstelle von Hager angeschlossen.

Um über VPN mit der KNX Schnittstelle zu kommunizieren, habe ich in der ETS3f KNXnet/IP im NAT Modus eingestellt. Der Busmonitor läuft einwandfrei.
Beim programmieren von Geräten, ist während der Programmierung, so ca. bei 50-70% vielfach der Fehler aufgetreten " Das Gerät antwortet nicht"

Im Busmonitor ist mir aufgefallen, dass dies immer dann passiert, wenn auf dem Bus keine anderen Telegramme, von anderen Geräten versendet werden.

Also habe ich während dem programmieren des Gerätes, im Busmonitor alle 15 sek. eine Leseanforderung auf ein anderes Gerät gemacht. Dieser Antwortete mir jedes Mal und das programmieren des Gerätes hat wunderbar funktioniert. Dies habe ich nun mit 10 Geräten gemacht und siehe da, alles hat super funktioniert.

Kann sich jemand vorstellen, auf was das zurück zu führen ist.
Ich versteh die Welt nicht mehr.

Da ich nun das Problem erkannt habe, werde ich im Eisbären wohl einen Button machen "Programmiermodus" der dann alle 15 sek. ein Telegramm absendet. So kann ich Problemlos die Geräte über VPN programmieren.

PS:
Bevor die Fehlermeldung " Das Gerät antwortet nicht" auftauchte, wurden auf den Busmonitor keine Telegramme mehr angezeigt. Ein erneuter Versuch, ein Gerät zu programmieren, endete mit folgender Meldung " Das Gerät mit der Phy. Adresse X.X.XXX kann nicht gefunden werden". Auch eine Leseanforderung im Busmonitor ergabe folgende Meldung "Das Telegramm wurde am Bus nicht bestätigt" Nach genau einer Minute seit dem letzten Telegramm empfang, funktionierte alles wieder!

[tbi]

Port forwarding für VPN einrichten

Hallo Roger,

das Problem ist anscheindend, dass dein eigener Router Pakete von aussen nicht mehr zu deinem VPN/ETS rechner leitet.

IPSec (im VPN) möchte von beiden Seiten erreichbar sein.

Dazu must Du in Deinem Router zuhause Port Forwarding für die IPSec Port (zwei) einrichten.

Letzten Endes must Du schauen welche Ports dein VPN verwendet. Diese müssen in Deinem Router freigegeben werden und der Verkehr zu deinem Rechner (wo VPN und ETS läuft) weiter geleitet werden.

Das Protokoll überwacht die VPN Verbindung von beiden Seiten. Die eine Seite hast Du aber ausgesperrt. Durch die Telegramme hälst Du die Verbindung künstlich aktuell.

Gruß Tbi

[MbM]

Hallo

Besten Dank für den Ausführlichen Beschrieb, nur Funktioniert das bei mir nicht.
Ich habe eine Fritzbox und beim PC auf dem VPN und ETS läufte die Einstellung Exposed Host in der Fritzbox eingestellt und die Firewall des PC's ausgeschaltet. Da sollte doch alles frei sein.

Was noch zu sagen ist, das seit heute Multicast auf den Netzwerkswitch freigegeben ist. Bessergesagt war dies schon immer freigegeben doch das IGMP war aktiv. Als heute das IGMP deaktiviert wurde, lief Multicast auf dem Netzwerk.

Gestern konnte ich aber über das Netzwerk, wo mein Router drannhängte, Geräte laden, was heute gar nicht mehr funktioniert.

Die Telegramme kommen im Busmonitor alle an. Beginne ich aber ein Gerät zu programmieren, stellt die Kommunikation nach 1-8 Telegrammen ab.

Siehe auch Anhang

Kann das trotzdem auf meiner Seite liegen?
Oder was könnte es noch sein?

[tbi]

Hallo Roger,

Als heute das IGMP deaktiviert wurde, lief Multicast auf dem Netzwerk.

Gestern konnte ich aber über das Netzwerk, wo mein Router dran hängte, Geräte laden, was heute gar nicht mehr funktioniert.

Also IGMP ist das Protokoll was für Multicast benötigt wird. Also was Du da schreibst ????? Wundert mich.

Also wenn IGMP deaktiviert wurde, dann ist auch Multicast deaktiviert worden.
Ich vermute dort im Netzrouter ?

Dass es dann nicht mehr geht ist klar.


Versuch doch mal schrittweise vorzugehen.

Versuch es doch erst mal mit die VPN strecke mit Tunneling sauber ab Leben zu erhalten. Da geht parallel auch der Monitor !!!!!

Wenn das geht, kannst Du auf Multicast (IGMP) mit IP-Routing umstellen.

Beides zusammen/gleichzeitig inbetrieb zu nehmen ist schwer, wie du siehst.

VPN testen: Verbindung aufmachen. Und dann nichts machen. Wenn die Verbindung noch nach 30 Minuten lebt. Sind die VPN ports vermutlich richtig.

Tunneling testen: Programmieren mit ETS und gleichzeitig Monitor laufen lassen. Sollte gehen. Wieder nach 30 Minuten mal wiederholen ohne die VPN neu aufzubauen. Sollte gehen.

IP-Routing testen: ETS auf IP-Routing umstellen und sicherstellen das alle Router auf der Strecke IGMP unterstützen. Alte Fritzbox tut das nicht, nur die neueren. Ist ggf. zu prüfen.

Gruß Tbi

[MbM]

Hallo Tbi

Ich denke dass nur das IGMP Sooping disabled wurde.


Wir sprechen hier von einem D-Link DGS-3100 Serie managed Layer 2 Switch
Am Anfang war IGMP snooping eingeschaltet. Tunneling funktionierte, Routing nicht! Bei tunneling wurde die Schnittstelle nicht automatisch erkannt.
Ein Techniker von D-Link Deutschland hatte am vergangen Freitag die Multicast Problematik auf dem Switch angeschaut. Er hatte schlussendlich das IGMP snooping ausgeschaltet. KNX Tunneling und Routing funktionierte problemlos bei Tunneling wurde auch die Schnittstelle automatisch erkannt. Schaltete er IGMP snooping wieder ein, lief Routing nicht mehr.
Vom Büro aus, funktioniert VPN (Sonicwall SSL-VPN NetExtender) für Remotedesktop vom Eisbär Hi Server. Auch KNX Tunneling für ETS Busmonitor läuft Stundenlang sauber durch, nur wenn ich Geräte laden will, fällt der Busmonitor aus und die Meldung das das Gerät nicht antwortet erscheint nachher.

Ich habe sicher schon 20 Anlagen mit KNXnet Tunneling /Routing In Betrieb genommen. Es sind auch solche mit VPN Zugang darunter. Aber solche Probleme wie bei diesem Objekt, hatte ich noch nie.