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

Hello Fred,

thank you for your reply and testing effort - if there is anything notable, I will be happy to hear.

At the moment, I am pretty sure Suricata is the reason for this: Disabling it on RED interface immediately increases the OpenVPN throughput to ~ 2 MBit/sec. However, as being mentioned before, I cannot reproduce this behavior on other installations.

The Core Update 135 changelog does not indicate such changes. Since Suricata does/did not scan traffic on OpenVPN interfaces, I have asked Stefan to change this the other day. Maybe he did so by now, and I missed the commit.

Another possibility is a regression introduced in C135, so more testing helps a lot here. Since my system switches from master to testing every now and then, I can also imagine some packaging glitches as a reason for this.

Either way, I am not satisfied with OpenVPN as it introduces quite some overhead. IPsec would be more elegant (cipher policies per connection, etc.) and perhaps faster, but I did not have time to set it up.

Thanks, and best regards, Peter Müller

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