Hello,
I have encountered strange issue on our FortiClient configuration.
We have deployed FortiClient via EMS Cloud to 500+ stations and for some time everything runned smoothly but suddenly lot of stations started to disconnect with this error even tho the configuration on both sides remained unchanged.
The VPN connection is re-established randomly.
For the specific error - VpnParameterConfigError i did not find any community posts, I reviewed configuration on both sides as the error is pretty explanatory but did not find any misconfigurations.
As this is currently production environment, i cannot really troubleshoot this issue and make lot of changes on the current VPN configuration at the moment and need to wait for a weekend.
If anyone encountered this beforehand please shine some light on this issue.
Thank you
Below I attach screenshot from the FortiClient (its in Slovak as the customer has it set this way)
Rougly translates to: Last reason of disconnection: VpnParameterConfigError
Hi Andrej
What is the versions of FCT & FGT?
The description you provided (suddenly lot of stations started to disconnect) it like the issue is from FGT side.
As first step try check VPN logs from both FCT and FGT sides. They may provide some interesting info about the disconnection.
Created on ‎11-20-2025 09:07 AM Edited on ‎11-20-2025 09:16 AM
FGT is 7.4.7, FortiClient is 7.4.4,
In FGT logs I wasnt really able to pinpoint exactly what was causing the issue as there was multiple logs about tunnels going up/down and renegotiations, nothing above log level notice, only some esp_error logs.
I recieved DiagFile from customer from FCT but wasnt also able to detect any specific issue, probably needs to dig deeper
According to the release notes, so many VPN related issues have been fixed since 7.4.7.
I recommend to update to 7.4.9 and there is a chance your issue will be solved.
Ok, so this is the log for the troubled station, the only thing that comes to mind right now is that the assigned IP from FGT is 10.10.0.255 with /22 mask which shouldnt be problem but is the only common denominator regarding this issue. Seems that the initial negotiation passes just fine and then FCT sends request to delete the tunnel.
Here is the partial log, idk if its best practice to send diag logs to public forum as im new to this but if so i can also provide that
IP assigment which seems to be the same when the issue occurs on the clients:
ike V=root:0:Kasanet-RAVPN_fe:48927: processed INITIAL-CONTACT
ike V=root:0:Kasanet-RAVPN_fe:48927: mode-cfg assigned (1) IPv4 address 10.10.0.255
ike V=root:0:Kasanet-RAVPN_fe:48927: mode-cfg assigned (2) IPv4 netmask 255.255.252.0
ike V=root:0:Kasanet-RAVPN_fe:48927: mode-cfg send (13) 0:10.10.0.0/255.255.252.0:0
ike V=root:0:Kasanet-RAVPN_fe:48927: mode-cfg send (13) 0:10.20.1.0/255.255.255.0:0
ike V=root:0:Kasanet-RAVPN_fe:48927: mode-cfg send (13) 0:10.101.0.192/255.255.255.240:0
ike V=root:0:Kasanet-RAVPN_fe:48927: mode-cfg send (3) IPv4 DNS(1) 8.8.8.8
ike V=root:0:Kasanet-RAVPN_fe:48927: mode-cfg send INTERNAL_IP6_SUBNET
ike V=root:0:Kasanet-RAVPN_fe:48927: mode-cfg IPv6 DNS ignored, no IPv6 DNS servers found
ike V=root:0:Kasanet-RAVPN_fe:48927: client save-password is disabled
ike V=root:0:Kasanet-RAVPN_fe:48927: client auto-negotiate is disabled
ike V=root:0:Kasanet-RAVPN_fe:48927: client-keep-alive is disabled
ike V=root:0:Kasanet-RAVPN_fe:48927:RA-test:5933481: replay protection enabled
ike V=root:0:Kasanet-RAVPN_fe:48927:RA-test:5933481: set sa life soft seconds=3591.
ike V=root:0:Kasanet-RAVPN_fe:48927:RA-test:5933481: set sa life hard seconds=3600.
ike V=root:0:Kasanet-RAVPN_fe:48927:RA-test:5933481: IPsec SA selectors #src=1 #dst=1
partial log for the message from fct to delete ike sa:
ike V=root:0: IKEv2 exchange=INFORMATIONAL id=41215900f4f11fe6/e8a15f42e6667f15:00000002 len=80
ike 0: in 41215900F4F11FE6E8A15F42E6667F152E20250800000002000000502A000034162A64BC71F53B0C1B2A2A726007C0E5F793B257AC5989BF1B998AA889941CF9475FB61FBE65244055C0F08251A90DD1
ike V=root:0:Kasanet-RAVPN_fe: HA state master(2)
ike 0:Kasanet-RAVPN_fe:47907: dec 41215900F4F11FE6E8A15F42E6667F152E20250800000002000000282A0000040000000801000000
ike V=root:0:Kasanet-RAVPN_fe:47907: received informational request
ike V=root:0:Kasanet-RAVPN_fe: HA send IKEv2 message ID update send/recv=0/3
ike V=root:0:Kasanet-RAVPN_fe:47907: processing delete request (proto 1)
ike V=root:0:Kasanet-RAVPN_fe:47907: deleting IKE SA 41215900f4f11fe6/e8a15f42e6667f15
ike V=root:0:Kasanet-RAVPN_fe:47907: schedule delete of IKE SA 41215900f4f11fe6/e8a15f42e6667f15
and then just tunnel being flushed:
ike V=root:0:Kasanet-RAVPN_fe:RA-test: delete
ike V=root:0:Kasanet-RAVPN_fe: connection expiring due to phase1 down
ike V=root:0:Kasanet-RAVPN_fe: going to be deleted
ike V=root:0:Kasanet-RAVPN_fe: sent tunnel-down message to EMS: (fct-uid=8D252630371B43579C4A316295AE3D87, intf=Kasanet-RAVPN_fe, addr=10.10.0.255, vdom=root)
ike V=root:0:Kasanet-RAVPN_fe: flushing
ike V=root:0:Kasanet-RAVPN_fe: flushed
ike V=root:0:Kasanet-RAVPN_fe: mode-cfg release 10.10.0.255/255.255.252.0
ike V=root:0:Kasanet-RAVPN_fe: delete dynamic
ike :shrank heap by 159744 bytes
update,
after restarting the device and reconnecting EMS the device that was previously unable to connect to VPN suddenly got different IP assigned and the VPN connected without issues and its working now, eventually another connection comes and the issue re-occurs.
| User | Count |
|---|---|
| 2800 | |
| 1424 | |
| 812 | |
| 750 | |
| 455 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2025 Fortinet, Inc. All Rights Reserved.