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@ipfire.org peter.mueller@ipfire.org Sent: 30 August, 2019 13:41 To: development@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@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@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