Question on the appropriateness/efficiency of a complex iptables rule...

Say I have three laptops, connected via VPN, that I want to allow to access three IP cameras, on three different ports. Would a couple of smaller rules be better than one big rule?

e.g., Below is an example of the "big rule" I speak of (multiple source IPs, multiple destination IPs, multiple ports). ESTABLISHED/RELATED packets have already been allowed previously. The VPN'ed laptops have fixed IPs assigned via OpenVPN/CCD and the cameras have fixed IPs via DHCP reservation.

The above rule covers a bunch of different combinations. Is this considered good or bad practice? Is the above rule going to be faster or slower than a bunch of individual rules?

Also, is there any benefit (speed or security) to "tightening" the rule any further with things like "-p tcp" and/or "-o br1"? The cameras are on a different network "br1", but their specific IP addresses that were already mentioned in the rule pretty much covered that. Similarly, I don't see any great need to specify TCP protocol only, because the rule is already locked to the specific camera IPs, and the cameras aren't going to respond to UDP anyway. So I don't see how over-specifying stuff gains you any functional difference ... but what about efficiency? Maybe specifying the seemingly redundant TCP could allow the rule to jump out of processing sooner and therefore make it more efficient.

Thanks in advance for any advice on this.

I found out a few things about the iptables that is implemented on my router (which runs FreshTomato 3rd party firmware). It does not recognize multiple source or destination addresses. So "$IP_1,$IP_2,$IP_3" type specifications for -s or -d are out. I only checked the comma separated syntax, I did not check the dash separated range syntax, which may or may not work.

Also, I found that my routers implementation of iptables would balk at things like "-d $IP_1 --dport $PORT" unless I additionally add "-p tcp"

So all my questions become moot at this point. My routers iptables implementation told me in no uncertain terms that the "big rule" I was proposing was a no-go. Other implementations of iptables may allow big rules, but mine does not. FreshTomato firmware must have implemented "iptables light", not "full iptables".

The best way to learn the answer to that is to read the documentation where it explicitly states:
i.e. it's an interface shortcut; you get individual rules either way.

If there had been a difference, the only way to determine efficiency would be profile both under equal conditions and compare. However, given these rules only apply to the first packet of any connection, any difference would likely be inconsequential.


So run "iptables --version" and find out what you've got.

It may not be a cut-down version, but simply an old one: a quick search confirms v1.4.7 only allowed a single address, but by v1.4.14 in 2013 a comma-delimited list of (non-negated) addresses was accepted.

Thanks for the response.

Router firmware:
FreshTomato 2021.7

iptables version:
1.3.8

Yikes! But it could have been a choice of the firmware developers. There is precious little RAM and flash memory to work with on a router compared to a full scale computer. They may have picked versions of these applications that were smaller or used less RAM or CPU than current versions.

I am not in the habit of replacing firmware on the router every time a new release comes out. If there is an update for a security problem that I find out about, or a fix for an issue that I myself am experiencing, then that is cause to upgrade. The addition of new features does not interest me for the most part. What I need feature-wise, my current firmware provides. I probably should upgrade more frequently, as the router is typically the first door that hackers must pass through. I have other doors, but it is a good practice to close all of the doors to create more layers of security. That, and the fact that I didn't realize my version of FreshTomato was that old (this could still be the newest release for all I know - I haven't checked since installing it). Just because the vast majority of router owners never upgrade their firmware from the OEM default that was installed when they bought the thing - that's not an excuse.