Core Update 139 (testing) report

Core Update 139 (testing) report

[Peter Müller]

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

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.

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(a)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

Re: Core Update 139 (testing) report

[ummeegge]

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

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-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.
> 
> 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(a)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

Re: Core Update 139 (testing) report

[Peter Müller]

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

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