Network range within Firewall Groups

[anowak (Andrew Nowak)]

Hi I am new to IPFire.
Coming from opnsense, wanted to know if it is possible to do network IP range blocks (192.168.50.10-192.168.50.20) within the Firewall groups rules. Hosts seems to be a single element. Network seems to only support CIDR?

Regards

[hvacguy (Shaun HVAC)]

Yes you can use port ranges.

25000:25500
Or
25000-25500

You can make service groups.
This is a great feature.

Firewall Groups - The IPFire Wiki

[casabenedetti (Carlo)]

Is it possible to do something similar for IPs as well?
I am interested too, but I am not sure if it can be done.

For the doors, I adopted the same strategy. I confirm that it is great!!!

[bonnietwin (Adolf Belka)]

Looking at the perl code for the Firewall Groups WUI page I could only find port range being defined and used.

I also checked out the network-functions.pl and general-functions.pl code and I could find the validportrange function but there is nothing for validiprange or iprange and also not if I checked just for range, I could only find the validportrange function.

So it looks like the answer is no, IP ranges can not be defined in the Network groups. You need to create individual host entries for each IP address and then you can group them together into a group that covers that IP range.

[casabenedetti (Carlo)]

I suspected as much. To remedy it, I did what is not recommended: I entered the IPs “by hand” by editing IPFire’s configuration files. But a mistake is fatal: you risk damaging IPFire. And this has happened to me before .

And anyway, I always inserted them one by one. Only with copy/paste/notepad I do it faster.

[cfusco]

@casabenedetti

And anyway, I always inserted them one by one. Only with copy/paste/notepad I do it faster.

you can consider using ipset

[casabenedetti (Carlo)]

I thank you @cfusco
I didn’t know that. You gave me a very good suggestion.
I will do studies on it, maybe on an IPFire used as a forklift (to try).
With the terminal I am not good, but I will try to succeed anyway.
Until next time .

[tphz (iptom)]

Tiny hint

When you edit the configuration files, remember the EOL in Unix format (LF).

[casabenedetti (Carlo)]

Meaning ?

[casabenedetti (Carlo)]

Yes, I think I got it. It has to do with coding. Windows and linux “are not the same” in that respect. Have I guessed?

[tphz (iptom)]

@casabenedetti

Windows and linux “are not the same”

Yes.
You can read a sample thread below
https://community.ipfire.org/t/openvpn-from-an-ipad-no-config/

[casabenedetti (Carlo)]

I thank you. I use both Windows and linux. Many times I have encountered this problem on a practical level (Not only for IPFire). Even such an error is fatal on IPFire files, that’s for sure!

[casabenedetti (Carlo)]

Yes, the topic you sent me is really helpful. You have to be careful if you use Windows. Maybe it is safer to edit everything with Linux.

Let’s say it worked out well for me in the sense that the editing program I use seems to keep the original encoding in my case .

[anowak (Andrew Nowak)]

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.

[cfusco]

@anowak

So, then could we not just use the inbuilt iptables iprange command?

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.

[casabenedetti (Carlo)]

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.

Problem entering a rule in the firewall

Just one more advice. If someone really wants to edit the config files of IPFire ( those in /var/ipfire especially ) he/she should be aware, that this switches off the usual checks for correctness. Therefore it is urgent to watch the system logs for error messages.

Problem entering a rule in the firewall

Conclusion of this thread ( and others ): Don’t edit internal configs without knowing exactly what you do. If doing this anyway, document this modifications if you have ‘mysterious’ problems.

Logs that are not clear to me

I’ve just added a paragrah about configuration to the wiki article wiki.ipfire.org - What is IPFire?

[hvacguy (Shaun HVAC)]

A way to use ASN in firewall rules would also be great.

[casabenedetti (Carlo)]

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.

[bonnietwin (Adolf Belka)]

@casabenedetti

Alternatively, is there a more professional way to save (in IPFire) the rules set with iptables?

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.

@casabenedetti

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.

The wiki is your friend.
https://wiki.ipfire.org/pkgs/fcron

[casabenedetti (Carlo)]

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 .