I've been using a couple of Archer C7 devices (v2 and v4) for a while, and recently I moved IPsec setup from HP miniserver behind a router to the router itself (it is Archer C7 v2 device running OpenWRT 18.06.1).
I noticed that the VPN bandwidth is quite low comparing to previous setup, charon process is running at 97-99% CPU. I did a quick googling and found this page:
The mcespi.c module mentioned there wasn't able to compile in my environment, but I managed to get it done - for the reference, here's the code:
So I got the mcespi.ko, copied it to the device, did "insmod mcespi" and checked that it actually was loaded ("lsmod" and "cat /proc/crypto").
However, I don't see any changes - charon still consumes almost all the CPU, bandwidth is the same. I have the following ciphers configured in ipsec.conf:
ike=aes128-sha-modp1536,aes128-sha-modp1024,aes128-md5-modp1536,aes128-md5-modp1024,3des-sha-modp1536,3des-sha-modp1024,3des-md5-modp1536,3des-md5-modp1024
esp=aes128-sha1,aes128-md5,3des-sha1,3des-md5
Is something wrong with the setup? Should the mcespi module be "switched on" somehow? How can I ensure that the module is actually working?
Assembler or C, a typical MIPS-based SoC is never going to be fast for VPN. Depending on the VPN bandwidth you need and security requirements, I’d put the end point back on the mini-server, in a VM, or on another device with appropriate hardware and crypto support.
I’d also evaluate your cipher list if you stay with IPSec
I second everything said by Jeff above. Setting up software crypto on this device may not be worth the trouble.
To ensure that the module is being used:
For the esp parameter in ipsec.conf, list the algorithms supported by the mcespi driver, or a subset of them. End the list with an exclamation mark to make it exclusive. You can find the supported algorithms in /proc/crypto by looking at the driver field.
Dump /proc/crypto before and after starting the connection. Compare the files, look for changes in the refcnt field.
That's interesting. I'm not sure tools like perf are available directly on the device, but I'm sure the charon process is the only one hitting CPU during the transfer.
Restart charon and check the log for loaded plugins. Make sure it is using the kernel-netlink plugin. Do not use the kernel-libipsec plugin, which handles IPsec in userspace.
However, CPU load caused by the kernel implementation of IPsec does not appear in the process list, only in the summary. Look at idle, for example, which decreases under load.
Removing strongswan-mod-kernel-libipsec and restarting ipsec did the trick! I'm now seeing bandwidth improvements even without mcespi loaded, but for some reasons I can't reach hosts behind the router directly if ipsec is operating in kernel. However, port forwarding works fine.
Ah, just checked the rules and it seems like there's no ipsec0 interface anymore, hence the firewall rules also do not work.
Could someone point me to the right direction on how to resolve this?
option extra_src '-m policy --dir in --pol none'
option extra_dest '-m policy --dir out --pol none'
to wan and lan zones configuration resulted in the following error during firewall reload and total router unavailability:
Oct 21 22:37:15 archer-c7-v2 kernel: [ 7976.111557] xt_policy: input policy not valid in POSTROUTING and OUTPUT
Oct 21 22:37:15 archer-c7-v2 kernel: [ 7976.137766] xt_policy: input policy not valid in POSTROUTING and OUTPUT
Oct 21 22:37:15 archer-c7-v2 kernel: [ 7976.179248] xt_policy: input policy not valid in POSTROUTING and OUTPUT
Anyway, thanks a lot for you help! I guess firewall issues aren't relevant in this particular topic. I'll try to handle it further.
Just for the reference, some numbers from iperf3 output, client is running on a laptop connected by wifi in one location, server is either HP miniserver connected by wire to the Archer C7 (v2), or Archer C7 itself (latest measurement) in another location, ISP is the same in both locations, bandwidth is limited to 50 Mbits/s by ISP, units is Mbits/sec, results go through ministat(1):
ipsec (no mcespi):
N Min Max Median Avg Stddev
x 60 29.6 37.5 35.2 34.933333 1.5985869
ipsec (mcespi):
N Min Max Median Avg Stddev
x 60 38.8 45.4 44.15 43.868333 1.079154
directly to the router:
N Min Max Median Avg Stddev
x 60 36.8 48.1 46.5 46.083333 2.0081332
I'll make another test with a router, server and client in the same room and wired connections, but overall I'm quite fine with the numbers for my particular purposes.