|
The iked process consistently consumes more than 80% CPU:
diagnose system top 3
Run Time: 12 days, 6 hours and 15 minutes
25U, 0N, 65S, 2I, 0WA, 0HI, 8SI, 0ST; 1987T, 412F
iked 3124 R 91.2 1.6 0
forticron 2987 S 0.5 2.0 0
wad 3251 S 0.0 4.8 0
- No change in tunnel or network traffic.
- NPU is disabled.
- No FortiOS crashes observed.
Debug Logs:
IKE debug logs show repeated DH computation requests:
ike V=root:0:RemoteAccess_1:512:RA-Tunnel:89321: compute DH shared secret request queued
ike V=root:0:RemoteAccess_1:512:RA-Tunnel:89321: compute DH shared secret request queued
ike V=root:0:RemoteAccess_1:512:RA-Tunnel:89321: compute DH shared secret request queued
Error counters increase rapidly:
diagnose vpn ike errors | grep crypto.async.dh.comp.failed:
crypto.async.dh.comp.failed: 412398712
crypto.async.dh.comp.failed: 412401876
crypto.async.dh.comp.failed: 412405039
Phase1/Phase2 configuration:
config vpn ipsec phase1-interface
edit "Test"
set type dynamic
set interface "wan1"
set peertype any
set proposal aes128-sha1 3des-sha1
set dhgrp 2
set nattraversal forced
set psksecret ENC <hidden>
next
end
config vpn ipsec phase2-interface
edit "Test"
set phase1name "RemoteAccess"
set proposal aes256-sha1 aes192-sha1
set dhgrp 2
set encapsulation transport-mode
set l2tp enable
set keylifeseconds 3600
next
end
- The FortiGate keeps retrying DH calculations without checking for errors.
- The VPN peers use different DH groups by mistake, causing a mismatch.
Workaround:
- Switching to IKEv2 for affected tunnels.
Next step:
Upgrade to FortiOS 7.6.5:
- FortiOS now checks if DH fails. If it does, it avoids retrying again and again. This helps reduce high CPU usage.
- Keeps DH group stable Only the VPN initiator can change DH group. Rekey and responder keep the same group.
- Rekey uses same DH group During rekey, it reuses the DH group from the old session.
|
