medium

IPsec phase 2 remains down with “error calculating auth information”

Q: IPsec phase 2 remains down with “error calculating auth information”

1. Review the affected phase 1 interface. The problematic configuration resembles the following, where is but no local ID value is configured: 2. Remove the local ID option or explicitly change the phase 1 interface to use the automatic local ID type. To set it manually to , apply this configuration: 3. Allow the peers to renegotiate the IPsec tunnel.

Confirmed 9/22/2026

Problem

An IPsec site-to-site tunnel between a FortiGate and another FortiGate or a non-Fortinet peer completes phase 1 negotiation, but phase 2 does not come up. IKE debugging shows that negotiation stops because the responder cannot process the authentication message from the initiator. This condition can occur with either IKEv1 or IKEv2.

Symptoms

The responder reports the following during IKE negotiation: ```text ike 1:To_Initiator:107663: sent IKE msg (INFORMATIONAL):<FortiGate/responder IP>:500-><Peer/initiator IP>:500, len=76, id=01a434efd1ff1bef/b6c552c4dc25fe05 ike 1: To_Initiator: schedule auto-negotiate ike 1: To_Initiator: flushed ike 1: To_Initiator:107664: processed INITIAL-CONTACT ike 1: To_Initiator:107664: error calculating auth information ``` After the responder fails to calculate the authentication information, the initiator periodically retransmits the authentication message while phase 2 remains down: ```text ike 1: comes <Peer/initiator IP>:500-><FortiGate/responder IP>:500,ifindex=7.... ike 1: IKEv2 exchange=AUTH id=44425e1f361f44cf/e27c22935352beff:00000001 len=284 ike 1: in <Hash> ike 1: To_Initiator:107665: detected retransmit ike shrank heap by 159744 bytes ike 1: comes <FortiGate/responder IP>:500-> <Peer/initiator IP>:500,ifindex=7.... ike 1: IKEv2 exchange=AUTH id=44425e1f361f44cf/e27c22935352beff:00000001 len=284 ike 1: in <Hash> ike 1: To_Initiator:107665: detected retransmit ```

Environment

IPsec site-to-site VPN between a FortiGate and either another FortiGate or a non-Fortinet peer. Phase 1 and phase 2 are configured on both endpoints. The error can occur with IKEv1 or IKEv2.

FortiOS version

FortiOS 7.0 and above

Root Cause

The phase 1 interface has `localid-type` configured as `keyid`, but no string value has been assigned with `set localid <IP string>`. As a result, the responder cannot calculate the authentication information.

Solution

Review the affected phase 1 interface. The problematic configuration resembles the following, where localid-type is keyid but no local ID value is configured:

config vpn ipsec phase1-interface
    edit "To_Initiator"
        set interface "port1"
        set ike-version 2
        set keylife 28800
        set peertype any
        set net-device disable
        set proposal aes256-sha1
        set localid-type keyid
        set dhgrp 14
        set nattraversal disable
        set remote-gw <FortiGate/responder IP>
        set psksecret ENC
    next
end

Remove the local ID option or explicitly change the phase 1 interface to use the automatic local ID type. To set it manually to auto, apply this configuration:

config vpn ipsec phase1-interface
    edit "To_Initiator"
        set interface "port1"
        set ike-version 2
        set keylife 28800
        set peertype any
        set net-device disable
        set proposal aes256-sha1
        set localid-type auto
        set dhgrp 14
        set nattraversal disable
        set remote-gw <FortiGate/responder IP>
        set psksecret ENC
    next
end

Allow the peers to renegotiate the IPsec tunnel.

Verification

Confirm that phase 2 negotiates successfully after changing localid-type to auto or unsetting the local ID option. If IKE debugging is collected again, verify that negotiation no longer stops with error calculating auth information and that repeated IKE AUTH retransmissions are no longer observed.

Community rating

— / 5 (0)

Discussion (0)

No comments yet.