From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rymes To: development@lists.ipfire.org Subject: Re: Extremely poor OpenVPN performance, help wanted Date: Wed, 25 Sep 2019 20:21:21 -0700 Message-ID: <7E7947DC-3E0D-4102-9E78-38720BA958BF@rymes.com> In-Reply-To: <1efd8fbe-ddbd-65ab-a0c0-2985ec581b43@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5965507338026351103==" List-Id: --===============5965507338026351103== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Peter, Perhaps it might make sense to start with the least complex option of windows= instead of Debian? Tom > On Sep 25, 2019, at 12:13 PM, wrote: >=20 > Hello Tom, >=20 > thank you for your reply. >=20 > Yes, these VMs are all running on FreeBSD. I will try to test it > with a Debian machine within the next days. >=20 > While I am pretty sure MTU is not the (only) root cause of this > problem, setting it to 1492 bytes on the VMs (interface setting > was 1500 bytes) causes a slight improvement to ~ 1.1 MB/sec, which > is still way too low. >=20 > Disabling remote packet filters did not change anything, both VMs > and IPFire machine have AES-NI available, thus being able to encrypt > a much bigger volume per second (~ 2.1 Gbit/sec on VMs, ~ 267 Mbit/sec > on IPFire host). >=20 > Changing the OpenVPN tunnel MTU to lower values (tested with 1350 and > 1300 bytes) did not change anything. >=20 > Thanks, and best regards, > Peter M=C3=BCller >=20 >> Peter, >>=20 >> Is the issue reproducible on different OS and different OpenVPN clients? T= here=E2=80=99s a chance that the issue lies with FreeBSD or how you are confi= guring the VMs at different locations. >>=20 >> Tom >>=20 >>> On Sep 24, 2019, at 9:23 AM, wrote: >>>=20 >>> Hello list, >>>=20 >>> as mentioned several times before, I am experiencing OpenVPN performance >>> problems. Since I am out of ideas by now, asking here to help seemed to >>> make sense to me, as I am not sure whether it can be traced to a bug or n= ot. >>>=20 >>> Test setup is as follows: >>> (a) IPFire is freshly installed on a testing machine with Core Update 135= (x86_64). >>> The machine is connected to the internet via DSL (link has 100 Mbit/sec >>> down capacity with MTU set to 1492) and runs dial-in by itself. No >>> cascading router or NAT in place here. >>> (b) The remote part is a VM hosted at a big German hosting company, with >>> FreeBSD 12 installed (OpenVPN 2.4.7). Uplink is 1 Gbit/sec with MTU =3D >>> 1492. >>> (c) Both systems are able to submit ICMP packets up to 1492 bits, so MTU >>> is set correctly on both interfaces. >>> (d) The VM is establishing an OpenVPN roadwarrior connection to the IPFire >>> machine, which can be set up successfully and uses AES-256-GCM (SHA 512) >>> for data channel. Tunnel MTU is set to 1400 bytes. >>>=20 >>> Downloading a test file via SCP from the VM using the OpenVPN connection >>> takes ages and results in throughput between 400 and 700 kB/sec. While >>> normal ICMP latency through the tunnel is around 35 ms, it fluctuates bet= ween >>> 40 and 500 ms while download is running. >>>=20 >>> Needless to say, a bandwidth of 700 kB/sec is unacceptable. Disabling >>> Suricata speeds up to ~ 1.2 MB/sec, disabling Quality of Service (QoS) >>> does not have any big effects. >>>=20 >>> Since there are some clients using OpenVPN in restricted environments, >>> TCP and port 443 is more or less fixed. Switching to UDP causes a small >>> improvement (~ 800 kB/sec), but does not seem to cure the root cause. >>>=20 >>> This effect is reproducible with multiple VMs at multiple locations, >>> so I do not think it is related to network outages at one certain hoster. >>>=20 >>> What am I doing wrong? Is anyone experiencing the same problem? >>>=20 >>> As mentioned in the Subject line, any help is appreciated. >>>=20 >>> Thanks, and best regards, >>> Peter M=C3=BCller --===============5965507338026351103==--