How to make a firewall include script fault-tolerant?

Hi folks

For those who don't know yet, I'm developing a project which does geoip blocking via firewall rules.

The way it integrates with OpenWrt is this. At installation time, the following actions are taken:

  • My scripts are copied into the system and config is set.
  • The mk-fw-include script is added and run, which makes sure that the firewall include exists and if not then adds it.
  • The firewall include calls my -run script. The -run script then checks whether required nftables or iptables rules and sets exist and if not then loads them from backup (if backup doesn't exist then the the -run script initiates download of ip lists and creation of new firewall rules and sets).
  • An init script is added which triggers on system reboot and on firewall reload and calls the mk-fw-include script.
  • A cron job is added which periodically calls the -run script to check for ip list updates.

All this works fine, as long as nothing went wrong. The problem I'm currently facing is that if something goes wrong in the -run script and it errors out then the system gets stuck at boot for a long time.

Presumably it tries to load the firewall include for a long time before it gives up. Yesterday, while testing on my router, I accidentally removed some essential variables assignment, and after rebooting the router, I thought it got bricked because it wouldn't complete the bootup (the router still uses a fw3+iptables OpenWrt if that matters). Eventually it recovered.

Anyway, the question is: how should I go about preventing a simple error in the script called by the firewall include from almost-bricking the system? Should I make it always exit with status 0, regardless of the actual state, or is there a more elegant solution?

Sorry about the recent questions spam. I'm new to developing for OpenWrt, and while I do RTFM, the documentation is not always clear.

That is, as I understand it, your project will block users based on geolocation? It would be better if it were the other way around, unblocking users, it would be much more useful

It works either in blacklist mode (blocking specific countries) or in whitelist mode (allowing specific countries). And it supports blocking (or allowing) certain ports on each TCP and UDP. So there is a lot of flexibility, and the user decides how to use it (via a user-friendly interface).

All this is cool, of course, but your creativity, as always, falls into the wrong hands and ordinary users will be left without normal Internet.
Three people will thank you for this project, but if you do the opposite so that you can bypass the ban, then millions of thanks to you

1 Like

Maybe run your script in the background so that it does not block further execution?
A script can be run in the background by adding a "&" to the end of the script.

You might want to look at adblock scripts like adblock lean they also download long lists and manipulate those

2 Likes

dear @fkl7834456

  1. You think my little project will make a big difference to the Internet? Haha
  2. Commercial firewall products have geoip blocking capabilities, these run on an actually large scale.
  3. OpenWrt deserves a proper geoip blocker not less for people who need it.
  4. OpenWrt already has some tools which essentially perform similar tasks, just not in the same way (I won't go into comparison here).
  5. Your replies are off-topic. I understand your concern but it's unfounded, and you are not helping me here.

In addition to @egc's suggestion above, please also consider how I handle exactly this situation in cake-qos-simple:

That is:

  • generate nft.rules file (using a here document);
  • check its validity before doing anything using nft -c; and
  • if all is well, load in the file using nft -f, else error out.
2 Likes

Thanks, I'll take a look.

Thanks, I'll take a look into your solution.

Eventually I went with @egc 's suggestion to run the script in background. I don't really want to convert my code into generating nft rules which then would be loaded via an include, for several reasons, including that this adds complexity, and that currently loading a large ruleset with multiple ip lists into nftables at once requires more memory than loading sets one by one, and so is less suitable for memory-constrained devices. Otherwise I think that my script's internal ip lists validation is adequate, and the generated nftables rules are very unlikely to have any issues in them.

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