Slow IPsec VPN

Hardware crypto offload is the best.

If you use AES 128 GCM (not 3DES) and one of the new Intel processors with AES-NI, you should now be getting hardware crypto.  Unless you already have a similar Intel NIC in the box, you will need to reload.

So to max your VPN tunnel you have to use multiple threads.

Have you tested that Frank?  I assume you mean multiple IPsec Connection definitions, thus creating multiple tunnels.

Cheers - Bob

HI,

Have you tested that Frank?  I assume you mean multiple IPsec Connection definitions, thus creating multiple tunnels.
Cheers - Bob

No one VPN connection to the remote site and multiple TCP connections inside.
Example,
You want to download 5 ISO files from the remote site via FTP inside the tunnel.
1; Download one at a time results in an download speed the is for instance 2-4mbit.
2; Add one new download and it will get the same speed. But altogether 6-8Mbit
3; Add another and it two till get 2-4mbit but the aggregated speed is now 11-13Mbit.


If I download an single file using Free Download Manager and have 4 sections the alltogether speed of the dowenload is the same as the max above but using 1 section results in 2-4mbit.


So it is the single tcp connection that is the limiting factor. 
I have tried FTP, SMB that I recall. Could be more. 

I did some testing and the issue is the same when using Site-To-Site SSL tunnel as well.

My guess is an buffer, Perhaps the NIC buffer or and system wide QoS buffer that will not be shut off when I disable QoS.

I did some googling about this last time and there was an command to see the buffers and you could see that it was counting although QoS was shut off.


Best Regards
Frank

Hi. As IPSEC tunnels aren´t multithreaded, a single tunnel will only get as fast until it maxes out the specific CPU core on the multicore CPU where it´s running. For a 2,9 GHz (I assume consumer core2 or core i) CPU 300 MBits is a realistic value for a single tunnel.

If your CPU´s already supports AES-NI extension, you most likely might get some extra boost by using the AES128_GCMxx encryption ciphers instead of "Normal" AES128.

Otherwise only higher CPU MHz will help speeding up things further.

BTW: Already followed the tweaking guide link in my signature ?

/Sascha

Hi. As IPSEC tunnels aren´t multithreaded, a single tunnel will only get as fast until it maxes out the specific CPU core on the multicore CPU where it´s running. For a 2,9 GHz (I assume consumer core2 or core i) CPU 300 MBits is a realistic value for a single tunnel.

If your CPU´s already supports AES-NI extension, you most likely might get some extra boost by using the AES128_GCMxx encryption ciphers instead of "Normal" AES128.

Otherwise only higher CPU MHz will help speeding up things further.

BTW: Already followed the tweaking guide link in my signature ?

/Sascha

Hi, yes I have read your guide. I am not new to networking, just Sophos UTM running on consumer hardware [:)]

Hi. As IPSEC tunnels aren´t multithreaded, a single tunnel will only get as fast until it maxes out the specific CPU core on the multicore CPU where it´s running. For a 2,9 GHz (I assume consumer core2 or core i) CPU 300 MBits is a realistic value for a single tunnel.

If your CPU´s already supports AES-NI extension, you most likely might get some extra boost by using the AES128_GCMxx encryption ciphers instead of "Normal" AES128.

Otherwise only higher CPU MHz will help speeding up things further.

BTW: Already followed the tweaking guide link in my signature ?

/Sascha

Hi, yes I have read your guide. I am not new to networking, just Sophos UTM running on consumer hardware [:)]