Bug 11323

Summary: firewall: Rules won't created when 15 services in a service group contain a range
Product: IPFire Reporter: Michael Tremer <michael.tremer>
Component: ---Assignee: Stefan Schantl <stefan.schantl>
Status: CLOSED FIXED QA Contact: Michael Tremer <michael.tremer>
Severity: - Unknown -    
Priority: - Unknown - CC: peter.mueller, peter.mueller, stefan.schantl
Version: 2   
Hardware: unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 12278    

Description Michael Tremer 2017-04-28 14:28:09 UTC 
I created a service group that had 14 regular services and one service that was a port range (81:82).

After that, the firewall rule could be saved but was not created since iptables refused to do so. I do not have the exact error, but it should be easy to reproduce.
Comment 1 Alexander Marx 2017-05-18 09:22:08 UTC 
This Bug is already fixed.
Just tested again with core 110. If someone adds more than 15 TCP or UDP services in a servicegroup an errormessage is displayed.

Also portranges are detected (which count twice).

You can close this bug
Comment 2 Michael Tremer 2017-05-18 20:17:14 UTC 
That is not what I meant here.

It is that the WUI accepts to create a group with 14 single ports and one range. That totals in 15 and that is accepted from the user interface.

However, that rule is not created but iptables returns an error.

Please create that thing and run firewallctrl to reload rules on the console.
Comment 3 Alexander Marx 2018-05-24 15:30:23 UTC 
still open?
Comment 4 Michael Tremer 2018-05-24 16:48:08 UTC 
(In reply to Alexander Marx from comment #3)
> still open?

Well if it wasn't fixed anywhere it is :)
Comment 5 Alexander Marx 2018-05-24 16:55:57 UTC 
Well, i am not able to create a testrule with 14 single ports and a portrange.
If i enter "1,2,3,4,5,6,7,8,9,10" i am not able to enter additional values.
so i think it is impossible to create such a rule
Comment 6 Michael Tremer 2018-05-24 17:56:22 UTC 
Has the limit been decreased at some point?
Comment 7 Peter Müller 2019-10-13 10:14:36 UTC 
I am setting this back to ASSIGNED, since I was unable to trace any patches or commits back to this. If there were any, please mention them here.
Comment 8 Stefan Schantl 2021-07-15 10:08:29 UTC 
Fix has been sent to the development mailing list.

https://patchwork.ipfire.org/project/ipfire/patch/20210715100737.3733-1-stefan.schantl@ipfire.org/
Comment 9 Peter Müller 2021-09-04 10:10:33 UTC 
Resetting this back to ASSIGNED since the patch has not been merged yet. No offense intended, it just makes things easier for me to track. :-)
Comment 10 Stefan Schantl 2023-02-12 15:22:19 UTC 
Patch has been accepted and shiped.