1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Simple firewall rules on shibby

Discussion in 'Tomato Firmware' started by michael.santos, Dec 1, 2016.


Would be a web interface for simple firewall rules on Tomato firmware useful?

  1. Yes

    14 vote(s)
  2. No

    7 vote(s)
  1. michael.santos

    michael.santos Connected Client Member

    Hi community,

    I know that IPTABLES is very powerful but I think Tomato firmware should also have a web interface for simple firewall rules.

    Every cheap router nowadays has this feature implemented so anyone who does not fell so comfortable with IPTABLES command line could implement some simple rules (ex.: port blocking, drop connection between VLAN's when from source to destination, etc.).

    This web interface could generate and fill the firewall script that already exists (with a warning that every time you save the rules, it would replace the firewall script!). With this method the more experienced users could still tweak or create their IPTABLE rules.

    I was thinking something like the Easy Firewall Generator project, but integrated on Tomato's GUI.

    I have attached an example from a ZyXEL WLAN Controller that may also use IPTABLES internally.

    I think this is the unique feature I still miss on Tomato firmware (I came from a Netgear Router with DGTeam firmware from back 2009 that already had this feature implemented!).

    I hope this time someone will look at this feature as a valuable feature. I can beta test it if needed (Asus RT-N18U).

    Let me hear other opinions... What do you thing about this feature and would it be useful? If not, why? Would you use it for simple firewall rules if it where available on the Tomato's GUI? Why are other things (like Torrent Download, etc.) that have nothing to do with routing more important than a feature like this? Fell free to comment! ;)

    Edit: the AsusWRT, that is based on Tomato, already has a limited implementation, so it should be possible to port it to Tomato by Shibby relative easy, or not?

    Thanks! :)

    P.S.: I have added a pool only to check if there are other "normal" tomato users (please be in mind that this feature is not intended for power users!) that would like this feature implemented on Tomato...

    Attached Files:

    Last edited: Dec 1, 2016
    DomDis likes this.
  2. ruggerof

    ruggerof Network Guru Member

    Just curious, can't "Access Restriction" in the GUI provide the same functionality?
  3. michael.santos

    michael.santos Connected Client Member

    No... You can't create a rule with source and destination... You can't create an "allow" rule...

    Attached Files:

    Last edited: Dec 1, 2016
  4. michael.santos

    michael.santos Connected Client Member

    The AsusWRT firmware, that is based on OpenWRT, has something similar (Network Services Filter) but limited. We only can create rules and assign them to one option: a white list or a black list...
    Tomato could have something similar but let us assign every single rule to "allow" or "deny" without having to write a script for IPTABLES... A little bit more user friendly... :)

    Attached Files:

  5. microchip

    microchip Serious Server Member

    Actually, ASUSWRT is based on Tomato RT/USB, not OpenWRT
  6. Monk E. Boy

    Monk E. Boy Network Guru Member

    Actually, if you stop to think about it, large portions of the Tomato GUI are just iptables. QoS is iptables. Port forwarding is iptables. Access restriction is, in part, iptables.

    As is usually the case with open source projects, if you want a feature implemented, the best way to do it is to contribute your time and effort to implement it yourself and share it back with the project when you're relatively satisfied its working.

    I don't know about you, but I'm none too keen on making demands on people's time if money isn't changing hands and this isn't their full-time job. Even things like bug reports occasionally get kind of demand-y.

    I don't think this feature would be particularly difficult to implement - the logic to sanitize what the user types would probably be the worst of it (which is never pretty), but given the vocal contingent who want BCM_NAT and CTF enabled, this would be another feature that would require those settings to be turned off. And there's always the perpetual war between features & NVRAM space, in that this feature would by necessity eat up more NVRAM.
  7. koitsu

    koitsu Network Guru Member

    I'll chime in here, because hey, why not. I'm one of the people who voted No on this, because my sysadmin spidey sense went tingling out of control.

    What isn't made crystal clear here is that controlling the iptables details through a GUI is incredibly complex. iptables is one of the absolute WORST things to try and handle in this fashion, mainly because of how netfilter modules work and the fact that iptables, just like ipchains and ipfwadm before it (two Linux firewalls which odds are were before the times of many here), is a command-line utility that is intended to be run "once per rule/line". The GUI would literally have to handle every syntactical case there is, including for modules which aren't even "commonly used". The syntax and arguments of every one of these modules differs (this is why you have to do something like iptables -m {module} -h to get usage/syntax help for that module). You can also chain them together, e.g. iptables -m tcp {arguments} -m multiport {more arguments} -m mymagicmodule {more arguments} ... Then you have the fact that there are several built-in tables (filter, nat, mangle, raw, security), which all have some slight differences (mainly in chain names, but definitely in targets). The list just goes on and on.

    Then you have the unspoken inevitable: people would want to start extending the thing to do more and more. Let's say for sake of example it started simple: maybe it's just a GUI for a brand new iptables chain that's inserted into the INPUT chain in the filter table and can be managed through the GUI (i.e. it wouldn't affect the default/existing rules; iptables -F NEWCHAIN would clear it, etc.). Someone starts wanting some new feature or thing that they can do manually via the CLI but not the GUI. So it gets implemented. Then someone else shows up wanting something else. Or worse, they find that the NEWCHAIN reference in the INPUT chain doesn't fit into their exact rule orders based on how they've designed their network (this happens quite often around here, believe it or not), so now you gotta code a way to move *that* around.

    Oh, and then there's the security concerns, since all this has to be implemented by doing an execl() or system() calling /sbin/iptables.

    Did I mention parsing errors in iptables isn't easy because nothing outputs the same error, and some modules don't even result in a non-zero exit code?

    From a programming and software perspective, this is total nightmare fuel in every way/shape/form.

    And finally, we need to face reality if it was to be written (even a simple implementation that just added rules to a new chain that went into INPUT, like I described): who is going to write/code this? Like with most feature requests I see proposed, the proposal never includes who will actually do the work (and a lot of the time, the proposer doesn't know how to do it either).

    All this is why I voted No. It's my vote citing concerns with regards to the reality and practicality of the request at hand. (I say this with no judgement towards the OP, by the way -- I'm only referring to the scope of work)

    The situation is different on, say, FreeBSD or OpenBSD with pf(4) -- there's a config file with a defined BNF, and the options/arguments/etc. are all statically known. The config parser ensures you can't botch yourself: there is no "oops, I ran mymagicfirewallprogram in the wrong order, now I'm buggered!" It's not a firewall implemented through glorified shell scripts. I would bet OPNsense, pfSense, and m0n0wall probably all offer something like this (Googling details for pfSense: yeah, it does).
  8. michael.santos

    michael.santos Connected Client Member

    Thanks for the correction. I though it was from OpenWRT because of the name... So if it is based on Tomato, there should be source code available from this part and an integration/modification easier, or am I wrong?
  9. michael.santos

    michael.santos Connected Client Member

    Just keep in mind that I'm not demanding anything, I'm just discussing ideas... ;)
    Last edited: Dec 1, 2016
  10. michael.santos

    michael.santos Connected Client Member

    I understand what you mean, but like I wrote on the title, I am discussing about a GUI for SIMPLE firewall rules... Something that we already see on cheap routers nowadays or on the almost "perfect" AsusWRT feature with the only limitation of choosing to apply all rules to one whitelist OR blacklist, missing the "AND" feature...

    If we start thinking that in future it cold become more complex with new features and because of that we don't thing on implementing basic features, then the Tomato firmware never reached what it is today...

    If with simple features is doable, I would prefer to have such a feature than not having it at all. For complex features we still have the scripting section of the firewall...

    I still don't understand why is this, that is part of the work of a router (routing packets), lower priority than features that normally belongs to servers (file server, print server, torrents downloader, etc.)?

    If I knew coding and had some help from a iptables power user, I definitely would have tried to implement a GUI for simple firewall rules, based on the already available work from AsusWRT... But it is only my opinion... ;)
    Last edited: Dec 1, 2016
  11. Mr9v9

    Mr9v9 Serious Server Member

    Hell why don't we just add in a content filter while we are at it? :D
  12. michael.santos

    michael.santos Connected Client Member

    Because it is a work for a proxy, not a router... ;)
  13. microchip

    microchip Serious Server Member

    There is source code available, that's how RMerlin makes his releases. But most of it is so heavily modified or rewritten, that I doubt it can easily be compared to stock Tomato these days.
  14. DomDis

    DomDis Network Newbie Member

    This would be cool and I think I just asked, in another post, if Tomato can do this.

  15. DomDis

    DomDis Network Newbie Member

    Oh the date on this post was back in 2016 - I wonder if any advances have been made - I'll keep searching
  16. michael.santos

    michael.santos Connected Client Member

    It seems that nobody cares about this basic feature and think every basic user is able to create iptables scripts... They forget that not everybody are network engineers... It seems also that it is more important to have features that should not be done by a router, like torrent downloading, file sharing, etc... It is sad, but reality...
  17. DomDis

    DomDis Network Newbie Member

    Its truly a shame. The first thing that started to worry me with tomato is when it warned me about using a 10.x.x.x. network.

    I think the ZyXel provides a little more that simple firewalling but its proof that it can be done. I have also used a Snapgear in the past and that too had firewall rules. If I'm not mistaken you were able to order them or tell the router to continue or not continue (to the next rule) if the current rule matched

    I have used Bordware & WatchGurad Firewalls but they commercial products. Visiting the ZyXel site the USG are categorized as enterprise or "commercial" products. I don't know if the lower end Zxel have the same features as the USG. If the only difference between the ZyXel home version and business version is the ability to purchase subscription services then I may change to a ZyXel but I have to research this.

Share This Page