Hello *,

> Hello *,
> 
> upcoming Core Update 139 (testing, see: https://blog.ipfire.org/post/ipfire-2-23-core-update-139-is-available-for-testing)
> 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