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 Clarke

On 01/07/15 16:49, Vick Khera wrote:
> On Wed, Jul 1, 2015 at 10:40 AM, Jon Gerdes <[email protected]> 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.
>>
> After you have done this do some of these things. These are all things I
> had to try to debug a horribly performing OpenVPN tunnel (about 10% of raw
> baseline in one direction only, other direction was line speed).
>
>
>    - Turn on/off the network offloading switches: checksum, TCP
>    segmentation, LRO. Do this one at a time. For APU you want checksum offload
>    disabled, but the others on in normal use. Disable here only to satisfy
>    yourself that they are not the culprit.
>    - Try different ciphers. AES-128-CBC is great and works with the
>    hardware cryptodev engine in modern CPUs.
>    - turn on/off BSD cryptodev (you already did this one)
>    - Try TCP instead of UDP (likely will be slower, though)
>    - change the MTU size to be smaller on the VPN link using the advanced
>    OpenVPN configurations
>    - use NULL encryption to rule out slow CPU crypto (you've already done
>    this one)
>    - Switch to IPSEC to rule out some crazy on intermediate routers between
>    endpoints
>    - Use port 443/TCP for same reason as above.
>
> For me, none of this made a difference and I gave up. Until the one day
> that my primary firewall WAN NIC died on the motherboard. The failover box
> took over and suddenly OpenVPN was running at line speed between the two
> endpoints. It turns out in my case that the NIC had started to fail a few
> months before, and the only symptom was outbound wrapped packets, either
> OpenVPN or IPSEC, would be lost frequently and retransmitted. Nonetheless,
> the above tricks should help you optimize your connection once you
> determine your raw baseline speed.
> _______________________________________________
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold

_______________________________________________
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Reply via email to