Not exactly, if two devices are connected to wired VLAN 4 through your switch, they will be able to send packets back and forth going directly through your switch without your router even knowing those packets are flowing....
I do think you'll be able to prevent wired devices from talking to your wifi and vice versa though.
Check the "bridge" box then add the two interfaces.
Since the bridge operates at layer 2, the regular layer 3 firewall can't prevent wired guests from accessing the wireless ones. There is such a thing as a layer 2 firewall but I've never used it. Of course two wired guests will always be linkable through the switch. Selective blocking like that won't be found in a consumer type switch.
You should have a firewall rule blocking guests from everything in 192.168.0.0/16, so they can't mess with your router and modem. Then you need to make a hole in that wall so they can DHCP from your router and maybe DNS (or change the DHCP rules to direct them to a public DNS).
I understand. It is not really a consumer switch. It is fully manageable pro switch that has horrible GUI It has RADIUS support, tagging and whatnot. I just need to learn how to use it. I assume tagging every port with it's own VLAN might work, but that is "nice to have" at this point :).
Guest zone is tight as a drum. Guests can only surf the Internet (throttled), not ping each other or even ping the router itself. Bridging it to VLAN4 will relax it somewhat but it will be fine.
Basically, port 1,2,7 tagged for VLAN4, port 1,2 tied to VLAN4 only and ingress filtering on port 7 disabled (otherwise it would strip all tagging).
Now only thing I need to do is to make new Firewall zone for my new "IoT" network. I would like it to be just like LAN, but devices should not be able to ping each other and only be able to communicate on defined port numbers. Any hints on how it should look like?
A snippet from firewall-config file describing such zone is also most welcome
I'm not clear exactly on whether this config is correct, do the devices connected to switch ports 1,2 use tags? Like, maybe they are access points or something?
If they're desktop computers or whatnot, you should have ports 1,2 untagged with PVID 4. Otherwise the switch will send tagged packets to the devices, and the devices will be confused and drop them on the floor.
Also if port 7 is supposed to only carry tagged packets then you probably want acceptable frame types to be "tagged" rather than admit all
Stuff that is connected to this port is basically a IoT device "hub/base station" whose firmware I have no control over. It just gets IP from DHCP and connects to "The Cloud". That is why I want it outside of LAN on it's own network.
Hm, this probably explains why it didn't work when I just added eth0.4 to "Guest" zone...computer attached to port 1 worked just fine (like being on Guest WiFi) but smart hub did not work It probably didn't know what to do with tagged traffic?
Correct, make those ports untagged and give them the port VID of the VLAN they're supposed to get connected to, the switch converts between tagged and untagged using the port VID.
Standard practice is to use ONLY tagged packets between infrastructure devices: routers, switches, access points, etc. This makes it very explicit what the VLAN is, and avoids having mismatches in port VID and lets you filter out any unwanted VLANs etc.
To do this convert your router to use tagged interfaces on all its physical settings, eth0.1 and eth0.4 for example rather than eth0 and eth0.4
Can you please explain best practices to make switch <--> router VLAN setup work well with different VLAN's? (So I can configure different switch ports to take different "ways/zones" in the router)
I would like to have my IoT traffic as VLAN4. It will be connected to ports 1,2. Currently, I have untagged ports 1,2 (my "IoT" ports) and gave them PVID 4.
Everything else can be VLAN1. I suppose I need to reconfigure my OpenWRT LAN interface from eth0 to eth0.1 to do that? But before I go that way, I better make sure that LAN traffic to router (on port 7) is indeed tagged as VLAN1 or I would basically "lock myself out" of the router, right?
Let's lay out what you want at the end so I don't give bad advice... what I think is:
VLAN 1 is your LAN
VLAN 2 is your WAN
VLAN 3 is your guest
VLAN 4 will be your IoT network
eth0 is your internal interface
eth1 is your external interface
This means you should make
br-lan containing eth0.1 and a wifi interface be your LAN
eth1.2 be your WAN, or possibly eth1 and plug it directly to your ISP equipment rather than go through the switch.
br-guest containing eth0.3 and a wifi interface be your guest
br-iot containing eth0.4 and maybe a wifi interface be your iot
The eth0 interface is plugged into your switch on port 7. Port 7 should accept only tagged frames, and belong to VLAN 1,3,4 as tagged member.
Some IoT wired devices are plugged into port 1,2 so these ports should be UNTAGGED members of only VLAN 4 with port VID 4 and accept only UNTAGGED frames.
How to avoid locking yourself out
You'll want to convert your router to use eth0.1 as its LAN interface, and convert your switch to send tagged frames for vlan1 on port 7... but if you don't do it simultaneously, you'll wind up locking yourself out... since you can't do it simultaneously, here's what I recommend... first convert the port on the switch... now you'll lose wired connectivity to the router... but log in on wifi and convert the router... you're back connected.
Another pro-tip: you can create a wifi SSID and a VLAN specifically for management. use tags on the vlan, and a separate SSID, password / encryption on the wifi.
I started by (U)ntagging ports 1,2 and (T)agging port 7 for VLAN4. Then I enabled ingress filtering for all ports (which is default).
I made a copy of "Guest WiFi" Firewall zone rules and called it "IoT" Firewall zone.
Then I created interface "IoT", gave it IP and DHCP (in separate subnet) and tied it to eth0.4 and "IoT" Firewall zone.
That did it. My dodgy chinese "black box" IoT "router" is now able to go on Internet but not able to ping anything else outside of its own "IoT" network. I tested it by connecting a PC and trying to ping other IP's (and even configuring another IP manually and then trying to ping). That basically solved the issue I started this thread for.
But now I learned more from you and would like to tag all packets between switch/router so I can create other funky "subnets" in the switch and let router decide what to do with them.
So as my next learning step I would like to tag my LAN traffic (basically everything else coming from switch port 7 into router eth0 and then rename router interface LAN from eth0 to eth0.x (x being new VLAN).
What needs to be done on switch side to do that? Currently, all ports except 1,2 are (U)ntagged for VLAN1
and it seems it cannot be changed (VLAN being "default").
Should I create a new separate VLAN5 for LAN traffic, tag those ports and then configure router LAN interface for eth0.5? Or are packets already tagged by switch as VLAN1 by default so I do not need to do anything in the switch?
By convention the trusted network (LAN) is VLAN 1, so you can leave it that way. In the router, eth0 should only be connected to a network using a tag number (eth0.x), so the packet goes out tagged and the switch can deal with it. Do not attach plain eth0 to anything, that results in mixing tagged and untagged packets on the cable.
The PVID and Ingress Filter settings determine what happens when an untagged packet arrives on a port set up to be tagged (trunk cable). Ideally that should never happen, and such packets should be ignored (Ingress Filter does not allow them, which in this case means set it to "Disable"). Those settings are there for the very few cases you may have to interoperate with a device which sends both tagged and untagged packets on its cable.
Actually I think here "Disabled" means turn off ingress filtering, and "Enable" means turn on ingress filtering. Ingress filtering means it will reject packets coming in that aren't for VLANs that the port is a member of. So I think you should have ENABLE on all ports.
As for packet tagging for LAN, I explained how to do that above: