From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Kienker, Fred" <fkienker@at4b.com>
To: development@lists.ipfire.org
Subject: RE: IPFire Core 135 testing
Date: Fri, 30 Aug 2019 18:35:01 -0400
Message-ID: <H000006e005211e5.1567204501.mail.at4b.net@MHS>
In-Reply-To: <12d0af2c-6159-9504-7f09-496d482558eb@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7597213813413365216=="
List-Id: <development.lists.ipfire.org>

--===============7597213813413365216==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

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



--===============7597213813413365216==--