Beiträge von anderl1969

  • Was bedeutet der LED Blink-Code Blue-White-OFF am U6-Lite

    Ich habe heute an einem meiner U6-Lite APs festgestellt, dass er permanent Blau-Weiß-AUS blinkt. Die Sequenz wiederholt sich ca 2x pro Sekunde. Der AP hat trotz des Blinkens einwandfrei funktioniert. Die Unifi Software hat keine Probleme bzgl. des APs gemeldet. Die mit ihm verbundenen Clients waren erreichbar...

    In der Ubiquiti-Doku habe ich gefunden, dass Weiß-Blau-AUS (bitte Reihenfolge beachten: mein Code war zuerst blau, dann weiß und zuletzt AUS) einen aktiven TFTP-Modus signalisieren würde. Ich habe testweise mal einen TFTP-Client angeworfen, der hat aber keinen aktifen TFTP-Server gefunden.

    Zu guter letzt habe ich den AP rebootet und der Spuk war beendet. Jetzt leucht er weider fröhlich dauerhaft blau vor sich hin.


    Mich würde aber trotzdem interessieren, was der Blink-Code BLAU-WEISS-AUS bedeuet. Weiß das wer?

  • Pi-Hole als DNS-Forwarder

    Die Whitelist hab ich gleich integriert. Bei den optionalen waren auch ein paar relevante für mich dabei. Die Herausforderung wird sein, künftig daran zu denken, dass es an Pihole liegen könnte, falls eine Website/-dienst nicht so funktioniert wie erwartet...


    Aber vielen Dank für die Hinweis!

  • Pi-Hole als DNS-Forwarder

    Hallo an alle Pi-Hole Spezialisten,


    ich betreibe in meinem Netzwerk ein Active Directory mit einem DC (Windows Server 2016 Essentials). Der übernimmt auch DHCP und DNS.

    Ich habe mir zum Testen jetzt Pi-Hole installiert, aber ich möchte als primären DNS-Server für meine Clients den bestehenden Windows-Server beibehalten.


    Damit Pi-Hole überhaupt zum Einsatz kommt, habe ich im DNS-Manager des Windows Server den Pi-Hole als DNS Forwarder konfiguriert. Auf den ersten Blick scheint es wie gewünscht zu funktionieren:

    • Lokale Domain-Namen werden direkt vom Windows-Server bedient.
    • Alles was der Windows Server nicht kennt, leitet er an den Pi-Hole weiter

    Das Einzige, was mir bisher aufgefallen ist, dass der Pi-Hole in seinen Statistiken als Client natürlich immer nur den Windows-Server sieht. Abgesehen von diesem zu vernachlässigenden Schönheitsfehler: sind mit meiner Konfiguration noch irgenwelche Probleme zu erwarten, die ich aktuell nicht sehen? Gibt es Nachteile? Freu mich auf Eure Kommentare.

  • Drucker aus einem VLAN erreichen und umgekehrt der Scanner den PC

    DIe Idee hinter einem einem separaten IoT-VLAN ist, dass darin Geräte verfrachtet werden, die man selber leicht aus dem Blick verliert, weil sie irgendwo im Hintergrund werkeln, und/oder bei denen auch die Versorgung mit Sicherheitspatches ungeregelt ist. Und wenn diese Geräte dann auch nicht mit dem Haupt-LAN kommunizieren müssen, dann sind sie prädestiniert für ein isoliertes VLAN. Gemessen an diesen Kriterien sind der FireTV und die Gaming-Konsolen sicher nicht kritischer als der Linux-Receiver oder der Smart-TV. Ich würde diese Geräte alle in ein VLAN werfen - ob du das am Ende Mutlimiedia oder IoT nennst, ist Geschmacksache.


    Dein Bild passt übrigens nicht zu Deinen Erläuterungen. Laut Bild schmeisst Du alle PCs ins gleiche VLAN - egal ob privat oder Büro. Alle Drucker kommen in anderes VLAN, aber wieder bunt gemischt privat und Büro. Und dann spendierst allen privaten WLAN Geräten wieder ein eigenes VLAN - warum? Du strukturierst Deine VLAN (zumindest in Teilen) anhand von Hardware-Merkmalen (PC vs Drucker vs Mobile). Das macht keinen Sinn.


    So, jetzt ist der Beitrag von Ronny1978 online zuvor gekommen:


    Ich will das VLAN Konzept von Ronny nicht im Einzelnen kommentieren. Aber es ist erst mal ein plausibles Grundgerüst. Daran kann man sich orientieren.

  • Drucker aus einem VLAN erreichen und umgekehrt der Scanner den PC

    Den Plan solltest du nochmal überdenken. Nur mal ein paar Anmerkungen:


    • Wieso trennst du PC und Drucker? Wenn überhaupt würde ich prüfen, ob eine Trennung nach Privat und Büro sinnvoll ist.
    • Was macht die Synology im Multimedia VLAN? Ist die nicht das Herz deines Heimnetztes (Fileserver und weiß der Geier, was Du da noch alles für Server-Dienste drauf laufen hast). Müssen da nicht permanent deine PCs darauf zugreifen?
    • Den Unterschied zwischen Deinem Multimedia und IoT Netz habe ich auch noch nicht verstanden.
    • Wieso willst Du ein eigenes VLAN für deine WLAN-Laptops? Was unterscheidet die von den wired PC`s?

    Am Ende kannst Du es natürlich anlegen wie Du willst. Aber die Menge der gerätespezifischen Einzel-Rules ist ein Maß für die Güte des VLAN-Konzepts. Ich fürchte, Du wirst eine Menge an Ausnahme-Regeln benötigen. Und das ist nicht nur eine Geschmacksfrage - deine Firewall wird auf Dauer nur sehr schwer zu warten sein.

  • Wo stellt ihr den DNS Server ein ? Altes/Neues Interface

    Um das Thema abzurunden:


    • Das was uboot21 und maxim.webster beschreiben, ist die Einstellung, welchen DNS-Server deine UDM-Pro via DHCP an die Clients kommuniziert. (Sofern die UDM-Pro auch der DHCP-Server ist...)
      Das ist auch die Einstellung, die wohl gesucht hast.
    • Die Einstellung, die Du unter Internet / Advanced / DNS-Server gefunden hast und die per default auf Auto steht, meint den DNS-Server, den die UDM-Pro selbst zur Auflösung von Domain-Namen im Internet nutzt. Und Auto meint hier die DNS-Server Deines Internetproviders.

  • Unifi Firewall Best Practice - Wiki Eintrag

    Zitat von Tuxtom007

    Wie soll dein Device mit 10.10.20.x ins Internet kommen, wenn es nicht das Gateway .20.1. erreicht ?


    Das 10.10.20.x kein Device in 10.10.10.x erreicht, ist ja in den meisten Fällen gewollte - Inter-VLAN Kommunikation verhindern genannt, ansonsten kann man sich mit den VLAN's auch direkt sparen.

    Will du ein Device von 10.10.20.x in 10.10.10.x erreichen, muss du das erlauben.

    Dass 10.10.20.x das Gateway 10.10.20.1 erreichen muss, ist klar. Auch dass ich i.d.R. keine Inter-VLAN-Kommunikation möchte, habe ich nie bestritten.

    Zitat

    Das ein Device aus 10.10.20.x. aber per ssh oder https auf die UDM kommt mit 10.10.20.1 ist dann ein Designfehler des Firewallsystem von Unifi

    Bei meiner Firewall geht das definitiv nicht, da ich jeden Zugriff auf die Firewall selber per ssh oder https explizit per Regel freischalten muss und zwar für jedes VLAN und das ist auch richtig so.

    Das ist genau mein Punkt: So wie die UDM designt ist und das was der Wiki-Artikel an Standard Firewall Regeln beschreibt, führt zu der Konstellation, dass ein Device 10.10.20.x zwar nicht mehr auf 10.10.1.1 oder 10.10.10.1 zugreifen kann, aber er kann über 10.10.20.1 per ssh und Web-UI zugreifen.

    Der Wiki-Artikel beschreibt also eine - sagen wir mal - unvollständige Lösung. Um den Designfehler, wie Du ihn nennst, der UDM zu kompensieren, braucht's halt noch 1-2 Regeln, um zumindest die Ports 80, 443 und 23 zu verrammeln.

  • Unifi Firewall Best Practice - Wiki Eintrag

    Zitat von defcon

    Punkt 1

    Ich hatte meine Firewall schon ähnlich aufgesetzt gehabt wie es im Wiki steht, bevor es den Eintrag überhaupt gab. Außerdem bin ich nicht verpflichtet, jeden Wiki Eintrag auf Richtigkeit zu prüfen und nachzustellen.

    Natürlich bist Du nicht dazu verpflichtet. Hat Dich keiner gezwungen, hier zu antworten.

    Zitat

    Punkt 2

    Stell dir vor, ich habe auch LAN Local regeln, aber halt anders umgesetzt… deswegen wollte ich auch Screenshots von dir.

    Wieso Screenshots von mir, wenn es immer um die Firewall-Regeln ging, die im Wiki beschrieben sind - mit Screenshots.

    Zitat

    Punkt 3

    Sorry, dass ich mich nicht in dein Netzwerk geglaskugelt habe!

    Kein Ding. Es ging ja auch nie um mein Netzwerk, sondern (Achtung: Wiederholung!) um den Wiki-Eintrag

    Zitat

    Punkt 4

    Sorry, dass ich meine Firewall nicht nach deinen Bedürfnissen umgebaut habe um zu testen.

    Auch das hat niemand verlangt.

    Zitat

    Punkt 5

    Hardcopys und Screenshots wären geil gewesen, wäre innerhalb von 5 Minuten gefunden gewesen das Problem.

    Der Wiki-Eintrag (um den es die ganze Zeit ausschließlich ging) ist bestens dokumentiert mit Screenshots.

    Zitat

    Punkt 6

    Bereue es meine kostbare Zeit verschwendet zu haben.

    dito

    Zitat

    Punkt 7

    Dann schreib einen Wiki Eintrag dazu.

    Du wirst lachen - das war meine ursprüngliche Intention. Doch die Lust dazu, ist mir gehörig vergangen.

    Was denn dann, wenn es keine "offense" sein soll?


    Du hast echt ne merkwürdige Art. Aber Du liest ja hier nicht mehr mit.

  • Unifi Firewall Best Practice - Wiki Eintrag

    Ernsthaft jetzt?

    Zitat von defcon

    Ich hab bei mir persönlich die Firewall nicht nach dem Wiki aufgebaut, bei mir ists ne Eigenlösung

    Ich eröffne ein Thema, in dem es um den Wiki-Eintrag zu den Firewall-Regeln geht und ich feststelle, dass die Regeln aus dem Wiki unzureichend sind. Und Du widersprichst, obwohl du Wiki-Regeln gar nicht implementiert hast? Respekt.

    Zitat von defcon

    Gut das es nun alles bei dir klappt, hätten aber sicher anhand von Screenshots den Fehler oder die zusätzlich benötigten Regeln schnell gefunden.

    Ich hatte bereits im allerersten Post geschrieben, dass ich für mich eine Lösung gefunden hatte. Es ging um das Regelwerk, das im Wiki dokumentiert ist.

  • Unifi Firewall Best Practice - Wiki Eintrag

    Wir brauchen doch nicht bis zum WE warten. Ich habe ein Youtube Video gefunden, wo genau die Regeln wie im Wiki-Eintrag angelegt werden.

    Video


    Die Vorgehensweise ist wie im Wiki:

    • "established" und "related" erlauben (LAN IN)
    • Inter-VLAN-Kommunikation blockieren (LAN IN)
    • Ab 7:59 sieht man, wie die Gateways geblockt werden (Vorgehensweise haargenau wie im Wiki-Eintrag)
    • Ab 11:33 demonstriert das Video den Effekt:
      • aus einem VLAN können die Gateways der anderen Subnetze nicht mehr erreicht werden
      • sehr wohl aber noch das "eigene" Gateway aus jedem VLAN erreicht werden! (Timestamp 12:12)
    • Ab 12:33 wird ein extra Regel-Set erstellt, um den Zugriff auf http, https und ssh zu unterbinden

    • Ab 14:44 gibt's dann noch ein Regel-Set um auch die Pings auf die eigenen Gateways zu blocken!


    Wie gesagt: die letzten beiden Regel-Sets fehlen im Wiki!

  • Unifi Firewall Best Practice - Wiki Eintrag

    Ok, dann haben wir da einen Unterschied zwischen UDM-SE (mein Gerät) und UXG-Pro.


    Ich werde am WE nochmal exakt die FW-Regel wie im Wiki beschrieben herstellen. (Aktuell habe ich eigene Regeln formuliert, um den Zugriff auf die UDM-SE zumindest auf den Ports 80, 443 und 23 aus den VLANs zu unterbinden).

    Wenn ich das von mir beschriebene Verhalten (weiterhin Zugriff auf das Web-UI und ssh aus den VLANs über die dem VLAN "zugewandte" IP-Adresse) reproduzieren kann, sollte man den Artikel im Wiki aus meiner Sicht aktualisieren - zumindest was das unterschiedliche Verhalten zwischen UXG-Pro und UDM-SE betrifft.


    Hat die UXG-Pro eigentlich vordefinierte Regeln unter LAN local? Die UDM-SE ist da nämlich blank.

  • Unifi Firewall Best Practice - Wiki Eintrag

    Ich glaube, wir reden/schreiben aneinander vorbei.


    Konkretes Beispiel:

    • Das Default-LAN ist 10.10.1.0/24
    • Der Router sei eine UDM-Pro mit 10.10.1.1 (und natürlich auch mit 10.10.10.1, 10.10.20.1, ...)
    • Das zu betrachtende Client-Device sitzt im VLAN 20 mit 10.10.20.55


    Mit den LAN local Regeln aus dem Wiki passiert folgendes:

    Der Client 10.10.20.55 kann die UDM-Pro unter der IP 10.10.1.1 nicht erreichen.

    Aber der Client 10.10.20.55 kann die UDM-Pro unter der IP 10.10.20.1 erreichen.


    Sind wir uns bis hierhin einig?


    Meine Frage ist, was habe ich damit gewonnen?

    Ist es nur ein "Hygenie-Thema", so nach dem Motto aus dem 10.10.20.x Netz darf kein Zugriff auf iwas mit 10.10.1.x erfolgen, auch nicht auf 10.10.1.1- wohl wissend, dass das selbe Device unter 10.10.20.1 dann doch erreichbar ist?

    Oder hat es tatsächlich eine praktische Relevanz, die ich nicht sehe?