Moin. Danke für eure Rückmeldung. Hab das ZTE genommen. Bin auch echt zufrieden. Muss nur alle 2 Monate neugestartet werden. Ansonsten läuft das top. Merkt man deutlich, wenn die Download und Upload Raten einbrechen. Mittlerweile ist das nicht mehr mein fallback, sondern mein Haupt und die feste Leitung ist fallback 😂. Ist etwa 8 mal schneller per 5G.
Schönen Sonntag und genießt das schöne Wetter.
Mit freundlichen Grüßen
Posts by Ewu1987
-
-
Oben sagten du was von Routen auf die WAN Netzadresse was aber unsinnig führt und mit keine wort erwähnt du Routen auf die LAN Netze.
ah btw...keine Ahnung abs bei der ugv auch nicht geht.. im wiki gibs Anleitungen wie man ein modem hinter den WAN Pirat erreicht aus dem
internen netz..
du route aufs wan hab ich gelegt, damit ich in die oberfläche der zte komme. Ohne diese würde ich nicht auf die ZTE oberfläche kommen um diese zu konfigurieren. Die Ursprüngliche Frage war ja, wie ich routen auf der ZTE einrichte. Ich dachte eigentlch, dass das verständlich war mit:
Ich dachte mir, eventuell muss ich statische Routen eintragen, wie ich es mit der FB auch gemacht habe. Im UCG eine Weiterleitung auf 192.168.178.0/24 über Schnittstelle WAN und in der FB jeweils eine Route in meine VLANS. Also 192.168.0.1/24, sowie 192.168.1.0/24 usw.
Ohne die Routen in der ZTE oder halt NAT im UCG kommt halt keine Rückantwort, weil er die Adressen nicht kennt und nicht weis wo er sie finden soll. Das leuchtet mir schon ein.
-
Ohne Nat auf dem Unifi benötigst du auf deiner Kiste Statische Routen aber für die Zielnetze im eigentlich LAN und nicht für die das
netz auf dem WAN port. Also wenn dein du z.b in default netzt die 192.168.1.0/24
brauch du ein routing für 192.168.1.0/24 über die WAN2 IP (also die 192.168.179.2 in deine fall)
Pro Tip, fasse ggf alles VLAN die du hast zu einem Supernetz zusammen. Also ne Route für 192.168.0.0/16
dann hast du für alles 192er Vlan Ruhe...
Mit NAT braucht es garnicht weil die Unifi ja schon alles als 192.168.179.2 tarnt wenns rausgeht.
Ach ja dein Router (also der TZE) muss das natürlich auch können.
Soweit so klar. Wie oben schon geschrieben. Problem ist ja nur, dass ich das beim ZTE nicht rein bekomme. Daher jetzt leider nat
-
Servus Gemeinde. Leider gab es keine weiteren Vorschläge, wie ich mein Problem umgehen könnte. Ich hab jetzt NAT Aktiviert auf der UCG. Somit läuft auch die Verbindung wie sie soll.
Kann mir vielleicht jemand erklären, wie ich es hinbekomme nur NAT für den WAN 2 einzurichten? Also WAN 1 ohne NAT der UCG und WAN 2 mit? somit könnte ich meine Playstation auch wieder ohne meckern nutzen.
MfG
Uwe
-
statische routen würde ich mal zum testen löschen.
ich habe auch 2 WAN Anschlüsse und habe nix eingestellt.
Ohne statische Route hatte ich’s am Anfang. Keinerlei Änderung ob mit oder ohne. Bei der Option mit, fehlt ja aber auch die Route zurück zu meinen verschiedenen ip Bereichen. Daher ja auch die Frage, wie man statische Routen in ein zte mc888 bekommt. Um ohne Routen das Ding laufen zu lassen, müsste ich nat aktivieren, was dazu führt, dass ich das auf beiden wan Anschlüssen machen müsste. Ich wollte es aber gern ohne Doppel nat auf beiden wan Schnittstellen haben.
-
Der Hop hin scheint zu funktionieren. Ich bekomme nur keine Rückantwort. Statische Route zu 192.168.179.0/24 auf wan2 Schnittstelle ist eingerichtet, nur hab ich bei dem zte keine Möglichkeit Routen zu meinen Netzen statisch anzulegen.
Mit freundlichen Grüßen
-
Ok. Dann blende die IPs aus. Wie gesagt. Ich arbeite mit festen ips in verschiedenen Bereichen. Ich hab versucht doppeltes nat zu vermeiden und ich glaube dort liegt irgendwo der Fehler. Wo auch immer. Daher die Frage hier.
Mit freundlichen Grüßen
-
Moin. Danke erstmal für deine Antwort.
Ich hab nat einfach bei der fb. Daher vielleicht der Fehler. Mein Problem ist ja, dass er über den zte anscheinend keine richtige lan Verbindung bekommt. Anfragen gehen ja raus, aber es kommt keine Antwort zurück. Ich bin aber auch irgendwie zu dumm den Bridge Mode zu finden. Das könnte mein Problem schon lösen.
Mit freundlichen Grüßen
-
Servus Gemeinde.
Zum Black Friday hab ich endlich ein ZTE MC888 5G Router geholt.
Heute hab ich mich Siegessicher dran gemacht meinen Internetanschluss mal etwas schneller zu machen.
Erstmal ganz kurz zum allgemeinen:
Genutzt wird ein UCG Ultra
WAN 1 -> FB 7490 DSL 100mbit (192.168.178.2)
WAN 2 -> ZTE MC888 5G (so ist der Plan) (192.168.179.2)
Ich hab das Gerät ausgepackt und Grundkonfiguriert. IP Adresse ZTE Router 192.168.179.1 im Netz 192.168.179.0/24.
Im ZTE Router hab ich auf die MAC der UCG die Adresse 192.168.179.2 fest vergeben. Das funktioniert auch.
Wenn ich mit meinem Laptop mit der ZTE verbunden bin, hab ich bomben Verbindung zum Internet.
In der UCG zeigt er mir auch WAN 2 -> Deutsche Telekom AG mit 192.168.179.2 an. Also ähnlich der WAN 1 dort ist es Thüringer Netkom 192.168.178.2
In der Oberfläche der ZTE Zeigt er mir auch die MAC als Client mit 192.168.179.2 an.
Also eigentlich alles wie es soll, doch es ist keine Internet Verbindung vorhanden, wenn ich versuche einen Speedtest laufen zu lassen von der UCG aus.
Ebenso bekomme ich ständig Package Lost Meldung, solang ich WAN 2 aktiv habe und den Traffic Balance auf 50% stelle.
Ich dachte mir, eventuell muss ich statische Routen eintragen, wie ich es mit der FB auch gemacht habe. Im UCG eine Weiterleitung auf 192.168.178.0/24 über Schnittstelle WAN und in der FB jeweils eine Route in meine VLANS. Also 192.168.0.1/24, sowie 192.168.1.0/24 usw.
Also hab ich jetzt eine solche Route angelegt in der UCG zu 192.168.179.0/24 über Schnittstelle WAN 2.
In der ZTE habe ich aber keine Möglichkeit eine Route zur UCG zurück zu erstellen.
Ich hab mir jetzt schon die Finger blutig gegoogelt.
Nachtrag: Ich kann auch keine Ping auf 192.168.179.2 durchführen, wenn ich meinen Laptop and der ZTE hängen habe. Immer Zeitüberschreitung. Zu 192.168.179.1 gibt es keine Probleme.
Ich hoffe, Ihr könnt mir mit Rat zur Seite stehen.
Schönen Nikolaus.
External Content beta.ubiquiti-networks-forum.deContent embedded from external sources will not be displayed without your consent.MfG
Uwe
-
Guten Morgen liebe Helfer.
Gute Nachrichten. Die Heizung blieb Online
External Content beta.ubiquiti-networks-forum.deContent embedded from external sources will not be displayed without your consent.. Jetzt hab ich sie wieder in das IoT Netz geschoben und einen kompletten Neustart vom Netzwerk gemacht, da ich in den Logs der Firewall nichts finden konnte, die den Traffic zwischen HA und Heizung blockiert hätte und ich ja jetzt endlich die Funktion dank gierig verstanden habe und es daran nicht liegen konnte. Daher war meine Vermutung, das irgendwo im System ein Gismo sein muss, der sich festgehangen hat. Wie bei jedem IT Gerät hilft da meist schon ein Neustart.
Siehe da, alles läuft wie geplant.
Ich danke euch, für eure kompetente Hilfe und eure Nerven, wenn ich mal wieder mit nicht wissen glänze.
MfG
Uwe
-
Danke für die Erklärung. Jetzt hab ich die Funktion erstmal verstanden. Isoliert ist nur das hast Netz über die gastfunktion. Mac Filter oder der gleichen ist nicht aktiv. Vielleicht braucht der Port oder auch der Switch ja mal einen Neustart. Vielleicht hat sich da auch nur was irgendwo festgesetzt vom ewigen hin und her probieren. Wie gesagt, jetzt ist erstmal wichtig, dass die Heizung online bleibt. Dann kann ich mich ans nächste Problem setzen.
Danke dir erstmal und gute Nacht.
Mit freundlichen Grüßen
Uwe
-
Was aber nicht daran liegen kann das du keine VLAN mehr auf den Port Erlaubst.
Die haben ja vorher auch keine Verbindung gehabt
Doch. Hatten sie. Ich habe die VLANs untereinander getrennt durch die Firewall. Dazu hab ich eine Firewall Regel erstellt, dass mein Home Assistant mit mehreren IoT Netzen kommunizieren darf. Das hat auch funktioniert, jetzt nach dem blocken, geht’s nicht mehr. Warum das so ist 🤷♂️. Deshalb jetzt erstmal die Lösung mit der Heizung im Home Netz.
Ich hab die Funktion mit getagt oder nicht bisher noch nicht verstanden. Für mich entscheidend ist, dass die IoT Geräte separiert sind von meinem normalen Netzwerk. Daher unterschiedliche Bereiche. Home 192.168.2.x 255.255.255.0 und IoT 192.168.3.x 255.255.255.0. Kommunikation per Firewall getrennt. Dazu dann die Ausnahme auf 192.168.2.3:8231 für HA und die IoT Geräte, die gesteuert/gelesen werden sollen.
Mit der alles zulassen Einstellung in den Port Einstellungen funktionierte das. Bei alles blockieren nicht mehr. Wie gesagt, ich hab die Funktion noch nicht wirklich verstanden.
Erstmal schau ich jetzt, ob die Heizung online bleibt und dann widme ich mich der Netztrennung wieder. Mit den anderen Geräten läufts ja soweit sehr gut, stabil und schnell.
Mit freundlichen Grüßen
Uwe
-
Guten Morgen liebe Helfer.
Erstes kurzes Feedback.
Zu meiner Schande muss ich gestehen, dass ich es gestern nicht mehr geschafft habe, die Heizung zurück zu bringen ins IoT Netz, da mich die Kids etwas auf trapp gehalten haben. Das habe ich aber heut früh direkt gemacht.
Was mir aber direkt aufgefallen ist, ist das ich dadurch keine Verbindung zu Homeassitant hinbekommen habe. Entsprechende Firewall Regel ist drin und aktiv und hatte ja voher auch funktioniert.
Ich habe die Heizung jetzt erstmal ins Home Netz geholt. Jetzt steht die Verbindung zu HA und ich kann sehen, ob die Heizung Online bleibt oder nicht.
Optimal ist das für mich noch nicht, aber mühsam ernährt sich das Eichhörnchen im Winter. Ich werde jetzt erstmal drauf achten ob Sie da bleibt oder nicht und dann kann ich mir gedanken machen, wie ich das Problem mit dem IoT Netz löse.
MfG
Uwe
-
Nö, das gilt für den PORT alleine der kann eh nicht mit den anderen VLAN anfangen.
Das sorgt nur dafür das keine Tagged Pakete für Frende VLAN auf den Port kommen.
Das betrifft, da ja kein Client in den tagen VLAN ist auf den PORT) in erster Linie
Broadcast und Floodingrequests..
Ok. Also, wenn ich das richtig verstanden habe, setz ich das auf blockieren und dann sollte es so funktionieren wie ich mir das vorstelle. Also Heizung im IoT Netz, Verbindung zum Internet und homeassistant im Home Netz. Dann werde ich das mal ausprobieren. Danke euch erstmal. Ich gebe dann bei Zeiten Rückmeldung ob es funktioniert hat oder nicht. Wenn nicht, dauert es ja nicht lang, bis die Rückmeldung kommt 🙈
-
Bei dir steht im VLAN Management "alle zulassen" er meint "alle blockieren"
Bei Buderus hatte ich dies auch (Junkers ist ergo Bosch Gruppe wozu auch Buderus gehört), ist wohl mehr ein Problem des Herstellers.
Beim Kunden war ein PI-Hole mit drin und in einem VLAN. Wir mussten aus dem PI-Hole raus und ein eigens Subnet nur für die Heizung aufziehen, danach ging es.
Ah ok. Dann hab ich ihn falsch verstanden. Aber wenn ich „alles blockieren mache“, kann mein homeassistant aus dem anderen VLAN nicht mehr mit der Heizung kommunizieren, richtig? Oder schirmt das nur broadcast ab?
-
Firewall Settings tangieren mich da nicht in meinen Überlegungen
External Content beta.ubiquiti-networks-forum.deContent embedded from external sources will not be displayed without your consent.
Hintergrund ist das das Das Netzwerkinterface der Heizung es evt. nicht mag wennda die Broadcast auf für die anderen VLAN aufschlagen weil ja dann
Ethernet Frames mit dem Falschen Typ (0x8100 für VLAN statt 0x0800 für IP)
und das die Heizung veranlassen könnte irgendwann das Interface zu sperren
wenns zuviele "Fehler" sind..
Sorry, aber dafür bin ich jetzt zu dumm in Sachen Netzwerk. Jetzt kann ich dir grad nicht folgen. Die Anschluss Konfiguration sieht so aus, wie auf dem Screenshot.
-
Verschrieben? das VLAN muss untagged (also als Natives Netzwerk) und alle anderen Blocked. So sieht ein Port aus der zu einem Endgerät geht. Die Heizung kann sicherlich kein VLAN Tagging.
Richtig. Verschrieben.
-
ier mal aus und das nötige vlan auf den Port zu haben sprich natives vlan auf was auch immer und dann Block all das keine tagged vlans anliegen.
Währe nicht erste mal das ne netzwerkarte es nicht mag die tagged frames zu sehen.
Genau so ist es konfiguriert. Also Port direkt als vlan IoT getagt und per Firewall die vlans untereinander verboten zu sprechen, außer natürlich ausnahmeregeln für bestimmte Geräte.
Mit freundlichen Grüßen
Uwe
-
Die USW Pro Max sind allerdings jetzt auch noch nicht ewig auf dem Markt
Mahlzeit. Es passiert ja aber auch, wenn ich es direkt am Gateway auf einen Port lege. Also muss es was mit der gesamten Netzwerk Konfiguration zutun haben und ist nicht vom USW abhängig.
Die Link LEDs sind nach den 14,x Stunden noch an? Und kann man dann die IP der Heizung noch anpingen?
Blinken ja, Ping nein. Gerät ist dann nicht mehr erreichbar. In der Topologie des Netzwerks wird die Heizung aber weiterhin als „online Teilnehmer“ am Port XY angezeigt.
Das Problem hab ich jetzt, wie oben beschrieben, erstmal damit umgangen, dass ich die Heizung auf die fritzbox gelegt habe und die netzwerkverwaltung der FRITZ!Box die Heizung jetzt macht. Das ist aber absolut nicht in meinem Sinn, da die FRITZ!Box eigentlich nur noch als Modem fungieren soll mit dem UCG-Ultra als einzigen Teilnehmer.
Das VLAN ist auf dem Port getagt. Das ist richtig.
Mit freundlichen Grüßen
Uwe
-
Guten Morgen Fred.
Ja. Hab sie statisch zugewiesen im dhcp auf die Mac der Heizung. Auch zwischen durch mal das vlan geändert und damit logischerweise auch die ip, machte aber keinen unterschied.
Grüße