Performance Tuning Tip - VPN Speed Test

[HeikoAnkenbrand]

Different methods of block encryption are used for VPN connections. In most cases, users tend to select the highest encryption algorithm available. The question, however, is what impact this choice has on performance.

To test the performance of DES, AES, and CAST, I created a small one-liner that shows which encryption algorithm achieves the highest performance on your appliances or open servers. Please note that the test runs on only one CPU core. Since VPN is multi-core capable, you can achieve significantly higher VPN encryption rates. Under normal circumstances, you should always achieve the best encryption throughput with AES, as modern CPUs include hardware acceleration for AES. You can find more information in the following article (Performance Tuning Tip - AES-NI).

Run this one-liner preferably on the standby gateway in a cluster, as it can temporarily generate 100% CPU load. This is necessary to avoid disrupting the production environment.

The one-liner shows how many kilobytes each encryption algorithm can process within three seconds and sorts the results by speed. Adjust your VPN settings to use the fastest algorithm if necessary. However, be aware that this may reduce the overall level of security.

Copy the one-liner via copy and paste into the bash shell of your gateway. Please note that execution may take between 2 and 5 minutes, depending on the CPU speed:

cpopenssl speed aes-128-cbc aes-256-cbc des-ede3 des-cbc cast-cbc 2>/dev/null | grep "aes\|cast\|des" | awk '{print $1, $2, $(NF-1)}' | sort -k3 -n -r | grep -v opt | sed -E 's/aes-128 cbc/AES-128/g; s/aes-256 cbc/AES-256/g ; s/des cbc/DES    /g; s/des ede3/3DES   /g ; s/cast cbc/CAST   /g'

 
This is what an example output might look like on your system:


In this case, AES-128 would be the fastest encryption algorithm on the gateway. 

PS:
In my tests on various Check Point appliances, "AES-128" was always the fastest algorithm. However, from a security perspective, I would recommend using AES-256 or higher.

[Hauke]

Many thanks for the years of excellent cooperation and for the always insightful articles on CheckMates.

I do have one small question, though: there are several additional encryption algorithms that can be used in Phase 1 and Phase 2.
Is it possible to integrate those as well?

[the_rock]

Excellent!

[Timothy_Hall]

@HeikoAnkenbrand Would it be possible to add the AES-GCM-128 and AES-GCM-256 variants to the tool and update the sample screenshot accordingly?  In theory, the Galois Counter Mode variants should be faster than their non-GCM counterparts on processor hardware that supports the AES-NI extension.  For those systems without AES-NI support (such as Quantum Spark), the non-GCM versions should be used for best performance.  Thanks!

[HeikoAnkenbrand]

Hi @Timothy_Hall , I had the same idea. Unfortunately, the ciphers AES-128-GCM and AES-256-GCM are not supported in the OpenSSL version used by Check Point.

R81.20:


I’ll check that in the lab this evening under R82 or R82.10.

[PhoneBoy]

R82 uses the same version, as I recall.
R82.10 uses a newer version.

[Bob_Zimmerman]

It takes an ideal computer around a nanojoule to set the state of 128 bits. To simply count through all the possible 128-bit keys without trying to do anything with them would take around 0.0028% of the total energy the sun emits in a year. The Earth gets about 0.000000066% of the energy the sun emits, so if we covered the whole planet with 50% efficient solar cells (better than the best research cells today), it would take a little over 85 thousand years to get the energy to count through all possible 128-bit keys without doing anything with them.

On top of this, perfect forward secrecy means spending all that time and effort would get the attacker one phase 2 interval of traffic (one hour by default). Then they would have to do it all over again for the next chunk of traffic.

AES (really, symmetric encryption in general) doesn't rely on problems which quantum computers solve. The best mode of attack is on the key negotiation (and quantum computers do help with that on older asymmetric negotiation systems) or side-channels, but most of those require extreme levels of hostile access to the system being attacked.

AES-128 is more than safe enough for the lifetime of anybody currently alive.

[HeikoAnkenbrand]

@Bob_Zimmerman 

Best comment in the community 2025👍

I’m going to print out this comment, hang it on my wall, and quote you in every one of my meetings about AES.

PS:
If we cover the earth with so many solar cells, it will look a bit like the Death Star from Star Wars when viewed from space.
 

[the_rock]

Its genius, for sure! AI seems to agree 🙂

Short answer: there are 2128≈3.402823669×10382^{128}\approx 3.402823669\times 10^{38}2128≈3.402823669×1038 possible keys. Brute-forcing that whole space is effectively impossible with any realistic hardware — even astronomical resources. Below are concrete examples so you can see why.

---

Key numbers

• Total keys: 2128=340,282,366,920,938,463,463,374,607,431,768,211,4562^{128} = 340,282,366,920,938,463,463,374,607,431,768,211,4562128=340,282,366,920,938,463,463,374,607,431,768,211,456 (≈ 3.4028×10383.4028\times10^{38}3.4028×1038).

• Average work to find a random key (expected): half that, ≈ 1.7014×10381.7014\times10^{38}1.7014×1038 keys.

How long to try the whole space (and average time = half of these)

Times shown are years to exhaust the entire keyspace (divide by 2 for the average time to hit a random key).

• 1 key / second → 1.08×10³¹ years (≈ 1.08⋅10311.08\cdot10^{31}1.08⋅1031 years)

• 1,000 keys / s → 1.08×10²8 years

• 1,000,000 keys / s → 1.08×10²5 years

• 1 billion (10^9) keys / s → 1.08×10²2 years

• 1 trillion (10^12) keys / s → 1.08×10¹9 years

• 1 quadrillion (10^15) keys / s → 1.08×10¹6 years

• 1 exa (10^18) keys / s → 1.08×10¹3 years (≈ 10.8 trillion years)

• 1 yotta (10^24) keys / s → 1.08×10⁷ years (≈ 10.8 million years)

• 10^30 keys / s → ~10.8 years

So to finish the whole 128-bit keyspace in a decade you'd need on the order of 103010^{30}1030 keys per second — an utterly unrealistic rate with any physically plausible technology today.

For perspective: the age of the universe is ≈ 1.38×10¹⁰ years (≈ 13.8 billion years).

• At 10^18 keys/s (extremely fast), cracking the entire 128-bit space would still take ~782 × the age of the universe.

• At 10^24 keys/s it would take ~10.8 million years (still far longer than any practical attack window).