Created attachment 481 [details] Firewall Groups - Hosts page iwth addresses incorrectly marked purple. In the WUI, IP Addresses are colored purple to indicate that the host is on the far side of an IPSec tunnel (correct me if I am wrong here). However, something is off with how these addresses are identified, as many, many addresses are identified with IPSec that have nothing to do with it. I have attached a badly redacted screenshot of the Firewall Groups - Hosts page and you can see that many, many of these addresses are purple, even though they have nothing to do with IPSec. Similarly, if you try to add network ranges to the "Firewall Groups - Networks" page, you often receive an error that the network you are adding conflicts with a tunnel, when it does not.
Created attachment 532 [details] Screenshot of the network/host firewall group page, note the wrong colors for some hosts This issue can be reproduced here (see attached screenshot, sorry for the redations). However, it seems to make a difference when the external hosts (such as 62.XXX.XXX.XXX) are added: If they are added before an IPsec tunnel was set up, they appear in correct colors.
Seemed to be in the wrong section. :-)
This problem did not occur here for IPsec connection with only one local and remote network defined. However, adding another network to a connection already in usage did not change anything either. To reproduce this issue, you need to create an IPsec connection with more than one local and remote interface.
- ping -
*** Bug 12075 has been marked as a duplicate of this bug. ***
This is not just an aesthetic issue as it prevents adding or modifying networks e.g. when working with firewall groups.
The problem is actually worse and breaks some functionality for a lot of people.
@Tom: This should be fixed by upstream commits mentioned in https://bugzilla.ipfire.org/show_bug.cgi?id=12263#c6. May I ask you to test this and report your findings back here? :-)
Peter: This does seem to resolve the problem! To be clear, I only modified the two lines in network-functions.pl: - if ($bin1[0] eq $bin2[0] && $bin1[1] eq $bin2[1]) { + if ($bin1[0] == $bin2[0] && $bin1[1] == $bin2[1]) { and - return (($address_bin ge $network_bin) && ($address_bin le $broadcast_bin)); + return (($address_bin >= $network_bin) && ($address_bin <= $broadcast_bin)); My "Firewall Groups:Hosts" page went from almost entirely purple to only a handful of entries being purple (as it should be)! However, I do see one address that is still purple, but which is not in /etc/ipsec.conf, and I am not certain why that is. The only place I can find this address is in /var/ipfire/fwhosts/customhosts. [root@myhost ~]# grep -r 24.249.28.52 /var/ipfire/ /var/ipfire/fwhosts/customhosts:19,ABC - George,ip,24.249.28.XXX/255.255.255.255 Thoughts?
Nevermind, I found the second commit with more changes. It made no difference that I could discern. Tom
Great, thanks for having a look at this.
Looks like I need some remedial training in redaction.
Thanks for the response. I will close this as a duplicate of #12263. Please reopen if this is an error of mine. *** This bug has been marked as a duplicate of bug 12263 ***
I am sorry, but I have to reopen this. Running Core Update 156 (testing), it is impossible to add a network such as 3.7.35.0/25 to the "firewall groups" section, as the CGI claims it would be already in use for an IPsec connection, which is wrong. This is a major issue, currently preventing me from creating firewall rules for some specific parts of the internet. 193.123.40.0/21, strangely, works fine. :-/
Another attempt to fix this: https://patchwork.ipfire.org/patch/4199/
Turns out fwhosts.cgi did not properly fetch subnet data for IPsec N2N connections with more than remote network configured. Suggested fix: https://patchwork.ipfire.org/patch/4206/
@Michael, Arne Please merge the second patch, which has been submitted by Peter. Thanks in advance, -Stefan
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=db4e10a6ecdb59a6f19249873ba5d50b22db6a68
https://blog.ipfire.org/post/ipfire-2-27-core-update-160-available-for-testing
https://blog.ipfire.org/post/ipfire-2-27-core-update-160-released