I have an IPSEC VPN tunnel between a CCR1016-12-1S+ and a CCR1036-8G-2S+ router.
VPN is working fine itself, but there is a problem with data rate. Max ISP speed between the links is 170mbit.
When I make a bandwith test between the routers, both TCP and UDP speeds are the maximum 170mbit, however when copying a file over one server to another over VPN the max speed is somewhere around 30-50mbit.
When I use btest.exe app on a server on one side and make bandwith test to it from the other router the TCP connection shows the slow 30-50mbit but UDP is 170mbit.
What could be the issue?
Hi, thanks for your reply.
Interfaces have only-hardware-queue specified. Tried to set it to multi-queue-ethernet-default, but there was no improvement.
Next I tried different encryptions and there seems to be the issue. Using AES-CBC 50mbit, AES-CTR 70mbit and Camelia 100mbit. When specified “null” then throughput is maximum speed, but this isn’t a great solution I think.
What encryption would you recommend in terms of security/speeds?
The rule of thumb I always use with customers is to have the more robust (okay, less famous to be already broken) encryption scheme with highest troupught achievable, let’s say a compromise.
For example in your case if you choose sha1 as hash algo and aes-256 (very robust enc schema) you enable the hardware encryption. In general we expect that hardware encryption will give a boost. Anyway in some scenarios becasue it will use more than one available core processing indepenedenlty packets, maybe a lot of work will be required at the endpoint to resequence the packet received with performance degradation. For this phenomenon check state-sequence-errors
Anotehr thing they advise basically in IPsec / VPN manual is to calculate the best MTU toa void IP fragmentation and this was saving me a lot of time on eterogenous kind of vpn (like sstp or l2tp)
Then add this one. You can remove those of PPP (there is a setting in the PPP profile that generates those) or just keep them.
Also make sure you are running the 6.39 or higher software!
Before you update, first do a telnet or ssh to make sure it does not ask the question about initial config anymore.
MTU … It can be so much fun. The clamp-tcp-mss won’t fix all of your problems. I’d look at using a GRE or IPIP tunnel wrapped in IPSec and setting a layer 3 MTU personally.
Here are the link to 2 posts I did very recently regarding MTU. That said MTU size can vary when you add IPSec into the mix. Cisco recommends IPSec GRE tunnels to be set to 1400 for layer 3 MTU and 1360 for TCP MSS (or just clamp-tcp-mss in the tunnel configuration option on MikroTik).
Like I say in the other post you may also find a performance boost by setting the clients MTUs when using IPv4. Even if you correctly set the MTU and TCP MSS values you can end up having fragmentation at the layer 3 boundary in my examples case that would be the router. In IPv4 the router is responsible to handle fragmentaiton. Slowing down the process and increasing resource utilization greatly. In other words when you are trying to min-max bandwidth over tunnels. Don’t leave out the client MTU setting. I commonly recommend setting this value on the client if a majority of the traffic at say a remote office is going to traverse the tunnel. Even if they dump Internet off locally.