Bug 11235

Summary: Calculation of which IP Addresses are IPSec (purple) incorrect
Product: IPFire Reporter: Tom Rymes <tomvend>
Component: ---Assignee: Stefan Schantl <stefan.schantl>
Status: CLOSED FIXED QA Contact: Peter Müller <peter.mueller>
Severity: Major Usability    
Priority: Will affect most users CC: peter.mueller, peter.mueller, stefan.schantl
Version: 2   
Hardware: all   
OS: All   
See Also: https://bugzilla.ipfire.org/show_bug.cgi?id=11604
https://bugzilla.ipfire.org/show_bug.cgi?id=12263
https://bugzilla.ipfire.org/show_bug.cgi?id=11278
Bug Depends on:    
Bug Blocks: 11618, 12278    
Attachments: Firewall Groups - Hosts page iwth addresses incorrectly marked purple.
Screenshot of the network/host firewall group page, note the wrong colors for some hosts

Description Tom Rymes 2016-10-06 00:47:50 UTC
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.
Comment 1 Peter Müller 2017-08-30 17:02:20 UTC
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.
Comment 2 Peter Müller 2017-12-20 14:48:41 UTC
Seemed to be in the wrong section. :-)
Comment 3 Peter Müller 2018-02-11 13:41:52 UTC
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.
Comment 4 Peter Müller 2019-05-11 09:49:40 UTC
- ping -
Comment 5 Peter Müller 2019-06-16 16:37:20 UTC
*** Bug 12075 has been marked as a duplicate of this bug. ***
Comment 6 Peter Müller 2020-01-31 15:32:33 UTC
This is not just an aesthetic issue as it prevents adding or modifying networks e.g. when working with firewall groups.
Comment 7 Peter Müller 2020-04-10 10:59:15 UTC
The problem is actually worse and breaks some functionality for a lot of people.
Comment 8 Peter Müller 2020-07-28 19:35:28 UTC
@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? :-)
Comment 9 Tom Rymes 2020-07-28 21:12:34 UTC
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?
Comment 10 Tom Rymes 2020-07-28 21:16:39 UTC
Nevermind, I found the second commit with more changes. It made no difference that I could discern.

Tom
Comment 11 Peter Müller 2020-07-29 14:01:53 UTC
Great, thanks for having a look at this.
Comment 12 Tom Rymes 2020-07-29 15:55:37 UTC
Looks like I need some remedial training in redaction.
Comment 13 Peter Müller 2020-08-01 15:12:29 UTC
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 ***
Comment 14 Peter Müller 2021-04-22 15:37:40 UTC
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. :-/
Comment 15 Peter Müller 2021-04-22 16:15:54 UTC
Another attempt to fix this: https://patchwork.ipfire.org/patch/4199/
Comment 16 Peter Müller 2021-04-22 20:22:32 UTC
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/
Comment 17 Stefan Schantl 2021-07-15 15:51:45 UTC
@Michael, Arne

Please merge the second patch, which has been submitted by Peter.

Thanks in advance,

-Stefan