- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: IPsec Throughput
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IPsec Throughput
Hello,
My internet connection speed is 100Mbps, testing by accessing speedtest.net and showing 101.90Mbps for download and 115.14Mbps for upload.
I also have IPsec site to site tunnel to connecting our onprem to azure, and when i do speed test by copy larger file from onprem to the azure i can see the traffic is not fully utilize the available bandwidth.
testing speed only get about 3-4 MB/s or about 30Mbps. Anyone know how to fine tuning my checkpoint to get better utilization for ipsec?
- Labels:
-
Site to Site VPN
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3des is the worst for performance see:
https://support.checkpoint.com/results/sk/sk73980
https://support.checkpoint.com/results/sk/sk98950
Change asap since it is very weak encryption method
If you like this post please give a thumbs up(kudo)! 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
And what about the load of the participating gateways in S2S tunnel? One for eg. SCP connection is handled by one CPU core. Can you check the CPU-s on both side?
Maybe the bottleneck is on the AZURE side? Can you check it somehow without VPN?
Akos
\m/_(>_<)_\m/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How i can check the load?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
#cpview
#top
#htop
If you are not familiar with the last 2 commands use #cpview CPU tab. You will see the CPU utilization
Akos
\m/_(>_<)_\m/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here result of 3 command, seems the utilization is normal.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
This depends on a few factors. Most common:
What blades are enabled on the gateways.
What encryption methods are used? (for example 3DES is not only very unsafe but also very intensive for the load)
If you like this post please give a thumbs up(kudo)! 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Enabled blades is : Firewall, S2S VPN, Mobile Access, App Control, URL Filtering, IPS, Antibot, Antivirus, network policy management & Log.
The encryption i used on VPN community string is AES-256 for phase 1 and 3DES for phase 2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3des is the worst for performance see:
https://support.checkpoint.com/results/sk/sk73980
https://support.checkpoint.com/results/sk/sk98950
Change asap since it is very weak encryption method
If you like this post please give a thumbs up(kudo)! 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Changed to AES-128 and have better throughput. Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can tell you that literally 99% of the time when I worked with folks on this exact problem, I always found it to be one of the 2 problems.
1) Encryption methods used
OR
2) MTU size
Never a combination of both.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Site-to-Site VPN performance issues generally come down to some combination of these three things:
1) Path Low MTU Issues - From expert mode on your Check Point firewall run tracepath to your Azure VPN peer, this will report the max MTU for that network path. If it is less than 1500 you may need to allow ICMP Type 3, Code 4 packets into your firewall from anywhere for pmtud to work, or look at TCP MSS Clamping
2) Slow algorithms in use like 3DES (already mentioned in this thread) - remember that the Phase 2/IPSec tunnel transfers the vast majority of data through a VPN so its encryption setting will have a far greater impact than the one for IKE/Phase 1. You may want to look at using the GCM versions of AES which are even more efficient than standard AES and also capable of being fully offloaded into the AES-NI processor extension, if the Azure peer supports GCM
3) Encryption/Decryption operations for a particular VPN tunnel can only happen on one core, or are stuck in the slowpath - If the first two listed are not the issue (check them first), the traffic may be in the F2F/slowpath due to what blades you have enabled or other unusual conditions being present, or it is being bottlenecked by single-core limitations as in the case of an elephant flow
All this is covered quite extensively in my Gateway Performance Optimization Course.
CET (Europe) Timezone Course Scheduled for July 1-2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Here result of tracepath, seem 1500 MTU i used. Am i right?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You got it.
