Firewall traffic rules override zone settings?

Installing and Using OpenWrt Network and Wireless Configuration
1

I configured a separate network with a separate interface on a different subnet than the LAN network that I only use for IP cameras.

I do not want to give the cameras network access to the internet or to the LAN devices to avoid the cameras to access internet through WAN interface (phoning home). It can be done by just creating a firewall rule that reject forward traffic to WAN interface from the specific camera IP addresses (if on LAN network).

But since I also do not want the cameras to be able to sniff/manipulate LAN traffic, I chose to create a new interface that uses a completely isolated physical network port (that on my device is its own NIC, not a VLAN). The only traffic I let through is DHCP and NTP for synchronizing the camera's time with the NTP server in OpenWrt. I created a firewall zone only for the camera network.

But now I have some questions about the function of the firewall rules. To be able to get DHCP server to hand out IP addresses properly, I set up a firewall rule allowing DHCP on port 67-68 as per the tutorial on guest WLANs.

Please explain to me in what order those rules are executed? For this rule to work i had to set Output=accept in the settings for the cam zone. Why is this?

When output is set to accept, it seems like only the traffic that is specified in a firewall rule gets through? Isn't it supposed to be the opposite, that a specific firewall rule can override the rules set for the firewall zone settings?

config zone
        option name 'cam'
        list network 'cam'
        option output 'ACCEPT'
        option input 'REJECT'
        option forward 'REJECT'

config rule
        option name 'Allow-DHCP-Cam'
        list proto 'udp'
        option src 'cam'
        option dest_port '67-68'
        option target 'ACCEPT'

config rule
        option name 'Allow-NTP-Cam'
        option src 'cam'
        option dest_port '123'
        option target 'ACCEPT'

config forwarding
        option src 'lan'
        option dest 'cam'

It must be correct that output=ACCEPT means the devices in the specific zone can initiate a connection to the OpenWrt device (for DHCP and NTP in my case)?
But, for the cam zone input is set to REJECT. I can still ping all the cameras from the OpenWrt router's shell console, and reach the camera web interface from a computer in the LAN zone. Wouldn't traffic originationg from OpenWrt device be rejected since there is no specific rule set for that?

Is it because I have set forward to ACCEPT and that the OpenWrt device is in the LAN zone that is possible?

I find it quite a bit confusing and the documentation is not very clear how everything works together.

2

From the perspective of the firewall, OUTPUT controls the egress the firewall itself for each zone.

Per the above, this is controlling traffic egress from the firewall.

It depends on structure and action of the rules... for example, input is a really easy one -- if you drop/reject input, devices cannot get a DHCP lease or DNS services from the router. Adding additional rules that accept this type of traffic will work.

IIRC, if you're dealing with output, you would have to make a rule that has a source of the firewall ("this device") and a destination of the zone or hosts in question.

Output is almost always accepted -- there are only a few rare situations where it should be dropped/rejected.

2 Likes
3

Thanks! Really helpful.
Do you mean that output=ACCEPT is the data egress from the devices on the "cam" zone, for the devices in that zone to be able to contact the DHCP server and request IP adresses?

And then, input=REJECT is overridden by the specific firewall rules so that the DHCP server can answer the request and hand out IP addresses?

4

Because the initial dhcp packet from a camera is not addressed directly to the OpenWrt DHCP server. After all the camera doesn't know its existance, so it is broadcasting it to the whole network. Then the DHCP server of OpenWrt will get the packet because you have allowed udp 67 for INPUT. But when it replies to the dhcp client it is using unicast packet and not broadcast, so the answer is not related to the solicitation, and the firewall is blocking it.
For example this one will work with OUPUT set as REJECT as well.

config rule
        option name 'Allow-DHCP-Cam'
        list proto 'udp'
        option src 'cam'
        option dest_port '67'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCP-Cam-Reply'
        list proto 'udp'
        option dest 'cam'
        option src_port '67'
        option target 'ACCEPT'

But then you'll have other issues, like you won't be able to ping for troubleshooting from OpenWrt to the cameras, which means you need to add another rule to allow that. This can be quite a burden and usually the OpenWrt is considered secure, so we don't regulate the traffic it originates from it.

3 Likes
5

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.