On Wed, Jul 1, 2015 at 10:40 AM, Jon Gerdes <gerd...@blueloop.net> 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
