Core Update 153 (testing) report

Core Update 153 (testing) report

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 3303 bytes --]

Hello development folks,
hello location folks (CC'ed),

Core Update 153 (testing, see: https://blog.ipfire.org/post/ipfire-2-25-core-update-153-available-for-testing)
is running here for a few days by now without any known issues so far.

After downloading a recent (Saturday or later) location database, I can confirm its data to be less inaccurate
by now. The output of the following commands are an ideal measurement for Q&A purposes since they differ from
older location databases which used the (crappy) delegated-extended-latest files, which we now only need for
regions covered by ARIN and LACNINC, as they do not publish better data:

> [root(a)maverick ~]# location lookup 51.15.0.1
> 51.15.0.1:
>   Network                 : 51.15.0.0/17
>   Country                 : Netherlands
>   Autonomous System       : AS12876 - ONLINE S.A.S.

> [root(a)maverick ~]# location lookup 51.15.129.1
> 51.15.129.1:
>   Network                 : 51.15.0.0/16
>   Country                 : France
>   Autonomous System       : AS12876 - ONLINE S.A.S.

> [root(a)maverick ~]# location lookup 95.216.0.1
> 95.216.0.1:
>   Network                 : 95.216.0.0/17
>   Country                 : Finland
>   Autonomous System       : AS24940 - Hetzner Online GmbH

Location filter has not been tested, but since we built safeguards into it in Core Update 152 and implemented
additional checks to exclude bogus RIR data as best as we can - not to mention Michael spending weeks on re-
implementing a fast (!) algorithm for dumping libloc's tree planar for xt_geoip module, which cannot reliably
handle overlapping networks -, I do not expect any issues here.

As mentioned earlier, I am unable to reproduce Suricata 6.0 eating up an unreasonable amount of CPU time on
my testing machine, which runs on an Intel N3150, thus apparently not being affected by the problem especially
virtualised users seem to experience. Actually, CPU load is a bit lower than it was in Core Update 152, while
usual network load and system resources remained unchanged.

OpenVPN road-warrior connections were reported to be notably faster, but I could not test them by myself for
technical reasons. Thanks to Michael again for cleaning up this mess (as explained in commit
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=d6989b4b0b42937485f5008cda6cdd730275f1ec). :-)

Tested IPFire functionalities in detail:
- IPsec (N2N connections only)
- Squid (authentication enabled, using an upstream proxy)
- OpenVPN (RW connections only)
- IPS/Suricata (with Emerging Threats community ruleset enabled)
- Guardian
- Quality of Service
- DNS (using DNS over TLS and strict QNAME minimisation)
- Dynamic DNS
- Tor (relay mode)

I look forward to the release of this Core Update, as it finally comes with an location database as less inaccurate
(given the rather patchy RIR data, I try to avoid the term "accuracy" here) as we could do with the data we
have at hand.

Thanks, and best regards,
Peter Müller

P.S.: Reading Unbound's latest release note, I stumbled across re-using TCP and TLS connections. In case this
works as I expect it to do, this should make DNS over TCP (rather dull) and TLS (more interesting in terms of
privacy) significantly faster in Core Update 154.