Core Update 165 (testing) report

["Peter Müller" <peter.mueller@ipfire.org>]

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

Hello development folks,

Core Update 165 (testing, see: https://blog.ipfire.org/post/ipfire-2-27-core-update-165-is-available-for-testing)
is running here for roughly a day, with some minor and one major issue(s) spotted so far.

While installing the update went smooth (the improved Pakfire GUI is really nice - thanks
again to Leo!), I bumped into some IPS-related trouble afterwards: Network connections timed
out frequently, no matter whether they were directed to IPFire itself or not, and the GUI
(especially the graphs) took ages to load, if at all.

Stopping the IPS and starting it again via the GUI solved the problem - I believe we should
do this in the update.sh script, but am not sure if there are cross-dependencies to something
else. There is no bug raised for this yet.

Also, I noticed Squid was not restarted during the update, which caused trouble until I
ran "/etc/init.d/squid restart" manually. Bug #12810 has been filed for this, and I just
submitted a patch fixing this a few minutes ago.

Since my IPFire machine is rebooting every night via a scheduled job, I usually do not
conduct a manual reboot immediately after installing an update. This time, I felt it was a
good thing to do.

Afterwards, Tor would not start again unless I disabled the "sandbox" feature manually. I
believe this is not a general problem, but due to the fact that we did not ship libseccomp.
Bug #12807 has been filed for this.

Today (i. e. another reboot later), I noticed charon emitting some iptables warnings while
establishing an IPsec connection (filed as bug #12808), and, more important, some location-
based firewall rules not being properly loaded, which rendered DDNS - and subsequently IPsec
and OpenVPN - useless for me, since I am getting IP addresses assigned dynamically.

Bug #12809 has been filed for the latter, and I believe this is a show-stopper. Oddly enough,
it did not appear after the first reboot, and _some_ location-based firewall rules were loaded
correctly after the second one. Manually reloading the rules via the GUI "solved" the problem
for now, but this is definitely something we need to have a look at before releasing C165.

Apart from these, things look good to me. 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)
- Dynamic DNS
- Tor (relay mode)

Thanks, and best regards,
Peter Müller