Slow IPsec and slightly faster OpenVPN

itatcapital · Jan 15, 2017, 11:04 PM

Hello,

TL;DR

I am trying to understand why our IPSec and OpenVPN transfers are slow compared to raw transfer. I realise there will be some overhead but the below transfer speeds are quite slow.

When I transfer data between the two sites over an open connection (not IPsec or OpenVPN) I see transfer speeds of 75 Mbps. I used two linux servers and transferred data a combination of "dd" and "nc"
When I use IPsec, the transfer rate fluctuates between 10 Mbps and 45 Mbps during the transfer, with the overall transfer at about 25 Mbps
When I use OpenVPN, the transfer rate fluctuates between 10 Mbps and 60 Mbps during the transfer, with the overall transfer at about 45 Mbps

we have two sites with 100/100 Mbps connections to the internet at each site.
Both sites use the same ISP (Telstra in Australia) and all traffic is carried over the same ISP's network.
We plan on setting up VPN's between six different site so this performance and CPU usage is a concern

Site 1: SG-2440 with Firmware 2.2.6-release
Site 2: SG-2440 with firmware 2.3.2-RELEASE-p1

When I transfer data between the two sites over an open connection (not IPsec or OpenVPN) I see transfer speeds of 75 Mbps. I used two linux servers and transferred data a combination of "dd" and "nc"

On the server:

nc –vvlnp 12345 > /dev/null

On the client:
dd if=/dev/zero bs=1M count=1k | nc -vvn <external-ip-address>12345

HOWEVER:
1. IPsec
When I use IPsec, the transfer rate fluctuates between 10 Mbps and 45 Mbps during the transfer, with the overall transfer at about 25 Mbps

2. OpenVPN
When I use OpenVPN, the transfer rate fluctuates between 15 Mbps and 70 Mbps during the transfer, with the overall transfer at about 50 Mbps

I note that

for IPsec, the CPU usage on both devices increases to about 35%
for OpenVPN, the CPU usage on both devices increases to about 70%

IPSec settings (although I tried a few different settings)
IPSec: Phase 1 : AES (256 bits)/SHA1
IPSec: Phase 2 : ESP/ AES (auto)/SHA1

OpenVPN settings:
Peer-to-Peer (Shared Key)
AES-256-CBC
SHA1
No compression

I would prefer to use IPSec but may be ok with OpenVPN, although the high CPU usage on one link is a problem.

Any assistance or thoughts would be welcome.</external-ip-address>

Derelict · Jan 16, 2017, 2:04 AM

It sounds like you might have a path MTU issue. You might try enabling MSS Clamping in the advanced IPsec settings. Maybe try something around 1300 and test again to see if there are some improvements.

To test to see what you're looking at you want to make sure at least one side's WAN address responds to pings then do something like:

Diagnostics > Command prompt

Execute command:

ping -c 3 -D -s 1472 far_side_ip_address

A full MTU 1500-byte path should be able to pass that and fail at size 1473.

If that fails then reduce the size until you can pass frames.

All of this is easier from the console/ssh option 8.

itatcapital · Jan 16, 2017, 2:25 AM

Thanks for the reply, Derelict
I will give that a try

itatcapital · Jan 16, 2017, 4:00 AM

@Derelict:

It sounds like you might have a path MTU issue. You might try enabling MSS Clamping in the advanced IPsec settings. Maybe try something around 1300 and test again to see if there are some improvements.

To test to see what you're looking at you want to make sure at least one side's WAN address responds to pings then do something like:

Diagnostics > Command prompt

Execute command:

ping -c 3 -D -s 1472 far_side_ip_address

A full MTU 1500-byte path should be able to pass that and fail at size 1473.

If that fails then reduce the size until you can pass frames.

All of this is easier from the console/ssh option 8.

That did not seem to improve performance.
Should I also set this value (MSS)and MTU in the Interfaces WAN or LAN section to ensure packets are sized correctly?

thanks

Derelict · Jan 16, 2017, 5:26 AM

No.

itatcapital · Jan 16, 2017, 5:32 AM

@Derelict:

No.

thanks again. I realised after I posted that it would not be necessary.

I see the point of the settings. It did not make a difference but I will persevere.

I wonder if the SG-2440 is just not up to the task of encrypting traffic at those speeds.

cheers!

Derelict · Jan 16, 2017, 8:16 AM

Those speeds are not something the SG-2440 will not keep up with.

There is something else going on.

You did not say what you did with the MSS or where.

I would stick with IPsec. Set your phase 2 encryption settings to AES-GCM and turn off all hash algorithms.

Make sure powerd is enabled in hi-adaptive mode for all contexts in System > Advanced, Misceallaneous

itatcapital · Feb 6, 2017, 1:16 AM

Sorry for my late response. I had some unexpected, personal leave.

1. MSS clamping
I tried a range of values from 1000 to 1500
–> no meaningful change, i.e. low and fluctuating speeds

2. Phase 2 encryption

I tried all values of AES-GCM
again, no meaningful change, i.e. low and fluctuating speeds

3. Turning off hash algorithms

Do you mean in Phase 2 only?
Hash algorithms cannot be turned off, so I chose SHA1

4. powerd

this is set to Enabled and hi-adaptive in all contexts

I will have another connection available in a few days will be able to test using virtual endpoints, using the community edition, instead, running server-class CPUs

thanks for your assistance.