[Ubiquiti-Netwerkapparatuur] Ervaringen & Discussie - Deel 4

[laurens0619]

Will_M schreef op woensdag 4 mei 2022 @ 21:50:
@laurens0619 Probleem van/met AP's welke middels MESH (met elkaar) verbinden is dat ze dat doen door een extra >>Hidden SSID<< op te zetten en vervolgens met elkaar te gaan delen óver de 2,4Ghz. band.... En die zat al niet vol genoeg, ......toch?

een beetje mesh zet een dedicated 5ghz kanaal op en gebruikt alleen 2.4 als het echt niet anders kan.
Hierdoor heb je wel meer nodes nodig dan bedrade accesspoints omdat je voor meer overlap moet zorgen.
Mesh node in gemiddeld huishouden
- meterkast
- gang Bij trap
- zolder bij trap

Geeft dankzij de trap wel overal 5ghz links

Ga je ze kris kras plaatsen dan krijg je 2.4 ghz links die idd brak zijn

[Will_M]

laurens0619 schreef op woensdag 4 mei 2022 @ 21:54:
[...]

een beetje mesh zet een dedicated 5ghz kanaal op en gebruikt alleen 2.4 als het echt niet anders kan.
Hierdoor heb je wel meer nodes nodig dan bedrade accesspoints omdat je voor meer overlap moet zorgen.
Mesh node in gemiddeld huishouden
- meterkast
- gang Bij trap
- zolder bij trap

Geeft dankzij de trap wel overal 5ghz links

Ga je ze kris kras plaatsen dan krijg je 2.4 ghz links die idd brak zijn

Ik zal eens een keer vragen of ik je een keer een dag als stagiair mee mag laten "lopen". Kun je zien hoe we , op afstand vanop een controller welke duizenden AP's aan stuurt, VOIP / VOWiFi verkeer middels QoS ordenen in meerdere panden met honderden AP's

[laurens0619]

@Will_M
Nee sorry ik ben niet in te huren als consultant, doe wifi alleen hobbymatig

Om even ontopic te reageren op mesh/unifi:
Deze post legt de volgende weg af
- mobile device naar openwrt ap in chalet
- openwrt ap met kabel naar ubiquiti nanostation m2 (hangt aan chalet)
- straalverbinding naar unifi outdoor op camping
- straalverbinding van camping naar vuurtoren (unifi ac mesh apparatuur dacht ik of iets airmax)
- straalverbinding van vuurtoren naar kerk dorp verderop (ubiquiti airfiber)
- hier de kabel op naar interwebs

Is hier jaaaren geleden ontstaan omdat er geen fiber was maar wel behoefte aan goed internet voor veel vakantieparken. Unifi guru dorpje verderop heeft dat toen opgezet via de kerk en vuurtoren

Best gaaf )

[ Voor 80% gewijzigd door laurens0619 op 04-05-2022 22:57 ]

[RobertMe]

laurens0619 schreef op woensdag 4 mei 2022 @ 22:16:
- straalverbinding van camping naar vuurtoren (unifi ac mesh apparatuur dacht ik)

Straalverbinding met een AC Mesh lijkt mij wel sterk. Lijkt mij toch eerder dat daarvoor iets uit de AirMax lineup gebruikt wordt?

[laurens0619]

RobertMe schreef op woensdag 4 mei 2022 @ 22:27:
[...]

Straalverbinding met een AC Mesh lijkt mij wel sterk. Lijkt mij toch eerder dat daarvoor iets uit de AirMax lineup gebruikt wordt?

Hmm ja klopt haal ff 2 dingen door elkaar
Hier gebruiken ze geloof ik een airmax nanobeam maar bij een strandtent (die zit wel echt vlak naast de vuurtoren) zag ik een ac mesh hangen. Lomp groot rechthoekig ding. Of dat is hun outdoor wifi maar daarvoor stond die op gekke plek

Edit: was oude foto. Ik geloof dat ik daar een mooie airfiber zie hangen

Hieronder staat het spul denk ik op die mast op de vuurtoren


Persoonlijk heb ik dr airmax lijn altijd erg gaaf gevonden van ubiquiti, is het bedrijf ook mee begonnen

[ Voor 35% gewijzigd door laurens0619 op 04-05-2022 22:55 ]

[xbeam]

laurens0619 schreef op woensdag 4 mei 2022 @ 21:39:
Sorry ik ben niet zo anti “mesh”

Repeater

Feit is gewoon dat de gemiddelde consument een betere internet ervaring krijgt na het naar binnen flikkeren van een mesh.

je gooit dus een daisy-chain naar binnen met 2 repeaters kan je geen MESH netwerk maken.

Want:
- provider modem staat in meterkast waarmee je slechts 2.4ghz dekking krijgt (als je geluk hebt)
- 2.4 zit zo vol troep dat geeft een hakkelende ervaring
- 2 mesh repeaters nodes kunnen op dezelfe locatie een betere verbinding tot stand krijgen dan een wifi client op
ap
- ja bandbreedte daalt maar dat boeit voor de gemiddelde consument niet. Stabiliteit is veel belangrijker en die mesh setjes weten wel stabiel 5ghz 50mbit in het hele huis te krijgen

Dat is voor de meeste mensen zeker prima

- bandbreedte daalt veeel minder bij tri-band. Kpn superwifi is ook tri band

Dat daalt precies even veel per toegevoegde hop/node het probleem zit hem niet in het aantal banden maar in het WiFi signaal en de natuurkundige eigenschappen van half-Duplex.

Alleen sinds WiFi 5 is WiFi snel genoeg dat 1 of 2 keer de snelheid halveren voor veel mensen nog steeds snel genoeg is.

- fool proof (dubbel nat/roaming)! Zelf meerdere accesspoints inrichten schijnt complex te zijn.
Sorry to say maar 1 van de redenen dat unifi zo populair is omdat het fantastisch roamde.

Deze snap ik niet? unifi of die zogenaamde mesh setjes doen helemaal niets met roaming. Dat doet je nieuwere telefoon helemaal zelf vanwege betere K,V,R protocol in de software van je telefoon en WiFi 5.

Meeste mensen dachten dat unifi iets magisch deed. Zat niets magisch in kwam puur door fool proof stuk.

Welk fool proof stuk?

(Verwarring komt ook door zero handoff wat ze in beta hebben gehad)

Zero handsoff was geen beta maar gewoon hoe je hoe je met WiFi 4 een (voice)bellen over wifi netwerk inrichten.

- via provider goedkoop. gemiddeld betaal je 30-40 euro per node met best prima hardware (en klaaglijn provider)

Eens

De oude repeaters van vroeger waren ruk want:
- single band
- ouwe spec die sowieso traag was (802.11n)
- vaak andere chipset provider wifi en repeater wat gedonder gaf. 2 mesh nodes zij op elkaar ontworpen

Onzin die 2 mesh nodes zijn gewoon standaard repeaters alleen nu (802.11ac wave2 ) en daardoor zijn sneller dan die oude N repeaters

Verder helemaal eens dat de term mega kut is. Ik noem het “multi ap”

Gebruik hem dan ook niet meer want MESH is geen wifi techniek maar en netwerk topologie

[Tonne]

Allemaal best interessant die discussie over mesh netwerken. Maar het is nu wel weer tijd om ontopic te gaan lijkt me.

[laurens0619]

@xbeam
Met wireless mesh refereer ik naar 802.11s. Nodes hoeven niet met alle paden draadloos verbonden te zijn en meestal is er maar 1 link omhoog (naar het beste pad)
https://www.cwnp.com/uplo..._mesh_networking_v1-0.pdf

Wikipedia: IEEE 802.11s

Bij 2 nodes js het discutabel ja maar ik had het niet perse over 2 nodes? Sowieso zijn de meeste setjes helaas niet 802.11s compliant maar het conceptuele komt overeen. Het blijft beetje vaag en daarom stond het ook tussen quotes

- waarom zou met een dedicated 5ghz backhaul (op dedicated channel) je bandbreedte net zo hard dalen?

- heb je ooit zero handoff gedraaid? Ik wel en dat was zelfs voor voip telefoons niet productiewaardig. Ik vond de techniek wel cool en daarom heb ik toen ook unifi gekocht. Afaik is het nooit uit beta gekomen maar daar kan ik naast zitten.

- de perceptie is vaak dat unifi/mesh iets magisch doen met roaming wat idd niet klopt. Dat dit dankzij 802.11krv is klopt ook niet, die rol is marginaal en komt meer door betere client roaming support.

- dat de repeaters nu beter zijn heeft niet alleen met 802.11ac te maken. De andere eigenschappen tellen ook zeker mee

Maar laten we het hierbij houden idd
Het zou wel mooi zijn als unifi enkele stappen zou maken op het gebied van 802.11s omdat dat nu een beetje mist

[ Voor 14% gewijzigd door laurens0619 op 05-05-2022 08:15 ]

[zeroday]

laurens0619 schreef op donderdag 5 mei 2022 @ 07:54:


- de perceptie is vaak dat unifi/mesh iets magisch doen met roaming wat idd niet klopt. Dat dit dankzij 802.11krv is klopt ook niet, die rol is marginaal en komt meer door betere client roaming support.

Sorry hoor maar hoe denk je dat clients betere roaming support krijgen? Dat kunnen ze absoluut niet zelf bedenken. Daar heb je protocollen voor .. Goh ..

Ik had graag gewild dat deze protocollen er waren toen ik de eerste 802.11b PCMCIA dongeltjes en AccessPoints kreeg om voor verkoop te testen en de WiFi Aliance nog niet bestond .. dat had me veel ellende mbt marketing taal kunnen besparen ..

en laten we dan even gewoon wat jip en janneke taal van Apple erbij pakken die eea uitlegt

https://support.apple.com/nl-nl/HT202628

[laurens0619]

@zeroday unifi setjes roamen al jaaaren heel goed terwijl 802.11krv er voorheen nooit in zat (behalve de afheleide fast roaming wat roaming tijd verkortte maar vaak uit stond)

Hoe zou je dat dan verklaren? Zet anders 802.11krv een keer uit en test het verschil (als het erin zit nu en of het uit kan)

[ Voor 19% gewijzigd door laurens0619 op 05-05-2022 08:33 ]

[zeroday]

[b]laurens0619 schreef op donderdag 5 mei 2022 @ 08:24:@zeroday unifi setjes roamen al jaaaren heel goed terwijl 802.11krv er voorheen nooit in zat (behalve de afheleide fast roaming wat roaming tijd verkortte maar vaak uit stond)

Hoe zou je dat dan verklaren? Zet anders 802.11krv een keer uit en test het verschil (als het erin zit nu en of het uit kan)

Dat valt en staat met de client. Er zijn zat gebruikers geweest die problemen hadden omdat krv er niet in zat. Maw gebruik nu gewoon afgesproken protocollen en dan spreken ze dezelfde taal.

Eigen work-arounds zijn mooi zolang de standaarden er niet zijn.

[ Voor 49% gewijzigd door zeroday op 05-05-2022 09:45 ]

[laurens0619]

@zeroday
Maar zijn die problemen op die clients dan nu opgelost omdat er krv is?
Uit mijn testen kwam (helaas) iets anders. Benieuwd naar jouw testresultaten

Neemt niet weg dat standaarden goed zijn maar het nare is dat
1. krv kan tegenwerken als je client het niet goed kan
2. de standaard niet super strak is, iedere implementatie bij een vendor is anders. Vooral minder volledig. En dan zie 1

Daarbij blijft het super vaag of unifi uberhaupt wel krv doen. Zover ik weet blijft dat onbekend/nee (op eigen varianten/workarounds na)
https://community.ui.com/...-bfb6-4731818f2449?page=2

[ Voor 26% gewijzigd door laurens0619 op 05-05-2022 10:08 ]

[xbeam]

laurens0619 schreef op donderdag 5 mei 2022 @ 08:24:
@zeroday unifi setjes roamen al jaaaren heel goed terwijl 802.11krv er voorheen nooit in zat (behalve de afheleide fast roaming wat roaming tijd verkortte maar vaak uit stond)

Hoe zou je dat dan verklaren? Zet anders 802.11krv een keer uit en test het verschil (als het erin zit nu en of het uit kan)

Accespoints van elk ander merk roamde niet slechter alleen SDN maakt fine tune gewoon iets makelijker

laurens0619 schreef op donderdag 5 mei 2022 @ 07:54:
@xbeam
Met wireless mesh refereer ik naar 802.11s. Nodes hoeven niet met alle paden draadloos verbonden te zijn en meestal is er maar 1 link omhoog (naar het beste pad)
https://www.cwnp.com/uplo..._mesh_networking_v1-0.pdf

Wikipedia: IEEE 802.11s

Bij 2 nodes js het discutabel ja maar ik had het niet perse over 2 nodes? Sowieso zijn de meeste setjes helaas niet 802.11s compliant maar het conceptuele komt overeen. Het blijft beetje vaag en daarom stond het ook tussen quotes

- waarom zou met een dedicated 5ghz backhaul (op dedicated channel) je bandbreedte net zo hard dalen?

Omdat het niet op magische wijze een full duplex medium wordt

- heb je ooit zero handoff gedraaid? Ik wel en dat was zelfs voor voip telefoons niet productiewaardig. Ik vond de techniek wel cool en daarom heb ik toen ook unifi gekocht. Afaik is het nooit uit beta gekomen maar daar kan ik naast zitten.

Ik was ook geen fan maar de functie van 1SSID met op alle AP’s het zelfde Mac adress was om te zorgen dat voip telefoons niet door hadden dat ze moesten roamen en dan de verbinding dropte om het volgende Accespoint te zoeken. Dat met de komst met beter protocollen voor wifi5 in de handsets worden handovers door de clients veel sneller gemaakte waardoor de verbinding minder snel wegvalt en is zero hands off overbodig waardoor het bij het EOL gaan van Unifi”s WiFi 4 Accespoints ook de functie is verwijderd uit de controller.

- de perceptie is vaak dat unifi/mesh iets magisch doen met roaming wat idd niet klopt. Dat dit dankzij 802.11krv is klopt ook niet, die rol is marginaal en komt meer door betere client roaming support.

Wat denk je dat 802.11krv zijn? Roaming protocollen en wat is volgens jouw client roaming support als 802.11krv dat niet is?

- dat de repeaters nu beter zijn heeft niet alleen met 802.11ac te maken. De andere eigenschappen tellen ook zeker mee

Een nieuwe auto is altijd beter dan het model van 10 jaar daar voor. maar op welke eigenschappen doel je precies?

Maar laten we het hierbij houden idd
Het zou wel mooi zijn als unifi enkele stappen zou maken op het gebied van 802.11s omdat dat nu een beetje mist

Nee laten we nu geen eigen rommel en eigen implementatie buiten de 802.11 standaard aan Accespoints gaan toevoegen

The IEEE 802.11s standard was issued in 2011 and was superseded in 2012

[laurens0619]

@xbeam ik weet niet of he zit te trollen of het echt niet snapt maar ik vind het best zo
Begint beetje semantisch te worden zo en daar heeft niemand wat aan

[ Voor 27% gewijzigd door laurens0619 op 05-05-2022 14:41 ]

[xbeam]

laurens0619 schreef op donderdag 5 mei 2022 @ 14:39:
@xbeam ik weet niet of he zit te trollen of het echt niet snapt maar ik vind het best zo
Begint beetje semantisch te worden zo en daar heeft niemand wat aan

jij beroept op een paper uit 2011 met door aangedragen S protocol allen is dat protocol in 2012 niet ingevoerd als onderdeel van de WiFi 5 standaard. En bij de definitie van de WiFi 6 standaard heb ik ze er niet meer over gehoord.

~xbeam]
Met wireless mesh refereer ik naar 802.11s. Nodes hoeven niet met alle paden draadloos verbonden te zijn en meestal is er maar 1 link omhoog (naar het beste pad)
https://www.cwnp.com/uplo..._mesh_networking_v1-0.pdf

Daarnaast als er nieuwe WiFi protocol wordt ingevoerd worden alle leden van de alliantie verplicht deze met een update aan hun hardware drivers toe te voegen. Wat betekent dat elke WiFi chip in een Accespoint over deze magische functie beschikt.

Het gaat mij er om dat dat die mesh setjes niets anders doen dan 3 lossen Accespoints die je met elkaar verbindt of te wel gewoon repeaters zijn.

we moeten gewoon stoppen die markting gehypet magische mesh (wat topologie technische niet eens mesh is ) setjes aan te prijzen.

[ Voor 63% gewijzigd door xbeam op 05-05-2022 15:43 ]

[laurens0619]

@xbeam
Waar lees jij dat die afgewezen is?

The IEEE 802.11s standard was issued in 2011 and was superseded in 2012 when it became part of the IEEE 802.11 standard that was issued in 2012

Verworpen? Hij is opgenomen. Net zo goed als 802.11krv trouwens, bv de r

It was published on July 15, 2008. IEEE 802.11r-2008 was rolled up into 802.11-2012.

Boeit ook niet want daar ging het niet over. Rest reageer ik niet meer op, geen zin in semantische discussie. Agree to disagree

[ Voor 6% gewijzigd door laurens0619 op 05-05-2022 15:06 ]

[xbeam]

laurens0619 schreef op donderdag 5 mei 2022 @ 15:03:
@xbeam
Waar lees jij dat die afgewezen is?

Je heb gelijk ik las suspended. Maar dan nog zit het in iedere standaard Accespoint en maakt die mesh setjes nog steeds bijzonder en van jouw Thuis Netwerk een mesh Netwerk. 2 of 3 repeaters blijft een daisy chain te zoal met een Wifi 4 repeater en half duplex zorgt nog steeds voor zelfde snelheid degradatie per node/repeater

Daarnaast gaat 802.11 S over authorization van Accespoint onderling en routering van data (wie is de termination router ) het is technische beschrijving van de auto uplink functie van je (unifi) Accespoint


Het heeft niet zo veel met roaming van cliënt te maken. Dat regel een cliënt/ laptop/telefoon echt zelf via 802.11krv

[...]

Verworpen? Hij is opgenomen. Net zo goed als 802.11krv trouwens,

Dat ontkent niemand en zit ook al jaren in de unifi Accespoints alleen wisselt in de controller nog wel eens van naam momenteel valt het onder de fast roaming tool set
Hier zomaar even de unifi KRACK Patch Van 4 jaar terug

[UAP] KRACK AP mode patches for 802.11r.

https://community.ui.com/...ec-4d19-83d9-8288c4e5fd14

[ Voor 97% gewijzigd door xbeam op 05-05-2022 16:36 ]

[laurens0619]

@xbeam
Fijn
Niet zoveel? Geen fluit zal Je bedoelen.
Roaming staat los van mesh

Roaming krijg je primair door correct ingestelde ssid/encr/passw. Bijkomstigheid van die multi ap setjes is dat je dit niet kunt verprutsen aangezien dat centraal ingesteld staat. Dat heeft nogmaals niets met meshing te maken. Als ik dat eerder impliceerde dat was niet de bedoeling

Secundair is 802.11krv. Het is echt secundair. Het ironische aan deze discussie is dat ubiquiti juist een van de vendors is (geweest) die het jaren heeft laten weten 802.krv te implementeren. Ze zijn er nog steeds vaag over dus geen id wat er bij welk product wel of niet in zit. De meeste setjes als deco/velop hebben dit wel

[ Voor 7% gewijzigd door laurens0619 op 05-05-2022 16:17 ]

[xbeam]

laurens0619 schreef op donderdag 5 mei 2022 @ 16:07:
@xbeam
Fijn
Niet zoveel? Geen fluit zal Je bedoelen.
Roaming staat los van mesh

Roaming krijg je primair door correct ingestelde ssid/encr/passw. Bijkomstigheid van die multi ap setjes is dat je dit niet kunt verprutsen aangezien dat centraal ingesteld staat. Dat heeft nogmaals niets met meshing te maken. Als ik dat eerder impliceerde dat was niet de bedoeling

Fijn dan zijn we er uit de dat dat hele marking gehyped mesh onzin is en dat je het zelfde bereikt met elke willekeurige WiFi Accespoint die wordt ingezet als repeater

Secundair is 802.11krv. Het is echt secundair. Het ironische aan deze discussie is dat ubiquiti juist een van de vendors is (geweest) die het jaren heeft laten weten 802.krv te implementeren. Ze zijn er nog steeds vaag over dus geen id wat er bij welk product wel of niet in zit. De meeste setjes als deco/velop hebben dit wel

Dit bedoelde ik met met brakke unifi implementatie.Maar daarom snapte ik jouw eerder conclusie ook niet dat unifi goed aangeschreven staan van wegen roaming.

Maar volgens mij doen ze die onduidelijkheid en brakke implementatie bewust. En zijn betwist eigen implementatie aanpassingen juist met als doel het creëren van incompatibiliteit met andere merken accespoints. Netzo als dat hun SDN implantatie van het openflow protocol het universele stuk voor gebruik van hardware van 3e mist zo dat geen andere SDN hardware kan gebruiken in je netwerk en unifi hardware niet een in thirt party omgeving kan adopteren. Dat is lijn met weigeren de protect cameras en deurbel en sloten te voorzien van het universal is Onvif aansturing protocol of HomeKit/Google integratie omdat mixen hardware mogelijk maakt.

[ Voor 64% gewijzigd door xbeam op 05-05-2022 18:50 ]

[lolgast]

Tijd om via DM te bekvechten?

Ik ben echt geen fan van alle keuzes die Ubiquiti maakt met de Unifi lijn en dat mag best benoemd worden, maar jullie nemen met zijn tweeën een heel topic over met een non-discussie

[Stefke]

Ik zat al een tijdje met een schuin oog te kijken naar een USW LITE 8 POE, maar die blijkt helemaal niet meer leverbaar en Ubiquity lijkt niet echt een alternatief te hebben.
De US-8-60W lijkt nog wel te krijgen maar vanwege de warmteontwikkeling die liever niet.

Ik kan natuurlijk een ander merk kijken, maar dan is er geen integratie (vraag is of ik dat voor dit geval nodig heb, switch in onze tuinhuis garage waarvan ik verwacht dat 8 genoeg is (4 poe nodig). Er ligt nu een oude 8p switch zonder poe, vandaar de vervanging

Bijv. pricewatch: Linksys LGS108P
Stuk goedkoper ook, maar toch. Is er vanuit Ubi niks hiervoor?

Ik zou ook 2x Ubiquiti UniFi Switch Flex Mini (per stuk) kunnen nemen, ook niet duur en die kan ik voeden met POE vanuit het huis (daar heb ik een Unify lite 16p switch) dan heb ik geen poe in het tuinhuis beschikbaar

[ Voor 17% gewijzigd door Stefke op 05-05-2022 17:13 ]

[jurroen]

Stefke schreef op donderdag 5 mei 2022 @ 17:08:


Ik zou ook 2x Ubiquiti UniFi Switch Flex Mini (per stuk) kunnen nemen, ook niet duur en die kan ik voeden met POE vanuit het huis (daar heb ik een Unify lite 16p switch) dan heb ik geen poe in het tuinhuis beschikbaar

De standaard Flex heeft PoE passthrough - misschien interessant om eens te bekijken?

[To_Tall]

@Stefke ik heb al 5 jaar de usw-8-60w hangen in onze schuur tegen het plafond aan.

Ja bij mij zat het er ook wel in dat het in de zomer te warm zou worden.

Maar nooit problemen mee gehad. Hij draait nog steeds. Zal hem wel een keer moeten vervangen bij defect of support.

[Stefke]

@To_Tall die is ook nergens op voorraad

jurroen schreef op donderdag 5 mei 2022 @ 19:33:
[...]


De standaard Flex heeft PoE passthrough - misschien interessant om eens te bekijken?

Bedoel je deze?
Daar heb ik te weinig poorten mee, ik zou er nog wel zo'n flex mini naast kunnen zetten.
edit: en ik heb 802.3at PoE+ nodig volgens mij (camera's)
edit2: en ook nergens te krijgen (niet via tweakers shops iig)


edit: op de site van Ubiquiti staat expliciet "sold out". Zijn die dingen EOL of gewoon niet te krijgen agv chiptekorten etc?

[ Voor 25% gewijzigd door Stefke op 05-05-2022 21:57 ]

[Tonne]

Stefke schreef op donderdag 5 mei 2022 @ 21:41:
@To_Tall die is ook nergens op voorraad

[...]

Bedoel je deze?
Daar heb ik te weinig poorten mee, ik zou er nog wel zo'n flex mini naast kunnen zetten.
edit: en ik heb 802.3at PoE+ nodig volgens mij (camera's)
edit2: en ook nergens te krijgen (niet via tweakers shops iig)


edit: op de site van Ubiquiti staat expliciet "sold out". Zijn die dingen EOL of gewoon niet te krijgen agv chiptekorten etc?

Chip tekorten. Zeker voor die lijn. Hopelijk verbetert dat snel

[m3gA]

nero355 schreef op dinsdag 3 mei 2022 @ 23:49:
[...]

Vergeet de 2.4 GHZ IoT Clients niet!


[...]


[...]

Mensen leren ook maar niet dat het grote bedrijf waar ze zo fantastisch fanboy/fangirl van zijn eigenlijk geen fuck om hen geeft als het eenmaal zover komt dat ze serieuze problemen ervaren met het produkt/de produkten van dat bedrijf!

De manier waarop Ubiquiti de laatste jaren met de community omgaat, laat wel zien hoe ze er tegenwoordig instaan. Denk dat mensen nog te veel vasthouden aan het oude Ubiquiti. Dat is er al lang niet meer.

[Stefke]

Tonne schreef op donderdag 5 mei 2022 @ 23:04:
[...]

Chip tekorten. Zeker voor die lijn. Hopelijk verbetert dat snel

Wat is dan slim om te doen, want ik moet toch wel dringend een aantal (3 minimaal) POE poorten hebben in het tuinhuis ivm beveiligingscamera's (in de afgelopen weken is hier in de buurt enkele keren ingebroken).

Ik heb een
- USG-3p
- USW-Lite-16-PoE
- 2x UAP-AC-Lite
- 1x UAP-AC-LR

De 16p switch doet alle vaste bekabeling in huis. Maar ik moet nu dus een oude 8p switch vervangen in onze tuinhuis/garage omdat ik daar POE moet hebben.
Tuinhuis/garage is nog in aanbouw, daar komt een thuiskantoor in.

Mijn voorkeur heeft om er niet een apparaat náást te zetten (dubbel stroomverbruik) als ik met een kleine investering 1 apparaatje nodig heb, vandaar dat ik een Unify 8p Poe lite switch wilde halen; niet verkrijgbaar.

Ik kan wachten tot ze er weer zijn, maar tot die tijd kan ik mijn camera's niet laten werken.

Ik kan een ander merk nemen, een unmanaged switch (1/3 van de prijs van een Unify 8p lite), maar dat integreert verder niet in mijn Unify netwerk.

Nu moet ik zeggen; ik heb me nog te weinig kunnen verdiepen in de optimalisatie van mijn netwerk. Waarom zou ik een Unify switch moeten hebben?

Ik wil op termijn - als ik meer tijd heb - wel bepaalde scheiding aanbrengen in mijn netwerk (domotica, camera's, internet), kan ik dan nog wel die opzet doorvoeren in de verdeling van de 8 poorten in het thuiskantoor als ik daar een unmanaged switch tussen zet?

Kan iemand me daar in helpen?

[ApC_IcE]

Stefke schreef op vrijdag 6 mei 2022 @ 08:55:
[...]

Wat is dan slim om te doen, want ik moet toch wel dringend een aantal (3 minimaal) POE poorten hebben in het tuinhuis ivm beveiligingscamera's (in de afgelopen weken is hier in de buurt enkele keren ingebroken).

Ik heb een
- USG-3p
- USW-Lite-16-PoE
- 2x UAP-AC-Lite
- 1x UAP-AC-LR

De 16p switch doet alle vaste bekabeling in huis. Maar ik moet nu dus een oude 8p switch vervangen in onze tuinhuis/garage omdat ik daar POE moet hebben.
Tuinhuis/garage is nog in aanbouw, daar komt een thuiskantoor in.

Mijn voorkeur heeft om er niet een apparaat náást te zetten (dubbel stroomverbruik) als ik met een kleine investering 1 apparaatje nodig heb, vandaar dat ik een Unify 8p Poe lite switch wilde halen; niet verkrijgbaar.

Ik kan wachten tot ze er weer zijn, maar tot die tijd kan ik mijn camera's niet laten werken.

Ik kan een ander merk nemen, een unmanaged switch (1/3 van de prijs van een Unify 8p lite), maar dat integreert verder niet in mijn Unify netwerk.

Nu moet ik zeggen; ik heb me nog te weinig kunnen verdiepen in de optimalisatie van mijn netwerk. Waarom zou ik een Unify switch moeten hebben?

Ik wil op termijn - als ik meer tijd heb - wel bepaalde scheiding aanbrengen in mijn netwerk (domotica, camera's, internet), kan ik dan nog wel die opzet doorvoeren in de verdeling van de 8 poorten in het thuiskantoor als ik daar een unmanaged switch tussen zet?

Kan iemand me daar in helpen?

Tijdelijk een poeinjector?

[To_Tall]

Stefke schreef op vrijdag 6 mei 2022 @ 08:55:
[...]

Wat is dan slim om te doen, want ik moet toch wel dringend een aantal (3 minimaal) POE poorten hebben in het tuinhuis ivm beveiligingscamera's (in de afgelopen weken is hier in de buurt enkele keren ingebroken).

Ik heb een
- USG-3p
- USW-Lite-16-PoE
- 2x UAP-AC-Lite
- 1x UAP-AC-LR

De 16p switch doet alle vaste bekabeling in huis. Maar ik moet nu dus een oude 8p switch vervangen in onze tuinhuis/garage omdat ik daar POE moet hebben.
Tuinhuis/garage is nog in aanbouw, daar komt een thuiskantoor in.

Mijn voorkeur heeft om er niet een apparaat náást te zetten (dubbel stroomverbruik) als ik met een kleine investering 1 apparaatje nodig heb, vandaar dat ik een Unify 8p Poe lite switch wilde halen; niet verkrijgbaar.

Ik kan wachten tot ze er weer zijn, maar tot die tijd kan ik mijn camera's niet laten werken.

Ik kan een ander merk nemen, een unmanaged switch (1/3 van de prijs van een Unify 8p lite), maar dat integreert verder niet in mijn Unify netwerk.

Nu moet ik zeggen; ik heb me nog te weinig kunnen verdiepen in de optimalisatie van mijn netwerk. Waarom zou ik een Unify switch moeten hebben?

Ik wil op termijn - als ik meer tijd heb - wel bepaalde scheiding aanbrengen in mijn netwerk (domotica, camera's, internet), kan ik dan nog wel die opzet doorvoeren in de verdeling van de 8 poorten in het thuiskantoor als ik daar een unmanaged switch tussen zet?

Kan iemand me daar in helpen?

Je zou een poe injector tijdelijk kunnen gebruiken. Blijft alles toch werken.

Een unmanaged switch is veelal niet VLAN aware. Daarmee kan je dus geen apparaten aansluiten die op een ander VLAN moeten komen.

[Stefke]

ApC_IcE schreef op vrijdag 6 mei 2022 @ 09:00:
[...]


Tijdelijk een poeinjector?

Die heb ik als het goed is een paar liggen ergens (geleverd bij die APs, 1 is nu in gebruik voor de AP LR in de garage)...misschien eens goed zoeken

[Goof2000]

Tonne schreef op donderdag 5 mei 2022 @ 23:04:
[...]

Chip tekorten. Zeker voor die lijn. Hopelijk verbetert dat snel

Ik zou een monitoring tool (zijn diverse voor) op de pagina van de USW LITE 8 POE zetten. Ik weet vrij zeker dat ik hem 1 of 2 weken geleden nog even op voorraad heb gezien. (zonder een mail te hebben gehad dat hij weer op voorraad was, en na een paar uur was het blijkbaar weer op)

Ik ben zelf in de markt voor een Switch 24 PoE die is nu weer op voorraad, maar heb nog een bestelling bij amazon.de staan voor 40 euro minder (375 euro) als waar deze nu bij Ubiquiti voor staat. Alleen de levertijd is nog steeds onbekend bij Amazon. (ik denk dat ze hem gaan annuleren als ik naar de prijzen op andere websites van de Switch 24 PoE kijk)

Ik heb nu een Switch Lite 16 PoE, 2 Flex mini's, U6 Mesh en een Wifi6 Pro en ben daar erg tevreden over. In een nieuwbouwhuis uit 2016 waarbij de U6 Mesh op de BG staat en de Wifi 6 Pro op zolder (2de verdieping) aan het plafond hangt. Opzich in hele huis wifi alleen de 1ste verdieping zit is de wifi redelijk en zit eraan te denken voor nog een U6 Mesh. Moet ik alleen nog het vermogen van andere 2 wifi stations naar beneden brengen.
In de garage naast het huis wil ik ook nog wifi hebben, daar ligt al een kabel voor de camera's dus daar komt een Switch Flex met een WiFi 6 Lite. (staat voor volgend jaar in de planning)

Nu volg ik het topic al een tijdje en twijfelde of ik nog naar een Dream Machine zou overstappen om all the way te gaan met Ubiquiti, maar dat gaat nog even in de ijskast. (vind het sowieso heel veel geld en de laatste discussie kan ik het mezelf niet rechtvaardigen)
Ik heb nu een MikroTik RB750Gr3 icm een 1gb glasvezellijn (rekam) met Netrebel.

Nu wil ik in de toekomst aan de slag gaan met Vlan's en ik heb me ingelezen en dat zou kunnen met die Mikrotik icm Ubiquiti netwerk apparatuur. Alleen vraag ik me af of die het nog gaat trekken of dat ik moet overstappen op de RB5009UG+S+IN of dat ik toch voor iets zelfbouw ga voor de firewall, dns afhandeling, etc. (Moet ik me nog verder voor gaan inlezen, dit staat in de planning voor 2023 of 2024) Ik heb een GPON die de glasvezel omzet naar een UTP stekker.

[RobertMe]

Stefke schreef op vrijdag 6 mei 2022 @ 09:04:
[...]

Die heb ik als het goed is een paar liggen ergens (geleverd bij die APs, 1 is nu in gebruik voor de AP LR in de garage)...misschien eens goed zoeken

Wel even goed opletten. De AC-LR en AC-Lite werkten vroeger op "passive 24V", een custom PoE variant van Ubiquiti. Later zijn ze ook 802.3af gaan ondersteunen, maar ik meen begrepen te hebben dat ze ook toen nog geleverd werden met passive 24V (wellicht tijdelijk om de oude voorraad weg te werken?). En zo'n passive 24V injector is mogelijk niet compatible met de camera's. Wat zal leiden tot wat magische zwarte rook uit de camera's. Controleer dus goed welke injectors je hebt en/of de camera's ook overweg kunnen met passive 24V.

[Tonne]

Stefke schreef op vrijdag 6 mei 2022 @ 08:55:
[...]

Wat is dan slim om te doen, want ik moet toch wel dringend een aantal (3 minimaal) POE poorten hebben in het tuinhuis ivm beveiligingscamera's (in de afgelopen weken is hier in de buurt enkele keren ingebroken).

Ik heb een
- USG-3p
- USW-Lite-16-PoE
- 2x UAP-AC-Lite
- 1x UAP-AC-LR

De 16p switch doet alle vaste bekabeling in huis. Maar ik moet nu dus een oude 8p switch vervangen in onze tuinhuis/garage omdat ik daar POE moet hebben.
Tuinhuis/garage is nog in aanbouw, daar komt een thuiskantoor in.

Mijn voorkeur heeft om er niet een apparaat náást te zetten (dubbel stroomverbruik) als ik met een kleine investering 1 apparaatje nodig heb, vandaar dat ik een Unify 8p Poe lite switch wilde halen; niet verkrijgbaar.

Ik kan wachten tot ze er weer zijn, maar tot die tijd kan ik mijn camera's niet laten werken.

Ik kan een ander merk nemen, een unmanaged switch (1/3 van de prijs van een Unify 8p lite), maar dat integreert verder niet in mijn Unify netwerk.

Nu moet ik zeggen; ik heb me nog te weinig kunnen verdiepen in de optimalisatie van mijn netwerk. Waarom zou ik een Unify switch moeten hebben?

Ik wil op termijn - als ik meer tijd heb - wel bepaalde scheiding aanbrengen in mijn netwerk (domotica, camera's, internet), kan ik dan nog wel die opzet doorvoeren in de verdeling van de 8 poorten in het thuiskantoor als ik daar een unmanaged switch tussen zet?

Kan iemand me daar in helpen?

Red je het ook met een switch flex? Waarbij de voeding dus eigenlijk uit je 16 lite komt?

[Stefke]

@Tonne welke bedoel je daar precies mee? werd hierboven al genoemd, maar de flex die ik kon vinden weet ik niet of dat dezelfde is, en die was ook niet verkrijgbaar

RobertMe schreef op vrijdag 6 mei 2022 @ 09:11:
[...]

Wel even goed opletten. De AC-LR en AC-Lite werkten vroeger op "passive 24V", een custom PoE variant van Ubiquiti. Later zijn ze ook 802.3af gaan ondersteunen, maar ik meen begrepen te hebben dat ze ook toen nog geleverd werden met passive 24V (wellicht tijdelijk om de oude voorraad weg te werken?). En zo'n passive 24V injector is mogelijk niet compatible met de camera's. Wat zal leiden tot wat magische zwarte rook uit de camera's. Controleer dus goed welke injectors je hebt en/of de camera's ook overweg kunnen met passive 24V.

ik heb één AP lite die alleen op een Ubiquity injector werkt, de LR werkt wel op de normale (andere AP lite ook). Maar idd, goed dat je t zegt, mijn camera's doen t daar niet op (die draaien als t goed is op "af")

To_Tall schreef op vrijdag 6 mei 2022 @ 09:03:
[...]

Je zou een poe injector tijdelijk kunnen gebruiken. Blijft alles toch werken.

Een unmanaged switch is veelal niet VLAN aware. Daarmee kan je dus geen apparaten aansluiten die op een ander VLAN moeten komen.

Dus als ik daar een Unify AP op aansluit (de AP dus via een 3e partij switch op mijn Unify 16p lite) dat gaat dan dus niet lekker?

[ Voor 19% gewijzigd door Stefke op 06-05-2022 10:01 ]

[To_Tall]

Je kan gewoon de AP aansluiten en hij zal ook werken. Het is alleen dat je geen vlan tag kan gebruiken. Ik heb hier alle ui apparatuur op 1 VLAN staan. Maar mijn clients en iot op een ander VLAN. Dat zal dan niet gaan.

Een unmanaged switch begrijpt alleen het verkeer wat binnen komt en niet de VLAN van andere netwerken. Komt er dus tagged verkeer binnen op VLAN 11 op je switch binnen zullen alle clients op deze switch ook alleen kunnen connected op VLAN 11

[Roy Batty]

Stefke schreef op vrijdag 6 mei 2022 @ 08:55:
[...]

Wat is dan slim om te doen, want ik moet toch wel dringend een aantal (3 minimaal) POE poorten hebben in het tuinhuis ivm beveiligingscamera's (in de afgelopen weken is hier in de buurt enkele keren ingebroken).

Je zou tijdelijk deze kunnen inzetten; die heb ik ook een hele tijd voor mijn camera`s gebruikt icm Unifi, werkt prima. Later heb ik die vervangen idd door een USW-Flex en nu liggen ze in de kast als reserve voor het geval een switch uitvalt en ik toch PoE nodig heb om bv AP`s actief te houden.

[Stefke]

Roy Batty schreef op vrijdag 6 mei 2022 @ 11:06:
[...]


Je zou tijdelijk deze kunnen inzetten; die heb ik ook een hele tijd voor mijn camera`s gebruikt icm Unifi, werkt prima. Later heb ik die vervangen idd door een USW-Flex en nu liggen ze in de kast als reserve voor het geval een switch uitvalt en ik toch PoE nodig heb om bv AP`s actief te houden.

MIsschien doe ik dat en hou ik t daarbij, plaats ik deze naast mijn oude 8p (omdat 5p te weinig is). Heb voorlopig toch geen tijd om me te verdiepen in meerdere Vlans

[Tonne]

Stefke schreef op vrijdag 6 mei 2022 @ 09:58:
@Tonne welke bedoel je daar precies mee? werd hierboven al genoemd, maar de flex die ik kon vinden weet ik niet of dat dezelfde is, en die was ook niet verkrijgbaar

[...]

Je hebt gelijk, ook niet leverbaar. Wat slecht dit zeg

[Stefke]

Roy Batty schreef op vrijdag 6 mei 2022 @ 11:06:
[...]


Je zou tijdelijk deze kunnen

Ik heb inderdaad deze maar gekocht

[carlob]

Goof2000 schreef op vrijdag 6 mei 2022 @ 09:08:
[...]

Ik zou een monitoring tool (zijn diverse voor)…

Interessant en nuttig. Maar voordat ik tien verkeerde tools ga testen, heeft iemand ervaring met een goede (gratis) tool?

[Airw0lf]

carlob schreef op vrijdag 6 mei 2022 @ 13:23:
[...]


Interessant en nuttig. Maar voordat ik tien verkeerde tools ga testen, heeft iemand ervaring met een goede (gratis) tool?

Mijn € 0,50:
Onder Windows is PRTG wel een goede. En onder Linux is Nagios een meer dan prima oplossing. Beiden zijn gratis voor hetgeen je ermee wil: een webpagina opvragen en te controleren op zijn inhoud.

Omdat dit topic over UB-netwerk apparatuur gaat (en niet over monitoring tools): graag een DM als je hier meer over wil weten.

[ Voor 16% gewijzigd door Airw0lf op 06-05-2022 13:38 ]

[Will_M]

Airw0lf schreef op vrijdag 6 mei 2022 @ 13:35:
[...]


Mijn € 0,50:
Onder Windows is PRTG wel een goede. En onder Linux is Nagios een meer dan prima oplossing. Beiden zijn gratis voor hetgeen je ermee wil: een webpagina opvragen en te controleren op zijn inhoud.

Omdat dit topic over UB-netwerk apparatuur gaat (en niet over monitoring tools): graag een DM als je hier meer over wil weten.

PRTG is inderdaad een briljante SNMP Trap Tool welke je tot 100 'nodes' gratis kunt gebruiken, maar......

Volgens mij zoekt @carlob een 'tool' welke de actuele voorraad status bij / van Ubiquiti apparatuur kan checken bij diverse leveranciers

[rally]

Will_M schreef op vrijdag 6 mei 2022 @ 13:41:
[...]


PRTG is inderdaad een briljante SNMP Trap Tool welke je tot 100 'nodes' gratis kunt gebruiken, maar......

Volgens mij zoekt @carlob een 'tool' welke de voorraad status bij / van Ubiquiti apparatuur kan checken bij diverse leveranciers

Volgens mij kan je daar ook UptimeRobot voor gebruiken...
Gewoon een monitor aanmaken op keyword van de website.

https://blog.uptimerobot....k-in-stock-notifications/

[Airw0lf]

Will_M schreef op vrijdag 6 mei 2022 @ 13:41:
[...]


PRTG is inderdaad een briljante SNMP Trap Tool welke je tot 100 'nodes' gratis kunt gebruiken, maar......

Volgens mij zoekt @carlob een 'tool' welke de voorraad status bij / van Ubiquiti apparatuur kan checken bij diverse leveranciers

Yup - I know:
PRTG: https://www.paessler.com/...http_full_web_page_sensor
Nagios: https://linux.101hacks.com/unix/check-http/

Kost alleen ff wat moeite om het draaiend te krijgen...

[carlob]

Will_M schreef op vrijdag 6 mei 2022 @ 13:41:
[...]

Volgens mij zoekt @carlob een 'tool' welke de actuele voorraad status bij / van Ubiquiti apparatuur kan checken bij diverse leveranciers

Klopt. Ik had iets meer tekst in de quote moeten laten staan…

Eigenlijk zoek ik dus een tool die ziet of een product in de Ubiquiti store weer beschikbaar is. De notificatie-mail van Ubiquiti zelf komt soms net te laat.

[Will_M]

carlob schreef op vrijdag 6 mei 2022 @ 14:49:
[...]


Klopt. Ik had iets meer tekst in de quote moeten laten staan…

Eigenlijk zoek ik dus een tool die ziet of een product in de Ubiquiti store weer beschikbaar is. De notificatie-mail van Ubiquiti zelf komt soms net te laat.

Die mail van Ubiquiti wordt alleen verstuurd naar de mensen welke in de cue staan op basis van het het aantal beschikbare apparaten waarbij er op volgorde van 'registreren' gewerkt wordt.

Stel dat Ubiquiti nú 100 apparaten van 'Type 123' beschikbaar heeft dan worden de éérste 100 mensen uit de cue voor apparaat 'Type-123' aangeschreven middels een mailtje. Op zich zou dat principe gewoon goed kunnen werken maar: Van die 100 mensen welke op dat moment een mailtje krijgen gaat (waarschijnlijk?) méér dan de helft daarvan ook weer elders op diverse fora melden dat er weer voorraad is.... Met als gevolg dat de voorraad weer wég is voor dat jij ooit hebt kunnen reageren op 'jouw' persoonlijke mailtje

[bauk]

Zo, voor diegenen die mijn rant nog kunnen herinneren aangaande de upgrade naar 7.x.x, het is mij deze week gelukt hoor. Helemaal vanaf scratch, usg resetten, firmware, VLAN op internet, gelijk set-inform (2 keer) en dan handmatig de DNS servers naar 1.1.1.1 en 9.9.9.9 (denk dat die wel ok zijn...). En daarna de rest adopten.

Het kan dus wel, met veel geduld en veel pushen .

Reden was dat m'n 16-POE raar gedrag vertoonde en ik toch daar iets mee moest (kijken of nieuwe firmware werkt)... Toch blijf ik met de volgende fout zitten en misschien hebben jullie hier een Tweakers-waardige oplossing voor:

code:

May  5 11:11:01 CoreSwitch daemon.info switch: BOXSERV: Error 17 occurred reading thermal sensor 5 data
May  5 11:11:03 CoreSwitch daemon.info switch: BOXSERV: Error 17 occurred reading thermal sensor 2 data
May  5 11:11:03 CoreSwitch daemon.info switch: BOXSERV: Error 17 occurred reading thermal sensor 3 data
May  5 11:11:03 CoreSwitch daemon.info switch: BOXSERV: Error 17 occurred reading thermal sensor 4 data

En dan reset de switch de POE op de poorten en heb ik een klein minuutje geen internet via de access points en de flex mini op zolder. Frequentie is eens per dag, soms twee keer.

Irritant, maar snel vervangen zit er niet in (levertijden...), nieuwe kopen zit er niet in en garantie waarschijnlijk ook niet (net over de 2 jaar uit bij eerste voorkomen van issue).

Tips?

[JB]

Kan iemand me op weg helpen met het volgende;

VLAN opzetten om domotica/smart spullen te isoleren van het normale LAN? Ik had nu een guest WiFi aangemaakt voor al deze spullen zodat ze alleen "naar buiten konden" maar ik loop nu tegen wat uitdagingen aan icm een Philips Hue Bridge. Deze gaat op LAN ipv WiFi en lokale discovery in het WiFi netwerk doet het niet obv guest spelregels. Dus isoleren is nu beter denk ik.

De Hue Bridge zit op een Unifi Switch-8. De overige spullen dus op WiFi. Ik heb geen USG maar een ERX als router.

[ Voor 3% gewijzigd door JB op 06-05-2022 15:26 ]

[Will_M]

JB schreef op vrijdag 6 mei 2022 @ 15:26:
Kan iemand me op weg helpen met het volgende;

VLAN opzetten om domotica/smart spullen te isoleren van het normale LAN? Ik had nu een guest WiFi aangemaakt voor al deze spullen zodat ze alleen "naar buiten konden" maar ik loop nu tegen wat uitdagingen aan icm een Philips Hue Bridge. Deze gaat op LAN ipv WiFi en lokale discovery in het WiFi netwerk doet het niet obv guest spelregels. Dus isoleren is nu beter denk ik.

De Hue Bridge zit op een Unifi Switch-8. De overige spullen dus op WiFi. Ik heb geen USG maar een ERX als router.

Wie of wat is de 'Gateway' van je netwerk / VLAN? Die Gateway bepaalt wie er met welke devices mag babbelen waarbij de 'gasten' niet en liefst ook nooit (direct) met elkaar mogen babbelen op een gasten netwerk.

[JB]

Will_M schreef op vrijdag 6 mei 2022 @ 15:43:
[...]


Wie of wat is de 'Gateway' van je netwerk / VLAN? Die Gateway bepaalt wie er met welke devices mag babbelen waarbij de 'gasten' niet en liefst ook nooit (direct) met elkaar mogen babbelen op een gasten netwerk.

De ERX. Die verzorgt ook de DHCP.

Ik zoek dus een juiste oplossing om de gasten de isoleren. Zowel via een kabeltje en/of WiFi.

Is deze goed om te gebruiken?

https://vninja.net/2019/0...olated-networks-ubiquiti/

Dan creëer ik volgens mij een los VLAN incl DHCP server voor alleen de "gasten"? Dan moet ik op de switch nog de Hue Bridge port taggen toch?

edit:
Hmm DHCP gaat niet zonder USG zie ik

[ Voor 8% gewijzigd door JB op 06-05-2022 15:48 ]

[Skynett]

Kijk nou:

Dit is wel weer iets heel nieuws!

[RobertMe]

Skynett schreef op vrijdag 6 mei 2022 @ 16:00:
Kijk nou:
[YouTube: UInnovations: UniFi Dream Wall [Early Access]]

Dit is wel weer iets heel nieuws!

De hoeveelste iteratie is dit? Volgens mij heeft @xbeam meer dan een jaar terug hier al eens gepost over zo'n type apparaat. Als in: een wall mounted gateway. Deze lijkt dan wel (veel) meer features te hebben (grotere switch denk ik, de HDD, meer software features met Protect en Talk etc), maar het idee is hetzelfde.

Weet in ieder geval niet wat ik er van moet vinden. Waar ga je dit als thuisgebruiker plaatsen? Toch niet midden in de woonruimte? En waar ga je dit als MKBer plaatsen? Waarschijnlijk net "zoals thuis" in een meterkast of technische ruimte. Dat hele "wall" is IMO dan nogal nutteloos.

[Tylen]

Skynett schreef op vrijdag 6 mei 2022 @ 16:00:
Kijk nou:
[YouTube: UInnovations: UniFi Dream Wall [Early Access]]

Dit is wel weer iets heel nieuws!

Wow, ik vind hem vet.

[ApC_IcE]

Skynett schreef op vrijdag 6 mei 2022 @ 16:00:
Kijk nou:
[YouTube: UInnovations: UniFi Dream Wall [Early Access]]

Dit is wel weer iets heel nieuws!

Ik vind hem ook wel tof!
Of het nou mijn rack op zolder vervangt?

Moet ik alle UTP weer naar beneden trekken? Vind het een tof ding maar eerst eens zien wat hij gaat kosten.

[Ethirty]

Ik wilde het net gaan posten. Moest heel hartelijk lachen om wat ze nu weer bedacht hebben.

Hoezo zijn ze hun focus kwijt?

De nerd in mij wil hem wel, maar inzetten bij bedrijven. "Kan de hele organisatie aan" - er zitten 16 ethernetpoorten in en ze hebben nog altijd geen echte firewall vziw. Hoe dan

Hoe ga je al die kabels door die muur heen halen, een 80mm gat en dan aan de achterkant een 19" rack met patchpunten?

[ Voor 16% gewijzigd door Ethirty op 06-05-2022 16:34 ]

[esky]

Skynett schreef op vrijdag 6 mei 2022 @ 16:00:
Kijk nou:
[YouTube: UInnovations: UniFi Dream Wall [Early Access]]

Dit is wel weer iets heel nieuws!

Ben benieuwd wat ze er in EA voor gaan vragen en wat de specs zijn.

Is het een UXG, UNVR, Switch Mission Critical en nog wat in 1 en kost het €€€
Of is het een UDM Pro met display en wat extra poorten en kost het €€

[JB]

Inmiddels een VLAN aangemaakt op de ERX incl DHCP server. Op de Unifi controller een nieuw network aangemaakt en daar de SSID voor IoT aan gehangen.

De devices komen nu allemaal keurig met een DHCP in nieuwe VLAN Op de Unifi switch port 4 (Hue Bridge) getagged op VLAN en die krijgt nu ook keurig een DHCP in dat segment.

Laatste stap is dan volgens mij dat het zaakje elkaar niet meer kan bereiken? Onderling is dan nog helemaal nice! Weet iemand hoe ik verkeer tussen die VLANs blokkeer?

[Polyphemus]

Dream Wall $799 en de Dream Wall Pro $1499 in EA

[xbeam]

RobertMe schreef op vrijdag 6 mei 2022 @ 16:09:
[...]

De hoeveelste iteratie is dit? Volgens mij heeft @xbeam meer dan een jaar terug hier al eens gepost over zo'n type apparaat. Als in: een wall mounted gateway. Deze lijkt dan wel (veel) meer features te hebben (grotere switch denk ik, de HDD, meer software features met Protect en Talk etc), maar het idee is hetzelfde.

Ik zal 15 juli 2021 er eens bij pakken
xbeam in "[Ubiquiti-Netwerkapparatuur] Ervaringen & Discussie - Deel 4"

Het enige wat ik verwacht zijn wat (hotel) deursloten en sensoren voor acces en protect en nieuwe wall mounted CloudKey/solaraccupack.

[ Voor 4% gewijzigd door xbeam op 07-05-2022 10:19 ]

[Slonzo]

JB schreef op vrijdag 6 mei 2022 @ 17:23:
Laatste stap is dan volgens mij dat het zaakje elkaar niet meer kan bereiken? Onderling is dan nog helemaal nice! Weet iemand hoe ik verkeer tussen die VLANs blokkeer?

Je blokkeert geen verkeer tussen VLAN's maar tussen subnets. Dus zorgen dat verkeer niet meer routed wordt tussen RFC-1918 ranges door ze in je firewall te blokkeren:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

[Slonzo]

Polyphemus schreef op vrijdag 6 mei 2022 @ 17:50:
Dream Wall $799 en de Dream Wall Pro $1499 in EA

Wat is de doelgroep van dit product tegen die prijzen?
Veel te duur voor consumenten, veel te beperkt voor KMO.

[-Jaap-io]

Voor de inrichting van vlan’s heb ik deze gevolgd YouTube: 05 - IoT Network Setup - UDM-Pro Complete Setup 2021

[xbeam]

Slonzo schreef op vrijdag 6 mei 2022 @ 19:54:
[...]

Wat is de doelgroep van dit product tegen die prijzen?
Veel te duur voor consumenten, veel te beperkt voor KMO.

Amerikaanse home builders en (actief) ubnt forum lid

***Jantjes, Dat is snel! Ik kon er wel 1 gebruiken staat mooi in de meterkast naast de alarm kasten tegen de muur in plaats van die 9U zwarte kast

[ Voor 57% gewijzigd door xbeam op 06-05-2022 21:11 ]

[nero355]

MAdD schreef op woensdag 4 mei 2022 @ 12:43:
misschien een domme vraag... maar ik merk dat er vanuit USA heel veel pogingen zijn die door de UDMB worden geblokkeerd.

Nu wil ik voor deze ip reeks een firewall rule maken (192.241.220.0 /24-192.241.221.0/24)
Alleen wordt 192.241.2200/24 niet geaccepteerd in port profile page.

Iemand een idee hoe ik deze 2 reeksen (192.241.220.0 /24-192.241.221.0/24) direct in de firewall kan blokkeren?

Bespaar je de moeite zou ik zeggen : ernstoud in "[Caiway Glasvezel] Ervaringen & Discussie - Deel 2"

abusimbal schreef op woensdag 4 mei 2022 @ 12:55:
De reeks van 192.241.220 zijjn van cloudinfrastructuurprovider DigitalOcean.

En daar zijn er veel meer van dus daar is geen beginnen aan en je hebt ook nog eens de kans dat je nuttige dingen blokkeert!

laurens0619 schreef op donderdag 5 mei 2022 @ 09:55:
Maar zijn die problemen op die clients dan nu opgelost omdat er krv is?
Uit mijn testen kwam (helaas) iets anders. Benieuwd naar jouw testresultaten

Neemt niet weg dat standaarden goed zijn maar het nare is dat
1. krv kan tegenwerken als je client het niet goed kan

Helemaal mee eens!

Daarbij blijft het super vaag of unifi uberhaupt wel krv doen. Zover ik weet blijft dat onbekend/nee (op eigen varianten/workarounds na)

laurens0619 schreef op donderdag 5 mei 2022 @ 16:07:
Het ironische aan deze discussie is dat ubiquiti juist een van de vendors is (geweest) die het jaren heeft laten weten 802.krv te implementeren.
Ze zijn er nog steeds vaag over dus geen id wat er bij welk product wel of niet in zit.

Het heeft !! 3 !! jaar geduurd totdat Ubiquiti een fatsoenlijke vervanging voor Zero Handoff heeft toegepast in de vorm van de officiële 802.11r/k/v standaarden en die zitten nu iets van 4 jaar lang in de firmwares van alle non-EOL UAP modellen

Bron : Mijn Zero Handoff Fanboy Hersenen die dus veeeel te lang op de officiële standaarden hebben moeten wachten!

Om vervolgens te lezen dat ze vaker slecht dan goed werken, want niet alle Clients doen aan Fast Roaming op de juiste manier of snappen überhaupt wat het is...

xbeam schreef op donderdag 5 mei 2022 @ 12:28:
Wat denk je dat 802.11krv zijn?

Roaming protocollen en wat is volgens jouw client roaming support als 802.11krv dat niet is?

Hoe verklaar jij fatsoenlijk roamen in de tijd dat Ubiquiti geen 802.11r/k/v in hun firmwares had dan

IMHO gewoon op basis van het sterkste signaal met hetzelfde SSID en Security Settings

Stefke schreef op donderdag 5 mei 2022 @ 17:08:
De US-8-60W lijkt nog wel te krijgen maar vanwege de warmteontwikkeling die liever niet.

Volgens mij heeft die niet de hitte problemen die de 150 Watt versie kent

Ik kan natuurlijk een ander merk kijken, maar dan is er geen integratie (vraag is of ik dat voor dit geval nodig heb, switch in onze tuinhuis garage waarvan ik verwacht dat 8 genoeg is (4 poe nodig). Er ligt nu een oude 8p switch zonder poe, vandaar de vervanging

Bijv. pricewatch: Linksys LGS108P
Stuk goedkoper ook, maar toch. Is er vanuit Ubi niks hiervoor?

TP-Link/Netgear modellen die vaak op PE eindigen in 5 en 8-poorts uitvoering zouden je prima moeten kunnen helpen voor een tijdje :
- P betekent PoE
- E betekent Managed versie.

Desnoods tweedehands aanschaffen en voor vrijwel dezelfde prijs weer verkopen!

Stefke schreef op vrijdag 6 mei 2022 @ 08:55:
Waarom zou ik een Unify switch moeten hebben?

Voor de mooie grafiekjes in je UniFi Controller natuurlijk!

Ik wil op termijn - als ik meer tijd heb - wel bepaalde scheiding aanbrengen in mijn netwerk (domotica, camera's, internet), kan ik dan nog wel die opzet doorvoeren in de verdeling van de 8 poorten in het thuiskantoor als ik daar een unmanaged switch tussen zet?

Managed Switches zijn zo betaalbaar geworden dat ik nooit meer een Unmanaged Switch zou aanschaffen heel eerlijk gezegd

Goof2000 schreef op vrijdag 6 mei 2022 @ 09:08:
Nu volg ik het topic al een tijdje en twijfelde of ik nog naar een Dream Machine zou overstappen om all the way te gaan met Ubiquiti, maar dat gaat nog even in de ijskast. (vind het sowieso heel veel geld en de laatste discussie kan ik het mezelf niet rechtvaardigen)

Goed zo!

Ik heb nu een MikroTik RB750Gr3 icm een 1gb glasvezellijn (rekam) met Netrebel.

Nu wil ik in de toekomst aan de slag gaan met Vlan's en ik heb me ingelezen en dat zou kunnen met die Mikrotik icm Ubiquiti netwerk apparatuur. Alleen vraag ik me af of die het nog gaat trekken of dat ik moet overstappen op de RB5009UG+S+IN of dat ik toch voor iets zelfbouw ga voor de firewall, dns afhandeling, etc.

Voor zover ik [MikroTik-apparatuur] Ervaringen & Discussie goed heb begrepen :
- De RB750 kan net 1 Gbps aan met FastTrack aan.
- De RB4011 is een veel betere keuze, vooral als je die goedkoop kan vinden.
- De RB5009 is nu gewoon het model dat je moet hebben, maar de prijs is op dit moment niet wat die moet zijn en amper op voorraad helaas...

Bron : De reacties in de buurt van deze reactie => !GN!T!ON in "[MikroTik-apparatuur] Ervaringen & Discussie"

En voor DNS moet je natuurlijk gewoon [Pi-Hole] Ervaringen & discussie draaien i.c.m. https://docs.pi-hole.net/guides/dns/unbound/

bauk schreef op vrijdag 6 mei 2022 @ 15:26:
Zo, voor diegenen die mijn rant nog kunnen herinneren aangaande de upgrade naar 7.x.x, het is mij deze week gelukt hoor.

Goed bezig!

Helemaal vanaf scratch, usg resetten, firmware, VLAN op internet, gelijk set-inform (2 keer)

Dat laatste zou eigenlijk niet meer nodig moeten zijn, maar goed... Whatever works!

en dan handmatig de DNS servers naar 1.1.1.1 en 9.9.9.9 (denk dat die wel ok zijn...).

https://docs.pi-hole.net/guides/dns/unbound/

Reden was dat m'n 16-POE raar gedrag vertoonde en ik toch daar iets mee moest (kijken of nieuwe firmware werkt)... Toch blijf ik met de volgende fout zitten en misschien hebben jullie hier een Tweakers-waardige oplossing voor:

code:

May  5 11:11:01 CoreSwitch daemon.info switch: BOXSERV: Error 17 occurred reading thermal sensor 5 data
May  5 11:11:03 CoreSwitch daemon.info switch: BOXSERV: Error 17 occurred reading thermal sensor 2 data
May  5 11:11:03 CoreSwitch daemon.info switch: BOXSERV: Error 17 occurred reading thermal sensor 3 data
May  5 11:11:03 CoreSwitch daemon.info switch: BOXSERV: Error 17 occurred reading thermal sensor 4 data

En dan reset de switch de POE op de poorten en heb ik een klein minuutje geen internet via de access points en de flex mini op zolder. Frequentie is eens per dag, soms twee keer.

Welk model is het PRECIES

Irritant, maar snel vervangen zit er niet in (levertijden...), nieuwe kopen zit er niet in en garantie waarschijnlijk ook niet (net over de 2 jaar uit bij eerste voorkomen van issue).

Tips?

Voor de pricewatch: Ubiquiti UniFi Switch (16-poorts, 150W PoE+) zijn er losse voedingen tekoop, maar ik zou eerst gewoon bij Ubiquiti zeuren, want bekend probleem bij bepaalde revisies!

[JB]

Slonzo schreef op vrijdag 6 mei 2022 @ 19:52:
[...]

Je blokkeert geen verkeer tussen VLAN's maar tussen subnets. Dus zorgen dat verkeer niet meer routed wordt tussen RFC-1918 ranges door ze in je firewall te blokkeren:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

Oké daar moet ik ook weer even induiken omdat mijn kennis niet dermate is dat ik alles zo volg.

Heb ik dan een onhandige inrichting gekozen qua subnets? Ik heb nu 192.168.1.0/24 en 192.168.2.0/24 om zaken te kunnen scheiden. Deze kun je ook blokkeren van elkaar lijkt me, want 2 verschillende ranges?

Nu gebruik ik ook nog een Pihole voor DNS, dus die wordt dan ook geblocked cq geen verkeer meer mogelijk voor IoT daarna?

[Airw0lf]

JB schreef op zaterdag 7 mei 2022 @ 09:06:
[...]

Oké daar moet ik ook weer even induiken omdat mijn kennis niet dermate is dat ik alles zo volg.

Heb ik dan een onhandige inrichting gekozen qua subnets? Ik heb nu 192.168.1.0/24 en 192.168.2.0/24 om zaken te kunnen scheiden. Deze kun je ook blokkeren van elkaar lijkt me, want 2 verschillende ranges?

Nu gebruik ik ook nog een Pihole voor DNS, dus die wordt dan ook geblocked cq geen verkeer meer mogelijk voor IoT daarna?

Je kan verkeer tussen vlans blokken. Stel je iot-vlan is 192.168.123.0/24 en je reguliere wifi-gebruikers zitten in 192.168.124.0/24. Dan zou je de reguliere wifi-gebruikers toegang kunnen ontnemen tot de iot-devices; waaronder bijvoorbeeld home assistant (mocht je van zoiets gebruik maken). Als je dit combineert met specifieke tcp-poorten, dan blokker je daarmee een specieke applicatie of website.

De invulling is wel afhankelijk van de fabrikant van de router/firewall software. Ook is het zaak dat je routing op je pihole-server uitgeschakeld is. Anders schiet het niet echt op...

Pihole (het dnsmasq-deel) laat zich in een vlan met zijn vlan-specifieke dhcp-range, dns-server en default gateway. Alleen zul je daarvoor in de cli moeten klimmen in de vorm van een aanvullend dhcp-config-bestand. Dit is weer afhankelijk van het type en versie van het OS.

Eenmaal gedaan zal het dnsmasq-deel dhcp verzorgen voor het vlan. En zal je in de pihole gui kunnen zien welke ip's er uitgedeeld zijn. Ook eventuele logging en zo blijft allemaal werken.

Maar dit pihole-config-stuk is redelijk off-topic => graag een dm als je hier meer over wil weten. Afhankelijk van je omgeving heb ik eventueel ook een voorbeeld-config voor je.

[Slonzo]

JB schreef op zaterdag 7 mei 2022 @ 09:06:
Heb ik dan een onhandige inrichting gekozen qua subnets? Ik heb nu 192.168.1.0/24 en 192.168.2.0/24 om zaken te kunnen scheiden. Deze kun je ook blokkeren van elkaar lijkt me, want 2 verschillende ranges?

Alles binnen een subnet passeert niet langs de router, dus kan vrij met elkaar praten. Alles wat bij een ander subnet wil geraken, passeert langs de router. Dus als je in de firewall van de router 192.168.0.0/16 blokkeert, dan kan geen enkel subnet in de 192.168.x.x range nog met elkaar communiceren. Zie link

Ubiquiti heeft een artikel over blokkeren van inter-VLAN routing.

JB schreef op zaterdag 7 mei 2022 @ 09:06:
Nu gebruik ik ook nog een Pihole voor DNS, dus die wordt dan ook geblocked cq geen verkeer meer mogelijk voor IoT daarna?

Tenzij je in de firewall een uitzondering voorziet om poort 53 door te laten tot aan je Pihole server, zal dat inderdaad ook niet meer lukken. Maar pas op, veel IoT devices hebben hardcoded DNS resolvers, veel kans dat ze dus niet langs je Pihole passeren. Je blokkeert dan best alle uitgaande requests naar poort 53, behalve voor je Pihole.

Maarreuh, gebruik je Pihole enkel voor DNS of is dat ook je DHCP server?

[ Voor 6% gewijzigd door Slonzo op 07-05-2022 10:50 ]

[JB]

Dank voor meedenken allemaal!

Vind niet zo erg als die IoT hun eigen DNS gebruiken, is meer dat er iets niet meer werkt als ik dat segment ga buiten sluiten. PiHole doet alleen DNS.

[Airw0lf]

JB schreef op zaterdag 7 mei 2022 @ 10:51:
Dank voor meedenken allemaal!

Vind niet zo erg als die IoT hun eigen DNS gebruiken, is meer dat er iets niet meer werkt als ik dat segment ga buiten sluiten. PiHole doet alleen DNS.

Veel IoT-devices gebruiken inderdaad hun eigen DNS => het "gewone" DNS (via UDP-53) i.c.m. mDNS (via UDP-5353). Dat laatste ga je niet met pihole/dnsmasq kunnen doen => moet anders geregeld worden.

Om die reden gebruik ik pihole ook voor DHCP.
In het dashboard kan ik dan zien waar welke IP-adressen zijn uitgedeeld. En wat de actuele DNS-naam is (dynamisch en statisch). Idem voor het onderliggende mDNS-deel (eindigt allemaal op .local) - in mijn geval via avahi omdat ik pihole op Ubuntu 20.04-LTS heb draaien => avahi is daar een onderdeel van.

Ik maak bij mDNS geen gebruik van de mDNS-reflector. Maar heb avahi een "pootje" gegeven in elk relevant vlan. En wel op dezelfde manier als ik dat met pihole heb gedaan.

[ Voor 14% gewijzigd door Airw0lf op 07-05-2022 11:10 ]

[pinda powerrr]

Top linkjes!!!
Toevallig daar ook mee bezig op de zaak (klein hotel). Dus pas leuk in de discussie over Ubiquiti zakelijk wel/niet.
Het voldoet meer dan prima, roamen is seamless met zes AP's. Nu eindelijk tijd gehad om meerdere subnets te maken. Netjes zoals @nero355 voorschrijft met een management LAN, eentje voor de staff en voor de guests.
Guest policy gooit gelukkig al bijna alles dicht. Nu nog even de standaard vaste apparatuur naar Staff LAN gooien. Doe ik via een managed switch waarin ik de VLANs kan toewijzen.

Maar omdat ik dit "erbij" doe en geen achtergrond heb in de IT is dit topic mijn belangrijkste betrouwbare bron

Dus hulde aan de vaste bijdragers van dit topic die geduldig blijven uitleggen


Overigens best lastig uit te leggen waarom eea gescheiden moet worden, de eigenaren boeit het niet. Hoezo? Als de gasten maar internet hebben

[RobertMe]

pinda powerrr schreef op zaterdag 7 mei 2022 @ 12:54:
Overigens best lastig uit te leggen waarom eea gescheiden moet worden, de eigenaren boeit het niet. Hoezo? Als de gasten maar internet hebben

Vind je het oke als de gasten ook zo nu en dan wat afdrukken op de printer op kantoor?
Vind je het oke als de gasten aan de gedeelde documenten op de administratie computer kunnen?
Vind je het oke als de gasten in de kassa kunnen kijken?

Of vraag gewoon waarom er bv een slot op de deuren zit die alleen voor het personeel toegankelijk zijn. "De gasten moeten toch kunnen slapen en eten? Daarvoor hoeft ook geen slot op kantoor te zitten".

[pinda powerrr]

RobertMe schreef op zaterdag 7 mei 2022 @ 13:02:
[...]

Vind je het oke als de gasten ook zo nu en dan wat afdrukken op de printer op kantoor?
Vind je het oke als de gasten aan de gedeelde documenten op de administratie computer kunnen?
Vind je het oke als de gasten in de kassa kunnen kijken?

Of vraag gewoon waarom er bv een slot op de deuren zit die alleen voor het personeel toegankelijk zijn. "De gasten moeten toch kunnen slapen en eten? Daarvoor hoeft ook geen slot op kantoor te zitten".

Zie hier de onwetendheid van de gemiddelde consument.

Maar goed, er komt een nieuw pin apparaat, die ipv op mobiel netwerk, op de WiFi komt te zitten. Toen ik de opmerking maakte dat het wel handig is om die gescheiden te houden waren ze het ineens wel met me eens

Het is een stukje awareness waar ook deels fabrikanten bewust de gevaren niet melden. Kijk, ik kan niet hacken, maar dat pikkie op de hoek van net 14 wel en die kraakt je netwerk zonder moeite. Dus het zo moeilijk mogelijk maken mag van mij wel meer gepromoot worden.

[JeroenVerweij]

Goedemiddag Tweakers,

Ik heb een vraag. Ik wil binnenkort de UniFi Protect G4 Doorbell gaan installeren. Daarvoor is uiteraard een goed WiFi signaal nodig. Ik wil daarom het WiFi 6 Lite AP van achter in de woonkamer (13m lang) naar voren in de woonkamer bij de voordeur verplaatsen, achter het tv meubel. Binnen heb ik namelijk volle snelheid (nu nog 300mbit, binnenkort 1Gbit) maar als ik een speedtest run op de plek waar de deurbel komt, kakt dit in tot 15-20mbit.

Mijn aansluiting loopt nu zo aan de voorkant:
Internet -> Ziggo modem (WiFi staat uit) -> UniFi Switch Lite 8 PoE -> Flex Mini switch

Op de Flex Mini zit de Apple TV, Tado bridge, Ziggo Next box & Samsung TV aangesloten. Mijn idee is om de Tado bridge een verdieping naar boven te plaatsen zodat ik het vrijgekomen punt op de Flex Mini kan gebruiken voor mijn WiFi 6 Lite AP.

Nu mijn vraag. De Flex Mini heeft geen PoE (out) poorten. Ik moet het WiFi 6 Lite AP dus op een andere manier voeden. Kan dat zo simpel als een PoE injector er tussen zetten? Of gaat dat niet werken in mijn setup?

Dank alvast!

[ Voor 8% gewijzigd door JeroenVerweij op 07-05-2022 14:45 ]

[nero355]

JB schreef op zaterdag 7 mei 2022 @ 09:06:
Nu gebruik ik ook nog een Pihole voor DNS, dus die wordt dan ook geblocked cq geen verkeer meer mogelijk voor IoT daarna?

- Geef die Pi-Hole instance wat VLAN Interfaces
- Koppel ze aan FTLDNS/DNSmasq
- Zorg ervoor dat de Port Profile de juiste VLAN's meegeeft aan de Switchpoort.

KLAAR!!!

Airw0lf schreef op zaterdag 7 mei 2022 @ 09:42:
Ook is het zaak dat je routing op je pihole-server uitgeschakeld is. Anders schiet het niet echt op...

- Volgens mij is dat bij elke Linux Distro standaard zo!
- Bovendien moet iemand dan handmatig het IP adres van je DNS Server ineens als Gateway op zijn Client Device instellen en ook nog eens op zoek gaan naar andere netwerken : Welke l*l doet dat nou als die ergens op bezoek is

Pihole (het dnsmasq-deel) laat zich in een vlan met zijn vlan-specifieke dhcp-range, dns-server en default gateway. Alleen zul je daarvoor in de cli moeten klimmen in de vorm van een aanvullend dhcp-config-bestand. Dit is weer afhankelijk van het type en versie van het OS.

Eenmaal gedaan zal het dnsmasq-deel dhcp verzorgen voor het vlan. En zal je in de pihole gui kunnen zien welke ip's er uitgedeeld zijn. Ook eventuele logging en zo blijft allemaal werken.

Allemaal zaken die niet kloppen of niet relevant zijn in dit geval!

Maar dit pihole-config-stuk is redelijk off-topic => graag een dm als je hier meer over wil weten. Afhankelijk van je omgeving heb ik eventueel ook een voorbeeld-config voor je.

"That's not the way to GoT"

Bovendien hebben we daar een prachtig topic voor : Zie mijn signature!

Airw0lf schreef op zaterdag 7 mei 2022 @ 11:05:
Veel IoT-devices gebruiken inderdaad hun eigen DNS => het "gewone" DNS (via UDP-53) i.c.m. mDNS (via UDP-5353). Dat laatste ga je niet met pihole/dnsmasq kunnen doen => moet anders geregeld worden.

Om die reden gebruik ik pihole ook voor DHCP.

Die twee dingen spreken elkaar tegen

Daarnaast is het gewoon een kwestie van :
- AVAHI slopen als je daar toch niks mee doet!
- DNAT/SNAT regels toepassen.
- Eventueel in je Firewall allerlei DoH/DoT Servers blokkeren.

En dan ben je al van heel veel IoT gezeik af!

In het dashboard kan ik dan zien waar welke IP-adressen zijn uitgedeeld. En wat de actuele DNS-naam is (dynamisch en statisch). Idem voor het onderliggende mDNS-deel (eindigt allemaal op .local) - in mijn geval via avahi omdat ik pihole op Ubuntu 20.04-LTS heb draaien => avahi is daar een onderdeel van.

Ik maak bij mDNS geen gebruik van de mDNS-reflector. Maar heb avahi een "pootje" gegeven in elk relevant vlan. En wel op dezelfde manier als ik dat met pihole heb gedaan.

IMHO ook allemaal niet relevant...

[RobertMe]

JeroenVerweij schreef op zaterdag 7 mei 2022 @ 14:44:
Daarvoor is uiteraard een goed WiFi signaal nodig. Ik wil daarom het WiFi 6 Lite AP van achter in de woonkamer (13m lang) naar voren in de woonkamer bij de voordeur verplaatsen, achter het tv meubel. Binnen heb ik namelijk volle snelheid (nu nog 300mbit, binnenkort 1Gbit) maar als ik een speedtest run op de plek waar de deurbel komt, kakt dit in tot 15-20mbit.

Ik zou ook even testen met het AP aan de voorkant van de woning. Door muren en zo heen is altijd lastig voor wifi. Als je het AP voor in de woning plaatst heb je voor hetzelfde geldt een nog net zo slechte verbinding naar buiten toe.

Op de Flex Mini zit de Apple TV, Tado bridge, Ziggo Next box & Samsung TV aangesloten. Mijn idee is om de Tado bridge een verdieping naar boven te plaatsen zodat ik het vrijgekomen punt op de Flex Mini kan gebruiken voor mijn WiFi 6 Lite AP.

Waarschijnlijk zou @nero355 je dan een In-Wall access point aanbevelen. Of de AC IW, met 2 LAN aansluitingen waarvan één PoE passthrough doet waar je de Flex Mini op aan kunt sluiten, of de AC IW HD of U6 IW, die 4 LAN poorten hebben en dan heb je de Flex Mini niet meer nodig. Voordeel is dan sowieso ook dat je een extra AP hebt i.p.v. een bestaande verplaatst. Want je beredeneerd nu alleen uit het oogpunt van de deurbel "die zal dan beter signaal hebben" (hoop je, zie ook hierboven m.b.t. dat het geen garantie is omdat isolatie in muren en glas gewoon altijd heel hard het signaal dempt). Maar als je dat AP verplaatst, op welke plekken in huis krijg je dan mogelijk een veel slechter signaal?

Nu mijn vraag. De Flex Mini heeft geen PoE (out) poorten. Ik moet het WiFi 6 Lite AP dus op een andere manier voeden. Kan dat zo simpel als een PoE injector er tussen zetten? Of gaat dat niet werken in mijn setup?

Ja, dit kan. De Flex Mini merkt niks er van en de injector zorgt ervoor dat er PoE wordt geleverd aan het AP.

[nero355]

RobertMe schreef op zaterdag 7 mei 2022 @ 15:03:
Waarschijnlijk zou @nero355 je dan een In-Wall access point aanbevelen.

Ik raad iedereen een In Wall aan, want waarom zou je wat anders kopen sinds die modellen er ook zijn ?!

U6 IW

Was dat ding nou al officiëel of nog steeds EA alleen

* nero355 houdt het allemaal niet meer zo goed bij...

offtopic:
Verder is dit geen Aankoopadvies Topic en IMHO vraagt hij allemaal dingen die je makkelijk kan opzoeken dus ik vind het wel prima verder...

Good luck!

[JeroenVerweij]

RobertMe schreef op zaterdag 7 mei 2022 @ 15:03:
[...]

Ik zou ook even testen met het AP aan de voorkant van de woning. Door muren en zo heen is altijd lastig voor wifi. Als je het AP voor in de woning plaatst heb je voor hetzelfde geldt een nog net zo slechte verbinding naar buiten toe.

Dank voor je tip! Had ik natuurlijk eerst even moeten doen. Zojuist gedaan en bij het AP voorin de woonkamer haal ik op de plek van de bel 150-200mbit. Aanzienlijke verbetering dus en ruim voldoende. En dat is met de voordeur en tussendeur dicht en het AP achter de tv-meubel.

[…]

Waarschijnlijk zou @nero355 je dan een In-Wall access point aanbevelen. Of de AC IW, met 2 LAN aansluitingen waarvan één PoE passthrough doet waar je de Flex Mini op aan kunt sluiten, of de AC IW HD of U6 IW, die 4 LAN poorten hebben en dan heb je de Flex Mini niet meer nodig. Voordeel is dan sowieso ook dat je een extra AP hebt i.p.v. een bestaande verplaatst. Want je beredeneerd nu alleen uit het oogpunt van de deurbel "die zal dan beter signaal hebben" (hoop je, zie ook hierboven m.b.t. dat het geen garantie is omdat isolatie in muren en glas gewoon altijd heel hard het signaal dempt). Maar als je dat AP verplaatst, op welke plekken in huis krijg je dan mogelijk een veel slechter signaal?

U6 IW had ik al naar gekeken maar nog niet goed beschikbaar. Dus ik wilde daar even op wachten en tot die tijd mijn huidige AP naar voren verplaatsen. Achterin de woonkamer lever ik niet zoveel in want daar zit nu alleen keukenapparatuur op de WiFi. Uiteindelijk dient dat punt achter wel voor ontvangst in de tuin maar die is nog niet in gebruik want moeten we nog aanleggen.

[...]

Ja, dit kan. De Flex Mini merkt niks er van en de injector zorgt ervoor dat er PoE wordt geleverd aan het AP.

Dankje!

[Airw0lf]

nero355 schreef op zaterdag 7 mei 2022 @ 15:01:
[...]

- Geef die Pi-Hole instance wat VLAN Interfaces
- Koppel ze aan FTLDNS/DNSmasq
- Zorg ervoor dat de Port Profile de juiste VLAN's meegeeft aan de Switchpoort.

KLAAR!!!

[...]

Allemaal zaken die niet kloppen of niet relevant zijn in dit geval!

[...]

Die twee dingen spreken elkaar tegen

Daarnaast is het gewoon een kwestie van :
- AVAHI slopen als je daar toch niks mee doet!
- DNAT/SNAT regels toepassen.
- Eventueel in je Firewall allerlei DoH/DoT Servers blokkeren.

En dan ben je al van heel veel IoT gezeik af!


[...]

IMHO ook allemaal niet relevant...

We zeggen allebei hetzelfde: vlans toevoegen aan pihole?!
Wat maakt dat je jouw post ziet als "is relevant"? En de mijne afserveert als "klopt niet of is niet relevant"?

En ook: in een eerdere post van @JB werd er gesproken over een "Hue Bridge". De preciese scope kon ik er niet uit afleiden. Maar mijn inschatting was dat IoT juist wel nodig is => dat was in ieder geval wel het vertrekpunt van mijn reactie.

Het stukje over avahi en mDNS borduurt hierop door: als je een Heu Bridge gebruikt in combinatie met Apple devices heb je mDNS nodig. Idem voor vormen van home automation via zoiets als Home Assistant. Zo heb ik in mijn IoT-vlan twee ESPHome devices draaien die alleen aangesproken kunnen worden via hun IP-adres en hun mDNS-naam => domweg mDNS blokkeren met een firewall rule lijkt me dan geen optie. Technieken als DoH en DoT zijn hier niet relevant.

Met in het verlengde: om op het geheel wat meer zicht/grip te krijgen heb ik het DHCP-deel van pihole/dnsmasq ingezet. Op basis van het MAC-adres krijgen de IoT-devices een vast IP-adres en een "normale" DNS-naam. Dat alles is weer terug te vinden in de pihole dashboards. Om vervolgens op basis van die gegevens de firewall rules te verbijzonderen naar een specifieke toepassing.

Daarmee ligt ook de mDNS-naam vast binnen een bepaald vlan. Door vlan gerichte instellingen in avahi kun je alles toch met elkaar laten babbelen - mocht dat nodig zijn. Door de reflector functie van avahi uitgeschakeld te laten voorkom ik dat er via mDNS een achterdeurtje ontstaat waarlangs die devices alsnog met elkaar gaan babbelen. En daarmee de eerder ingevoerde firewall rules (min-of-meer) omzeilen.

Ook is er op een eerder moment gesteld dat de mDNS invulling binnen Ubiquiti niet goed (of onvolledig) is. De precieze details zou ik op moeten zoeken.

Mij lijkt dat deze combinatie maakt dat de bijdrage op alle punten relevant (en on-topic!) te noemen is:
(1) - het zou een workaround kunnen zijn voor de onvolledige Ubiquiti-invulling rondom mDNS.
(2) - het gebruik van een Hue Bridge en home automation binnen vlans.

Misschien allemaal wat ver gezocht? Zeker als je langs een ander kanaal meer details hebt ontvangen over de omgeving van @JB ? Maar daar heb ik dan weer geen zicht op => ik hoor graag hoe of wat.

[Airw0lf]

nero355 schreef op zaterdag 7 mei 2022 @ 15:01:
[...]

- Volgens mij is dat bij elke Linux Distro standaard zo!
- Bovendien moet iemand dan handmatig het IP adres van je DNS Server ineens als Gateway op zijn Client Device instellen en ook nog eens op zoek gaan naar andere netwerken : Welke l*l doet dat nou als die ergens op bezoek is

[...]

Klopt - prive is de kans misschien niet zo groot dat dit gebeurd... maar zo risico-minded als we tegenwoordig zijn...

Maar zakelijk is het wellicht een ander verhaal (zie de opmerking van @pinda powerrr over toepassen in een hotel): hoe zit het bij een pand op een bedrijventerrein?
Lijkt me een pracht van een (red-team?) aanval: je loopt het pand/hotel binnen, neemt plaats in de wachtruimte/lobbey en gaat aan de slag... kijken hoe ver je komt...

[ Voor 6% gewijzigd door Airw0lf op 08-05-2022 13:17 ]

[nero355]

Airw0lf schreef op zondag 8 mei 2022 @ 12:50:
We zeggen allebei hetzelfde

Nee, absoluut niet!

vlans toevoegen aan pihole?!

- Jij wil AVAHI in meerdere VLANs...
- Ik wil FTLDNS in meerdere VLANs !!

Wat maakt dat je jouw post ziet als "is relevant"? En de mijne afserveert als "klopt niet of is niet relevant"?

Je noemt oplossingen voor dingen die totaal niet de oplossing voor dat probleem zijn!

En ook: in een eerdere post van @JB werd er gesproken over een "Hue Bridge". De preciese scope kon ik er niet uit afleiden. Maar mijn inschatting was dat IoT juist wel nodig is => dat was in ieder geval wel het vertrekpunt van mijn reactie.

"When you ASSuME..."

Het stukje over avahi en mDNS borduurt hierop door: als je een Heu Bridge gebruikt in combinatie met Apple devices heb je mDNS nodig. Idem voor vormen van home automation via zoiets als Home Assistant. Zo heb ik in mijn IoT-vlan twee ESPHome devices draaien die alleen aangesproken kunnen worden via hun IP-adres en hun mDNS-naam => domweg mDNS blokkeren met een firewall rule lijkt me dan geen optie.

Multicast DNS heb je sowieso in gebruik als je ééń van die twee apparaten in huis hebt en niet alleen als je ze combineert met elkaar...

Technieken als DoH en DoT zijn hier niet relevant.

Op het moment dat je al het DNS verkeer binnen je netwerk wilt houden : Zeer zeker wel!

Met in het verlengde: om op het geheel wat meer zicht/grip te krijgen heb ik het DHCP-deel van pihole/dnsmasq ingezet. Op basis van het MAC-adres krijgen de IoT-devices een vast IP-adres en een "normale" DNS-naam. Dat alles is weer terug te vinden in de pihole dashboards. Om vervolgens op basis van die gegevens de firewall rules te verbijzonderen naar een specifieke toepassing.

Daar heb je dus helemaal niet een andere DHCP Server dan je UniFi Router voor nodig!

Daarmee ligt ook de mDNS-naam vast binnen een bepaald vlan.

Betere oplossing : Fatsoenlijke DNS Records voor elk apparaat op je netwerk en daar is Pi-Hole dan weer wel nuttig voor!

Door vlan gerichte instellingen in avahi kun je alles toch met elkaar laten babbelen - mocht dat nodig zijn. Door de reflector functie van avahi uitgeschakeld te laten voorkom ik dat er via mDNS een achterdeurtje ontstaat waarlangs die devices alsnog met elkaar gaan babbelen. En daarmee de eerder ingevoerde firewall rules (min-of-meer) omzeilen.

Ook is er op een eerder moment gesteld dat de mDNS invulling binnen Ubiquiti niet goed (of onvolledig) is. De precieze details zou ik op moeten zoeken.

De webGUI mDNS Reflector/Repeater is bagger, want gelijk ook op je WAN actief bij een USG in ieder geval!
De config.JSON optie echter is net zo goed als een aparte AVAHI Instance alleen dus wat meer gedoe

De UDR/UDM reeks schijnt nu wat meer opties in de webGUI erbij te hebben gekregen en kan je per VLAN in/uitschakelen gelukkig!
Of dat ook een upgrade is voor de USG gebruikers durf ik niet te zeggen...

Mij lijkt dat deze combinatie maakt dat de bijdrage op alle punten relevant (en on-topic!) te noemen is:
(1) - het zou een workaround kunnen zijn voor de onvolledige Ubiquiti-invulling rondom mDNS.
(2) - het gebruik van een Hue Bridge en home automation binnen vlans.

Misschien allemaal wat ver gezocht? Zeker als je langs een ander kanaal meer details hebt ontvangen over de omgeving van @JB ? Maar daar heb ik dan weer geen zicht op => ik hoor graag hoe of wat.

Het punt is dus dat je oplossingen voor niet bestaande problemen noemt of niet de juiste oplossingen voor bepaalde problemen

[Will_M]

@nero355 Zélfs op de USG-3P kun je mDNS tegenwoordig ook gewoon pér VLAN middels de GUI inschakelen / beheren (Unifi Network Controller V7.x.x).

Het USG-3P apparaatje kan genoeg, het is vaak de management implementatie middels de 'Unifi Controller' welke een eigen willetje heeft (als in: UI weet zelf vaak niet meer dat ze dat ding ooit geleverd hebben en dus ook moeten kunnen managen en onderhouden).

[ Voor 76% gewijzigd door Will_M op 08-05-2022 15:51 ]

[Airw0lf]

nero355 schreef op zondag 8 mei 2022 @ 14:59:

Nee, absoluut niet!

- Jij wil AVAHI in meerdere VLANs...
- Ik wil FTLDNS in meerdere VLANs !!

[...]

Ik kan me wel enigszins voorstellen dat je dat erin leest. Maar das was zeker niet de intentie!
Het doel was (en is) juist om met pihole de DNS-records op orde te krijgen voor alle in gebruik zijnde IP's - ongeacht hoe ze uitgedeeld en gebruikt zijn.

Omdat pihole niet met mDNS overweg kan was (en is) het idee om avahi op hetzelfde systeem te zetten - mocht er om wat voor reden dan ook mDNS nodig zijn. Met voorbeelden van situaties waarbij dit inderdaad nodig is.

Dat je DHCP via een router (Unify of iets anders) niet perse hoeft te vervangen weet ik. Maar als je je DNS-records met pihole op orde wil krijgen lijkt het me wel handig als je die ook DHCP laat afhandelen i.v.m. de lokale DNS-updates.

Oftewel met pihole (DHCP en DNS) en avahi (mDNS) op één systeem heb je alles rondom adres beheer en name resolving op een plek liggen. Lijkt me handiger dan verdeelt over twee apparaten. Of zie je dat anders?

nero355 schreef op zondag 8 mei 2022 @ 14:59:
Op het moment dat je al het DNS verkeer binnen je netwerk wilt houden : Zeer zeker wel!

Mwah - ik weet het niet - DoH en DoT onderscheppen de initiële DNS-aanvraag en sturen die in een tunnel/versleuteld het Internet op. Ergens eindigt die tunnel - bijvoorbeeld bij Google, Cloudflare of Nextdns. Op dat punt wordt je oorspronkelijke DNS-aanvraag alsnog zichtbaar. Alleen is dat "beperkt" tot (in dit voorbeeld) Google, Cloudflare of Nextdns (en alles wat daar nog achteraan komt). Maar of je er verder veel mee op schiet...

nero355 schreef op zondag 8 mei 2022 @ 14:59:
Het punt is dus dat je oplossingen voor niet bestaande problemen noemt of niet de juiste oplossingen voor bepaalde problemen

Mja - blijkbaar maakt mijn manier van schrijven dat dingen "vatbaar" zijn voor meerdere interpretaties. Maar meer dan dat is het niet...

[nero355]

Will_M schreef op zondag 8 mei 2022 @ 15:31:
Zélfs op de USG-3P kun je mDNS tegenwoordig ook gewoon pér VLAN middels de GUI inschakelen / beheren (Unifi Network Controller V7.x.x).

NICE!

Het USG-3P apparaatje kan genoeg, het is vaak de management implementatie middels de 'Unifi Controller' welke een eigen willetje heeft

Helaas heel erg keihard de waarheid!

Airw0lf schreef op zondag 8 mei 2022 @ 17:06:
Omdat pihole niet met mDNS overweg kan was (en is) het idee om avahi op hetzelfde systeem te zetten - mocht er om wat voor reden dan ook mDNS nodig zijn. Met voorbeelden van situaties waarbij dit inderdaad nodig is.

Maar dat hoeft dus niet om DNS redenen!

Je hebt AVAHI alleen als eventuele "Inter-VLAN Multicast DNS Reflector/Repeater" nodig!

Maar als je je DNS-records met pihole op orde wil krijgen lijkt het me wel handig als je die ook DHCP laat afhandelen i.v.m. de lokale DNS-updates.

En dat hoeft dus ook niet en levert je zelfs amper verbetering op t.o.v. van :
- Via de UniFi Controller webGUI voor elke Client een Static DHCP IP Mapping op basis van MAC adres aanmaken voor in een bepaald VLAN.
- Daarna via de Pi-Hole webGUI voor elk van die IP adressen een Local DNS Record aanmaken.

Oftewel met pihole (DHCP en DNS) en avahi (mDNS) op één systeem heb je alles rondom adres beheer en name resolving op een plek liggen.

AVAHI heb je niet nodig voor je DNS en wil je voor DNS niet eens van afhankelijk zijn!

Lijkt me handiger dan verdeelt over twee apparaten.

Of zie je dat anders?

Dat zie ik dus totaal anders en het werkt nog betrouwbaarder ook!

DoH en DoT onderscheppen de initiële DNS-aanvraag en sturen die in een tunnel/versleuteld het Internet op.

Wablief

Ergens eindigt die tunnel - bijvoorbeeld bij Google, Cloudflare of Nextdns. Op dat punt wordt je oorspronkelijke DNS-aanvraag alsnog zichtbaar. Alleen is dat "beperkt" tot (in dit voorbeeld) Google, Cloudflare of Nextdns (en alles wat daar nog achteraan komt). Maar of je er verder veel mee op schiet...

Je schiet ermee op dat (onder andere) die drie helemaal niet hoeven te weten wat ik uitspook op basis van mijn DNS Requests

Mja - blijkbaar maakt mijn manier van schrijven dat dingen "vatbaar" zijn voor meerdere interpretaties. Maar meer dan dat is het niet...

Ook dat zie ik dus ietsje anders...

[xbeam]

Nee, absoluut niet!

- Jij wil AVAHI in meerdere VLANs...
- Ik wil FTLDNS in meerdere VLANs !!

Airw0lf schreef op zondag 8 mei 2022 @ 17:06:
[...]
Ik kan me wel enigszins voorstellen dat je dat erin leest. Maar das was zeker niet de intentie!
Het doel was (en is) juist om met pihole de DNS-records op orde te krijgen voor alle in gebruik zijnde IP's - ongeacht hoe ze uitgedeeld en gebruikt zijn.

Omdat pihole niet met mDNS overweg kan was (en is) het idee om avahi op hetzelfde systeem te zetten - mocht er om wat voor reden dan ook mDNS nodig zijn. Met voorbeelden van situaties waarbij dit inderdaad nodig is.

Dat je DHCP via een router (Unify of iets anders) niet perse hoeft te vervangen weet ik. Maar als je je DNS-records met pihole op orde wil krijgen lijkt het me wel handig als je die ook DHCP laat afhandelen i.v.m. de lokale DNS-updates.

Oftewel met pihole (DHCP en DNS) en avahi (mDNS) op één systeem heb je alles rondom adres beheer en name resolving op een plek liggen. Lijkt me handiger dan verdeelt over twee apparaten. Of zie je dat anders?

mDNS reflectie moet je na mijn inziens altijd zoveel mogelijk vermeiden. Je maakt daarmee namelijk default al je active devices op je met mdns inschakelde vlan’s voor elkaar zichtbaar. Daar in ga ik met @nero355’s voorkeur mee om dit gewoon netjes via dns records vast te leggen.

Beter laat je de pi-hole via dhcp relay dan maar de dhcp voor je vlan’s doen.
https://help.ui.com/hc/en...294-EdgeRouter-DHCP-Relay

Mwah - ik weet het niet - DoH en DoT onderscheppen de initiële DNS-aanvraag en sturen die in een tunnel/versleuteld het Internet op. Ergens eindigt die tunnel - bijvoorbeeld bij Google, Cloudflare of Nextdns. Op dat punt wordt je oorspronkelijke DNS-aanvraag alsnog zichtbaar. Alleen is dat "beperkt" tot (in dit voorbeeld) Google, Cloudflare of Nextdns (en alles wat daar nog achteraan komt). Maar of je er verder veel mee op schiet...

Ja & Nee @nero355 praat altijd over unbounded FTL Pi-hole dan heb je geen upstream naar 3e partijen zoals jij noemt. Upstream is optioneel en handig voor een betaalde upstreams web gateway proxy’s zoals Cisco umbrella of watchguard DNS Watch
https://docs.pi-hole.net/ftldns/
https://docs.pi-hole.net/guides/dns/unbound/
Unbound: https://nlnetlabs.nl/projects/unbound/about/
Avahi doet volgens dns reflection (vergelijkbare met Apple Bonjour)
https://www.brewblox.com/...822_avahi_reflection.html
DNSmasq: doet dns repeating https://help.ui.com/hc/en-us/articles/115002673188
Beide beogen dns en discovery maar technische doen ze dit compleet anders en zijn goed in verschillende situaties en lossen verschillende problemen op maar die zijn niet altijd verenigbaar binnen een gezamenlijke oplossing. Vandaar zoveel verschillende forks en tool voor het zelfde

Zelfs ubnt gebruikt verschillende tools/diensten per router voor opties vergelijkbare functies maar toch werken en gebruik je ze anders.

Mja - blijkbaar maakt mijn manier van schrijven dat dingen "vatbaar" zijn voor meerdere interpretaties. Maar meer dan dat is het niet...

Dat is een linux ding omdat geen enkel Netwerk het zelfde is en iedere dhcp of dns function per merk andere software met mogelijkheden en manier van werken vergt. (Niet alles is MS) Je kan het over de zelfde functie en beoogde oplossing hebben en over instellingen praten met de zelfde functie maar andere namen of nog vervelender dezelfde namen maar een andere functies. daarom zie vaak (altijd doen makkelijker problemen zoeken met google) dat niet de functie maar de tool benoemd wordt.

@JB kijk hier eens naar deze unifi controller en pi-hole installatie voor je raspberry pie
https://crayzeigh.com/how-to-setup-pihole/

YAML:

version: "3"

services:
  jwilder-proxy:
    image: budry/jwilder-nginx-proxy-arm
    ports:
      - '80:80'
      - '443:443'
    environment:
      DEFAULT_HOST: pihole.domain.tld
    volumes:
      - '/var/run/docker.sock:/tmp/docker.sock'
    restart: always

  pihole:
  # https://github.com/pi-hole/docker-pi-hole/blob/master/README.md
    image: pihole/pihole:latest
    container_name: pihole
    # For DHCP there is some advanced router configuration. Do not use host mode networking or it will conflict with nginx and the unifi-controller
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "67:67/udp"
      - "8053:80/tcp"
      - "9443:443/tcp"
    environment:
      ServerIP: ###.###.###.###
      TZ: 'America/New_York' #Adjust for your timezone
      PROXY_LOCATION: pihole
      VIRTUAL_HOST: pihole.domain.tld
      VIRTUAL_PORT: 80
      # WEBPASSWORD: 'enter a password and uncomment, otherwise random'
    # Volumes store your data between container upgrades
    volumes:
      - './pihole/etc-pihole/:/etc/pihole/'
      - './pihole/etc-dnsmasq.d/:/etc/dnsmasq.d/'
      # run `touch ./var-log/pihole.log` first unless you like errors
      - './var-log/pihole.log:/var/log/pihole.log'
    # Recommended but not required (DHCP needs NET_ADMIN)
    # https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
    cap_add:
      - NET_ADMIN
    extra_hosts:
      - 'domain.tld:###.###.###.###'
      - 'pihole pihole.domain.tld:###.###.###.###'
      - 'unifi unifi.domain.tld:###.###.###.###'
    restart: unless-stopped

  unifi-controller:
    image: ghcr.io/linuxserver/unifi-controller
    container_name: unifi-controller
    ports:
      - "3478:3478/udp"
      - "10001:10001/udp"
      - "8080:8080"
      - "8443:8443"
      - "1900:1900/udp"
      - "8843:8843"
      - "8880:8880"
      - "6789:6789"
      - "5541:5541"
    environment:
      PROXY_LOCATION: unifi
      VIRTUAL_HOST: unifi.domain.tld
      VIRTUAL_PORT: 8443
      VIRTUAL_PROTO: https
    volumes:
      - './unifi/config:/config'
    restart: unless-stopped

Bij een usg moet je deze deze edge CLI omzet naar een Json input

> set service dhcp-relay interface ethX.x
> set service dhcp-relay server ###.###.###.###
> commit ; save

[ Voor 41% gewijzigd door xbeam op 09-05-2022 12:20 ]

[Airw0lf]

@xbeam en @nero355: inmiddels zijn we behoorlijk afgedwaald van het topic. Mochten jullie hier verder over willen bomen, dan graag een dm zodat we langs een ander kanaal de draad weer op kunnen pakken.

Voor de time being blijf ik doorgaan op de ingeslagen weg met een stabiele, lean-en-mean ingerichte VM (geen containers) die alles wat nodig is aan boord heeft; aangevuld met de nodige monitoring/auditing en pentesten. En met een minimale beheer(s)last.

Maar voor nu laat ik het hierbij.

[tcviper]

Even vraagje hier voor degene die het gebruiken, heeft KPN (Glas) nog altijd SLAAC nodig voor het IPV6 stuk?
Want dat werkt volgens mij nog niet standaard met UDM he? Kan alleen DHCPv6 aanzetten of static.

[bauk]

nero355 schreef op vrijdag 6 mei 2022 @ 20:28:
[...]


Welk model is het PRECIES

De US-16-150W.

[...]

Voor de pricewatch: Ubiquiti UniFi Switch (16-poorts, 150W PoE+) zijn er losse voedingen tekoop, maar ik zou eerst gewoon bij Ubiquiti zeuren, want bekend probleem bij bepaalde revisies!

Ja die dus, en allright, dan heb ik er slim aan gedaan een supportverzoek in te dienen . We zien wel, hoop doet leven .

[xbeam]

Airw0lf schreef op maandag 9 mei 2022 @ 08:44:
@xbeam en @nero355: inmiddels zijn we behoorlijk afgedwaald van het topic. Mochten jullie hier verder over willen bomen, dan graag een dm zodat we langs een ander kanaal de draad weer op kunnen pakken.

Voor de time being blijf ik doorgaan op de ingeslagen weg met een stabiele, lean-en-mean ingerichte VM (geen containers) die alles wat nodig is aan boord heeft; aangevuld met de nodige monitoring/auditing en pentesten. En met een minimale beheer(s)last.

Maar voor nu laat ik het hierbij.

Dit is toch juist on topic alleen gaan nu eindelijk weer een keer de technische de Unifi / Edge diepte met verschillende configuratie opties voor een oplossing in en plaats van dat oppervlakkig herhaling van van het reilen en zeilen van unifi.
Dit topic is gebouwd op het plaatsen van code en delen van json’s, Het is jammer dat we dit al tijden niet meer zien. Het is toch de bedoeling dat we gezamenlijk tot een werkende oplossing voor het gestelde unifi probleem komen? Dat is waar iedereen van leert

[ Voor 14% gewijzigd door xbeam op 09-05-2022 15:10 ]

[JB]

Ik ben in ieder geval heel blij met al deze inhoudelijke kennis van jullie! Ik ga dit weer proberen eigen te maken. Het hoeft voor mij niet complex en ik moet het kunnen snappen want ben ik geen netwerk specialist. Vooralsnog heb ik bereikt;

- IoT VLAN voor alle WiFi IoT meuk incl port tagged voor de Hue Bridge op de Unifi-8

To do;

- IoT niet meer laten praten met "normale netwerk doormiddel van subnet verkeer blocken
- IoT DNS bieden al dan niet via de PiHole want dat gaat stuk bij blocken subnet

Wellicht verwoord ik het niet geheel juist, maar ik ben niet helemaal thuis in het vakjargon

[ed1703]

xbeam schreef op maandag 9 mei 2022 @ 10:28:
Dit topic is gebouwd op het plaatsen van code en json’s Het is jammer dat we dit al tijden niet meer zien.

Zal ik dan een duitje in het zakje stoppen?

Ik was op zoek naar een crontab poe-script aangezien dit met de controller niet kan.
in de ochtend moeten mijn picore muziekspelers aan.
in de avond moeten mijn picore muziekspelers uit.

(dit kun je natuurlijk ook vertalen naar andere poe-devices die je niet 24 uur aan wilt hebben)

Dus gemaakt: (ben geen wereld-scripter, maar dit doet wat het moet doen )
Draai ik op mijn pihole RPI. Uiteraard dien je wel SSH pubkey in je controller te laden.
Status werkt de controller niet bij dus die ignore ik gewoon

code:

#!/bin/bash

## voorbeeld ./poe-control.sh sw01 1 off

username=deviceusername


case "$1" in
 sw01)
switch=sw01.mgmt.lan
;;


 sw02)
switch=sw02.mgmt.lan
;;

esac

case "$2" in

 1)
port=1
;;

 2)
port=2
;;

 3)
port=3
;;

 4)
port=4
;;

 5)
port=5
;;

 6)
port=6
;;

 7)
port=7
;;

 8)
port=8
;;

esac


case "$3" in

 on)
status=auto
;;

 off)
status=off
;;

esac

ssh $username@$switch swctrl poe set $status id $port

exit 0

Crontab:

code:

# POE
0 7 * * * /path/./poe-control.sh sw01 6 on >/dev/null 2>&1
0 7 * * * /path/./poe-control.sh sw02 6 on >/dev/null 2>&1

0 22 * * * /path/./poe-control.sh sw01 6 off >/dev/null 2>&1
0 22 * * * /path/./poe-control.sh sw02 6 off >/dev/null 2>&1

[xbeam]

JB schreef op maandag 9 mei 2022 @ 10:53:
Ik ben in ieder geval heel blij met al deze inhoudelijke kennis van jullie! Ik ga dit weer proberen eigen te maken. Het hoeft voor mij niet complex en ik moet het kunnen snappen want ben ik geen netwerk specialist. Vooralsnog heb ik bereikt;

- IoT VLAN voor alle WiFi IoT meuk incl port tagged voor de Hue Bridge op de Unifi-8

To do;

- IoT niet meer laten praten met "normale netwerk doormiddel van subnet verkeer blocken
- IoT DNS bieden al dan niet via de PiHole want dat gaat stuk bij blocken subnet

Wellicht verwoord ik het niet geheel juist, maar ik ben niet helemaal thuis in het vakjargon

Jargon is prima we herkennen aan het jargon wel dat je de defeat functie bedoelt de spraak verwarring vindt meestal plaats tussen mensen die wat dieper in de materie zitten zoals @nero355 en @Airw0lf daarom mijn vorige bericht met linkjes om hun meningsverschillen wat betreft de uitvoering van de zelfde oplossing te duiden voor iedereen.

- IoT DNS bieden al dan niet via de PiHole want dat gaat stuk bij blocken subnet

Wat je voorlopig kan doen is in de unifi controller bij je wan instellingen de pi-hole als dns opgeven waarna de Usg/udm je request forward naar de pi. Zo blijven je controller stats en firewall intact en heb toch alvast je dns filtering. Allen zie je niet alle devices terug in je pi-hole omdat de requests richting de pi-hole van je router komen.


edgerouter:

configure
set system name-server 192.168.pi.hole
commit
save
exit

Dit geeft tijd om op later tijdstip waneer je de firewall iets meer onder de knie hebt eens rustig te gaan kijken naar voor jouw de beste oplossing. Dit kan zijn een pi-hole met 1 voet in iedere vlan @nero355 of de in 1 vlan met intervlan toegang met mdns voor bijv Chromecast en AirPlay @Airw0lf .
Beide manieren werken

IoT niet meer laten praten met "normale netwerk doormiddel van subnet verkeer blocken

Edgerouter:
Het is voor mij ook al een aantal jaar terug maar volgens mij zo iets als dit. Als de edgerouter het niet al via een template installatie zelf doet.

configure
set firewall name LAN_IN default-action drop
set firewall name LAN_IN description "Intervlan block"
set firewall name LAN_IN enable-default-log
set firewall name LAN_IN rule 10 action accept
set firewall name LAN_IN rule 10 description "Allow established/related"
set firewall name LAN_IN rule 10 log enable
set firewall name LAN_IN rule 10 protocol all
set firewall name LAN_IN rule 10 state established enable
set firewall name LAN_IN rule 10 state invalid disable
set firewall name LAN_IN rule 10 state new disable
set firewall name LAN_IN rule 10 state related enable
Commit
Save

[ Voor 69% gewijzigd door xbeam op 09-05-2022 15:11 ]

[laurens0619]

@JB
had je deze pagina al gevonden?
https://help.ui.com/hc/en...Disable-InterVLAN-Routing

Om apparaten uit je iot vlan toegang geven tot je pihole dns kun je:
- pihole lid maken van beide vlans (dus 2 netwerk interfaces activeren, 1x in iot vlan en 1x in je lan vlan))
Meer info: https://mroach.com/2019/11/using-pi-hole-on-multiple-vlans/
- een exceptie in de "block inter vlan" firewall rule maken dat verkeer wel richting pihole mag
- dns via usg laten lopen

Eeerst dit maar opzetten

edit:
ah lees ik nu dat je een edgerouter X hebt ipv een usg?
Dan is deze tutorial handiger om verkeer tussen vlans te blokkeren
https://help.ui.com/hc/en...a-Guest-LAN-Firewall-Rule
-------------------------------------------------------------------
Daarna wel nadenken hoe internet te filteren.
Vanuit het scenario dat je IoT apparaat gehackt is heb je grofweg de volgende risicos:
risico 1. Het IoT apparaat gaat andere devices in je netwerk infecteren
risico 2. Het IoT apparaat wordt ingezet voor internet aanvallen

Wat ik vaak zie is dat mensen vooral bezig zijn om apparaten in aparte vlans te stoppen maar geen internet filtering toepassen.
Dat apparaten niet meer met elkaar kunnen praten is goed maar vergeet niet om internet verkeer te filteren. Dan ga je pas echt toegevoegde waarde hebben (security technisch gezien dan)

[ Voor 77% gewijzigd door laurens0619 op 09-05-2022 13:12 ]

[Airw0lf]

xbeam schreef op maandag 9 mei 2022 @ 10:28:
[...]


Dit is juist on topic we alleen gaan nu eindelijk weer een keer de Unifi diepte met verschillende configuratie opties voor een oplossing in en plaats van dat oppervlakkig herhaling van van het reilen en zeilen van unifi.
Dit topic is gebouwd op het plaatsen van code en delen van json’s, Het is jammer dat we dit al tijden niet meer zien. Het is toch de bedoeling dat we gezamenlijk tot een werkende oplossing voor het gestelde unifi probleem komen? Dat is waar iedereen van leert

Ok - prima - bij deze (met het idee dat het merendeel van de hier aanwezige populatie dat ook zo ziet).

Zoals eerder aangegeven maak ik gebruik van één Ubuntu-VM (20.04-LTS).

Hieronder achtereenvolgens de configs van/voor:
- ubuntu: /etc/network/interfaces
- de pihole configs zoals aangemaakt door de gui
- aanvullingen op pihole
- pihole vlan-config
- avahi-config met daaronder het resultaat van "avahi-browse -a"

Instellingen die niet genoemd zijn hebben fabrieksinstellingen (if any at all).

In het netwerk worden twee routers gebruikt. Beiden wijzen naar pihole als DNS-server. Dit zijn de IP-adressen welke eindigen op 235.

Voor de goede orde drie dingen:
(1) - dit zijn niet de werkelijk gebruikte subnetten. Maar een vereenvoudigd abstract op basis van een 24-bits subnet masker voor alle vlans => het gaat immers om de principe-werking.
(2) - overal waar je pihole ziet moet je eigenlijk dnsmasq lezen => het zijn eigenlijk dnsmasq instellingen. Ik gebruik pihole vanwege de dashboards en het "rondwandelen" in de query-logs.
(3) - pihole/dnsmasq is dhcp-server voor alle vlans/subnetten => geen dhcp-relay.

=====

ubuntu: /etc/network/interfaces

code:

# The 1-st network interface
auto eth0
iface eth0 inet static
    address 192.168.139.235
    netmask 255.255.255.0
    gateway 192.168.139.240
    dns-nameserver 192.168.139.235

# Other v-lan configs
#
# Pre-prod en test (via Sophos XGS)
auto eth0.100
iface eth0.100 inet static
        address 192.168.100.235
        netmask 255.255.255.0
        gateway 192.168.100.234
        dns-nameserver 192.168.100.234

# Prod - Datacenter
auto eth0.200
iface eth0.200 inet static
        address 192.168.200.235
        netmask 255.255.255.0
        gateway 192.168.200.240
        dns-nameserver 192.168.200.235

# Prod - Office - Wired
auto eth0.210
iface eth0.210 inet static
        address 192.168.210.235
        netmask 255.255.255.0
        gateway 192.168.210.240
        dns-nameserver 192.168.210.235

# Prod - Office - Wifi
auto eth0.220
iface eth0.220 inet static
        address 192.168.220.235
        netmask 255.255.255.0
        gateway 192.168.220.240
        dns-nameserver 192.168.220.235

# Prod - Domotica & IoT
auto eth0.230
iface eth0.230 inet static
        address 192.168.230.235
        netmask 255.255.255.0
        gateway 192.168.230.240
        dns-nameserver 192.168.230.235

# Prod - Guest wifi (via Sophos XGS)
auto eth0.240
iface eth0.240 inet static
        address 192.168.240.235
        netmask 255.255.255.0
        gateway 192.168.240.234
        dns-nameserver 192.168.240.234

=====

de 3 pihole configs zoals aangemaakt door de gui

code:

addn-hosts=/etc/pihole/local.list
addn-hosts=/etc/pihole/custom.list
localise-queries
no-resolv
cache-size=10000
log-queries
log-facility=/var/log/pihole.log
log-async
server=45.90.28.138
server=45.90.30.138
domain-needed
expand-hosts
bogus-priv
local-service
dhcp-name-match=set:hostname-ignore,wpad
dhcp-name-match=set:hostname-ignore,localhost
dhcp-ignore-names=tag:hostname-ignore

code:

dhcp-authoritative
dhcp-range=192.168.139.11,192.168.139.60,24h
dhcp-option=option:router,192.168.139.240
dhcp-leasefile=/etc/pihole/dhcp.leases
#quiet-dhcp

domain=itv.lan
local=/itv.lan/

code:

dhcp-host=00:04:20:23:22:15,192.168.139.61,sb-1
dhcp-host=00:04:20:12:93:16,192.168.139.62,sb-2
dhcp-host=00:04:20:12:A3:7B,192.168.139.63,sb-3
dhcp-host=88:A9:A7:93:60:3F,192.168.139.146,3d-printer-if0
dhcp-host=68:B9:D3:D2:AD:74,192.168.139.145,3d-printer-if1
dhcp-host=B8:D7:AF:54:3E:C9,192.168.230.225,inv-1
dhcp-host=CC:C0:79:39:6B:65,192.168.230.226,inv-2
dhcp-host=DC:F5:05:25:34:21,192.168.230.201,roomba
dhcp-host=C8:C9:A3:6C:7D:D9,192.168.230.227,smartreader
dhcp-host=94:B9:7E:17:97:EC,192.168.230.228,smartdoorbell

=====

aanvullingen op pihole (lees: instellingen voor dnsmasq)

code:

#####
addn-hosts=/etc/95-static-hosts
dhcp-client-update
dhcp-fqdn
domain=dmz.itv.lan,192.168.2.0/24
server=//
server=/lan/
stop-dns-rebind
dns-loop-detect
edns-packet-max=1232
dhcp-option=43,01:04:00:00:00:02 # Disable Netbios

# NextDNS specifics | WMO 2020jul4
add-cpe-id=<code>

# Nessus scannner specifics | WMO 2022apr23
rebind-domain-ok=/msftncsi.com/officeapps.live.com/nessus.org/fixed.kpn.net/

# Misc
filterwin2k
localise-queries
dns-forward-max=300
all-servers
no-negcache

=====

pihole/dnsmasq vlan-config

code:

# Pre-prod and test - 100 (traffic is processed via Sophos XGS)
domain=preprod.itv.lan,192.168.100.0/24
dhcp-range=eth0.100,192.168.100.11,192.168.100.60,24h
dhcp-option=eth0.100,option:router,192.168.100.234
dhcp-option=eth0.100,option:dns-server,192.168.100.234

# Prod - Datacenter - 200
domain=dc.itv.lan,192.168.200.0/24
dhcp-range=eth0.200,192.168.200.11,192.168.200.60,24h
dhcp-option=eth0.200,option:router,192.168.200.240
dhcp-option=eth0.200,option:dns-server,192.168.200.235

# Prod - Office - Wired - 210
domain=wired.itv.lan,192.168.210.0/24
dhcp-range=eth0.210,192.168.210.11,192.168.210.60,24h
dhcp-option=eth0.210,option:router,192.168.210.240
dhcp-option=eth0.210,option:dns-server,192.168.210.235

# Prod - Office - Wifi - 220
domain=wifi.itv.lan,192.168.220.0/24
dhcp-range=eth0.220,192.168.220.11,192.168.220.60,24h
dhcp-option=eth0.220,option:router,192.168.220.240
dhcp-option=eth0.220,option:dns-server,192.168.220.235

# Prod - Domotica & IoT - 230
domain=iot.itv.lan,192.168.230.0/24
dhcp-range=eth0.230,192.168.230.11,192.168.230.60,24h
dhcp-option=eth0.230,option:router,192.168.230.240
dhcp-option=eth0.230,option:dns-server,192.168.230.235

# Prod - Gasten wifi - 240 (traffic is processed via Sophos XGS)
domain=gasten.itv.lan,192.168.240.0/24
dhcp-range=eth0.240,192.168.240.11,192.168.240.60,24h
dhcp-option=eth0.240,option:router,192.168.240.234
dhcp-option=eth0.240,option:dns-server,192.168.240.234

=====

avahi-config (lees: mDNS) en de uitkomst van avahi-browse -a

code:

[server]
host-name=sdn
domain-name=local
use-ipv4=yes
use-ipv6=no
allow-interfaces=eth0,eth0.210,eth0.220,eth0.230
enable-dbus=yes
disallow-other-stacks=yes
ratelimit-interval-usec=1000000
ratelimit-burst=1000

[wide-area]
enable-wide-area=no

[publish]
publish-addresses=yes
publish-hinfo=no
publish-workstation=no

[reflector]
enable-reflector=no
reflect-ipv=no

code:

+ eth0.230 IPv4 hass [6df5181aa0754c5a8bb50e4f1a154fe9]       Workstation          local
+ eth0.220 IPv4 hass [6df5181aa0754c5a8bb50e4f1a154fe9]       Workstation          local
+ eth0.210 IPv4 hass [6df5181aa0754c5a8bb50e4f1a154fe9]       Workstation          local
+   eth0 IPv4 hass [6df5181aa0754c5a8bb50e4f1a154fe9]       Workstation          local
+   eth0 IPv4 mtk8530 [98:93:cc:cf:4b:c3]                   Workstation          local
+   eth0 IPv4 C4A-8b84440d7539e95aa218317c548d1881          _googlecast._tcp     local
+   eth0 IPv4 8b84440d-7539-e95a-a218-317c548d1881          _googlezone._tcp     local
+   eth0 IPv4 mouse                                         Web Site             local
+   eth0 IPv4 mouse                                         Microsoft Windows Network local
+   eth0 IPv4 mouse                                         _device-info._tcp    local
+   eth0 IPv4 mouse                                         Apple File Sharing   local
+ eth0.220 IPv4 morpheus                                      Apple File Sharing   local
+ eth0.220 IPv4 MORPHEUS                                      Microsoft Windows Network local
+ eth0.220 IPv4 MORPHEUS                                      _device-info._tcp    local
+   eth0 IPv4 morpheus                                      Apple File Sharing   local
+   eth0 IPv4 MORPHEUS                                      Microsoft Windows Network local
+   eth0 IPv4 MORPHEUS                                      _device-info._tcp    local
+   eth0 IPv4 HASS Bridge 5587F7                            _hap._tcp            local
+   eth0 IPv4 ITV-HQ                                        _home-assistant._tcp local
+   eth0 IPv4 OfficeJet                                     UNIX Printer         local
+   eth0 IPv4 OfficeJet                                     PDL Printer          local
+   eth0 IPv4 OfficeJet                                     Internet Printer     local
+   eth0 IPv4 OfficeJet                                     Web Site             local
+   eth0 IPv4 OfficeJet                                     _scanner._tcp        local
+   eth0 IPv4 OfficeJet                                     _http-alt._tcp       local
+   eth0 IPv4 OfficeJet                                     _uscan._tcp          local
+   eth0 IPv4 OfficeJet                                     _privet._tcp         local
+   eth0 IPv4 OfficeJet                                     _uscans._tcp         local
+   eth0 IPv4 mtk8530                                       SFTP File Transfer   local
+   eth0 IPv4 LG_SMART_AUDIO-9b3a45b7-cf17-4d45-815b-e66cb80d5224 _lg-smart-device._tcp local
+   eth0 IPv4 mtk8530                                       SSH Remote Terminal  local
+ eth0.220 IPv4 Bitdefender for Android                       _bitdefender-app._tcp local

=====

[JB]

laurens0619 schreef op maandag 9 mei 2022 @ 11:26:
@JB
had je deze pagina al gevonden?
https://help.ui.com/hc/en...Disable-InterVLAN-Routing

Om apparaten uit je iot vlan toegang geven tot je pihole dns kun je:
- pihole lid maken van beide vlans (dus 2 netwerk interfaces activeren, 1x in iot vlan en 1x in je lan vlan))
Meer info: https://mroach.com/2019/11/using-pi-hole-on-multiple-vlans/
- een exceptie in de "block inter vlan" firewall rule maken dat verkeer wel richting pihole mag
- dns via usg laten lopen

Eeerst dit maar opzetten

edit:
ah lees ik nu dat je een edgerouter X hebt ipv een usg?
Dan is deze tutorial handiger om verkeer tussen vlans te blokkeren
https://help.ui.com/hc/en...a-Guest-LAN-Firewall-Rule
-------------------------------------------------------------------
Daarna wel nadenken hoe internet te filteren.
Vanuit het scenario dat je IoT apparaat gehackt is heb je grofweg de volgende risicos:
risico 1. Het IoT apparaat gaat andere devices in je netwerk infecteren
risico 2. Het IoT apparaat wordt ingezet voor internet aanvallen

Wat ik vaak zie is dat mensen vooral bezig zijn om apparaten in aparte vlans te stoppen maar geen internet filtering toepassen.
Dat apparaten niet meer met elkaar kunnen praten is goed maar vergeet niet om internet verkeer te filteren. Dan ga je pas echt toegevoegde waarde hebben (security technisch gezien dan)

Jep ERX nog altijd inderdaad (ook) vanwege afwijkende PoE voltages 1e serie APs. Je hebt helemaal gelijk mbt de zaken eromheen. Die pakken we ook aan. Vind het altijd beetje lastig als ik gewoonweg commando's ga rammen en niet helemaal weet wat het doet.

Ben nu ook naar deze tuto aan het kijken;

[laurens0619]

@JB
Niets mis hoor met de ER-X en goede eigenschap om niet commandos/input over te nemen zonder dat je het snapt.
Gewoon stap voor stap doen, firewalls rules lezen kan wat overzichtelijk worden en complex worden.
Ik kwam deze site nog tegen, die leggen het wel aardig stap voor stap uit

https://www.geekbitzone.c...-groups-on-the-edgerouter

[ Voor 10% gewijzigd door laurens0619 op 09-05-2022 13:27 ]

[xbeam]

laurens0619 schreef op maandag 9 mei 2022 @ 13:27:
@JB
Niets mis hoor met de ER-X en goede eigenschap om niet commandos/input over te nemen zonder dat je het snapt.
Gewoon stap voor stap doen, firewalls rules lezen kan wat overzichtelijk worden en complex worden.
Ik kwam deze site nog tegen, die leggen het wel aardig stap voor stap uit

https://www.geekbitzone.c...-groups-on-the-edgerouter

Zeker voor het leer en de hobby is edge veel beter en leuker. Alleen de overstap van bijv asus naar edge is het wel een stijle leercurve vergeleken met unifi. Maar zeker de moeite waard

[JB]

laurens0619 schreef op maandag 9 mei 2022 @ 13:27:
@JB
Niets mis hoor met de ER-X en goede eigenschap om niet commandos/input over te nemen zonder dat je het snapt.
Gewoon stap voor stap doen, firewalls rules lezen kan wat overzichtelijk worden en complex worden.
Ik kwam deze site nog tegen, die leggen het wel aardig stap voor stap uit

https://www.geekbitzone.c...-groups-on-the-edgerouter

Ja dit helpt zeker! Meteen een vraagje mbt switch0;

Enabling VLAN on the switch0 interface

We will now make the switch0 interface VLAN-aware by tagging VLAN ID 10 to port eth1.

Waarom doen ze dit alleen op eth1? Ik gebruik 1t/m4 (3 en 4 hebben ook PoE voor de APs). Tag je dan alle 4 met ID 10 (in mijn geval 5)?

[laurens0619]

JB schreef op maandag 9 mei 2022 @ 13:32:
[...]

Ja dit helpt zeker! Meteen een vraagje mbt switch0;

[...]


Waarom doen ze dit alleen op eth1? Ik gebruik 1t/m4 (3 en 4 hebben ook PoE voor de APs). Tag je dan alle 4 met ID10?

Omdat

In this simple network diagram we have assumed that the Internet (WAN) is connected to port eth0 on the EdgeRouter. On the LAN side, eth1 is connected to port 1 on the MikroTik switch. Finally, on port 2, we have connected an insecure Internet of Things (IOT) device which we will isolate into its own VLAN.

Ze hebben dus maar achter 1 poort het iot vlan
Zie ook plaatje



Als jij hem overal hebt, dan moet je hem overal aanzetten.
Maar ik denk dat je dit VLAN stukje veilig kunt overslaan aangezien je dat al aan de praat had toch?
Aparte vlans met subnets en aparte dhcp servers etc

[ Voor 8% gewijzigd door laurens0619 op 09-05-2022 13:39 ]

[JB]

laurens0619 schreef op maandag 9 mei 2022 @ 13:35:
[...]

Omdat

[...]

Ze hebben dus maar achter 1 poort het iot vlan
Zie ook plaatje

[Afbeelding]

Als jij hem overal hebt, dan moet je hem overal aanzetten.
Maar ik denk dat je dit VLAN stukje veilig kunt overslaan aangezien je dat al aan de praat had toch?
Aparte vlans met subnets en aparte dhcp servers etc

Ja klopt, het werkt prima nu. Ik heb alleen de Hue Bridge getagged, maar die zit op de Unifi-8 en krijgt mooi een DHCP in de 5 reeks

[laurens0619]

JB schreef op maandag 9 mei 2022 @ 13:40:
[...]

Ja klopt, het werkt prima nu. Ik heb alleen de Hue Bridge getagged, maar die zit op de Unifi-8 en krijgt mooi een DHCP in de 5 reeks

Om het compelx te maken, dat klinkt alsof je hem hebt geuntagged

Weet niet of je dat verschil al snapt
Tagged = vlans die je aanbiedt op een poort. Aangesloten apparaten kunnen dan dit vlan joinen mits het ingesteld staat op de netwerk interface (of via wifi als je SSID zo ingesteld staat) Als je niets instelt, kom je op het untagged vlan uit. Je kan dus meerdere tagged vlans op een poort hebben

Untagged = het vlan waar je standaard op uitkomt als je client niets instelt qua vlans. Hier kan je er dus maar 1 van hebben op een poort

Security technisch wil je het instellen van het VLAN niet op een untrusted apparaat doen zoals een iot device. Dus dan maak je een wifi iot SSID die standaard op vlan 5 uitkomt of je reserveert een aantal utp poorten op een switch die op untagged vlan 5 uitkomen

[ Voor 20% gewijzigd door laurens0619 op 09-05-2022 13:47 ]