Skip to Content

How to fix IPsec VPN tunnel unexpected payload type issue

By: Author Alex Lim

Posted on

Categories Troubleshooting

This article provides information on possible causes of an unexpected payload type in IKE debug log.

Scope

FortiOS.

Solution

When troubleshooting IPsec VPN tunnel issues, one of the most useful and reliable tools is the logs collected with ‘diag debug app ike -1’.

The log collected when having this issue usually looks like the following:

ike 0:test-VPN:168871: response message_id 0, expected 1
ike 0:test-VPN:168871: unexpected payload type 42 <- Type could be 11 or other number.
ike 0:test-VPN:168871: schedule delete of IKE SA b5574a3dfa846971/077ffcce98411264
ike 0:test-VPN:168871: scheduled delete of IKE SA b5574a3dfa846971/077ffcce98411264
ike 0:test-VPN: connection expiring due to phase1 down
ike 0:test-VPN: deleting
ike 0:test-VPN: deleted

It is clear from the IKE log that the two VPN peers are not able to complete phase1 negotiation (phase1 is down).

Possible causes and fixes are:

  1. This error could be caused by phase1 keylife timer mismatch. Check both peers.
  2. If the VPN is between FortiGate and devices from other vendors, and there are some phase1 feature/s not supported by one of the devices, disable those features or turn it off on the device that has that capability.
  3. The IKE daemon or one of the VPN devices may be older or slightly incompatible. Try upgrading the side that seems lagging behind.
  4. Check phase1 parameters generally to ensure there is no mismatch.