Gerät mit fester Ip Adresse in anderem Subnet erreichen.

Diese Webseite finanziert sich ausschließlich durch freiwillige Spenden. Dank der Unterstützung unserer Nutzer können wir die Inhalte werbefrei und unabhängig anbieten. Jetzt Unterstützen
  • Guten Abend zusammen,

    ich habe vor kurzem ein Smartmeter Gateway von meinem Stromnetzbetreiber installiert bekommen. Diesen würde ich nun gerne aus meinem Netzwerk erreichen können.

    Das bereits stehende Netzwerk wird von der UDM-Pro verwaltet.

    Es gibt verschiedene VLANs und Geräte im Netzwerk.

    Die entscheidenden sind folgende:

    • Laptop1 mit Windows im Netzwerk "Haupt-Netz" (VLAN-ID 20; Subnet 10.6.20.0/24)
    • Laptop2 mit Homeassistant im Netzwerk "Server-Netz" (VLAN-ID 70; Subnet 10.6.70.0/24)
    • Smartmeter von PPC (Link) im Netzwerk "SMGW-Netz" (VLAN-ID 98; Subnet 192.168.1.0/24)
      • Dieses Gerät hat eine Feste IP 192.168.1.200 die vom Netzbetreiber verwaltet wird und nicht von mir geändert werden kann.
      • Ich habe nur über die HAN Schnittstelle zugriff darauf.

    Bisher habe ich folgendes gemacht:

    • Das oben genannte Netzwerk mit dem Namen "SMGW-Netz" und der VLAN ID 98 erstellt
    • Die HAN-Schnittstelle des Smartmeter Gateway mit dem Port 1 der UDM Pro per LAN Kabel verbunden
    • Port 1 der UDM Pro mit VLAN Tag 98 getagged (Native VLAN = VLAN 98 / Tagged VLAN Management = Allow all)
    • Eine Firewall Regel erstellt, die das "Haupt-Netz" und das "SMGW-Netz" kommunizieren lassen (Direction = Source to Destination)

    Nachdem ich das gemacht habe, kann ich das Webinterface des Smartmeter Gateway vom Laptop1 aus dem "Haupt-Netz" nicht erreichen.

    Es sollte über https://192.168.1.200/cgi-bin/hanservice.cgi" erreichbar sein.

    Wenn ich Laptop1 durch "Virtual Network Override" in das "SMGW-Netz" zwinge, kann ich das Webinterface erreichen, da dieser dann auch eine IP aus dem 192.168.1.0/24 Subnetz bekommt.

    Ich habe auch versucht alle "Block" Regeln zu pausieren, ohne Erfolg.

    Ebenso habe ich mit einer statischen Route in das SMGW Netz experimentiert. Mit meinem bisherigen Verständnis, dachte ich jedoch es muss ohne Routing funktionieren. Immerhin kann ich auch vom "Haupt-Netz" in das "Server-Netz" kommunizieren. Also von Laptop1 zu Laptop2 in unterschiedlichen Subnetzen

    Was muss ich noch beachten, damit ich das Interface auch aus dem Haupt-Netz und später auch von Laptop2 auch aus dem Server-Netz erreichen kann?

    Ich bin dankbar für jeden Hinweis.

    Vielen Dank und viele Grüße,

    Fox

  • Go to Best Answer
  • Ich kenne den Zähler nicht und ggf. blocked dieser aber:

    Kannst Du von Deinem Laptop das Gateway des Netzes erreichen ( ping 192.168.1.1 )

    Dann kannst Du routing Probleme ausschließen. Und fw Probleme sind evt auch nicht die Ursache.

    Kannst Du Laptop 1 von Laptop 2 erreichen wenn ja geht das auch das dem Network overwrite? Dann kannst Du eigentlich auch few Probleme ausschließen.

    Kannst Du den Zähler nach overwrite per ping 192.168.1.200 erreichen. Wäre ein Test ob der Zähler auf Anfragen reagiert.

    Evt auch vom Unifi Gateway aus probieren.

  • Ich kann vom Laptop1 aus dem Haupt-Netzt das Gateway des SMGW-Netzes per Ping erreichen.

    Ich kann Laptop1 im Haupt-Netz von Laptop2 aus dem Server-Netz erreichen. Das ist beabsichtigt, da vom Server-Netz aus nichts ins Haupt-Netzt soll.

    Der Zähler dropped laut anderen Nutzern alle IMCP Pakete.

    Ich kann diesen Somit nicht per Ping erreichen.

    Ausserdem habe ich getestet ob ich Laptop1 mit override im server-Netz vom Laptop2 im server-Netz per Ping erreichen kann ( um die WIndows FW als Problem auszuschließen). Das klappt.

    Wenn ich den Laptop1 per override in das SMGW-Netz schiebe, dann kann ich vom Laptop2 im server-Netz den Laptop1 nicht mehr per Ping erreichen.

    Obwohl ich folgende Regel erstellt habe:

    • Action: Allow
    • Source: Haupt-Netz; Server-Netz
    • Destination: Local Network: SMGW-Netz
    • Traffic Direction: Source to Destination
    • Schedule: Always

    Ich dachte ich habe das bisher verstanden, aber hier scheint ein Problem zu liegen.

    Mein Kopf raucht. Ich probiere das morgen nochmal mit anderen Geräten und auch vom UniFi-Gateway aus.

    Danke schon Mal für die Hilfe,

    Fox

  • Kann man am Smartmeter irgendwelche Netzwerkeinstellungen vornehmen?

    IP Ändern - gar auf DHCP umstellen?

    Oder wenigstens statische Routen hinterlegen? (wäre am einfachsten, simpel für sämtliche privaten Adressbereiche statische Routen auf die Gateway-IP im genutzten VLAN)

    Falls nicht ggf. NAT um als Quell-IP für Zugriffe aus anderen Netzen die Gateway-IP des VLAN des Smart-Meter zu nehmen. (mal ins Blaue gedacht - ggf. muss da noch nachjustiert werden)

  • Kann man am Smartmeter irgendwelche Netzwerkeinstellungen vornehmen?

    Am Smartmeter kann ich leider gar nichts selbst verändern. Dieser ist verplombt und wird vom Netzbetreiber Administriert. Ich habe Mal angefragt ob DHCP aktiviert werden könnte. Andere haben mir hier aber nicht viel Hoffnung gemacht.

    Ich habe jetzt mit meinem Android Gerät versucht in das SMGW-Netz zu kommen. Leider ohne Erfolg.

    Ich kann zwar 192.168.1.1 per Ping erreichen, aber keine anderen IPs.

    Ich kann weder 192.168.1.200 (SMGW) noch 192.168.1.177 (Laptop1 mit Override) erreichen.

    Ein Traceroute zu 192.168.1.177 endet beim Gateway des Haupt-Netz 10.6.20.1 :(

    Das verwirrt mich, da ich mit den selben Einstellungen und identischen Regeln vom Android Gerät im Haupt-Netz sowohl zum Laptop1 im Haupt-Netz als auch zum Laptop2 im Server-Netz komme.


    Deutet aber vermutlich doch auf ein Firewall Problem hin?

    Muss ich eventuell doch eine statische Route erstellen? Diese sind für mich allerdings neu.

    Woher hab ihr eigentlich das ?


    Tagged VLAN Management = Block all

    Ehrlich gesagt habe ich mich damit nicht groß beschäftigt. Nach meinem Verständnis spiel es sowieso keine Rolle, da die UDM-Pro physikalisch nur für mich zugänglich ist, sollte also kein Problem darstellen. Sicherer wäre definitiv "Block all".

  • Dann solltest du dich dringend mal damit beschäftigen um zu verstehen, was VLAN's sind.

    Der Port gehört eigentlich einem USW Lite 16 PoE. Nur zum testen ist da der SMGW direkt an der UDM Pro.

    Mein Wissen kommt von dieser Ubiquiti Dokumentation:

    Damit verstehe ich, dass ein "Allow All" die kommunikation zwischen Laptop1 und SMGW wie ich das beabsichtige nicht beeinträchtigt.

    Wenn ich damit falsch liege, würde ich mich über einen konkreten Hinweis freuen wo ich falsch liege und wo ich das nachlesen kann.

    Evt fehlt Dir die Regel für die Antwortpakete.

    Ich habe jetzt noch die entsprechende Regel eingefügt.

    Und einen Raspberry Pi in das SMGW Netz gehängt. Diesen kann ich nun per Ping erreichen. Und die Trace zeigt 2 Hops über 10.6.20.1 und dann direkt 192.168.1.99 (der Raspberry Pi), wie erwartet.

    Ich vermute deshalb, dass Georgius recht hat und einfach keine Pakete aus anderen Netzen angenommen werden.

    Wenn das also stimmt, bleiben meiner Meinung nach nur noch 2 Möglichkeiten:

    • Der Netzbetreiber stellt die IP um / aktiviert DHCP
    • Ich setze einen ReverseProxy in das 192.168.1.0/24 Subnetz, der das dann regelt

    Sollte es doch noch andere Fehlerquellen geben, wäre ich dankbar über einen Hinweis.

    Für alle Hilfen sage ich herzlich dankeschön!

    Viele Grüße,

    Fox

  • Ich habe jetzt noch die entsprechende Regel eingefügt.

    Und einen Raspberry Pi in das SMGW Netz gehängt. Diesen kann ich nun per Ping erreichen. Und die Trace zeigt 2 Hops über 10.6.20.1 und dann direkt 192.168.1.99 (der Raspberry Pi), wie erwartet.

    Hallo FriendlyFoxFromSpace ,

    wenn Du nun einen Host (RasPi) mit im SMGW-VLAN hast: kannst Du vom RasPi das gewünschte Endgerät per Ping erreichen oder auch nicht? Hast Du ein UI auf dem RasPi installiert, um die UI von dem Strom-Ding zu sehen?

    Und generell:

    Wenn Du keine Firewall-Regeln erstellst, dann ist im UniFi-Umfeld alle Kommunikation zwischen den VLANs zugelassen.

    Ich würde also als erstes immer prüfen, ob eine Kommunikation OHNE Regelwerk funktioniert (oder nicht), um das Regelwerk als Fehler auszuschließen.

  • Damit verstehe ich, dass ein "Allow All" die kommunikation zwischen Laptop1 und SMGW wie ich das beabsichtige nicht beeinträchtigt.

    Wenn ich damit falsch liege, würde ich mich über einen konkreten Hinweis freuen wo ich falsch liege und wo ich das nachlesen kann.

    Mache mal einen Gegentest:

    Stelle das Gerät, welches an dem Port hängt, mal auf DHCP um und schaue, aus welchen IP-Bereich der seine IP bekommt. Ich wette fast drauf, dass dies nicht der IP-Bereich des gewünschten VLANs ist, sondern das Management-Netz

    Die Funktion VLAN "Allow all"/"Block all" hat rein gar nichts damit zu tun, welche anderen Systeme aus anderen VLANs darauf zugreifen können, sondern nur welche VLANs mit auf dem Switchport liegen - im schlimmsten Fall eben alle.

    Das macht man nur, wenn es sich um einen Trunk handelt, der zw. Switchen untereiander oder AP an Switche verbindet, damit diese alle VLAN bekommen.

  • wenn Du nun einen Host (RasPi) mit im SMGW-VLAN hast: kannst Du vom RasPi das gewünschte Endgerät per Ping erreichen oder auch nicht? Hast Du ein UI auf dem RasPi installiert, um die UI von dem Strom-Ding zu sehen?

    Und generell:

    Wenn Du keine Firewall-Regeln erstellst, dann ist im UniFi-Umfeld alle Kommunikation zwischen den VLANs zugelassen.

    Ich würde also als erstes immer prüfen, ob eine Kommunikation OHNE Regelwerk funktioniert (oder nicht), um das Regelwerk als Fehler auszuschließen.

    Ich kann vom Raspberry Pi im SMGW-VLAN den SMGW nicht pingen (Die IMCP Pakete werden laut anderen Nutzern komplett gedropped)

    Auf dem RasPi läuft kein UI. Somit kann ich nur per SSH drauf.

    Die FW Regeln habe ich nun alle probeweise Pausiert und auch dann keine Erfolgreiche Verbindung hinbekommen.

    Stelle das Gerät, welches an dem Port hängt, mal auf DHCP um und schaue, aus welchen IP-Bereich der seine IP bekommt.

    Das Gerät das am Port hängt is das SMGW. Dieses kann ich nicht verändern.

    Habe nen zweiten RasPi Mal an den Port gehängt. Der bekommt die IP 192.168.1.51.

    Das macht man nur, wenn es sich um einen Trunk handelt, der zw. Switchen untereiander oder AP an Switche verbindet, damit diese alle VLAN bekommen.

    Genau das ist ja die eigentliche funktion des Port 1. Eigentlich hängt wie oben gesagt eine USW Lite 16 PoE dran. Nur in der aktuellen Konfiguration ist ein Kabel quer durch den Keller bevor was festes hinkommt. Habe aber auch mit Block All getestet, keine Veränderung.


    Zusätzlich habe ich folgende SNAT Regel getestet:

    Hat nichts gebracht. NAT Regeln sind aber auch heir für mich das erste Mal.

  • Genau das ist ja die eigentliche funktion des Port 1. Eigentlich hängt wie oben gesagt eine USW Lite 16 PoE dran. Nur in der aktuellen Konfiguration ist ein Kabel quer durch den Keller bevor was festes hinkommt. Habe aber auch mit Block All getestet, keine Veränderung.

    Zusätzlich habe ich folgende SNAT Regel getestet:

    Hat nichts gebracht. NAT Regeln sind aber auch heir für mich das erste Mal.

    Du musst schon die Ports für das konfigurieren, was Du aktuell nutzt und nicht was da eigentlich dran hängt. Oder fährst Du bei ner roten Ampel weil vorhin eigentlich grün war? Es gibt halt Gurkige Netzwerkgeräte die einfach nicht damit klar kommen, wenn auf einem Link getaggte Pakete ankommen.

    Warum eigentlich NAT Regeln?!?

    Bin mal gespannt ob das Problem gelöst werden kann, es ist ja zumindest jede Menge gefährliches Halbwissen vorhanden :) Ich drücke die Daumen.

  • Moin, hast Du das Problem schön lösen können ? Hab gestern mein Smartmeter auch eingebunden. Hab mir auch ein eigenes Netzwerk erstellt und einem Port zugweisen wo der Smartmeter dran hängt. Ich kann aus allen anderen Netzwerken alles was an dem Port hängt erreichen, nur die Webseite des Smartmeter nicht. Kann ich im Unifi Netzwerk (CGM) eine DummyIP definieren aus dem Hauptnetz (z.B. 192.168.15.222) was sich im Smart Meter Netzwerk als 192.168.1.222 ausgibt. So wie es aussieht lässt der Smartmeter ja nur anfragen aus seinem eignen Netz zu, und Gateway ist nicht eingetragen. Wenn ich die HAN zugänge habe muss ich mal meinen Netzbetreiber anschreiben ob er den Sartmeter nicht auf DHCP umstellen kann.

  • Guten Morgen,

    das Problem besteht leider weiterhin. Den Netzbetreiber (Bayernwerk) habe ich angeschrieben. Die antwort war nach vielen Wochen, dass es keine Kundenindividuellen konfigurationen geben wird.
    Die vorgeschlagenen Lösungen haben in meinem Fall kein Ergebnis gebracht :(

  • Nachdem ich jetzt mit unterschiedlichen Menschen und unterschiedlichen KI die verschiedensten Ansätze getestet habe bleiben trotzdem viele Fragezeichen. Aufgrund fehlender Zeit ist das auch immer Mal wieder liegen geblieben und letzte Woche habe ich mich dann für einen anderen Ansatz entschieden. Im Github Repository der HA Integration des SMGW bin ich zwischenzeitlich mehrmals auf den Vorschlag mit einem reverse Proxy gestoßen.
    How to implement the reverse proxy?

    Daraus ist dann die Idee entstanden, den SMGW gar nicht ins Netwerk zu lassen und lediglich einen Raspberry Pi direkt per Ethernet am HAN Port des SMGW anzuschließen. Der Raspberry Pi ist dann mit eth0 im 192.168.1.x Netz und mit wlan0 im gewünschten heimnetz. Dann ein Nginx Proxy und alles läuft wunderbar.

    Folgendes habe ich gemacht:

    • Raspberry Pi eth0 mit SMGW PPC HAN Schnittstelle per Kabel verbunden
    • eth0 feste Ip im 192.168.1.0/24 Bereich vergeben
    • wlan0 mit gewünschtem Netzwerk verbinden
    • Nginx auf dem Pi installiert
    • Proxy stream erstellt mit SMGW als upstream und Raspberry Pi als server
    • IP Forwarding auf dem Raspberry Pi aus machen
    • SSH auf dem Raspberry pi nur auf wlan0 und nicht auf eth0

    => SMGW Weboberfläche ist dann unter der IP des Raspberry Pi erreichbar (z.B.: https://10.1.1.120/cgi-bin/hanservice.cgi )


    Vielleicht hilft es ja noch jemandem.
    Ich habe jedenfalls viel gelernt.

    Viele Grüße und danke für die Unterstützung.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!