|
This issue affects all dialup IKEv1 IPsec tunnels on v7.6.1 and causes a temporary traffic disruption while the IPsec tunnel renegotiates, as no traffic can pass through the tunnel in-between the previous key expiring and a new key being negotiated. This issue is resolved in v7.6.2, and upgrading the FortiGate to FortiOS v7.6.2 will resolve this issue.
Debugs can be set up and run to verify if this issue is taking place. For these debugs to capture the time of the VPN tunnel going down, it is necessary to wait until the phase1 key has almost expired. The current phase1 key life can be checked with the following value in the output of the CLI command ‘diagnose vpn ike gateway list name <phase1-name>’, where '<phase1-name>' corresponds to the individual dialup IPsec tunnel.
Example output:
blackbird-kvm78 # diagnose vpn ike gateway list name Dialup-P1Rekeys_0
vd: root/0
name: Dialup-P1Rekeys_0
version: 1
interface: port1 3
addr: 10.21.4.164:500 -> 10.119.200.29:500
tun_id: 10.119.200.29/::10.0.0.7
remote_location: 0.0.0.0
network-id: 0
transport: UDP
created: 7s ago
xauth-user: julia
2FA: no
groups:
julia 16777218
peer-id: 10.119.200.29
peer-id-auth: no
FortiClient UID: 405F0D390D4D4BDEA27DE68CD532B457
assigned IPv4 address: 10.0.0.1/255.255.255.255
pending-queue: 0
IKE SA: created 1/1 established 1/1 time 100/100/100 ms
IPsec SA: created 1/1 established 1/1 time 200/200/200 ms
id/spi: 17 c295f5198f6e9aed/7b42028686f9ce07
direction: responder
status: established 7-7s ago = 100ms
proposal: aes256-sha256
key: 2dbf3db9fae0e20d-d72842925684c5f3-d19ed4d5672f98cf-9dee8f23ab5c5e61
QKD: no
PQC-KEM (IKE): no
PQC-KEM (all IPsec): no
lifetime/rekey: 120/92 -------------------------- Current tunnel lifetime and the time until the SA expires.
DPD sent/recv: 00000000/00000000
peer-id: 10.119.200.29
The ‘lifetime/rekey’ value contains both the maximum lifetime of the tunnel(lifetime), as well as the remaining time until the phase1 key expires(rekey). Both values are measured in seconds.
Note that for this article, the phase1 key lifetime has been set to a lower value of 120 seconds instead of the default value of 86400 seconds(1 day).
Once the phase1 key lifetime is known, the following debug can be run to confirm the issue. Substitute <client-ipv4-address> for the public IP of the remote client that is connecting to the dialup tunnel.
diagnose vpn ike log filter rem-addr4 <client-ipv4-address> <-- for v7.2.x and below use "dst-addr4" instead of "rem-addr4"
diagnose debug enable
diagnose debug console timestamp enable
diagnose debug app ike -1
Once the ‘diag debug app ike -1’ command is run, the debug output will begin to generate. The issue can be positively identified based on the following debug messages:
2025-01-23 11:34:14.123022 ike V=root:0:Dialup-P1Rekeys_0:12: sent IKE msg (ident_r2send): 10.21.4.164:500->10.119.200.29:500, len=316, vrf=0, id=0323082166381321/20c5dede6d5e7c80 ---The FortiGate sends an IKE ident_r2send message.
2025-01-23 11:34:14.125073 ike V=root:0:Dialup-P1Rekeys_0:12: schedule delete of IKE SA 0323082166381321/20c5dede6d5e7c80
2025-01-23 11:34:14.126408 ike V=root:0:Dialup-P1Rekeys_0:12: scheduled delete of IKE SA 0323082166381321/20c5dede6d5e7c80 ------------------- The FortiGate’s IKE daemon deletes the phase1 security association keys from for the IPsec tunnel.
2025-01-23 11:34:14.127806 ike V=root:0: comes 10.119.200.29:500->10.21.4.164:500,ifindex=3,vrf=0,len=92....
2025-01-23 11:34:14.129072 ike V=root:0: IKEv1 exchange=Identity Protection id=0323082166381321/20c5dede6d5e7c80 len=92 vrf=0
2025-01-23 11:34:14.130593 ike 0: in 032308216638132120C5DEDE6D5E7C8005100201000000000000005C81BD521DCBD72B5F8191B87DE339E4CDCC34625463038A528D66F79DD4E6D687FF0253F6055ECE368E9F9EFAAF077ED9EFB88B6CC1B21FCB64209B7F55DA0A57
2025-01-23 11:34:14.132942 ike V=root:0: malformed responder cookie 0323082166381321/20c5dede6d5e7c80 from 10.119.200.29:500->10.21.4.164 3 exchange-type Identity Protection, drop --- The Fortigate rejects the client’s attempt to negotiate a new set of keys.
For this set of example debug messages, the IKE SPIs that identify the set of keys are ‘0323082166381321/20c5dede6d5e7c80’. Once the Fortigate deletes the phase1 SA in the third line for these IKE SPIs, the tunnel is effectively down and must re-negotiate before traffic can start passing again. The debugs can then be stopped with the following commands:
diagnose debug disable
diagnose debug reset
Workarounds:
The recommended solution is to upgrade to v7.6.2, which includes a fix for this bug. If upgrading to v7.6.2 is not an option, then the following other workarounds are available:
- Use IKEv2 instead of IKEv1 for the IPsec tunnel. IKEv2 is completely unaffected by this problem and can renegotiate phase1 tunnels as normal when the keys are about to expire. This requires changes on both the IPsec client and FortiGate.
- Increase phase1 key lifetimes to a larger value to mitigate the frequency of the tunnel going completely down. Note that this change will still result in traffic not passing while the tunnel renegotiates, but will reduce the frequency of these events.
|
