Hello *,
Hello *,
upcoming Core Update 139 (testing, see: https://blog.ipfire.org/post/ipfire-2-23-core-update-139-is-available-for-te...) is running here for about 24 hours by now, and caused major trouble especially related to IPsec.
First, the update did not triggered a "reboot is requried" message, which is obligatory since we are shipping some new Intel microcodes. Those need a reboot in order to be loaded into the CPU.
This is filed as #12258 and fixed by https://patchwork.ipfire.org/patch/2643/ .
Second, I forgot to execute /usr/local/bin/sshctrl during update (update.sh),> so user settings were not applied to the SSH configuration. My fault (again).
This is filed as #12259 and fixed by https://patchwork.ipfire.org/patch/2642/ .
Third, IPsec N2N connections are not set up automatically after rebooting although they were configured to be. Worse, something seems to go seriously wrong, as traffic to a destination IP address on the other side of the IPsec connection is emitted directly to the internet.
This is filed as #12256 and #12257. In addition, #12260 was opened by some community tester - thank you! - due to Suricata crashing while parsing its configuration.
The latter one is fixed by https://patchwork.ipfire.org/patch/2644/ , while this patch only partially resolves #12257 . I still did not get why IPsec tunnels did not came up by themselves as described in #12256.
Surprisingly enough, connections initiated from the remote network behind an IPsec connection succeed and response packets apparently are sent back through the tunnel. [...]
Apart from that, the following parts of IPFire seem to work correctly: - DDNS - OpenVPN (RW connections only) - Squid proxy (including authentication and upstream proxy) - Guardian - Tor (acting as a relay) - Quality of Service
Thanks, and best regards, Peter Müller