public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Tom Rymes <trymes@rymes.com>
To: development@lists.ipfire.org
Subject: Re: Extremely poor OpenVPN performance, help wanted
Date: Tue, 24 Sep 2019 10:04:37 -0700	[thread overview]
Message-ID: <DBD9E30F-953C-4431-BC4C-F8CCAE3B37EA@rymes.com> (raw)
In-Reply-To: <b974af0e-142c-8bb0-5be0-2dd204871539@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

Peter,

Is the issue reproducible on different OS and different OpenVPN clients? There’s a chance that the issue lies with FreeBSD or how you are configuring the VMs at different locations.

Tom

> On Sep 24, 2019, at 9:23 AM, <peter.mueller(a)ipfire.org> <peter.mueller(a)ipfire.org> wrote:
> 
> Hello list,
> 
> 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 not.
> 
> 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 =
>    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.
> 
> 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 between
> 40 and 500 ms while download is running.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> What am I doing wrong? Is anyone experiencing the same problem?
> 
> As mentioned in the Subject line, any help is appreciated.
> 
> Thanks, and best regards,
> Peter Müller

  reply	other threads:[~2019-09-24 17:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-24 16:22 peter.mueller
2019-09-24 17:04 ` Tom Rymes [this message]
2019-09-25 19:13   ` peter.mueller
2019-09-26  3:21     ` Tom Rymes
2019-10-29 17:41       ` peter.mueller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DBD9E30F-953C-4431-BC4C-F8CCAE3B37EA@rymes.com \
    --to=trymes@rymes.com \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox