Hi cfusco,
Ok so we can use an ipset which requires modifications via CLI.
So, then could we not just use the inbuilt iptables iprange command?
iptables -A INPUT -p tcp --destination-port 22 -m iprange --src-range 192.168.1.100-192.168.1.200 -j ACCEPT
Thanks.
Not sure, but I believe you can, using firewall.local script. Keep in mind, probably you know more than I do on these things, so take this opinion with a healthy dose of salt.
In addition to Post #8, I feel obliged to inform those who wish to use my way, to also be careful not to change the attributes I have framed in the figure.
If you switch a file from linux to windows, the framed permissions are also reset, and this is also fatal to IPFire files. When I was new to IPFire, I had to reinstall the whole system also because of making the error just mentioned.
A way to use ASN in firewall rules would also be great.
Inspired by @cfusco suggestion and observing @anowak rule
I did some tests on my IPFire CU174 test.
I am very satisfied and I must say that it works!!!
However, I noticed that every time I restart IPFire, the iptables rules are reset and have to be reinstated.
I found an unusual method to solve this problem, perhaps even as dangerous as editing IPFire files “by hand”.
I describe it with pictures…
Doing so runs /usr/iptables.sh with all the rules to be added to iptables each time IPFire is started.
Just edit that file (to customize it) and restart IPFire.
I am waiting for suggestions for any refinements regarding this system. Alternatively, is there a more professional way to save (in IPFire) the rules set with iptables?
Also because “fcrontab” I see that IPFire often restores it to its original state when the upgrade is performed. So, in my case, it has to be checked at every update.
As @cfusco suggested,
https://community.ipfire.org/t/network-range-within-firewall-groups/9508/15
you should use firewall.local and put your rules in the CUSTOMINPUT chain rather than directly in the INPUT chain, where if you make a mistake it could impact your firewall performance or security bu affecting the rules implemented in the code.
The wiki is your friend.
https://wiki.ipfire.org/pkgs/fcron
Thank you very much @bonnietwin
Although I think I am getting closer to a solution, I was sure that I had taken a risky path for safety and stability. I will rethink the whole situation better 
.
Once more. IPFire is distribution well designed and maintained regarding security and stability.
This includes the main configuration process:
An update presumes this proceeding. So all standard configuration files are subject for a modification to reflect a new software version. .local configs are untouched.
Additionally it is much easier to help with problems, if this structure is adhered.
I thank you for the valuable suggestions. In fact, I fully agree. I specify to users who see my example, that I did it on a forklift server installed in a VmWare. So, there I can do as many experiments as I want, which I need to understand. Should my images tempt people to do “dangerous” tests on good servers, I also invite them to remove them .
As your ‘experiments’ show, iprange can be used in IPFire.
It isn’t possible to generate a rule with the WUI (yet), but can be used in firewall.local.
You are invited to discuss a possible extension in the development mailing list.
I’ve always thought about it. I could use it very much. Also because I’m having tremendous difficulty solving the “IP range” entry problem by doing a safe and simple thing 
.
IPv6 integration would also not be bad.
However, I don’t feel like doing that. I do not know English, I am not a developer, and these are operations that I have never done. It is better for someone with considerable experience in these areas to do it.
I still can’t figure out how to use firewall.local. to “integrate” my “brutal solution”. But should firewall.local. be edited and modified?
I tried to open it (firewall.local), but I end up with some kind of “script language” and I have no idea what to write in it.
But a wrong modification of this file, isn’t it fatal?
Go to the IPFire Wiki and in the search box at the top write firewall.local and you will get a range of search results.
Looking through those results you will find some that give details of how to use firewall.local in a specific use case which you can then use that as general guidance for how to create your own input for your needs.
Again, thank you very much. While I was waiting for a response, I did some research. I can also do some testing on my IPFire forklift. However, I am still left with the question whether it is fatal to edit this file incorrectly.
Editing firewall.local is as fatal as editing any configuration file.
You must be sure about what you do. Else you can run into a ‘desaster’.
This is also true for publishing unreflected ‘tips’ here in the community.
Thank you very much. I was sure of that. So any method seems complex and dangerous. I return to the idea of implementing a GUI function for IP range entry .
I also return to the subject of my images.
I think I’m dealing with experienced people, so I didn’t bother to avoid posting “dangerous tutorials” to explain my evidence. If you think that something I have posted, may create problems for novice people, please remove it without hesitation. Possibly, future times, I will write privately to one of you in such cases.
Any suggestions for doing this?
Alternatively, I tried experimenting with the firewall.local file.
It seems easy to modify it. I didn’t realize that in the end you just have to write the same thing in it as in my example in the picture.
The difficulty is using the “iptables” command, but for terminal experts I think that is not the problem.
Here is how I configured firewall.local with a trivial example.
Would that work?
#!/bin/sh
# Used for private firewall rules
# See how we were called.
case "$1" in
start)
## add your 'start' rules here
iptables -C INPUT -p tcp --destination-port 444 -m iprange --src-range 10.168.0.1-10.168.255.254 -j ACCEPT
if [ $? -eq 1 ]
then
iptables -I INPUT -p tcp --destination-port 444 -m iprange --src-range 10.168.0.1-10.168.255.254 -j ACCEPT
fi
iptables -C INPUT -p tcp --destination-port 22 -m iprange --src-range 10.168.0.1-10.168.255.254 -j ACCEPT
if [ $? -eq 1 ]
then
iptables -I INPUT -p tcp --destination-port 22 -m iprange --src-range 10.168.0.1-10.168.255.254 -j ACCEPT
fi
;;
stop)
## add your 'stop' rules here
iptables -D INPUT -p tcp --destination-port 444 -m iprange --src-range 10.168.0.1-10.168.255.254 -j ACCEPT
iptables -D INPUT -p tcp --destination-port 22 -m iprange --src-range 10.168.0.1-10.168.255.254 -j ACCEPT
;;
reload)
$0 stop
$0 start
## add your 'reload' rules here
;;
*)
echo "Usage: $0 {start|stop|reload}"
;;
esac