As the number of Internet connected devices in my home slowly grows, I decided I want to have a bit more control over their network access and keep them separated from my self-administered devices. So I created a second WiFi network, created a firewall zone that covers that network and started to configure firewall rules for it. I'm currently mostly using the LuCI GUI for that.

However, I noticed that I apparently still don't understand some terms and concepts completely and thought I'd start a thread to collect my questions that turn up in relation to this.

So, first some general questions:

• I'm not sure I have understood the concepts of the INPUT,OUTPUT, and FORWARD chains correctly. Here's what I think I figured out:
  

  • INPUT governs traffic originating from devices in the zone that has its final destination on the router. Examples for this would be DHCP requests or DNS lookups

  • In general, FORWARD covers traffic that goes from one network to another.

  • FORWARD in the "General Settings" for the covers traffic that originates at devices in the zone and tries to reach devices on another network in the same zone. So, for a zone that only covers one network, this setting would not have any effect.

  • OUTPUT covers traffic originating on the router and going to a device in the zone. I'm not quite sure qhat kind of traffic this would be. Would this include DHCP or DNS replies from the router? Do packets that were accepted through another zone's FORWARD chain also still go through the OUTPUT chain of the zone they are entering?

• I haven't quite understood how stateful the firewall is or isn't. Apparently, checking "allow forwarding to destination zones" also allows answers on connections initiated from within to reach the originating device. Adding a rule that allows forwarding from a specific device to the WAN zone seemingly doesn't. Is there some systematic to that?

On a more specific note connected to my last question, my first try was to create the zone with DROP or REJECT as the default policies for all chains. I then added a rule that allowed traffic from any device in the zone to ports 67 and 68 on the router with the intention to enable DHCP. However, the firewall apparently filtered out the DHCP answers. What would a (set of) rule(s) need to look like to allow DHCP within the zone?

Thanks in advance for any answers! I'm sure I'll come up with more questions along the way.

(Last edited by Manul on 25 Jul 2017, 16:48)

Nobody? I could really use some help here.

To get the obvious out of the way, I'm not an iptables expert. The following is my understanding on how things work, and thus it might not be completely accurate. But I believe it is quite close

Before going to your questions, I recommend you read http://www.thegeekstuff.com/2011/01/ipt … ndamentals. If you have the time, you can also look and study this image https://en.wikipedia.org/wiki/File%3aNe … t-flow.svg

A key point to understand is the distinct difference between netfilter which is the kernel-side module that implements the firewall and 'iptables' which is a user-space program used to control the netfilter module. In addition to these, OpenWRT comes with a user-space program called 'firewall' (or 'firewall3') which is an OpenWRT-specific tool used to control 'iptables'. The configuration file at /etc/config/firewall contains instructions for the 'firewall' or 'firewall3' program. The terminology used in this file resembles that of iptables and netfilter, but is not exactly the same.

The 'table', 'chain' and 'rule' concepts belong to netfilter and iptables. The 'zone' is a 'firewall3' concept, and 'network' belongs to /etc/config/network.

To sum things up, 'network' helps in managing physical interfaces, and grouping them into "networks" (Ta-daah!) while 'zones' help in grouping 'networks' that should be controlled by same firewall rules. The settings administered to 'network' and 'zone' then control what gets generated and placed into the 'tables', 'chains' and 'rules' of the netfilter and iptables.

The "Chain of Command", in short terms:
/etc/config/firewall -> 'firewall3' -> 'iptables' -> 'netfilter'.

------

Now then, the questions:

This is correct. This INPUT affects the INPUT chain found from the FILTER table. See the above link I mentioned.

This is also correct.

The router will look at its "routing table" to determine which interface it should forward the packet to. The netfilter will then step in to determine if the packet is allowed to traverse to the destination interface. If allowed, the packet will arrive at the target interface. From here, it may either go out directly without consulting any further chains, or it may enter the INPUT chain. In this latter scenario, the first interface received a packet which was destined to the router, but was using an IP address that belongs to a different interface of the router. The FORWARD chain is found from the FILTER table.

Note: If packet mangling (QoS scripts) or NAT is involved in the operation, it gets a lot more complex. See the image I linked above.

There are two "General Settings": the default policy applied to the built-in chains in the FILTER table. These are found from the very start, near the "Enable syn_flood protection". There are also the zone-specific default actions found next to each zone.

The default policy applied to the built-in chains kicks in if no rule in these chains matches a packet, and comes into question e.g. when a physical interface does not belong into any network (and thus, does not belong to any zone). It is, afterall, possible to configure an interface without the help of /etc/config/network altogether. But the physical interface is still subject to netfilter's operation.

The default action of a zone, on the other hand, is a rule that is added to the end of the zone-specific chains and matches packets that were not matched earlier. It does the same job as the "default policy", but only from the zone's perspective.

The FORWARD setting of a zone, according to my understanding, controls how packets are forwarded by default in the zone. Usually you set it to "reject" or "drop", and then specify an explicit forwarding rule between zones. If you set it to "accept", then you do not need any explicit forwarding rules as forwarding is allowed by default.

OUTPUT chain of the FILTER table deals with packets that are generated by the router. The packets do not necessarily 'go out' of the router. Examples are DHCP and DNS replies sent out to hosts (which really do "go out") and local loopback packets that one process in your router is sending to another process in the same router, but on a different port. All these packets traverse the OUTPUT chain. Additionally, the local loopback packets also traverse the INPUT chain.

The answer is 'sometimes'. See the image I linked earlier. Find the OUTPUT chain of the FILTER table (middle right and lower right corner, in the green and blue areas) and see when stuff goes through it.

If the WAN zone uses masquerading (NAT), or if the 'conntrack' option is set to '1' in the zone, then connection tracking is enabled, and return packets that belong to an earlier connection are allowed automatically. New packets coming from the same outside host to same inside host are blocked. "Allow forwarding to destination zones" should not, by itself, enable connection tracking.

A DHCP client should use port 68 to send its packets, and a DHCP server usually uses port 67 for listening and for responses. To facilitate your scenario, allow incoming and outgoing UDP traffic to/from port 67 on your router from any host and any port in the zone. You could restrict the source port to 68 for the client, but different client implementations might hamper your success.

(Last edited by Antek on 31 Jul 2017, 20:09)

It will probably be a couple of days before I'll be able to fully digest all that information and consequently try to apply what I've learned, so I just wanted to pop in a quick thank you for this very helpful post!