Beiträge von DerT

    Danke für die Ideen.

    Ich hab damit noch ein paar Tests gemacht finde aber nach wie vor kein Muster.

    Ich habe nun mehrere IP Adressen in meinem Client Bereich ausprobiert.

    Bei manchen kommt ein ARP Reply von den APs und bei manchen nicht. Allerdings sehe ich kein Muster wann er kommt und wann nicht.

    Dann war bei meinen Tests irgendwann der Moment bei dem plötzlich alle IPs auf Ping reagiert haben die Adressen in der ARP Tabelle meines Clients auch standen.

    Nach dem löschen und neu Pingen kam für die dann auch ein Reply von den Unifi Komponenten.


    Und nun zu den anderen Anregungen.


    Firewall auf dem Client an / doof ?

    Die Clients welche Probleme machen sind meistens Geräte wie Drucker oder IP Kameras. Also nichts bei dem ich Einfluss oder Infos auf eine Firewall hätte. Wobei ich auch nicht davon ausgehe, dass diese eine haben.


    Hat der Switch auf dem VLAN / PORT / Global irgendwelche ARP Spoofing / Protection / Settings.

    Sind relativ Dumme TP-Links (TL-SG108E). Das einzige was ich gefunden habe und an ist wäre "IGMP Snooping" und "QoS 802.1P Based"

    Beim IGMP Snooping bin ich mir unsicher ob es Probleme beim ARP Request machen könnte. Der Request als Broadcast kommt ja bei den APs und beim USG an.


    Oder hat er MAC Spoofing / Protection / Settings.

    Nein


    Auf dem Unifi AP wie ist das WLAN zum den VLAn konfiguriert ?



    Interessant sind:

    „Proxy ARP“ (ggf. ausschalten)

    Hatte ich auch schon im Verdacht und hab es ausgeschaltet.


    „Multicast und Broadcast Control“ (aus oder MAC von Router und Drucker anderen clients eintragen)

    Ist schon aus. Aber das Multicast Enhancement ist noch an


    „Client Device Isolation“ (aus damit wenn an)

    Ist aus

    Hallo zusammen,


    ich kämpfe nach wie vor mit dem Problem und habe mittlerweile ein paar Erkenntnisse.

    Eventuell kann mir ja jetzt jemand weiterhelfen.


    Der Aufbau der Umgebung hat sich nicht verändert und das Gerät mit dem Problem ist nach wie vor der Drucker mit der IP 10.20.1.17.

    Der Fehler muss irgendwo an der ARP Tabelle liegen. Deshalb kommt der Fehler auch nur wenn sich die beiden Geräte im selben VLAN befinden. Da andernfalls der Traffic ja über das Gateway geht.


    Während mein USG in der ARP Tabelle die 10.20.1.17 korrekt aufführt.


    Scheint mein Client damit ein Problem zu haben.


    Beim versuch die IP von meinem Client aus zu pingen (10.20.1.13) sehe ich sowohl auf dem USG als auch auf dem AP, dass ein ARP Request kommt.


    USG


    AP


    Wenn ich die Adresse Statisch in der ARP Tabelle eintrage funktioniert alles.

    Außerdem funktioniert es sobald ich den AP auf dem der Drucker verbunden ist neu starte.


    Jemand eine Idee wo ich weiter suchen kann?

    Okay, spannende Erkenntnis die mich kein Stück schlauer macht.

    Ich habe zum testen AP2 an das Kabel von AP1 angeschlossen.

    Siehe da. Alle Geräte waren erreichbar,

    Dann wieder AP1 angeschlossen und es geht auch wieder?

    Frei nach dem Motto "Ein Reboot tut gut".

    Jemand ne Idee?

    Ich hab nun nochmal die komplette VLAN Konfig auf den Switchen kontrolliert und gerad gezogen.

    Tatsächlich war hier noch ein Fehler bei meinem Testclient. (Wahrscheinlich ein Überbleibsel aus alten Tests)

    Die Kommunikation der beiden Client innerhalb auf dem selben Switch funktioniert nun.

    Den Drucker und ein paar andere Geräte im WLAN erreiche allerdings nicht.

    Was mit aufgefallen ist, ist das es abhängig vom AP ist.

    Ich habe zwei identische IP Kameras. Kamera 1 ist mit AP1 verbunden und Kamera 2 mit AP2.

    Kamera 1 kann ich von meinem Client nicht per Ping erreichen

    Kamera 2 schon.

    Beide Kameras sind vom USG aus per Ping erreichbar.


    Mein erster Gedanke war nun eine falsche VLAN Konfig an den Ports der APs.


    Die sieht wie folgt aus.


    Zentraler Switch

    NamePVIDTaggedUntagged
    Uplink UV11010,20,30
    Uplink UV21010,20,30
    Uplink UV31010,20,30



    Unterverteiler 1

    NamePVIDTaggedUntagged
    Uplink HV 1010,20,30
    AP11020,3010


    Unterverteiler 2

    NamePVIDTaggedUntagged
    Uplink HV 1010,20,30
    AP21020,3010


    Unterverteiler 3

    NamePVIDTaggedUntagged
    Uplink HV 1010,20,30
    Testclient202



    Die VLAN Konfiguration ist also für beide APs gleich.

    AP1 ist ein neuer U6-Lite und AP2 ist ein UAP-AC-Lite.

    Gibt es da ne Konfiguration die ich übersehe?

    Hallo zusammen,


    erstmal die Grundzüge meiner Umgebung


    VLANs

    10 - Server - 10.10.0.0/16

    20 - Clients - 10.20.0.0/16

    30 - IoT - 10.30.0.0/16


    Aktuell gibt es neben dem Standard keine Firewall Regeln und somit ist jeder Traffic zwischen den VLANs erlaubt.

    Für jedes VLAN gibt es ein eigenes Netzwerk.


    Nun habe ich das komische Phänomen, dass Geräte die sich im selben VLAN befinden teilweise nicht erreichbar sind.


    Beispiele


    10.20.1.41 und 10.20.1.10 --> Können sich gegenseitig nicht erreichen

    Beides Windows PCs im VLAN Clients die sich am selben Switch befinden.


    10.20.1.10 --> 10.20.1.17

    Die 17 ist ein Drucker welcher sich auch im Clients VLAN befindet.

    Dieser ist per WLAN angebunden und vom Client 10.20.1.41 aus nicht erreichbar.

    Vom USG aus aber schon


    Die Probleme bestehen aber nur in der Kommunikation von Clients im selben VLAN.

    Sobald sich ein Client in einem anderen VLAN befindet und die Kommunikation über das Gateway läuft funktioniert alles.

    Hat Jemand einen Tipp wo ich nach dem Fehler suchen kann?


    Gruß

    Thomas

    Hallo zusammen,


    ich bin gerade dabei mein Netz zu segmentieren um unter anderem meine Server, Clients und IoT Komponenten zu trennen.

    Das klappt bisher auch gut soweit.


    Eine Komponente dabei ist allerdings die Kommunikation meiner Tasmota Geräte mit Alexa.

    Realisiert ist das ganze über Node-Red mit dem Modul https://flows.nodered.org/node/node-red-contrib-amazon-echo.


    Das funktioniert allerdings nicht wenn der Server sich in einem anderen VLAN befindet als die Alexa Lautsprecher. Problem ist, dass die Kommunikation hier über eine UDP Broadcast auf Port 80 läuft. Dieser kommt natürlich nicht vom IoT VLAN ins Server VLAN.


    Nun habe ich schon ein paar Ansätze gefunden bin mir aber nicht sicher was der richtige Weg wäre dies zu realisieren.


    • Broadcast weiterleiten?
    • IoT Server und Alexa Lautsprecher ins IoT VLAN?
      • Ist ja irgendwie IoT
      • Aber eigentlich soll das IoT VLAN kein Internet haben.




    Hat jemand einen Tipp?



    Danke und Gruß


    Thomas

    Perfekt und danke dir.

    Das war der Fehler.

    Nun funktioniert es wie es soll.


    Full Ack da:

    allerdings müsste dann bereit auf der Fritze eine route für das

    192.168.178.X existieren das zur USG (192.168.0.2) geht.

    Weil quasi Analog das gleiche.

    Ja das tut.

    Das schlimme ist, als ich es angelegt hab, dachte ich mir auch "Das muss ich dann für alle VLANs machen die Internet brauchen".

    Damit wäre der Test ob das doppelte Nat wirklich aus ist nun auch erledigt :grinning_face_with_smiling_eyes:

    Hallo zusammen,


    ich bin noch recht frisch in der Unifi Welt und habe mir ein USG geholt um damit mein Netzwerk in mehrere VLANs zu segmentieren.

    Aktuell habe ich folgende Komponenten.

    FritzBox --> Baut die Internetverbindung auf

    USG --> Sitzt zwischen meinem Netzwerk und der FritzBox (Transfernetz 192.168.0.0/24) --> NAT ist deaktiviert um ein doppeltest NAT zu vermeiden

    Mehrere managebare TP-Link Switche (alle können 802.1Q)

    Windows DC/DHCP/DNS

    Aufbau meiner Netze

    Mein "altes" Netz -192.168.170.0/24.

    Dort befinden sich folgende relevanten Geräte.

    • 192.168.170.24 - Pi-Hole
      • DNS Server der bei den Clients eingetragen ist. Ist nur fürs Filtern von Adressen da
    • 192.168.170.20 - DC / DHCP / DNS
      • Forwarder für den PiHole. --> Der eigentliche DNS Server im Netz
      • DHCP Server für 192.168.170.0/24 und später auch für die anderen VLANS
    • 192.168.170.1
      • USG --> Ist im DHCP auch als Router eingetragen

    Transfernetz - 192.168.0.0/24

    • 192.168.0.1 -> FritzBox
    • 192.168.0.2 -> USG (WAN)

    Clients - 10.20.0.0/16 - VLAN 20

    Das erste VLAN welches ich testen wollte ist für Clients und hat die Adresse 10.20.0.0/16 und die VLAN ID 20.

    Nun habe ich dieses soweit im Controller eingerichtet und als DHCP Mode "DHCP Relay" ausgewählt. Dort habe ich den DHCP 192.168.170.20 eingetragen.


    Im DHCP ist das Netz wie folgt eingerichtet.


    Was geht und was geht nicht

    Auf den Switchen habe ich an jedem Uplink Port das neue VLAN als tagged konfiguriert und bei meinem Switch hier am Schreibtisch habe ich einen Port mit dem VLAN unttaged konfiguriert.

    Wenn ich meinen Testclient anschließe funktioniert auf den ersten blick alles wie gewollt.

    Er bekommt die IP 10.20.1.0 von meinem DHCP Server. Hat als DNS ist die 192.168.170.24 hinterlegt. Gateway ist die 10.20.0.1.

    Die Namensauflösung funktioniert sowohl mit internen als auch mit externen Namen.

    Das Gateway, der DNS und die WAN Seite des USG (192.168.0.2) sind via Ping erreichbar.

    Alles was im Internet liegt aber nicht. Das USG scheint keinen Traffic dieses Netzes in Richtung WAN zu lassen.

    Wenn ich ein tracert google.de mache kommt dieser bis zum Gateway und danach ist Schluss. Eigentlich müsste als nächster Hop ja die Fritzbox kommen.



    Meine Vermutung liegt bei der Firewall. Allerdings verstehe ich es noch nicht ganz.

    Hat jemand eine Idee?


    Gruß


    Thomas