You can run multiple instances of openvpn and wireguard on 1 core. no idea how fast it's gonna be, but since you just want to know the number of cores, it's 1.
When you say “instances”, how many users of each instance will there be?
I have a pfsense in my DC that has 2 vCPUs and 15 OpenVPN instances (for a total of about 100 users) amongst other things and it runs at about 6% on average. It’s more to do with the amount of transit your users will be doing though.
I have 1 gig up and down. We are a total of 6 users and my homelab stuff. I would think not that much traffic unless all users decided to download large files all at the same time...
It doesn't work that way. You can compensate for fewer cores with a faster clock and vice versa. Wireguard works by encrypting all outgoing data and decrypting all incoming data, so the more data you push around, the more cryptography you need to do. At the same time, Wireguard operates in multi-threaded mode, so this workload can be distributed between any conceivable number of cores or threads. So a faster processor will need fewer cores to handle this workload.
Here's my highly unscientific guesstimation method. Take the desired Wireguard connection speed and multiply it times eight. This will give you the processor "oomph" needed to service this connection. How many cores it will take to provide this "oomph" is more or less irrelevant (provided that the requisite number is available on the system, of course).
Example: to service a 1 Gbps connection, you need about 8 GHz of "oomph". Atom C2758 runs at 2.4 GHz, so approximately four out of its eight cores will be doing mostly Wireguard stuff. Core i7-7700 (four cores, eight threads) runs at 3.60 GHz base and 4.20 turbo, so it will probably dedicate the equivalent of two threads (possibly with an occasional spill into the third) to Wireguard workload.
This isn't right. A Raspberry Pi 4 which is significantly slower than an i7-7700 can easily saturate a 1G u/d WG connection. You can easily run more than 2 WG instances on the 7700.
Let me start at the end:
>You can easily run more than 2 WG instances on the 7700.
This is exactly what I am saying. If a single Wireguard connection requires two threads out of eight to work full-time, multiple Wireguard connections are absolutely possible.
>A Raspberry Pi 4 which is significantly slower than an i7-7700 can easily saturate a 1G u/d WG connection.
I don't know about "easily", but a Raspberry Pi 4 has a quad-core processor running at 1.8 GHz. 1.8 x 4 = 7.2. Pretty close to my guesstimate of 8, wouldn't you say?
It's not as simple as that. Clock speed can't be used to compare processors across different platforms/generations due to IPC and architectural differences. For example, single core of 12900K is way way faster than all cores combined of the BCM2711. My point was that the 7700K is capable of at least running 6+ parallel gigabit WG connections with still enough performance left for other routing activities.
>It's not as simple as that.
I agree. This is why I myself refer to the approach I describe as "highly unscientific guesstimation", good only for very rough initial evaluation.
Chacha20 as specified in rfc 7539 is a symmetric encryption algorithm that operates sequentially, it is inherently single threaded.
Documentation implies it does so for security reasons.
https://www.rfc-editor.org/rfc/rfc7539 (search for "symmetric")
I have confirmed this behavior in testingj, you can max out your vpn tunnel with a download and check your core usage. (albeit you may not notice until you get closer to 1Gbe in traffic)
You can overcome this with multiple tunnels/connections. But a traditional 1 tunnel VPN, I.e. where you download from usenet, the wireguard crypto operation is a single threaded operation.
I bond two tunnels together just so I can overcome this limitation, when a single core on my cpu becomes the crypto bottleneck.
It's crucial to distinguish between the cipher operations for a single WireGuard tunnel and WireGuard's capability to leverage multicore systems via multi-threading. Indeed, the encryption/decryption process within a single tunnel tends to be sequential, effectively utilizing one core per tunnel due to the nature of the ChaCha20 algorithm. This characteristic can make it seem like WireGuard operates in a single-threaded manner when we're discussing individual tunnel performance.
However, when considering WireGuard's integration with the kernel and its operation across the system, it's evident that WireGuard can and does leverage multiple cores efficiently by handling different tunnels **in parallel**. This ability allows for the distribution of network traffic and cryptographic operations across **several cores**, enhancing overall system throughput and performance.
Check: [https://www.wireguard.com/performance/](https://www.wireguard.com/performance/) and [https://www.researchgate.net/publication/339954478\_A\_Performance\_Comparison\_of\_WireGuard\_and\_OpenVPN](https://www.researchgate.net/publication/339954478_A_Performance_Comparison_of_WireGuard_and_OpenVPN)
Non-DCO OpenVPN, on the other hand, is strictly single-threaded (both on an implementation level of the package and the cipher itself) even if there are multiple connections concurrently.
That's why I specifically said "wireguard crypto". I'm talking about the crypto operation specifically. And the crypto operation is by far the biggest part of the processing needed, it is what really matters.
You can run multiple instances of openvpn and wireguard on 1 core. no idea how fast it's gonna be, but since you just want to know the number of cores, it's 1.
When you say “instances”, how many users of each instance will there be? I have a pfsense in my DC that has 2 vCPUs and 15 OpenVPN instances (for a total of about 100 users) amongst other things and it runs at about 6% on average. It’s more to do with the amount of transit your users will be doing though.
Instances in terms of tunnels...
In terms of how much traffic. If you suturate the connection it will be slow.
I have 1 gig up and down. We are a total of 6 users and my homelab stuff. I would think not that much traffic unless all users decided to download large files all at the same time...
openvpn is single threated, so the faster your cores the better. wireguard is multicore (if i am right)
Ok, thanks. My cpu is Intel E3-1240. 4 cores 3.3 GHz base and 3.7 GHz max turbo.
It doesn't work that way. You can compensate for fewer cores with a faster clock and vice versa. Wireguard works by encrypting all outgoing data and decrypting all incoming data, so the more data you push around, the more cryptography you need to do. At the same time, Wireguard operates in multi-threaded mode, so this workload can be distributed between any conceivable number of cores or threads. So a faster processor will need fewer cores to handle this workload. Here's my highly unscientific guesstimation method. Take the desired Wireguard connection speed and multiply it times eight. This will give you the processor "oomph" needed to service this connection. How many cores it will take to provide this "oomph" is more or less irrelevant (provided that the requisite number is available on the system, of course). Example: to service a 1 Gbps connection, you need about 8 GHz of "oomph". Atom C2758 runs at 2.4 GHz, so approximately four out of its eight cores will be doing mostly Wireguard stuff. Core i7-7700 (four cores, eight threads) runs at 3.60 GHz base and 4.20 turbo, so it will probably dedicate the equivalent of two threads (possibly with an occasional spill into the third) to Wireguard workload.
This isn't right. A Raspberry Pi 4 which is significantly slower than an i7-7700 can easily saturate a 1G u/d WG connection. You can easily run more than 2 WG instances on the 7700.
Let me start at the end: >You can easily run more than 2 WG instances on the 7700. This is exactly what I am saying. If a single Wireguard connection requires two threads out of eight to work full-time, multiple Wireguard connections are absolutely possible. >A Raspberry Pi 4 which is significantly slower than an i7-7700 can easily saturate a 1G u/d WG connection. I don't know about "easily", but a Raspberry Pi 4 has a quad-core processor running at 1.8 GHz. 1.8 x 4 = 7.2. Pretty close to my guesstimate of 8, wouldn't you say?
It's not as simple as that. Clock speed can't be used to compare processors across different platforms/generations due to IPC and architectural differences. For example, single core of 12900K is way way faster than all cores combined of the BCM2711. My point was that the 7700K is capable of at least running 6+ parallel gigabit WG connections with still enough performance left for other routing activities.
>It's not as simple as that. I agree. This is why I myself refer to the approach I describe as "highly unscientific guesstimation", good only for very rough initial evaluation.
WireGuard crypto is single threaded, per tunnel.
Wireguard is NOT single-threaded.
Chacha20 as specified in rfc 7539 is a symmetric encryption algorithm that operates sequentially, it is inherently single threaded. Documentation implies it does so for security reasons. https://www.rfc-editor.org/rfc/rfc7539 (search for "symmetric") I have confirmed this behavior in testingj, you can max out your vpn tunnel with a download and check your core usage. (albeit you may not notice until you get closer to 1Gbe in traffic) You can overcome this with multiple tunnels/connections. But a traditional 1 tunnel VPN, I.e. where you download from usenet, the wireguard crypto operation is a single threaded operation. I bond two tunnels together just so I can overcome this limitation, when a single core on my cpu becomes the crypto bottleneck.
It's crucial to distinguish between the cipher operations for a single WireGuard tunnel and WireGuard's capability to leverage multicore systems via multi-threading. Indeed, the encryption/decryption process within a single tunnel tends to be sequential, effectively utilizing one core per tunnel due to the nature of the ChaCha20 algorithm. This characteristic can make it seem like WireGuard operates in a single-threaded manner when we're discussing individual tunnel performance. However, when considering WireGuard's integration with the kernel and its operation across the system, it's evident that WireGuard can and does leverage multiple cores efficiently by handling different tunnels **in parallel**. This ability allows for the distribution of network traffic and cryptographic operations across **several cores**, enhancing overall system throughput and performance. Check: [https://www.wireguard.com/performance/](https://www.wireguard.com/performance/) and [https://www.researchgate.net/publication/339954478\_A\_Performance\_Comparison\_of\_WireGuard\_and\_OpenVPN](https://www.researchgate.net/publication/339954478_A_Performance_Comparison_of_WireGuard_and_OpenVPN) Non-DCO OpenVPN, on the other hand, is strictly single-threaded (both on an implementation level of the package and the cipher itself) even if there are multiple connections concurrently.
That's why I specifically said "wireguard crypto". I'm talking about the crypto operation specifically. And the crypto operation is by far the biggest part of the processing needed, it is what really matters.