My gut reaction is two-fold;
- is the line capable of bi-directional throughput at that level; prove
it via some other means like an unencrypted junk file transfer back and
forth
- is the VPN device processor maxing out? i.e. is it capable of feeding
the line at that rate with encrypted data
Tim
On Wed, Jul 1, 2015 at 10:40 AM, Jon Gerdes wrote:
> Your first job is to establish a real baseline. That is: How fast can
> you really move data between the two sites without any tunnels? You may
> have to be creative with NATting and other tricks to get a system at
> each end to see the other
On 1/7/15 3:37 pm, Seth Mos wrote:
You mean 18Mbps downstream? Not upstream?
No, I mean 18Mbps upstream. Downstream is way higher - around 75Mbps at
each site.
On 1/7/15 3:40 pm, Jon Gerdes wrote:
If your ~18Mbps is a real measured figure then consider: UDP vs TCP,
MTU, TUN vs TAP. You do
On Wed, 2015-07-01 at 15:16 +0100, Chris Bagnall wrote:
> Greetings list,
>
> I'm trying to improve OpenVPN performance on a site-to-site link I have
> between 2 pfSense boxes.
>
> I am currently only getting around 7Mbps each way via the OpenVPN
> tunnel, measured by running iperf back and for
Chris Bagnall schreef op 1-7-2015 om 16:16:
> Greetings list,
>
> I'm trying to improve OpenVPN performance on a site-to-site link I have
> between 2 pfSense boxes.
>
> - upstream at each site is provided by a VDSL connection delivering
> ~18Mbps
You mean 18Mbps downstream? Not upstream?
That
Greetings list,
I'm trying to improve OpenVPN performance on a site-to-site link I have
between 2 pfSense boxes.
- upstream at each site is provided by a VDSL connection delivering
~18Mbps
- both pfSenses are PCEngines APU w/ 4GB RAM
I am currently only getting around 7Mbps each way via
