From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter =?utf-8?q?M=C3=BCller?= <peter.mueller@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Core Update 139 (testing) report
Date: Fri, 13 Dec 2019 17:40:00 +0000
Message-ID: <20733f66-4b49-20da-dae3-eeadbfdd7d28@ipfire.org>
In-Reply-To: <870f0e4f-d807-f088-76c9-a876b3eea335@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5706367666301284534=="
List-Id: <development.lists.ipfire.org>

--===============5706367666301284534==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hello *,

> Hello *,
>=20
> 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 especia=
lly
> related to IPsec.
>=20
> 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 re=
boot
> in order to be loaded into the CPU.
This is filed as #12258 and fixed by https://patchwork.ipfire.org/patch/2643/=
 .
>=20
> 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 (aga=
in).
This is filed as #12259 and fixed by https://patchwork.ipfire.org/patch/2642/=
 .
>=20
> Third, IPsec N2N connections are not set up automatically after rebooting a=
lthough
> they were configured to be. Worse, something seems to go seriously wrong, a=
s traffic
> to a destination IP address on the other side of the IPsec connection is em=
itted
> directly to the internet.
This is filed as #12256 and #12257. In addition, #12260 was opened by some co=
mmunity
tester - thank you! - due to Suricata crashing while parsing its configuratio=
n.

The latter one is fixed by https://patchwork.ipfire.org/patch/2644/ , while t=
his
patch only partially resolves #12257 . I still did not get why IPsec tunnels =
did not
came up by themselves as described in #12256.
>=20
> Surprisingly enough, connections initiated from the remote network behind a=
n IPsec
> connection succeed and response packets apparently are sent back through th=
e 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=C3=BCller

--===============5706367666301284534==--