Technical Tip: IPsec VPN tunnel fails to establish between FortiGate and SonicWall with 'ignoring unsupported INFORMATIONAL message' error

Symptoms:

The IPsec VPN tunnel fails to establish between FortiGate and SonicWall. Run IKE debug as below 

diagnose debug reset

diagnose vpn ike log filter dst-addr4 x.x.x.x <----- Public IP of the SonicWall side.
diagnose debug application ike -1
diagnose debug console timestamp enable
diagnose debug enable

For v7.4.0 and above, there is a change in the ike debug filter command:

diagnose debug reset

diagnose vpn ike log filter rem-addr4 x.x.x.x - Public IP of the SonicWall side
diagnose debug application ike -1
diagnose debug console timestamp enable
diagnose debug enable

When running the IKE debug, an error swas een in the output about an unsupported IKE informational payload: 

ike V=root:0:a69ff508e55753df/0000000000000000:1369: protocol id = ISAKMP: ike V=root:0:a69ff508e55753df/0000000000000000:1369: trans_id = KEY_IKE ike V=root:0:a69ff508e55753df/0000000000000000:1369: type=OAKLEY_ENCRYPT_ALG, val=3DES_CBC. ike V=root:0:a69ff508e55753df/0000000000000000:1369: type=OAKLEY_HASH_ALG, val=SHA. ike V=root:0:a69ff508e55753df/0000000000000000:1369: type=AUTH_METHOD, val=PRESHARED_KEY. ike V=root:0:a69ff508e55753df/0000000000000000:1369: type=OAKLEY_GROUP, val=MODP1024. ike V=root:0:a69ff508e55753df/0000000000000000:1369: SA proposal chosen, matched gateway Tunnel ike V=root:0:Tunnel:1361: negotiation timeout, deleting ike V=root:0:Tunnel:1369: ignoring unsupported INFORMATIONAL message 0.

After collecting the debugging output, disable the debug processes with the following commands:

diagnose debug disable

diagnose debug reset

Packet capture reveals that the SonicWall device sends a 'NO SA PROPOSAL CHOSEN' notification to the FortiGate, which appears in the debug as 'ignoring unsupported INFORMATIONAL message'.

Environment:

• FortiGate migrated from SonicWall using FortiConverter.
• IPsec VPN tunnels are configured between FortiGate and non-migrated SonicWall devices.
• Configuration has IKEv1 / Aggressive mode and the use of a PeerID.
• SonicWall as tunnel initiator.

Cause:

In IKEv1 Aggressive mode, the negotiation consists of three messages:

• The SonicWall initiates the connection and sends a proposal containing Security Association (SA), Key Exchange (KE), NONCE, Initiator ID (IDi), and Vendor ID (VID) payloads.
• Second, the FortiGate responder accepts the proposal and sends its own proposal and key exchange data, including the same payloads plus the Authentication (AUTH) payload. The SonicWall compares the received authentication data against its records. If the peer ID does not match, the SonicWall rejects the proposal by sending a 'NO SA PROPOSAL CHOSEN' notification.
• In the third message, the Initiator should respond with the AUTH payload and IDi. In this case, the Initiator sent a NO SA PROPOSAL CHOSEN instead.

The root cause is a mismatch in peer ID configuration between the two devices. FortiGate does not support the SonicWall-specific 'Firewall Identifier' peer ID type. SonicWall treats the Firewall Identifier as its own proprietary serial number.

When migrating from SonicWall to FortiGate using FortiConverter, this setting is not compatible with FortiGate and causes authentication failures even when the pre-shared key is correct.

The FortiGate accepts the initial proposal (confirming that the pre-shared key is correct), but authentication fails due to an incompatibility in peer ID types.

Solution:

Change the peer ID type configuration on the SonicWall device from 'Firewall Identifier' to 'Key ID' or another compatible type.

Below are the options available on the SonicWall device:

Ensure that both FortiGate and SonicWall use the same peer ID type and values.