Re: IPFire Core 135 testing

Re: IPFire Core 135 testing

[Michael Tremer]

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

Hello,

Thank you for the feedback.

I have also tested a fresh installation which looked fine to me.

I will consult with Arne for a release date I suppose early next week.

If anyone has anything, please raise your hand now!

Best,
-Michael

> On 28 Aug 2019, at 19:33, Kienker, Fred <fkienker(a)at4b.com> wrote:
> 
> Just reporting - we have been through our testing cycle for Core 135 and have found no issues to report. We have seen better stability in unbound in C135, for reasons unknown, compared to C134. 
>  
> Eagerly anticipating the official release.
> Best regards,
> Fred Kienker

Re: IPFire Core 135 testing

[peter.mueller]

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

Hello Michael, hello *,

I can confirm the testing update looks good so far.

These parts are working as expexcted:
- DDNS
- IPsec (N2N connections only)
- Squid proxy (including upstream proxy)
- OpenVPN (RW connections only)
- Suricata (see below)

However, I observed OpenVPN RW connection throughput decreased to
~ 350 kB/sec - 1.1 MB/sec if Suricata is enabled and filtering
traffic on RED interface. Otherwise, throughput is usually ~ 2.0 MB/sec
(= 16 MBit/sec), which is not that fast on my testing machine using
a 100 MBit/sec internet downlink, but the remote system or some
general OpenVPN performance issues seem to be the bottleneck here.

This issue probably appeared before upgrading to Core 135, and
I am still debugging why this is (Suricata configuration is identical
to a productive firewall instance with better OpenVPN throughput).

Further, DNS resolution sometimes fails, but that issue has been
around here for quite a while. If there is enough time left, I
will send in patches for always allowing DNS traffic to root servers
and enabling hyperlocal (see RFC 7706).

Running kernel is as follows:
> [root(a)maverick ~]# uname -a
> Linux maverick 4.14.138-ipfire #1 SMP Sat Aug 10 00:53:30 GMT 2019 x86_64 Intel(R) Celeron(R) CPU N3150 @ 1.60GHz GenuineIntel GNU/Linux

Speaking about CPU vulnerabilities, I notice changes in kernel
status output for Spectre v1 (CVE-2017-5753):
> [root(a)maverick ~]# grep . /sys/devices/system/cpu/vulnerabilities/*
> /sys/devices/system/cpu/vulnerabilities/l1tf:Not affected
> /sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled
> /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
> /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Not affected
> /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
> /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling

As far as I can recall, "usercopy/swapgs barriers" was not present
before. No comments on hardware security landscape in general.

Things look good so far, thanks to everyone who worked on this. :-)

Thanks, and best regards,
Peter Müller

RE: IPFire Core 135 testing

[Kienker, Fred]

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

Peter - we did not observe a similar slowdown on the OpenVPN slowdown on 
Net2Net connections. That said, we will go ahead and retest them based 
on your report. We will also take a close look at the Net2Net 
configurations since we do a slight modification to them verses the 
standard setup. This may or may not be why a similar change was not 
observed.

Best regards, 
Fred Kienker

-----Original Message-----
From: peter.mueller(a)ipfire.org <peter.mueller(a)ipfire.org> 
Sent: 30 August, 2019 13:41
To: development(a)lists.ipfire.org
Subject: Re: IPFire Core 135 testing

Hello Michael, hello *,

I can confirm the testing update looks good so far.

These parts are working as expexcted:
- DDNS
- IPsec (N2N connections only)
- Squid proxy (including upstream proxy)
- OpenVPN (RW connections only)
- Suricata (see below)

However, I observed OpenVPN RW connection throughput decreased to ~ 350 
kB/sec - 1.1 MB/sec if Suricata is enabled and filtering traffic on RED 
interface. Otherwise, throughput is usually ~ 2.0 MB/sec (= 16 
MBit/sec), which is not that fast on my testing machine using a 100 
MBit/sec internet downlink, but the remote system or some general 
OpenVPN performance issues seem to be the bottleneck here.

This issue probably appeared before upgrading to Core 135, and I am 
still debugging why this is (Suricata configuration is identical to a 
productive firewall instance with better OpenVPN throughput).

Further, DNS resolution sometimes fails, but that issue has been around 
here for quite a while. If there is enough time left, I will send in 
patches for always allowing DNS traffic to root servers and enabling 
hyperlocal (see RFC 7706).

Running kernel is as follows:
> [root(a)maverick ~]# uname -a
> Linux maverick 4.14.138-ipfire #1 SMP Sat Aug 10 00:53:30 GMT 2019 
> x86_64 Intel(R) Celeron(R) CPU N3150 @ 1.60GHz GenuineIntel GNU/Linux

Speaking about CPU vulnerabilities, I notice changes in kernel status 
output for Spectre v1 (CVE-2017-5753):
> [root(a)maverick ~]# grep . /sys/devices/system/cpu/vulnerabilities/*
> /sys/devices/system/cpu/vulnerabilities/l1tf:Not affected
> /sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU 
> buffers; SMT disabled
> /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI 
> /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Not affected
> /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: 
> usercopy/swapgs barriers and __user pointer sanitization
> /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full 
> generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB 
> filling

As far as I can recall, "usercopy/swapgs barriers" was not present 
before. No comments on hardware security landscape in general.

Things look good so far, thanks to everyone who worked on this. :-)

Thanks, and best regards,
Peter Müller