From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Question regarding IPsec N2N throughput with and without IPS
Date: Thu, 23 Jan 2020 22:44:45 +0000
Message-ID: <81BA3FDB-766B-403F-B5B0-20E4F5FBF6A1@ipfire.org>
In-Reply-To: <c9ef30fe-d3ce-ace5-2cd4-0a4d446c689c@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8241185999001724858=="
List-Id: <development.lists.ipfire.org>

--===============8241185999001724858==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi,

> On 22 Jan 2020, at 16:24, Peter M=C3=BCller <peter.mueller(a)ipfire.org> wr=
ote:
>=20
> Hello Stefan, hello list (CC'ed),
>=20
> are you aware of any IPS bottlenecks regarding IPsec N2N throughput?

No, not at all.

There is actually not much the IPS can do with the ESP packets. I would assum=
e it just passes them through.

> I finally (!) managed to get an IPsec connection between OpenBSD 6.6 (OpenI=
KED)
> and IPFire 2.23 Core Update 139 working.

Yay \o/.

Please do not forget to add the relevant documentation to the IPFire wiki.

> During throughput tests, where
> I downloaded a 1 GByte test file from the machine via the IPsec tunnel,
> a rather large throughput difference with and without IPS enabled on RED
> has come to my attention:
>=20
> With IPS enabled on RED, the download starts at ~ 2.5 MByte/sec. and
> continually decreases to ~ 580 kByte/sec. - 800 kByte/sec., which is
> even lower than OpenVPN performance. Without IPS enabled on RED, throughput
> is 4.0 MByte/sek. on average - running the IPS on other interfaces does
> not change this behaviour, neither does enabling monitoring mode.

How is CPU load?

Did you see any retransmissions?

> This suspiciously sounds like the issue we have had with Suricata last
> year - as far as I am concerned that was fully fixed. Are you aware of
> any other similar issue that could cause this massive throughput loss?

No. You can try Suricata 5 which has been posted to the list today.

> Anyway, thank you in advance for any help and hints. :-)
>=20
> Kernel and CPU information of the OpenBSD machine:
>> openbsd# uname -a
>> OpenBSD openbsd 6.6 GENERIC.MP#4 amd64
>> openbsd# sysctl hw.model hw.machine hw.ncpu
>> hw.model=3DIntel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
>> hw.machine=3Damd64
>> hw.ncpu=3D2
>=20
> Content of /etc/iked.conf on the OpenBSD machine:
>> set fragmentation
>>=20
>> ikev2 "[REDACTED]" active esp \
>>   from 10.xxx.xxx.2/24 to 10.xxx.xxx.0/24 \
>>   local [REDACTED] peer [REDACTED] \
>>   ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group curve25519 \
>>   childsa enc aes-256-gcm group curve25519 \
>>   srcid [REDACTED] dstid [REDACTED] \
>>   ikelifetime 3h \
>>   lifetime 1h
>=20
> Kernel and CPU information of the IPFire machine:
>> [root(a)maverick ~]# uname -a
>> Linux maverick 4.14.154-ipfire #1 SMP Fri Nov 15 07:27:41 GMT 2019 x86_64 =
Intel(R) Celeron(R) CPU N3150 @ 1.60GHz GenuineIntel GNU/Linux

This is a really small Atom processor AFAIK. Could we struggle with Meltdown/=
Spectre mitigations here? Just to rule it out, can you boot the kernel with t=
hem disabled?

Best,
-Michael

> Thanks, and best regards,
> Peter M=C3=BCller


--===============8241185999001724858==--