OpenVPN performance

I would guess an Atom CPU will handle 100mbit of OpenVPN traffic. Under load you might find an Atom will introduce a little more latency than a faster CPU but this will probably not be significant when considered against the latency of any long distant links you have between the server and the clients.

Some unscientific test results, running data between my netbook with an Atom CPU to a local OpenVPN server (over a 1000mbit network, but the netbook only has a 100Mbit NIC):

dspillett@minirant:~$ time dd if=/dev/zero bs=1024 count=1048576 | nc -q 0 192.168.43.1 3333
1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 91.2072 s, 11.8 MB/s
real        1m31.227s
user        0m1.792s
sys         0m25.874s
dspillett@minirant:~$ 

dspillett@minirant:~$ time dd if=/dev/zero bs=1024 count=1048576 | nc -q 0 192.168.44.1 3333
1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 113.082 s, 9.5 MB/s
real        1m53.107s
user        0m1.468s
sys         0m15.337s
dspillett@minirant:~$

where 192.168.43.1 is the server as seen just over the local network and 192.168.44.1 is the same machine as seen via an OpenVPN link over that network. The VPN is in bridged mode, using a UDP based connection.

htop showed the CPU being taxed more during the VPN test than the user+sys counts from time indicate because time is only counting dd's CPU activity not the VPN's. It showed cpu0 at ~70% and cpu1 at ~30% all through the test which would suggest the CPU is close to the limit it can transfer via OpenVPN in that test (that Atom was single core but with hyperthreading) - though it still managed to shuffle along at 9.5Mbyte/sec.

As an indication of the latency added by the VPN (which will be a combination of overheads from CPU work encrypting data and overhead from the tunnelling method), pinging with small (default, 56 byte payload) packets:

--- 192.168.43.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8997ms
rtt min/avg/max/mdev = 0.138/0.166/0.183/0.015 ms
--- 192.168.44.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8998ms
rtt min/avg/max/mdev = 0.544/0.614/0.860/0.091 ms

and larger (2048 byte payload) ones:

--- 192.168.43.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet los
rtt min/avg/max/mdev = 0.514/0.521/0.531/0.021 ms
--- 192.168.44.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 0.710/0.997/1.437/0.173 ms

Obviously you'll get different results with the VPN handling multiple connections exhibiting real-world traffic patterns, so you might want to perform some more detailed tests yourself. You might be able to squeeze more out with some tweaking - my OpenVPN set is pretty much running on out-of-the box defaults.

I doubt that a setup that large has ever been attempted before, so you likely will be pushing limits when trying. I could find an article on a VPN deployment for 400 clients but judging from the text, the author just relied on rough estimates about how many clients could be run per CPU and lacked some understanding about how his setup would perform.

You would mainly need to consider these two points:

1. The bandwidth your data transfers are going to use would need encryption / decryption at the VPN server side, consuming CPU resources

2. OpenVPN client connections consume both, memory and CPU resources on the server even when no data is transferred

Any decent PC hardware available today should easily saturate a Gigabit link with Blowfish or AES-128, even $100 embedded devices are capable of rates near 100 Mbps, so CPU bottlenecks due to bandwidth intensity should not be of any concern.

Given the default rekeying interval of 3600 seconds, a number of 1,000,000 clients would mean that the server would need to be able to complete 278 key exchanges per second on average. While a key exchange is a rather CPU-intensive task, you could offload it to dedicated hardware if needed - cryptographic accelerator cards available easily meet and exceed this number of TLS handshakes. And memory restrictions should not bother too much as well - a 64-bit binary should take care of any virtual memory restrictions you would be likely to hit otherwise.

But the real beauty with OpenVPN is that you can scale it out quite easily - simply set up an arbitrary number of OpenVPN servers and make sure your clients are using them (e.g. through DNS round-robin), configure a dynamic routing protocol of your choice (typically this would be RIP due to its simplicity) and your infrastructure would be capable of supporting an arbitrary number of clients as long as you've got enough hardware.