What are you trying to achieve and what is happening?
What @flygarn12 said is correct, but the nuance that wasn't stated is that the firewall is what allows or prohibits (or selectively allows/prohibits) inter-VLAN connections.
You have not actually told us anything about what happened when you put multiple VLANs in the same zone... simply saying:
... doesn't tell us anything about your actual results (nor does it tell us what you're trying to do).
Chances are that we can help you solve your issue in an efficient way (or if it is something that cannot be done because of a technical reason, we can tell you why), but we need to know specifically what you are trying to achieve and what you are experiencing when you attempt to accomplish that goal.
The purpose is compartmentalization, I put trusted devices in the LAN zone. I also want untrusted devices (guests, IoT, etc.) in untrusted compartments, I also want untrusted devices to not probe each other preferably, a VLAN for each one would be ideal, even if it's cumbersome. Thinking about it, maybe your solution of creating an untrusted firewall zone and throwing all the untrusted VLANs there with forward policy set to Reject would achieve the same result as a different firewall zone for each VLAN. I'm not sure.
Also, in theory there would be no point allowing 53 and 67 to device since the interface address is supposed to be the device, right? I'm still understanding the host model.
There are a few ways to prevent devices from probing each other...
at an inter-network level, if you have 2 or more networks, you can prevent them from talking to each other simply by not allowing forwarding between them. If they are in the same firewall zone, use the zone-level control: forward = drop/reject to do this. If they are in different zones, simply don't create forwarding rules between the two or more networks.
at a intra-network (i.e. the same network), this is much harder to accomplish. For wifi devices, you can use wifi client isolation. That will make sure that no wifi clients can talk to each other. This doesn't prevent wired <-> wireless connections, and it also doesn't work all that well if you have multiple APs. Otherwise, all traffic within a single network is switched, so it is hard to isolate clients (you can use a bridge firewall, but that requires that you have a bridge between each of the devices and the rest of the network, so it's only practical for a very small number of devices
Yes, that's what I was getting at. It makes for a much more compact firewall. Basically any networks that have the same desired allowances/restrictions at a firewall level can be put together into a single zone... there are nuances for when you want to have different zones vs one zone containing multiple networks, but often they can be consolidated.
I'm not sure what you're getting at here.
Port 53 is DNS -- Any device on your network(s) that needs internet access will also need DNS. You can provide DNS services on your router or not... but if you don't, you need to advertise other DNS options to the client devices or they won't be able to access the internet (from a practical perspective, that is... no DNS = no name resolution = practically no useful internet).
Ports 67-68 are DHCP. If you don't provide DHCP services on your network(s), your devices cannot get an IP address on your network automatically. This means that you would be required to set each device manually with a static IP (this must be done on each device individually).
Ok, I will consolidate them within a single firewall zone rejecting input and forward and allowing only output. I also have a firewall zone for untrusted devices connecting via VPN, that zone is set to drop output too, and strangely it works, whereas if I deny output to zones pertaining to phisical devices (ethernet/WiFi) they have no Internet connection. Do you know why is that?
What I'm saying is: I never allowed those port for devices in LAN, but I have to allow them for VLAN, why? LAN interface address (192.168.1.1) points to the router, but so does VLAN interface address (192.168.2.1), so why do I have to allow ports for VLANs but not for LAN?
You need to look at the input/output rules from the perspective of the firewall itself. Input is actually traffic destined for the firewall (to interact with the actual firewall/router). Output is basically the data exiting the firewall itself towards the network (or zone) in question (if I'm thinking of this in the correct way)... if you block that traffic, stuff from the internet enters into the firewall but can't actually reach the network for which it is destined.
because on your trusted LAN, input = accept. on your untrusted networks/zones, input = drop or reject. That means that hosts on the LAN can reach the router, including for DNS and DHCP services, while those on the other networks cannot. You must specifically allow those services if you have set input to drop/reject.
You don’t, unless you have made listing change to the uhttpd config file the router listen to all addresses you can even imagine on the port 80 and 443.
So you set what IP address you need to use to call the router in uhttpd. The firewall control from which zone you are allowed to access the port 22, 80 and 443 by calling the uhttpd IP address (or dropbear for port 22).
But every zone with Input=accept is all allowed to call “device” (router) by Input data to the device.
Right, right, I still have problems grasping the host model, thank you @grrr2 for replying as well. I thought accepting input would be needed for incoming connections from outside, in this case though, I can forward ports even if input is set to Reject, correct?
Ok, but the clients connected to the VPN have Internet access, which they shouldn't have since output is set to Drop there
Yes. Input is irrelevant here.
Think of it this way... Input refers to packets that are destined for the router itself (as an entity). It's like if you send a physical package or mail to UPS/FedEx/USPS/any other carrier. Normally, you send packages via/through those carriers, so the carriers themselves are not the recipients. Only if the carrier (router) is itself the intended recipient would you need to allow input.
When you port forward, the router is simply passing the data connections through (it becomes a carrier in the mail example) between the internet and the host that is designated as the recipient (the port forwarding is basically telling the routing/firewall engines who should receive the requests that arrive on a given port on the internet facing interface).
let me think about this... I might have it backwards. A while back, I got used to the way that Ubiquti EdgeMax's firewall works, which is not a ZBF (by default, although you can do ZBF if you want on that platform). The definitions of the terms are slightly different, so I might be confusing myself due to this.
There's a great firewall explanation for edgemax (which is actually based on Vyatta). I wish there was something similar for OpenWrt's ZBF... there might be, but I haven't located it yet. I'm still thinking about "output" in this context to make sure I have a correct understanding and the ability to explain it.
Maybe @lleachii can do a good job explaining the zone level "output" rule?
zone rule defines what you can do within a zone
and forwarding rule, whether to allow connection to made from source zone's device to destination zone's device.
your rules above translates to:
in vpn zone you drop everything, i.e. a device in vpn zone cannot send any traffic to router (input drop), cannot send out traffic to vpn device and cannot do any forward to other zone. with the exception (=forwarding rule) from vpn to wan.
@psherman - I am struggling to follow this thread TBH, some inquires of other posters are responded to as matters-of-fact, etc., when suddenly something else is introduced. Plus I'm still unclear on the use case...It would be so much easier if the OP described the setup and use case in its entirety, first.
Then I read that all VLAN clients use VPN?
Regarding output, this is specific to the OpenWrt itself. Basically, the Zone Output rule controls if the OpenWrt can send (initiate) packets to interfaces in that zone. Certain VPN technologies (i.e. Linux-Kernel-based) may still work if they are configured on the router. Aside from the VPN, this could mean that if a user sets output of REJECT or DROP they will not receive DHCP settings (DNS should not be affected because the tracking can determine that as related).
So I see the OP pasted a DNS rule and then noted:
It seems because the OP made a rule to allow the OpenWrt to make DNS inquires over the VPN - but did not allow the OpenWrt to send replies to the VLAN the client request originated from. It seems to be OpenWrt n00b confusion over Zone-based firewalling. It's OK.
Yeah... I've been hoping to see more details about the configuration and topology of the network, the goals, and the actual experience/what is happening. The OP, for some reason, has appeared to be reluctant to provide most of the details.
Yes, I agree. In fact, this thread has now gone on tangent after tangent and no longer resembles the original ask... maybe it is time to close this thread. The OP is welcome to open new threads with targeted questions -- this would make it easier to follow and to get good authoritative answers.
This is rather rude, don't you think... could you not simply just (politely) ignore responses you deem unhelpful instead? This is a volunteer forum so no one is payed to respond and hence no one owes you a response let alone one you consider helpful.
Ignore this, the thread turned friendly almost immediately after the cited text, so I likely misunderstood the mood....
I certainly felt it was rude -- it had been directed at me. But I decided not to react to it and to continue trying to help.
@sadcrew - I have no interest in arguing, and I'm sure you don't either... I'm glad we were able to continue the conversation in a friendly way. In the future, please keep in mind that most users here, including me, want to to help solve your problem... I'm sorry if you thought my comment (that precipitated yours) was rude (it wasn't intended that way). It just felt that the goal posts were moving, and I was trying to get more clarity. Anyway, all is good.
I'm sorry if I came across as rude, it was not my intention. I was afraid you wanted to argue semantics and I just wanted to cut short, I didn't mean any disrespect. I appreciate the help you and the others gave me.