IPFire 2.21, Core 128 Current Configuration: - RED-GREEN-BLUE - Firewall -> Hosts (about 670 IPs to block) - Firewall -> Groups (1, Blocked IPs with all hosts + 5 blocked Networks) - Firewall -> Rules, Top rule Source: Blocked IPs, Destination: all, Action: Deny I had now the second time the issue that when I was adding firewall hosts to the firewall groups within the web interface an additional host with IP 0.0.0.0 was added to the top of the firewall group. As far as I can see this happens when I add a host and press the "Save" button while the IPFire Web interface was loading the list of hosts in that group. The consequence of this adding of 0.0.0.0 is that all traffic regardless from where will be blocked because of the firewall rule.
Additional Information: This happens when you do the following: - Go Firewall -> Firewallgroups -> Network/Host Groups - Edit a group - Go directly to the hosts combobox and select the last host with the End-Key - Press the add button as fast as possible Because the web interface haven't yet switched from "Standard-Networks ALL" to "Host" it will add 0.0.0.0 to the group. If this group will be used for blocking all traffic will be blocked (from GREEN/BLUE TO RED, FROM RED TO GREEN/BLUE). I would suggest that no radio button is selected when you enter that mask. This would prevent such mistakly added 0.0.0.0 entries.
I could track down the problem to javascript: If you have a longer list of hosts/host groups the radio button on the left side of "Standard Networks", "Network" and "Hosts" will be changed with the "Change" event of the comboboxes. This function will be executed when the whole page is loaded [document.ready()]. Because of this the radio button remains unchanged at "Standard Networks" and in the Combobox "All" is automatically selected. If you press the "Save" button the whole network will be added to the block list. A possible workaround could be to deselect all radio buttons when the page is loaded and no submit was made before.
That switch works fine on my browsers. There is a slight delay of like 200ms, but that is not enough time to be able to click the Save button. (In reply to Rolf Ackermann from comment #2) > A possible workaround could be to deselect all radio buttons when the page > is loaded and no submit was made before. I do not think that this is a good solution for this JS bug. We should just solve the bug and not make the UI more complicated.
> That switch works fine on my browsers. There is a slight delay of like 200ms, > but that is not enough time to be able to click the Save button. I have about 1000 IP's in two groups. So this loading takes some time ;) > I do not think that this is a good solution for this JS bug. We should just > solve the bug and not make the UI more complicated. Another way would be to write a function like this: <script> function onItemChanged( selectIdName ) { var id = document.getElementById( selectIdName ).name; $('#' + id).prop("checked", true); } </script> <select name="DEFAULT_SRC_ADR" style="width:16em;" onchange="onItemChanged( 'DEFAULT_SRC_ADR' )"> <select name="CUST_SRC_NET" style="width:16em;" onchange="onItemChanged( 'CUST_SRC_NET' )"> <select name="CUST_SRC_HOST" style="width:16em;" onchange="onItemChanged( 'CUST_SRC_HOST' )">