May I ask for your suggestion to create a openWRT configuration wich has the folowing goal:
create 2 areas for connecting devices via DHCP one with internet access and the 2nd one with the possibility to cut internet acccess?
In more detail, I have my Router (Turris Omnia) running OpenWRT (a flaviour of it) and i like to have a area where normal Wifi and LAN clients will connect with internet access,...
And a second area where all my IOT devices where located and where I can cut the internet access to avoid cloud communication,...
one of the tricky things a a side requirement are to types of devices that creates problems at the moment. Chromcast audio devices located in the area where normal clients connecting to for having the ability to directly stream to them, and IOT devices (Temptest Weatherflow) in the IOT area that are sending Wifi broadcast udp packages that shall be received by all clients in this area.
In the IOT area I run a data broker (iobroker @ RPi4) to collect data from all the devices and present them via a visualation to all clients no matter if there are in area1 or 2.
what i tried but is not sufficient so far:
I've splitted my available interfaces (5 LAN ports + 2 Wifi networks) into 2 sub nets
One with 3 Ethernet ports (bridged) + 1 Wifi (SSID A) that has 192.168.1.x
2nd with 2 ethernet ports (bridged) + 1 Wifi (SSID B) that has 192.168.2.x
Connecting devices and Chromcast units to area 1 is working as expected (only Wifi clients at the moment)
Connecting devices to area 2 is working also in prinzip
2 LAN devices (PV-Inverter, ioBroker@RPI4) and a lot of Wifi IOT clients (Wifi Main plugs, Mains metering reader, Weatherfow Weather station,...)
However, my RPi4 on LAN will not receive UDP broadcast packages coming from a Wifi device in the same network ?!?!
Also the RPi4 is not detecting the cromecast devices because the multicast DNS packages were only visible in area 1.
Many thanks to all that have read my long explainations and maybe someone can give me a advice hwo a configuration can look like. Maybe I'm running completly in the wrong direction and VLANs are mor capable or any other configuraton method.
this means your fork/flavored owrt may work differently than stock owrt so i am not sure if followings will help or not.
second, from high level point of view this is how networking works in general and in owrt:
192.168.1.0/24 i assume you are using this network where /24 is the netmask, which means 192.168.1.0 is the network address, 192.168.1.255 is the broadcast address, in between you can freely use ip addresses, but these two are reserved;
you can only broadcast within a broadcast domain, i.e. 192.168.1.0/24 is one broadcast domain, 192.168.2.0/24 is another broadcast domain, cannot broadcast between the domains;
owrt firewall implementation is based on zone concept: you can control how to treat traffic within a zone and between zones. e.g. you can see in owrt firewall config that lan to wan forwarding is allowed, meaning from a client in lan zone owrt firewall is allowed to send (=forward) traffic into wan zone.
network stack by classic definition is divided to 7 layers, each provides/defines unique features and layers are built on top of each other. L2 is close to hardware, sends frames to/from network entities identified by their MAC address (typical L2 object in owrt config is 'bridge'). L3 is a more abstract layer, where packets are sent between network entities defined by their IP address (typical L3 object in owrt config is 'interface').
in owrt this is tied together like: create an interface with an IP address + netmask (e.g. 192.168.1.1/24), which is bind to a bridge device (br-lan), which bundles the network ports (lan1, lan2 etc). also interface has a firewall zone ('lan'). as a result: if you connect your pc to any physical port on the router which is part of br-lan, and you specify an IP address for you pc in the same network as your lan interface then you can access your router. if you connect a second pc to another physical port which is also part of br-lan, specify a 3rd ip address, then you can access from that pc the router and also you can access pc2 from pc1.
so, depending on level of customization/variance of your fork things may work differently but i think the base is the same:
if you created two interfaces in the same zone then depending on your firewall configuration you may or may not see traffic in between them. but broadcast traffic still will not leave broadcast domain border;
if you created two interfaces in different zones depending on your fw config you may see traffic from one to the other but not the reverse direction by default, as forwarding rules are unidirectional;
Chromecast is using multicast, from one network to other network you'll need something like smcroute to route multicast traffic.
At first thank you for spending time with my chellange.
Second sorry that I missed to say that my 2 networks have a 255.255.255.0 sub netmask
I think most of your explenations are clear to me, even if I do not see a solution to my problem.
But as you say that communication does not need to be devided by sub nets (192.168.1.x & 192.168.2.x) maybe a different approach in the same subnet could help for all my different devices I try to handly.
The next absence is only a kind of brainstorming
What if I create 2 networks in the same sub net?
a Bridge Network with 192.168.1.1/24 and the second one with 192.168.1.2/24 that are only devided be independent firewall zones where the one is allowed to communcate with everybody and the 2nd on (IOT devices) can be restricted by FW rules to not have access to my wan zone (internet).
due to the same subnet mask it is maybe possible to see all the traffic as long I do not block something by fw rules.
Of curse I need to take care of all my ip adress ranges also for the DHCP server. Even if all IOT devices and chromecast will always get a static IP.
Just a side note:
Did anyone have a clue why in a bridged network with LAN and Wifi interfaces broadcast packages from an Wifi device will not be presented on the LAN interfaces?
Same network, same Subnet, same FW zone
i don't want to confuse you, maybe my wording is misleading (or i am totally wrong) but:
while you can have multiple ip address (L3) assigned to an L2 device, but a bridge device allows all members to communicate each other, i.e. acts as a switch. like using the default config where all lan ports are combined into br-lan bridge device (and an interface is assigned to this bridge) clients connected to any member ports can access each other.
i am not sure, this should be tested, if you have a bridge network with two interfaces in different zones what happens for example with firewall rules creation. usually generated fw rule set has a zone_input, zone_output, zone_forward structure but the logical interface names are references with their respective device names in the fw rules. so not sure the two interface on top of the same L2 bridge device how would be handled, e.g. if both sets of rules are generated pointing to same device, the order of rules would matter in this case i think.
so i'd suggest to rather fine tune your existing setup with smcroute, i.e. two bridges (lan1+2; and lan3+4), assign interfaces to each in different zones (lan+iot); allow lan -> wan+iot and iot-> wan and with smcroute allow multicast from iot to lan. this might help.
but either way, must be tested. i hope though someone smarter will come with an easy solution for you.
After playing a bit with different possibilities, I come back to the simplest and working solution for me.
All clients in the same WiFi and Subnet.
Adding a firewall rule for individual cloud based devices (IP addresses) to reject all transfer to the wan zone.
That avoids all the difficulties with broadcasting devices and multicast DNS packet transfer.
never the less thanks for the interesting suggestions,
Mario
