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-testi...) 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@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@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@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=d6989b4b0b42937485f5008c...). :-)
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.