FortiOS 7.6.7 IKEv2/IPsec VPN stopped working after upgrade

Question

Hello.First, I apologize for my imperfect English. Recently, I started learning about networking using FortiGate.When running FortiOS v7.6.6, I configured IKEv2/IPsec VPN on a FortiGate 60F.At that time, the VPN connection worked correctly.However, after upgrading the FortiGate to FortiOS v7.6.7, the VPN connection stopped working.No VPN configuration changes were made between the upgrade and the failure.Based on the FortiGate logs and packet captures taken with Wireshark,I suspect that during the certificate authentication process,the intermediate certificate that should be sent from the server to the client is no longer being transmitted. After rolling back to FortiOS v7.6.6, the VPN connection started working again.I also confirmed that the VPN connection works on FortiOS v7.6.7when the R12 intermediate certificate is manually imported into Windows.This seems to indicate that the client is not receiving the intermediate certificate from the FortiGate during authentication.The following observations were made from the logs and packet captures:The AUTH response payload length became approximately one quarter of its previous size.	The AUTH response was fragmented into 2 packets instead of 5 packets.	The total packet size remained almost unchanged.	Most other values remained unchanged, except for expected differences such as MAC addresses, IP addresses, and timestamps.Because of these observations, I suspect that some certificate-related data may be missing from the AUTH response.I really hope you will help me identify the cause or provide guidance regarding this issue. The following is the environment used for my verification.FortiOS : v7.6.7	FortiGate model : FortiGate 60F	VPN protocol : IKEv2/IPsec	authentication method : certificate + EAP-MSCHAPv2	Server certificate issuer : Let’s encrypt	Windows trusted root certificate : ISRG root X1	intermediate certificate  in FortiGate: R12	tunnel creation method : created by wizard (when FortiOS is v7.6.6)	VPN client : Windows built-in VPN clientHas anyone experienced similar behavior after upgrading to FortiOS v7.6.7?Due to security considerations, I cannot share packet captures publicly.However, I can provide sanitized log outputs if needed.Thank you for your time.

christian_89_ · Accepted Answer

Two things from your update.First, send-cert-chain being enable while the intermediate is still not sent confirms this is the 7.6.7 regression and not your configuration. That is a clean data point for the TAC case.Second, the reason your bundled PEM came in as a remote CA instead of a local certificate: a local certificate has to include the matching private key. Your exported file only contained the public certificates, the leaf and R12, with no private key, so the FortiGate can only treat it as a CA certificate. That behaviour is expected. To import it as a local certificate you need the leaf certificate, its private key, and the R12 intermediate together, and the format for that is PKCS#12.Build the bundle on your workstation with OpenSSL:openssl pkcs12 -export \  -inkey leaf-privatekey.pem \  -in leaf-cert.pem \  -certfile R12-intermediate.pem \  -out bundle.p12It will prompt for an export password. Then on the FortiGate go to System > Certificates > Import > Local Certificate, set Type to PKCS #12 Certificate, upload bundle.p12, enter the password and give it a name. It now imports as a local certificate with the chain attached, and you bind it in phase1 with set certificate "<name>".The hard dependency is the private key. If you originally generated the CSR on the FortiGate, the private key never left the box and cannot be exported, so you cannot rebuild a PKCS#12 and this route is closed. The same applies if the certificate is handled by the FortiGate's built-in ACME (Let's Encrypt) automation. In either of those cases, skip to the fallbacks. If you obtained the certificate and key externally, for example with certbot, you already have the private key file and can build the p12.Honest expectation: even with the intermediate inside the local certificate, I cannot promise this defeats the bug, because the FortiGate may still file the intermediate into its CA store and hit the same broken chain builder. Test it, but keep a fallback ready.Fallbacks, in order:Stay on 7.6.6, which you have already proven works, until Fortinet fixes 7.6.7.If you must run 7.6.7, push the R12 intermediate to the Windows clients through Intune or GPO into the Intermediate Certification Authorities store. That scales fine for managed clients.Open the TAC case and reference the earlier 7.4.x send-cert-chain regression so they map it to a 7.6.7 bug ID. send-cert-chain set to enable with no chain in the IKE_AUTH is exactly the evidence they need.

christian_89_ · Answer

Your analysis is correct, and your English is perfectly clear. The FortiGate is no longer putting the R12 intermediate into the CERT payloads of the IKE_AUTH response, so the Windows client cannot build the path from the leaf up to ISRG Root X1, which is the only thing it trusts. That is exactly why importing R12 into Windows fixes it (you give the client the missing link locally) and why rolling back to 7.6.6 fixes it (the gateway sends the intermediate again). Your packet observations, roughly a quarter of the payload and 2 fragments instead of 5, are the missing CERT payload(s).

This is not your configuration. The behaviour is controlled by a phase1 attribute, and the same regression has happened before on the 7.4 branch. The send-cert-chain attribute in the IPsec phase1 configuration is enabled by default and controls whether the CA certificate chain is included in the IKE_AUTH response, and after a firmware upgrade it stopped including the chain despite being enabled. You are seeing the same class of bug on 7.6.7. Fortinet Community

What to do:

Confirm the knob first. get vpn ipsec phase1-interface <tunnel> and check send-cert-chain. If it is already enable and the intermediate is still not sent, that confirms the regression rather than a config change.

config vpn ipsec phase1-interface
    edit "<tunnel>"
        set send-cert-chain enable
    next
end

Server-side workaround worth testing: bundle the intermediate into the local certificate itself. Re-import the server certificate as a PEM or PKCS#12 that contains the leaf plus the R12 intermediate, so the intermediate travels as part of the local cert object instead of relying on the FortiGate to assemble the chain from its CA store. Chaining the intermediate CA on the FortiGate is the documented way to stop FortiOS from sending an incomplete chain to the client. This is the cleanest fix if it restores the payload, since it avoids touching every client. Fortinet Community
There may be a Let's Encrypt cross-signing angle. There is a known bug class where FortiOS prioritises its built-in FortiGuard CA bundle over user-installed CAs when building chains for cross-signed certificates: bug 1197212, WAD incorrectly prioritising the default FortiGuard CA bundle over user-installed CAs for cross-signed server certificates, fixed in 7.4.10. That was the WAD/SSL path, but the Let's Encrypt R12 to ISRG Root X1 chain is exactly the cross-signed situation that can trip a similar chain-builder, so mention it on the ticket. cisco
For TAC, capture the negotiation with an IKE debug together with the fnbamd debug: Fortinet Community

diagnose debug application ike -1
diagnose debug application fnbamd 255
diagnose debug enable

That shows how the CERT payload is being built and what the FortiGate decides to include.

Recommendation: open a TAC case and reference the earlier 7.4.x send-cert-chain regression so they can map it to a 7.6.7 bug ID. In the meantime, try the bundled-intermediate local cert, and your 7.6.6 rollback is the safe fallback you have already proven. Pushing R12 to clients works but does not scale, so keep that as the emergency option only.

Sign up

Login with SSO

Login to the community

Login with SSO