Excessive 60C CPU usage with heavy traffic thru IPSEC tunnel

[MikeU]

I have a 60C-WiFi (4.0 MR2) at home and have setup a route-based IPSEC tunnel to a 110C (4.0 MR3) at the office. The tunnel comes up fine and stays up without problems. However, if I try to pass a lot of traffic through the tunnel, the CPU usage on the 60C becomes excessive and essentially brings the 60C to a crawl. My laptop is directly connected to the 60C, and ping responses will take 2800+ ms - whether connected by cable or WiFi. It doesn' t matter if the heavy traffic is voice, FTP or SMB. When the CPU is getting hammered, it is the system, not user, processes consuming the CPU. When this happens, the GUI and CLI interfaces are almost completely unresponsive. The output of ' diag sys top' appears incorrect - some processes show impossible numbers. If there is a small amount of IPSEC traffic (like just a VNC session and Outlook), I can get very good throughput to the internet via the 60C. So, I doubt that this is a physical problem. If I disable the IPSEC tunnel and use SSL VPN from my laptop to the same 110C, the throughput is significantly better than the IPSEC tunnel - comparable to connecting to a non-Fortinet VPN appliance we have in the office. Fortinet support has double-checked VPN setup, firewall policies, port settings (speed/duplex) and also asked me to change session-helpers & mtu size. I' ve had this ticket open with Fortinet support for more than 2 weeks, and it seems that we' re not getting any closer to a solution. I wouldn' t call this critical, but I need to find a solution - or give up on the 60C and put a tally in the anti-FortiGate column. ;) Has anyone worked through similar problems with IPSEC tunnels on a 60C?

[ede_pfau]

I' m mostly working behind a 60B running 4.2.11 and a lot of IPsec VPN tunnels, and never experienced a situation like that. - which encryption do you use? some time ago there' s been a bug in the AES256 encryption. Try to vary this to say AES128, 3DES, with and without digest (MD5, SHA1). Avoid any other SHA algorithm for now (if available). - I assume you use the tunnel without UTM protection which is processed by the CPU alone - in general it would help to have all the IPsec parameters posted - any logging going on? logging level?

[MikeU]

Thanks for the reply. I' ll try the different encryption settings. If that doesn' t help, I' ll probably try updating the firmware to the most recent. Then, I' ll try an older 100A that is now a spare. Correct, there is no UTM, and the only fw policy is allow all. Logging is memory only, information level. Settings: Mode: Main Auth: PSK Accept any peer IKE: v1 P1 Proposal: 3DES, SHA256, DH = 5 Keylife = 86400 XAuth: Disable NAT Traversal: Enable Keep Alive: 10 Dead Peer Detection: Enable P2 Proposal: 3DES, SHA256, Enable replay detect, Enable PFS, DH = 5 Keylife: 14400 Auto Keep Alive: Enable (No quick mode selectors)

[ede_pfau]

I see - reduce the computational load a bit: - from SHA256 to SHA1 - from DH group 5 to group 2 (shorter keylength), both in phase 1 and 2 You won' t loose any significant measure of security by following this. Be cautious before you switch firmware versions. You can always go to 4.2.11 if you' re on a lesser patch level. But think twice before upgrading to a 4.3 release. Experience shows that it' s got more functionality and higher memory footprint. Don' t take my word for it, have a look at the 100+ posts about 4.3 ...

[ddskier]

ORIGINAL: ede_pfau I see - reduce the computational load a bit: - from SHA256 to SHA1 - from DH group 5 to group 2 (shorter keylength), both in phase 1 and 2 You won' t loose any significant measure of security by following this. Be cautious before you switch firmware versions. You can always go to 4.2.11 if you' re on a lesser patch level. But think twice before upgrading to a 4.3 release. Experience shows that it' s got more functionality and higher memory footprint. Don' t take my word for it, have a look at the 100+ posts about 4.3 ...

Does fortinet have any plans to optimize for SHA256 or is it a hardware limitation?

[harald21]

Hello, modify your ipsec settings: DES, 3DES, AES encrytion are handled by the content processor, the same is with MD5 or SHA1 authentication. SHA256 is handled by the main cpu - so it is better to avoid this. You can check this at the Fortigate CLI: " get vpn status ipsec" Sincerely Harald

[MikeU]

Thanks Ede & Harold. Reducing the encryption level helped. That' s a bit of a surprise, since there is just the one client on the 60C side of the tunnel, and the 110C at the other end did not appear to show any CPU spike. We just purchased 5 80C' s for small offices. I hope we don' t run into similar problems. I can reduce the encryption level, but there will be multiple clients (10-40) behind the 80C' s. I was planning to setup site-to-site VPN' s for WAN failover. So, that may require a little additional load testing, after seeing the 60C struggle. Ede - I understand the concerns about upgrading firmware. The 110C on the other end of this tunnel has been running 4.0 MR3 for a while without issues, and it has a business IPSEC VPN for use with an outside business partner. That' s one of the reasons I was leaning towards trying the firmware upgrade.