Vlan implementeren voor iot , toch onhandig?

[R.G]

Graag zou ik met wat vrienden, bij ons allen het gevreesde iot network probleem willen tacklen.

Situatie:
2x routers met 3 eigen ap wifi punten.
Op 1 router2 : wifi 6 fast wifi point doorgelust met router 1.

Router 1:
Heeft een
Wifi ap punt: slow met 2.4ghz en een 5ghz normal punt
Daarnaast staat daar wifi quest aan

Hier kunnen visitors op inloggen mer een qr code in huis.
Zij kunnen Dan niet op het lan Alleen op het wan.

Alle iot devices kan ik bij via de 3 wifi punten momenteel.

Alle routers en wifi punten zitten in hetzelfde netwerk en subnet.

Alleen volgens mij met deze manier verdeel je de belasting over verschillende routers? Of is dat onzin?

Stel we willen nu iot in een vlan doen maar de iot devices maken gebruik of hebben wan access nodig voor internet hoe kan je dat regelen?

Een eis blijft ook gemak. Ik zou van miin telefoon en laptop en desktop machine het iot device moeten kunnen gebruiken. Is dat mogelijk?

Want het lijkt mij dat het vlan juist het lan scheidt?

Waardoor de lan apparaten dus wanneer ik verbind met de acces points Dan Kam ik niet bij de iot apparaten?

Wat mij onhandig en onbruikbaar maakt?

Waarom is vlan een opposing voor iot devices?

Waar sla ik hier de plank mis en mis ik hier nog kennis?

[Ben(V)]

Wat is eigenlijk in jouw ogen het gevreesde iot probleem?

[boyd86]

IOT apparaten in een eigen VLAN en eigen subnet kan prima, middels ACL's of firewallregels (afhankelijk vh platform) kun je IOT -> WAN verkeer toestaan en voor je telefoon en andere LAN clients een regel voor LAN -> IOT op de poortnummers die nodig zijn.
IOT apparaten die WiFi nodig hebben kun je middels een apart SSID aan het juiste VLAN koppelen of dynamisch VLAN toekennen o.b.v. ingevoerde wachtwoord als dat ondersteund wordt (PPSK zonder Radius in TP-Link Omada bijvoorbeeld)
Dit zou geen problemen mogen geven.

[R.G]

boyd86 schreef op donderdag 15 mei 2025 @ 09:42:
IOT apparaten in een eigen VLAN en eigen subnet kan prima, middels ACL's of firewallregels (afhankelijk vh platform) kun je IOT -> WAN verkeer toestaan en voor je telefoon en andere LAN clients een regel voor LAN -> IOT op de poortnummers die nodig zijn.
IOT apparaten die WiFi nodig hebben kun je middels een apart SSID aan het juiste VLAN koppelen of dynamisch VLAN toekennen o.b.v. ingevoerde wachtwoord als dat ondersteund wordt (PPSK zonder Radius in TP-Link Omada bijvoorbeeld)
Dit zou geen problemen mogen geven.

Oke maar wat lost het op?
Em waarom Wil of raadt men dit aan?

[R.G]

Ben(V) schreef op donderdag 15 mei 2025 @ 09:36:
Wat is eigenlijk in jouw ogen het gevreesde iot probleem?

Dat iot teveel logt of stuurt naar de iot fabrikant ( china paranoid) mij maakt her niet veel uit wel een beetje) maar vrienden ziin achterdochtig en vroegen mii erna

[Noob_Saibot]

VLAN's + FW regels
Implementatie op fw:

1. Netwerksegmentatie:
Primair LAN (VLAN 10): Jou telefoons/laptops/desktops.

IoT VLAN (VLAN 20): Alle IoT-apparaten.

Gast VLAN (VLAN 30): Bestaand gastnetwerk (behouden zoals het is).

Gebruik een router/firewall (jou hoofdrouter, bijvoorbeeld Router 1) om het inter-VLAN-verkeer te beheren

VLAN-configuratie:
Wijs VLAN's toe aan SSID's:

Thuisnetwerk (VLAN 10) – Voor jou vertrouwde apparaten.
IoT-netwerk (VLAN 20) – Voor IoT-apparaten.
Gastnetwerk (VLAN 30) – Geen wijzigingen.

Zorg ervoor dat alle AP's/routers VLAN-tagging ondersteunen (of gebruik aparte SSID's per VLAN).


Configureer VLAN's op Router 1:

Maak VLAN 20 aan voor IoT en wijs dit toe aan een SSID (bijv. IoT-netwerk).
Verplaats alle IoT-apparaten naar de nieuwe SSID/VLAN.

Stel firewallregels in:

Sta gevestigd/gerelateerd verkeer toe (voor reacties op jou verzoeken).
Blokkeer nieuwe verbindingen van IoT naar LAN.

Test:

Controleer of IoT-apparaten internet hebben (bijv. slimme stekkers kunnen updaten).
Controleer of jou telefoon IoT-apparaten kan bedienen (bijv. via de Smart Life-app)
Controleer de isolatie (bijv. IoT-apparaten kunnen jou laptop niet pingen).

Verder:
"VLAN scheidt LAN": Ja, maar u staat gecontroleerde toegang toe van LAN → IoT via firewallregels. Dit zorgt voor gebruiksgemak en verhoogt de beveiliging.
Belastingverdeling: VLAN's verbeteren de load balancing niet direct. Voor betere prestaties:

Gebruik verschillende kanalen voor AP's.
Zorg ervoor dat routers/AP's in bridge-modus staan ​​(indien niet nodig voor routing).
Voorbeeldconfiguratie (Router 1):

VLAN	Purpose	SSID	Access Rules
10	Main LAN	Home-Network	Full LAN access, no IoT → LAN
20	IoT	IoT-Network	Internet only + LAN → IoT allowed
30	Guest	Guest-Network	Internet only, isolated

[R.G]

Noob_Saibot schreef op donderdag 15 mei 2025 @ 09:44:
VLAN's + FW regels
Implementatie op fw:

1. Netwerksegmentatie:
Primair LAN (VLAN 10): Jou telefoons/laptops/desktops.

IoT VLAN (VLAN 20): Alle IoT-apparaten.

Gast VLAN (VLAN 30): Bestaand gastnetwerk (behouden zoals het is).

Gebruik een router/firewall (jou hoofdrouter, bijvoorbeeld Router 1) om het inter-VLAN-verkeer te beheren

VLAN-configuratie:
Wijs VLAN's toe aan SSID's:

Thuisnetwerk (VLAN 10) – Voor jou vertrouwde apparaten.
IoT-netwerk (VLAN 20) – Voor IoT-apparaten.
Gastnetwerk (VLAN 30) – Geen wijzigingen.

Zorg ervoor dat alle AP's/routers VLAN-tagging ondersteunen (of gebruik aparte SSID's per VLAN).


Configureer VLAN's op Router 1:

Maak VLAN 20 aan voor IoT en wijs dit toe aan een SSID (bijv. IoT-netwerk).
Verplaats alle IoT-apparaten naar de nieuwe SSID/VLAN.

Stel firewallregels in:

Sta gevestigd/gerelateerd verkeer toe (voor reacties op jou verzoeken).
Blokkeer nieuwe verbindingen van IoT naar LAN.

Test:

Controleer of IoT-apparaten internet hebben (bijv. slimme stekkers kunnen updaten).
Controleer of jou telefoon IoT-apparaten kan bedienen (bijv. via de Smart Life-app)
Controleer de isolatie (bijv. IoT-apparaten kunnen jou laptop niet pingen).

Verder:
"VLAN scheidt LAN": Ja, maar u staat gecontroleerde toegang toe van LAN → IoT via firewallregels. Dit zorgt voor gebruiksgemak en verhoogt de beveiliging.
Belastingverdeling: VLAN's verbeteren de load balancing niet direct. Voor betere prestaties:

Gebruik verschillende kanalen voor AP's.
Zorg ervoor dat routers/AP's in bridge-modus staan ​​(indien niet nodig voor routing).
Voorbeeldconfiguratie (Router 1):

VLAN	Purpose	SSID	Access Rules
10	Main LAN	Home-Network	Full LAN access, no IoT → LAN
20	IoT	IoT-Network	Internet only + LAN → IoT allowed
30	Guest	Guest-Network	Internet only, isolated

toon volledige bericht

Wow sir, netjes ik wens je een hele goede dag en bedankt hiervoor. Ik ga het uit testen.

[boyd86]

R.G schreef op donderdag 15 mei 2025 @ 09:43:
[...]


Oke maar wat lost het op?
Em waarom Wil of raadt men dit aan?

Daar kunnen verschillende redenen voor zijn, maar met name het scheiden van verkeersstromen, betere controle over wat met wat mag communiceren.
Als je alles in eenzelfde VLAN zet kan het op laag 2 met elkaar communiceren, daar ziet een firewall dan niets van.
Als je niet wilt dat bepaalde IOT apparaten met internet verbinden, kun je een regel maken die je alleen aanzet voor updates bijvoorbeeld, of altijd dicht laten staan en handmatig firmware uploaden vanuit intern netwerk.

[R.G]

Hoe test j3 dit als je het iot device niet zelf kan besturen? Zoals een google speaker of google nest

Controleer de isolatie (bijv. IoT-apparaten kunnen jou laptop niet pingen

[Ben(V)]

Vlan's en subnetten zijn alleen functionele scheidingen en geen security scheidingen.
Als je iets echt wilt beveiligen/afscheiden heb je een firewall nodig.

Eigenlijk begint het al bij je keuze om wifi iot te gebruiken, als je Zigbee met bijvoorbeeld Home Assistant had gebruikt zou er niets van je iot naar buiten gaan als je dat niet wilt.

[Bertsjuhn]

[b]Ben(V) in "Vlan implementeren voor iot , toch onhandig?"..
Eigenlijk begint het al bij je keuze om wifi iot te gebruiken, als je Zigbee met bijvoorbeeld Home Assistant had gebruikt zou er niets van je iot naar buiten gaan als je dat niet wilt.

Ben ik niet helemaal met je eens, als je bijvoorbeeld een Ring (of andere deurbel unit) hebt, is het ook fijn om deze op het IOT wifi te hebben zitten.
Eigenlijk wil je daar alle devices op die niet met elkaar hoeven te communiceren, en die niet aan je 'normale' LAN hoeven te hangen.
Ik heb hier bijvoorbeeld de deurbel, de robot stofzuiger, de robot maaier, ... aan hangen. Werkt prima, mits je dit op de juiste manier inricht inderdaad, en een firewall ertussen zet.

[Ben(V)]

Tja dat is een gemaks argument die dus daarmee de risico's voor lief neemt.
Dat is ook de reden dat fabrikanten wifi inbouwen omdat iedereen al wifi heeft, lekker makkelijk.
Wifi voor iot is technisch en ook uit beveiliging oogpunt gewoon geen goed idee.

Overigens is een ring deurbel nauwelijks onder iot te scharen maar eigenlijk gewoon een video camera.

[ Voor 12% gewijzigd door Ben(V) op 15-05-2025 09:57 ]

[Kenhas]

Heb dit jaren geleden eens ingesteld, aan de hand van een youtube tutorial, op mijn unifi systeem. Apart wifi netwerk en apart vlan voor iedere "categorie": "gewoon netwerk", IoT (kunnen op internet maar verder geen interne communicatie). Daarnaast nog NoT (network of things) met ook een apart vlan. Deze hebben wifi verbinding nodig maar geen internet. Daar zitten bijvoorbeeld mijn shelly's op.

Beetje getest door met laptop te verbinden met de verschillende wifi netwerken en alles leek te werken. Moet toegeven dat ik er sedertdien niet meer naar omgekeken heb. De meeste nieuwe devices zijn zigbee en komt er iets nieuw met wifi verbinding is het gewoon kwestie van juiste wifi netwerk te selecteren

Allemaal beetje paranoide misschien maar het kan met het unifi systeem dus waarom niet

[laurens0619]

Hetgeen waar je bij iot apparaten het meest zorgen om moet maken is:
- data ontsluiten naar buiten toe, bv camera/microfoon.data
- apparaat ingezet wordt voor cyber aanvallen (BOT)

Dit los je op door kwalitatief spul te kopen waar je de leverancier vertrouwd en/of je internet verkeer restricten.
Minimaal tot alleen het ip van het backend maar eigenlijk wil je voor beide risicos internet er volledig af halen.

Waar je je het minst zorgen om moet maken is:
- Dat een iot apparaat gehackt wordt en ze vanuit hier andere apparaten op het lan gaan hacken.
Om dit (vooral theoretisch) risico te mitigeren kun je apparaten in apparte vlan stoppen en cross vlan verkeer blokkeren.

Wat je vaak ziet is dat mensen het iot spul in apart netwerk stoppen maar wel internet volledig open laten.
Risico technisch heeft dat niet heel veel nut....

[Ben(V)]

Elk apparaat dat je toegang geeft tot het internet kan gehackt worden waardoor jouw lan niet meer veilig is.

Meestal zetten ze een connectie op naar een sever in de cloud om daar data heen te sturen, maar die connectie is eenvoudig te onderscheppen of zelfs door de leverancier te misbruiken.

En iot devices doen zelf echt helemaal niets aan beveiliging.

[Yucon]

Misschien begrijp ik het verkeerd, maar dit laat toch nog steeds toe dat data teruggestuurd wordt?

[lier]

Yucon schreef op donderdag 15 mei 2025 @ 10:54:
Misschien begrijp ik het verkeerd, maar dit laat toch nog steeds toe dat data teruggestuurd wordt?

Wat bedoel je precies met je opmerking?

laurens0619 schreef op donderdag 15 mei 2025 @ 10:19:
Risico technisch heeft dat niet heel veel nut....

Hangt ervan af welk risico je wil mitigeren.

[mash_man02]

Yucon schreef op donderdag 15 mei 2025 @ 10:54:
Misschien begrijp ik het verkeerd, maar dit laat toch nog steeds toe dat data teruggestuurd wordt?

Dan had je de gevraagde oplossing niet op basis van cloud-it of IOT moeten aanschaffen.

Het grootste issue is daar dat we eerst iets aanschaffen dan daarna pas gaan nadenken, gebeurd zakelijk overigens ook heel vaak.

IOT segmenteren is echt wel heel goed mogelijk, maar als je het echt goed wilt doen heb je ook goede apparatuur nodig om te scheiden per platform / functie / risico profiel, en connectivity alleen op basis van whitelisting toestaan zodat anomalies goed opvallen.

[ Voor 40% gewijzigd door mash_man02 op 15-05-2025 13:33 ]

[R.G]

mash_man02 schreef op donderdag 15 mei 2025 @ 13:30:
[...]


Dan had je de gevraagde oplossing niet op basis van cloud-it of IOT moeten aanschaffen.

Het grootste issue is daar dat we eerst iets aanschaffen dan daarna pas gaan nadenken, gebeurd zakelijk overigens ook heel vaak.

IOT segmenteren is echt wel heel goed mogelijk, maar als je het echt goed wilt doen heb je ook goede apparatuur nodig om te scheiden per platform / functie / risico profiel, en connectivity alleen op basis van whitelisting toestaan zodat anomalies goed opvallen.

Heb je daarvoor een pva voor consumenten/ techneuten zonder enterprise businesses apparatuur?

Maar zon iot device heeft vaak verbindijg nodig van buiten: voor toevoegen account etc en updates?

Is het wel mogelijk?

Denk aan nest camera , aan google devices, log devices temperatuur, slimme lampen.

Het is niet local only he bij iot

[laurens0619]

Klopt het is daarom ook een catch22 bij veel iot producten.

Wil je het grootste risico mitigeren dan moet je internet toegang blokkeren maar dan werkt vaak je iot apparaat niet meer

Beste is iot apparatuur kopen waarmee je lokaal kunt interfacen en het apparaat geen internet nodig heeft.

Mrja vaak is het spul gekocht en willen mensen het toch beveiligen en dan komt snel het aparte netwerk/vlan om de hoek kijken.
Daarmee los je een heel ander risico op, een risico imho wat vooral theoretisch van aard is voor een thuissituatie.

[Ben(V)]

Ik blijf erbij dat je voor iot geen wifi devices moet gebruiken maar Zigbee in combinatie met bijvoorbeeld Home Assistant.
Firmware upgrade is dan onder controle van HA en niet via een cloud server van de fabrikant en wordt je privé data met niemand gedeeld terwijl die wifi devices alles naar hun cloud server sturen.
Ook gaat dan zo'n device per definitie niet het internet op want dat kan Zigbee helemaal niet.
Iot wil je lokaal houden is mijn mening.

Ook moet je geen threads gaan gebruiken, want dat is van Meta(Zuckerberg), dus per definitie onveilig en heeft weer hetzelfde probleem als wifi dat het Ip based is.

[mash_man02]

R.G schreef op donderdag 15 mei 2025 @ 15:06:
[...]


Heb je daarvoor een pva voor consumenten/ techneuten zonder enterprise businesses apparatuur?

Maar zon iot device heeft vaak verbindijg nodig van buiten: voor toevoegen account etc en updates?

Is het wel mogelijk?

Denk aan nest camera , aan google devices, log devices temperatuur, slimme lampen.

Het is niet local only he bij iot

IOT is geen functie, het is just het concept dat je devices met internet / cloud services communiceren om een functie te kunnen bieden dus IOT is juist altijd non local. Het is dan ook de afkorting van Internet Of Things.

Dus je kiest over het algemeen niet voor IOT je kiest voor een functioneel iets, ik wil een camera systeem of ik wil een deurbel met camera, of ik wel een laadpaal met verrekening. Zou je dan niet moeten weten hoe iets werkt voor je het koopt ? Of koop je het eerste en realiseer je je daarna pas dat het niet veilig voldoende is ?

En ja, je zult bij een nieuwe functionaliteit los van of je een bedrijf of particulier persoon bent altijd een PVA moeten opstellen. Letterlijk veel onderdelen staan daar altijd impliciet in, daar denken we niet eens over na. Zoals eerst betalen en dan meenemen, lijkt me wel degelijk een ingesleten pva .

Ik stel alleen dat we daar technisch ook over na moeten denken en de verwachtingen zouden moeten valideren voordat we iets kopen.

Als je dat process andersom doet krijg je vragen zoals de TS heeft.

[ Voor 3% gewijzigd door mash_man02 op 15-05-2025 17:20 ]

[R.G]

Oke stel dat ik het gewoon zolaat in combinatie met gemak en fijne gebruikers ervaring?

Wat doe ik Dan, wat brengt het ons om een firewall en vlan in te regelen?
M.b.t.:

Gebruik ervaring
Security
Network effectiveness
Administration

Daarnaast begrijp niet wat je met de ziggbee en home assistant moet?

Zigbee lijkt mij een limited factor want apparaat moet Ondersteunen?

Home assistant is een application layer data laag en application oplossing.

Ons probleem ligt hier nu op data laag Niveau osi laag 1-3?

[Ramon]

Google devices kan je niet op een nuttige manier van het internet afhalen. Ze worden bewust en expres zo gemaakt dat ze internet nodig hebben en dat blokkeren van bepaalde dingen ook heel lastig is. Dat is nou eenmaal hoe Google werkt en schreeuwend rijk wordt. Als je niet getrackt wil worden door Google moet je geen Google gebruiken, zo simpel is het.

[smuldersbram]

Ben(V) schreef op donderdag 15 mei 2025 @ 15:56:
...Ook moet je geen threads gaan gebruiken, want dat is van Meta(Zuckerberg), dus per definitie onveilig en heeft weer hetzelfde probleem als wifi dat het Ip based is.

Uh, nu haal je twee dingen door elkaar. Threads(twitter alternatief) is inderdaad een meta product, maar heeft niks met IoT te maken.

Ik denk dat je thread bedoelt, dit is een netwerk standaard speciaal bedoelt voor smart home devices en is in theorie beter dan zigbee of z-wave. Dit is ook het primaire protocol wat embedded is in de Matter smart home standaard. En dus imho prima te gebruiken voor offline apparaten.

[ Voor 5% gewijzigd door smuldersbram op 15-05-2025 18:46 ]

[Ben(V)]

Sorry foutje je hebt gelijk.
Het komt bij Apple vandaan, niet bij meta.

En thread is helemaal niet embedded in Matter, je kunt net zo goed Zigbee in Matter gebruiken.

Maar het probleem is nog steeds dat het ip based is, dus routeerbaar en dus gaan alle fabrikanten weer verplichte connecties met hun cloud servers in die devices inbakken wat we juist niet willen.

Bij Zigbee kan dat gewoon niet.
Je ziet nu al vele iot devices in twee vormen verschijnen te weten een wifi model en hetzelfde model met zigbee en die wifi modellen doen allemaal "phone home".

[smuldersbram]

Ben(V) schreef op donderdag 15 mei 2025 @ 19:25:
Het komt bij Apple vandaan, niet bij meta.

Apple is later aangesloten bij de thread group nadat een hoop andere bedrijven deze groep opgericht hebben. (bron, bron)
Er zitten veel bedrijven achter/werken mee aan thread. Daarnaast bestaat het board van de thread group uit mensen vanuit al die verschillende partners. Dus niet alleen Apple.

Ben(V) schreef op donderdag 15 mei 2025 @ 19:25:
En thread is helemaal niet embedded in Matter, je kunt net zo goed Zigbee in Matter gebruiken.

"Zigbee is similar to Thread but is not directly compatible with Matter. Connecting to Matter requires a separate Bridge, as it operates as a standalone solution with its own application and network layers." (Bron)
Dus ja, je kunt zigbee devices aansturen via matter áls de zigbee bridge matter ondersteund, zigbee kan niet direct aan een matter border router gekoppeld worden.

Daarnaast is thread wel groot onderdeel van de matter standaard:
"Presently, official support is limited to Wi-Fi, Ethernet, and the wireless mesh network Thread." (Bron)

Ben(V) schreef op donderdag 15 mei 2025 @ 19:25:
Maar het probleem is nog steeds dat het ip based is, dus routeerbaar en dus gaan alle fabrikanten weer verplichte connecties met hun cloud servers in die devices inbakken wat we juist niet willen.

Klopt, maar een device kan alleen het internet op als je border router dat toestaat, en dat heb je zelf in de hand met de keuze van border router.

[Miezie]

R.G schreef op donderdag 15 mei 2025 @ 09:44:
[...]


Dat iot teveel logt of stuurt naar de iot fabrikant ( china paranoid) mij maakt her niet veel uit wel een beetje) maar vrienden ziin achterdochtig en vroegen mii erna

Dan gebruik je zoveel als mogelijk juist geen wifi devices… maar zigbee, zwave, …

[Kenhas]

Ben(V) schreef op donderdag 15 mei 2025 @ 19:25:
Sorry foutje je hebt gelijk.
Het komt bij Apple vandaan, niet bij meta.

En thread is helemaal niet embedded in Matter, je kunt net zo goed Zigbee in Matter gebruiken.

Maar het probleem is nog steeds dat het ip based is, dus routeerbaar en dus gaan alle fabrikanten weer verplichte connecties met hun cloud servers in die devices inbakken wat we juist niet willen.

Bij Zigbee kan dat gewoon niet.
Je ziet nu al vele iot devices in twee vormen verschijnen te weten een wifi model en hetzelfde model met zigbee en die wifi modellen doen allemaal "phone home".

zoals @smuldersbram zegt, komt Thread helemaal niet van bij Apple.

Maar de keuze voor zigbee zou, zoals je zegt, evident moeten zijn. Denk dat 80% van mijn devices Zigbee zijn. Maar er zijn nu eenmaal zaken die niet kunnen met zigbee. Mijn Android TV streamer kan nu eenmaal niet zonder internet, net als mijn Sonos luidsprekers. Ook mijn Panasonic airco's hebben internet nodig (tot ik eindelijk eens tijd maak om ESP bordjes te installeren). Heb twee infrarood stralers en die zijn enkel wifi.

En veel devices in een wifi of zigbee variant ? Kan me toch niet zoveel devices voor de geest halen waar je kunt kiezen. Er zullen er ongetwijfeld wel zijn maar dat is toch een minderheid. Zeker met de opkomst van het Tuya systeem zie je toch veel zaken die enkel een wifi versie hebben.

[bl33d]

Ik snap even niet helemaal wat je hier daadwerkelijk probeert op te lossen. Als er devices zijn die je niet vertrouwt vanwege xxx redenen, dan wil je die onbetrouwbare devices überhaupt niet in je netwerk houden. Daarnaast is IOT een rekbaar begrip. Je kunt je Samsung tv als IOT zien en ook je Sonos apparaat. Als jedie op een eigen vlan aansluit wordt het uitdagend om inter vlan verkeer onderling te regelen met een mdns repeater. Je wilt bijvoorbeeld immers wel vrij kunnen casten. Wat je dan doet is de communicatie weer openzetten tussen vlans, wat dus het principe van veiligheid onderuit haalt.

Ik heb deze weg al eens eerder bewandeld en ben ervan afgestapt omdat het voor mij niets oplost en meer complexiteit creëert. Het was voor mij eerder schijnveiligheid. De devices die ik niet vertrouwde heb ik reeds vervangen door gerenommeerde merken. Andere devices heb ik afgestoten en ontdaan van communicatie.

[gwabber]

bl33d schreef op vrijdag 16 mei 2025 @ 08:42:
Ik snap even niet helemaal wat je hier daadwerkelijk probeert op te lossen. Als er devices zijn die je niet vertrouwt vanwege xxx redenen, dan wil je die onbetrouwbare devices überhaupt niet in je netwerk houden. Daarnaast is IOT een rekbaar begrip. Je kunt je Samsung tv als IOT zien en ook je Sonos apparaat. Als jedie op een eigen vlan aansluit wordt het uitdagend om inter vlan verkeer onderling te regelen met een mdns repeater. Je wilt bijvoorbeeld immers wel vrij kunnen casten. Wat je dan doet is de communicatie weer openzetten tussen vlans, wat dus het principe van veiligheid onderuit haalt.

Ik heb deze weg al eens eerder bewandeld en ben ervan afgestapt omdat het voor mij niets oplost en meer complexiteit creëert. Het was voor mij eerder schijnveiligheid. De devices die ik niet vertrouwde heb ik reeds vervangen door gerenommeerde merken. Andere devices heb ik afgestoten en ontdaan van communicatie.

Middels mDNS zet je niet gelijk het verkeer open tussen vlan's. Het enige wat je doet is het mogelijk maken dat de apparaten zich kenbaar maken buiten hun eigen subnet, zodat je ernaar kan casten. Dat werkt prima als je apparaat in je trusted network de verbinding initieert. Vervolgens zijn er firewallrules die ervoor zorgen dat er geen open communiicatie is vanaf je IOT vlan naar je trusted vlan. Uiteraard stel je het zo in dat het andersom wel het geval is.

[Boudewijn]

bl33d schreef op vrijdag 16 mei 2025 @ 08:42:
Ik snap even niet helemaal wat je hier daadwerkelijk probeert op te lossen. Als er devices zijn die je niet vertrouwt vanwege xxx redenen, dan wil je die onbetrouwbare devices überhaupt niet in je netwerk houden. Daarnaast is IOT een rekbaar begrip. Je kunt je Samsung tv als IOT zien en ook je Sonos apparaat. Als jedie op een eigen vlan aansluit wordt het uitdagend om inter vlan verkeer onderling te regelen met een mdns repeater. Je wilt bijvoorbeeld immers wel vrij kunnen casten. Wat je dan doet is de communicatie weer openzetten tussen vlans, wat dus het principe van veiligheid onderuit haalt.

Ik heb deze weg al eens eerder bewandeld en ben ervan afgestapt omdat het voor mij niets oplost en meer complexiteit creëert. Het was voor mij eerder schijnveiligheid. De devices die ik niet vertrouwde heb ik reeds vervangen door gerenommeerde merken. Andere devices heb ik afgestoten en ontdaan van communicatie.

Het lastige is dat ook gerenommeerde merken geowned kunnen worden. Ik verwacht dat er minder spionage/tracking troep in zit dan chinees spul, maar ik vertrouw mijn A-merk televisie ook niet (echt).


Ik heb het probleem opgelost met:

1) Zoveel mogelijk Zigbee en Zwave. Dat praat met mijn HA instance.
2) De dingen die wifi 'moeten' hebben (BBQ thermometers, tv, shelly's, robotstofzuiger, PV-omvormer dat soort werk) op een eigen VLAN. Ja een VLAN is niet onhackbaar,maar voor ongerichte aanvallen geloof ik het wel. Dat VLAN kan met de HA instance praten maar verder alleen een gelimiteerd internet.
3) Camera's op eigen VLAN.
4) Een gasten VLAN met eigen wifi. Kun je gecapped mee internetten.
5) Vanuit mijn vertrouwde netwerk kan ik bij veel spullen. Op mijn vertrouwde netwerk komt met name apparatuur die ik vertrouw of zelf beheer. IOT-spulletjes weer ik hier actief uit.

Spullen die wifi hebben maar waarbij ik dat ik niet ga gebruiken (vaatwasser, oven) ga ik niet aan netwerken knopen.

[Ramon]

gwabber schreef op vrijdag 16 mei 2025 @ 11:20:
[...]

Middels mDNS zet je niet gelijk het verkeer open tussen vlan's. Het enige wat je doet is het mogelijk maken dat de apparaten zich kenbaar maken buiten hun eigen subnet, zodat je ernaar kan casten. Dat werkt prima als je apparaat in je trusted network de verbinding initieert. Vervolgens zijn er firewallrules die ervoor zorgen dat er geen open communiicatie is vanaf je IOT vlan naar je trusted vlan. Uiteraard stel je het zo in dat het andersom wel het geval is.

Maar waar wil je je tegen beschermen? @R.G noemt alleen google speaker en google nest bij naam. Daarmee trek ik de conclusie dat hij zich vooral wil beschermen tegen tracking door google. Maar de enige manier om dat echt voor elkaar te krijgen is door die google producten niet te gebruiken.

Want leuk dat je netwerken kan scheiden en dat Android TV of Chromecast niet bij je netwerk kan, maar dat is maar een fractie van waar google geïnteresseerd in is. Google is veel meer geïnteresseerd in wát je streamt dan hoe je netwerk eruit ziet.

[FredvZ]

bl33d schreef op vrijdag 16 mei 2025 @ 08:42:
Daarnaast is IOT een rekbaar begrip. Je kunt je Samsung tv als IOT zien en ook je Sonos apparaat.

Als je die kant op gaat zou je je telefoon en laptop net zo goed als IOT kunnen beschouwen

En is ook gelijk duidelijk dat scheiding op basis van VLAN's voor de meeste huishoudens niets toevoegt: alle devices moeten eerst verbinding met internet maken om elkaar aan te sturen.

Wanneer het imho wel nuttig is om VLANs te gebruiken:
- Camera's met lokale NVR (excl. hybrid oplossingen zoals Eufy)
- Sensoren met lokale registratie (bijv. Home Assistant)
- Actuators met lokale aansturing (bijv. lampen, verwarming, rolluiken die lokaal via Home Assistant worden aangestuurd)
- Loklale opslag (NAS, fileserver)

In deze situaties heeft het nut en kan je hiermee (icm met een router/firewall) een netwerk creëren waarbij jij in control bent welke devices met elkaar mogen communiceren binnen je eigen netwerk. Als je je huis bedient met Google of andere "werkt zonder hub" apps dan heb je dan is er nauwelijks directe communicatie tussen de devices.

[Frogmen]

Teken om te beginnen eens je netwerk want dat maakt veel duidelijk maar brengt vaak ook de valkuilen aan het licht. Vervolgens welke apparatuur heb je.
Vaak is het het belangrijkste dat je niet wil dat gasten bij IoT kunnen, met een gastennetwerk heb je dat opgelost. Vervolgens kan je de rest wel scheiden maar je wilt gebruikers gemak en alles met al je devices kunnen bedienen. Hoe je dat inricht is sterk afhankelijk van de devices en hoe die aangestuurd worden.
Wat kan een IoT vlan zonder internet toegang en gescheiden van je normale netwerk en dan Home assistant gebruiken die in beide netwerken zit, waardoor je home assistant kan bedienen maar alle IoT afgescheiden is. Maar als al je devices netjes up to date zijn moet je je afvragen wat het risico is.
Vergeet niet dat voor veel Tweakers hun huis ook hun home lab is, waar soms de regel omdat het kan belangrijk is.

[ Voor 6% gewijzigd door Frogmen op 17-05-2025 12:52 ]