Ich habe auch einen BYD Speicher. Um darauf zu kommen habe ich folgende statische Route angelegt:
Die IP 192.168.16.254 ist eine interne IP im BYD Speicher. Um diese zu erreichen musst du als nächsten Hop die IP angeben, die der BYD Speicher in deinem Netzwerk bekommen hat. Hier am besten dann eine statische IP per DHCP vergeben, damit du die Route nicht immer wieder anpassen musst.
Ich kann sie unter Flows auch nicht sehen. Allerdings werden mir noch infos unter Logs->Trggers angezeigt.
Möchte ja nur verstehen, warum im Forum hier die Anleitung Objects mit IP-range einbindet und die Gateways blockiert, während 95% der Youtuber schlicht Policies für absolut nutzen. Am Ende soll das Netzwerk möglichst sicher sein.
Hast Du denn besondere Videos oder Anleitungen gefunden ? Würde das sonst exakt so machen, wie „777 or 404“ in seinem oben geposteten Video, der eben auch keine GW-Sperren oder IP-ranges nutzt.
Dann bräuchte ich nur noch einen Weg, nach dem ich einzelne IoT-Geräte für andere Netze freigeben kann…
Also ich nutze die Objects mit IP-Ranges nach RFC weil es für mich einfach und logische Regeln in der Firewall bedeuten. Ich muss damit nicht für jedes Netz eigene Object anlegen sondern kann "gleiche/ähnliche" Regeln in den jeweiligen Zonen verwenden.
Den Zugriff auf die Gateways (UDM-SE bei mir) blockiere ich aus jedem "unsicheren" Netz da diese erst garnicht die möglichkeit haben sollen eine ggf. vorhanden Sicherheitslücke im Gateway auszunutzen.
Um einzelne Geräte in andere zu lassen kannst du einfach dafür passende Regeln in der Firewall hinterlegen. Dabei auch die Checkbox für die Anlage der Regeln für dei Rückrichtung aktiveren.
Muss mal fragen:
Die 192.168.0.0/16 deckt eine VLANs mit 192.168.1.0 bis 192.168.4.0 wegen /16 ab, korrekt ?
192.168.0.0/16 deckt alle IPs von 192.168.0.1-192.168.255.254 ab.
Display MoreHallo zusammen,
ich habe mich jetzt Mal an das Thema ran getraut und umgestellt, hat mich 5 Stunden meines Lebens gekostet, da auch mein Proxmox Server mit den ganzen LXC-Containern und VMs umgestellt werden mussten und dann NAS freigaben etc. neu vergeben werden mussten.
So sieht das ganze jetzt aus:
Eiin paar fragen habe ich noch:
- Im Wiki steht ja, dass man, wenn man alles in Internal lässt, die Gateways und die Geschwätzigkeit unter den VLANs blockierten sollte. Da ich im Internal ja nur die Unifi Geräte und meine "vertrauenswürdigen Geräte (Handy, PC) habe und den Rest in eigenen Zonen, brauche ich das ja nicht, da bei eigenen Zonen sowieso von Haus aus alles geblockt ist?
- Ich verbinde mich über Teleport von unterwegs, um auf die Geräte zu kommen. Vorher hat er glaube ich das Netz 192.168.3.x genutzt (das ist auch noch eingestellt, wenn ich auf den VPN-Reiter für Wireguard gehe). Jetzt verbindet er sich aber über 192.168.2.x und ich habe noch nichts gefunden, wo ich das umstellen kann? Ich musste dann auch eine Regel erstellen, dass ich von der Zone VPN auf z.V. meine Zone NAS und HomeLAB komme, sonst war nur das Gateway uner 192.168.1.1 erreichbar.
- Ich habe jetzt komplett der Zone VPN zugriff auf die Zonen HomeLab und NAS gegeben. Ich denke das ist ja recht unsicher, da wenn sich mal jemand fremdes darüber reinhacken sollte, er ja in den Zonen Unfug machen kann. Wie sollte hier die Freigabe für Laptop und Handy am besten eigerichtet werden?
Noch eine grundsätzliche Frage, macht es mehr sinn, für jedes Gerät in einem VLAN eine eigene Freigabe zu machen, bzw. die IPs/Geräte einzeln in einer Regel auszuwählen, als das ganze VLAN/Zone freizugeben?
Danke vorab und Grüße
zu 1:
Da du eigene Zonen angelegt hast und diese nutzt ist die Standardeinstellung, dass die Geräte in INTERNAL nicht mit den neuen Zonen sprechen dürfen. Da müsstest du also wirklich nicht alles per Hand einschränken.
zu 2:
Da kann ich leide rnicht viel zu sagen, ich nutze wireguard. Verstehe nicht, warum sich dein IP-Bereich geändert haben sollte. Da dein NAS in eine custom Zone liegt müsstest du den Zugriff aus dem VPN mit einer eigenen Regel erlauben. Denk dabei daran den haken bei "Return Route" zu aktivieren.
zu 3:
Generell hast du Recht. Wenn sich da jemand rein hackt dann kann er auf die Geräte in den anderen Zonen zugreifen. Sind diese denn ohne authentifizierung erreichbar? Wenn nicht stellt das ja auch noch eine hürde da. Bei Wireguard ist klar, welcher Client welche IP verwendet, da könnte man wirklich einzelne Regeln erstellen pro Gerät für den privaten Gebrauch ist das aus meiner Sicht aber overkill. Wichtiger ist die UDM aktuell zu halten und den Zugriff auf zentrale Dienste wie NAS nur per authentifizierung zuzulassen.
zu deiner grundsätzlichen Frage:
Zugriff aus meinen "trusted" Netzwerk sicher ich mit generellen Regeln ab. Da habe ich keine Lust jedes GErät einzeln zu behandeln. Einzelne andere Zugriffe aus "unsicheren" Zone binde ich immer die expliziten IPs.
Hm, ich weiß dann aber immernoch nicht, was genau man als Gruppen einrichten muss. Da wären Screenshots hilfreich
Hier meine EInstellung für Local Networks RFC1918
Die Einstellung für ipv6 ist identisch - nur eben mit meinem ipv6 Adressbereich denn ich von meinem Internetprovider zugewiesen bekommen habe.
Ja die Objects sind die Gruppen. Die sind unter Einstellungen -> Profile -> Netzwerk Gruppen (oder so ähnlich, habe das bei mir auf Englisch).
Die Objects definieren bei mir die lokalen IPV4 Adressen und meine IPV6 Netzbereiche (ich habe statische ips).
Dein Verständnis von DMZ ist nicht ganz verkehrt. Aber die DMZ steht im Kontext der UDM nicht direkt "vor" der Firewall. Hier ist es auch nur eine Zone und wenn man Server im Internet betreiben würde, dann würde man sie dort hinstellen. Diese Zone ist bei der UDM inital (default regeln) recht gut von den anderen Zonen getrennt. Man kann z.B. von intern dorthin zugreifen aber nicht von der DMZ in die interne Zone. Ich habe in der DMZ alle VLANs die ich hart von meiner internen Zone abtrennen möchte.
Ich glaube das hängt davon ab, wie komplex deine FW Regeln sind und ob du das Netzwerk für die Zeit der Umstellung ohne einen fertigen Regelsatz laufen lassen willst.
Ich habe erstmal umgestellt und unifi die Migration machen lassen. Dann habe ich die Regeln geprüft und alle unsinnigen (ja die Migration erzeugt ggf. viele unsinnige Regeln) gelöscht. Im nächsten Schritt habe ich die VLAN in die passenden Zonen gezogen und die Regeln erneut angepasst. Dabei war mir dann aber auch immer klar, wo ggf. gerade welche Einschränkungen im BNetz bezüglich der Firewallregeln herrschen.
1) Abschottung der VLANs 2-LAN-IoT und 3-LAN-Kids ?
Ich habe hierfür eine Regel erstellt, die VLAN übergreifende Kommunikation in einer Zone unterbindet.
2) die VLANs 1-LAN-Mgt und 3-LAN-Kids sollen Zugriff auf die Geräte in 3-LAN-IoT erhalten (Drucker, Smarthome etc), nicht aber umgekehrt. Wie ?
Etwas ähnliches habe ich auch. Mein IoT-VLAN liegt in der DMZ Zone. Von LAN gibt es eine Allow All Regel in die DMZ. Die gab es sogar schon in den DefaultEinstellungen.
3) Der Server soll in 5-LAN-Server in der Server-Zone für das VLAN 1-LAN-Mgt und für ausgewählte Geräte aus dem 2-LAN-IoT erreichbar sein. Dabei bietet der Server auch Mediendienste wie Plex an.Wie?
Du kannst dafür eine IP Adressen basierte Regel erstellen und die "Rückrichtung" erlauben. Beispiel bei mir DMZ darf auf die DNS Server im LAN zugreifen.
Vielleicht ein Problem mit ipv6 und dein Browser hat auf ipv6 gewechselt?
Ich hatte mit http://www.ipv6-test.com/ auch immer unzuverlässige Ergebnisse. Habe ewig geprüft ob ich irgendwo Fehler habe und bin am Ende zum Schluss gekommen, dass es an der Seite liegt.
Klar, hier einmal vom Esszimmer (20 MHz - Kanal 1; 80 MHz - Kanal 40)
Und Dachboden (20 MHz - Kanal 11; 80 MHz - Kanal 44):
Nach den Bildern hast du zumindest zum Zeitpunkt der Bilder kein Problem mit fremden Funkzellen. Klar hast du viele Netze in deiner Umgebung aber alle "schwach genug". Das sollte deine Funkkanäle nicht stören. Ggf. hier nochmal drauf schauen, wenn du gerade Probleme hast.
Kannst du mal ein Screenshot der "Radios->Environment" Ansicht machen? Die finde ich viel Aussage kräftiger.
Hier die Seite meine ich:
Und natürlich dazu nochmal angeben welchen Kanal und Bandbreite du gerade in 2,4 und 5Ghz nutzt.
Vielleicht hat die Änderung ja garnichts mit dir/deinen Geräten zu tun. Wie ist die Auslastung/Belegung der Funkkanäle bei dir? Vielleicht spielt ein Gerät deiner Nachbarn "verrückt" und wechselt zyklisch den Funkkanal was dann zu Störungen bei dir führt? Vielleicht kannst dd ja mal einen Umgebungsscan machen wenn alles ok ist und wenn du gerade wieder Probleme hast.
Das mit der VLAN Trennung müsstest du über Firewallregeln selber umsetzen. Das klappt aber nur dann, wenn du ein festes Prefix hast. Die UDM stellt dann sicher, dass ein VLAN immer den gleichen ipv6 Bereich zugeteilt bekommt.
Falls du kein festes Prefix vom Provider hast könntest du ipv6 ggf. nur in einem VLAN aktivieren und in den anderen deaktiviert lassen.
Du kannst ipv6 ganz normal aktivieren. Die Standardeisntellungen der UDMSE sind so, dass von draußen kein Zugriff erlaubt ist. Das heißt du kannst dann Webseiten/Server im Internet über ipv6 erreichen bist aber nicht ungeschützt im Netz unterwegs.
Das unterstützt die UDM SE nicht direkt.
Falls das QNAP die Daten der USV networkupstools bereit stellt kannst du den den Client dafür manuell über ssh auf der UDM SE installieren und einrichten. Musst dann aber aufpassen, da bei einem Update der Console (nicht der Apps), diese Änderungen verloren gehen und dann erneut durchgeführt werden müssen.
Hier ein paar weitere Information zu der Einrichtung des NUT Clients auf ubuntu/debian https://wiki.ubuntuusers.de/USV/NUT/
Kurzes Update von mir. DIe Ursache meines Problem konnte ich nun identifizieren: Intelligent Wifi. Das ist eine Funktion bei Samsung Handys, die ggf. den Wechsel zu mobilen Daten aber auch zwischen Accesspoint forciert, sobald es eine angeblich "bessere" Verbindungsmöglichkeit gibt. Bei dem betroffenen Handy führt es dazu, dass es die ganze zeit zwischen allen APs hin und her springt. Nach der Deaktivierung dieses Features habe ich nun endlich eine stabile Verbindung auch in einem Netz mit 2,4 und 5Ghz gleichzeitig. Vorher hatte ich das Netz extra nur auf 2,4Ghz beschränkt.
Es scheint übrigens kein generelles Problem zu sein, da ein A54 von Samsung (auch mit diesem intelligent wifi) ohne Probleme funktioniert.
Gibt dir dein Provider wirklich nur ein 64er Netz? Falls ja wird es nach meinem Verständnis nicht so einfach gehen, da das 64 nicht einfach weiter aufgeteilt werden kann auf deine VLANs, wenigesten nicht per prefix delegation.
Weiterhin benötigst du ein festes ipv6 prefix von deinem provider. Wenn sich das ändert müsstest du sonst jedesmal die Firewalltegeln anpassen.
Falls du doch z.B. ein 56er vom provider bekommst kannst du per prefix delegation 64er auf die VLANs verteilen. Dann kannst Du anschließend die Firewallregeln einstellen. DIe UDM stellt sicher, dass immer das gleiche 64er Subnetz dem gleichen VLAN zugewiesen wird.
Also auf deinen Bildern kann ich den packet loss nicht erkennen.
Bei ipv6 kannst du schnell Probleme bekommen, wenn du das nicht richtig konfiguriert hast. Du musst dann z.B. icmpv6 richtig durchlassen. Wenn du noch eine Firtzbox vor der UDM hast musst du die dafür auch richtig konfigurieren. Einfach ist daher wirklich die Variante ipv6 zu deaktiveren. Dann kannst du ausschließen, ob der Fehler daher kommt. Ist dann immer noch da hat es nichts mit ipv6 zu tun und wir müssen weiter schauen. Dann bitte mal dein Setup beschreiben.
