Hello *,
this is just a quick testing report for upcoming Core Update 133 (see: https://blog.ipfire.org/post/ipfire-2-23-core-update-133-ready-for-testing).
The following parts of IPFire seem to work correctly: - DDNS - Squid proxy (including upstream proxy) - OpenVPN (RW connections only) - Suricata
Regarding Strongswan/IPsec, I experience tunnel crashes after approximately 30 minutes. However, Strongswan still logs INFORMATIONAL packets, which can be parsed successfully, too.
Restating the connections manually via WebUI works, but leaves log messages like these:
Jun 16 16:13:42 maverick charon: 03[ENC] parsed CREATE_CHILD_SA response 2 [ N(NO_PROP) ] Jun 16 16:13:42 maverick charon: 03[IKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built Jun 16 16:13:42 maverick charon: 03[IKE] failed to establish CHILD_SA, keeping IKE_SA
At the moment, I have no idea what the reason of this might be. Using certificate-based N2N connection with Chacha20/Poly1305 and Curve25519.
Regarding CPU load data, I notice a decrease in IRQ usage, probably because of Hyperscan and Suricata changes.
I can confirm missing translations are now present.
Interestingly, spectre-meltdown-checker thinks my testing hardware is vulnerable to Spectre 3a:
CVE-2018-3640 aka 'Variant 3a, rogue system register read'
- CPU microcode mitigates the vulnerability: NO
STATUS: VULNERABLE (an up-to-date CPU microcode is needed to mitigate this vulnerability)
/var/log/bootlog however, states current microcodes have been loaded:
[ 0.000000] microcode: microcode updated early to revision 0x368, date = 2019-04-23 [ 0.000000] Linux version 4.14.121-ipfire (root@helena.ipfire.org.ipfire.org) (gcc version 7.3.0 (GCC)) #1 SMP Wed May 22 13:45:15 GMT 2019
(Two glitches here: "helena.ipfire.org.ipfire.org" and GCC 7.3.0 . I thought the toolchain now uses GCC 8.0?!)
Besides of the IPsec issue, which needs to be investigated further, everything seems to work correctly.
Thanks, and best regards, Peter Müller
Hello *,
just some minor corrections and additions...
Hello *,
this is just a quick testing report for upcoming Core Update 133 (see: https://blog.ipfire.org/post/ipfire-2-23-core-update-133-ready-for-testing).
The following parts of IPFire seem to work correctly:
- DDNS
- Squid proxy (including upstream proxy)
- OpenVPN (RW connections only)
- Suricata
By the way: I am currently observing a ton of scans coming from 92.118.37.0/24 . Just in case anyone is interested in. :-/
[...]
/var/log/bootlog however, states current microcodes have been loaded:
[ 0.000000] microcode: microcode updated early to revision 0x368, date = 2019-04-23 [ 0.000000] Linux version 4.14.121-ipfire (root@helena.ipfire.org.ipfire.org) (gcc version 7.3.0 (GCC)) #1 SMP Wed May 22 13:45:15 GMT 2019
(Two glitches here: "helena.ipfire.org.ipfire.org" and GCC 7.3.0 . I thought the toolchain now uses GCC 8.0?!)Since we did not ship an updated Linux kernel, I guess this cannot
say "GCC 8.x" yet. Sorry.
[...]
Thanks, and best regards, Peter Müller
On 2019-06-16 16:47, Peter Müller wrote:
Hello *,
just some minor corrections and additions...
Hello *,
this is just a quick testing report for upcoming Core Update 133 (see: https://blog.ipfire.org/post/ipfire-2-23-core-update-133-ready-for-testing).
The following parts of IPFire seem to work correctly:
- DDNS
- Squid proxy (including upstream proxy)
- OpenVPN (RW connections only)
- Suricata
By the way: I am currently observing a ton of scans coming from 92.118.37.0/24 . Just in case anyone is interested in. :-/
[...]
/var/log/bootlog however, states current microcodes have been loaded:
[ 0.000000] microcode: microcode updated early to revision 0x368, date = 2019-04-23 [ 0.000000] Linux version 4.14.121-ipfire (root@helena.ipfire.org.ipfire.org) (gcc version 7.3.0 (GCC)) #1 SMP Wed May 22 13:45:15 GMT 2019
(Two glitches here: "helena.ipfire.org.ipfire.org" and GCC 7.3.0 . I thought the toolchain now uses GCC 8.0?!)Since we did not ship an updated Linux kernel, I guess this cannot
say "GCC 8.x" yet. Sorry.
If you are using the 32bit PAE Kerel this is still compiled with 7.3.0 (core131).
Arne
Hello Arne,
/var/log/bootlog however, states current microcodes have been loaded:
[ 0.000000] microcode: microcode updated early to revision 0x368, date = 2019-04-23 [ 0.000000] Linux version 4.14.121-ipfire (root@helena.ipfire.org.ipfire.org) (gcc version 7.3.0 (GCC)) #1 SMP Wed May 22 13:45:15 GMT 2019
(Two glitches here: "helena.ipfire.org.ipfire.org" and GCC 7.3.0 . I thought the toolchain now uses GCC 8.0?!)Since we did not ship an updated Linux kernel, I guess this cannot
say "GCC 8.x" yet. Sorry.
If you are using the 32bit PAE Kerel this is still compiled with 7.3.0 (core131).
I am running a x86_64 kernel on this system.
Thanks, and best regards, Peter Müller
Hey,
Long list, but good finds.
On 16 Jun 2019, at 15:26, Peter Müller peter.mueller@ipfire.org wrote:
Hello *,
this is just a quick testing report for upcoming Core Update 133 (see: https://blog.ipfire.org/post/ipfire-2-23-core-update-133-ready-for-testing).
The following parts of IPFire seem to work correctly:
- DDNS
- Squid proxy (including upstream proxy)
- OpenVPN (RW connections only)
- Suricata
Regarding Strongswan/IPsec, I experience tunnel crashes after approximately 30 minutes. However, Strongswan still logs INFORMATIONAL packets, which can be parsed successfully, too.
Restating the connections manually via WebUI works, but leaves log messages like these:
Jun 16 16:13:42 maverick charon: 03[ENC] parsed CREATE_CHILD_SA response 2 [ N(NO_PROP) ] Jun 16 16:13:42 maverick charon: 03[IKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built Jun 16 16:13:42 maverick charon: 03[IKE] failed to establish CHILD_SA, keeping IKE_SA
I assume that this is now fixed with the patch that you sent?
At the moment, I have no idea what the reason of this might be. Using certificate-based N2N connection with Chacha20/Poly1305 and Curve25519.
Regarding CPU load data, I notice a decrease in IRQ usage, probably because of Hyperscan and Suricata changes.
No, that shouldn’t decrease IRQ at all. You would receive the same amount of packets and the scanning wouldn’t show up as interrupt usage.
I can confirm missing translations are now present.
Interestingly, spectre-meltdown-checker thinks my testing hardware is vulnerable to Spectre 3a:
CVE-2018-3640 aka 'Variant 3a, rogue system register read'
- CPU microcode mitigates the vulnerability: NO
STATUS: VULNERABLE (an up-to-date CPU microcode is needed to mitigate this vulnerability)
I have seen systems where this as mitigated. So it could be the the microcode doesn’t support the mitigation?
/var/log/bootlog however, states current microcodes have been loaded:
[ 0.000000] microcode: microcode updated early to revision 0x368, date = 2019-04-23 [ 0.000000] Linux version 4.14.121-ipfire (root@helena.ipfire.org.ipfire.org) (gcc version 7.3.0 (GCC)) #1 SMP Wed May 22 13:45:15 GMT 2019
(Two glitches here: "helena.ipfire.org.ipfire.org" and GCC 7.3.0 . I thought the toolchain now uses GCC 8.0?!)
Besides of the IPsec issue, which needs to be investigated further, everything seems to work correctly.
Thanks, and best regards, Peter Müller -- The road to Hades is easy to travel. -- Bion of Borysthenes
-
Arne Fitzenreiter -
Michael Tremer -
Peter Müller