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.
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).
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.
Surprisingly enough, connections initiated from the remote network behind an IPsec connection succeed and response packets apparently are sent back through the tunnel.
Reason for this is unknown; as far as I am concerned, this Core Update is not yet ready. I will open bug tickets for the problems mentioned above (and others, if necessary).
Output of "uname -a" for reference purposes:
[root@maverick ~]# uname -a Linux maverick 4.14.154-ipfire #1 SMP Fri Nov 15 07:27:41 GMT 2019 x86_64 Intel(R) Celeron(R) CPU N3150 @ 1.60GHz GenuineIntel GNU/Linux
Thanks, and best regards, Peter Müller
Hi all, after the update there are a lots of sshd[17731]: error: kex_exchange_identification: Connection closed by remote host messages. SSH was not accesible but like Peter already announced it, a restart fixed this.
OpenVPN RW and N2N seems to work as expected.
Currently here are no further complications.
Erik
Am Donnerstag, den 12.12.2019, 19:35 +0000 schrieb Peter Müller:
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.
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).
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.
Surprisingly enough, connections initiated from the remote network behind an IPsec connection succeed and response packets apparently are sent back through the tunnel.
Reason for this is unknown; as far as I am concerned, this Core Update is not yet ready. I will open bug tickets for the problems mentioned above (and others, if necessary).
Output of "uname -a" for reference purposes:
[root@maverick ~]# uname -a Linux maverick 4.14.154-ipfire #1 SMP Fri Nov 15 07:27:41 GMT 2019 x86_64 Intel(R) Celeron(R) CPU N3150 @ 1.60GHz GenuineIntel GNU/Linux
Thanks, and best regards, Peter Müller
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
-
Peter Müller -
ummeegge