Hello @Artur Zaprzała ,
There are several timeout values that can affect VPN behaviour.
I think that most of what you are observing can be explained by the idleTimeoutSeconds value in this structure:
typedef struct IPSEC_SA_IDLE_TIMEOUT0_ {
UINT32 idleTimeoutSeconds;
UINT32 idleTimeoutSecondsFailOver;
} IPSEC_SA_IDLE_TIMEOUT0;
The default value used under Windows is hard coded in vpnike.dll and can only be overridden by undocumented registry values. It is not influenced by the IdleDisconnectSeconds value that you set.
This timeout controls when a "quick mode" (also known as a "child") Security Association (SA) can be expired. So long as the "main mode" SA remains valid, a new "quick mode" SA can be created by either end of the communication channel whenever needed (there is a separate "quick mode" SA for each direction (inbound/outbound traffic)).
To know whether you actually have any issue at all, we would need a bit more information. For example, can you ping the client from the server during the first few minutes of a new VPN connection? The VPN connection on the client might be in the firewall "public" profile and just drop inbound ICMP echo requests.
If pings work in the first few minutes, then we can examine (via more tracing) why the server is not able to establish new quick mode SAs when it needs them - let us know if you need any advice on how best to do this.
Gary