PCoIP connectivity issues when installing policy, R80.20

[Svante_Oskarsso]

Hi,
We have a newly upgraded 15000 Appliance Cluster to R80.20 T47, only Firewall and IA blades are activated on this cluster.
We did not have this issues before with r77.30, 

Now when we install policy, all VDI (PCoIP) connections are disrupted, some close totally and some reconnects but still gets disconnected. It seems to happen when it has been longer than about 1h after the latest install, if an installation is done in 20-30 minutes since the last one we don´t seem to get the issue.

I've tested to increase the "end timeout R80" global setting from 5 to 20 as it was before but still the same issue is occurring. I cannot see anything unusual in the logs och anything with a zdebug drop. 

I'll troubleshoot with TAC on monday but wanted to see if anyone has any ideas on what this could be caused by and what more to check?

Regards
Svante

[PhoneBoy]

TCP End Timeout is for connections that terminate gracefully.
Normally the gateway forces connections to "re-establish" after a policy install, though it depends on the Global Policy settings.
If you want to set this on a per-service basis, you can create/edit the relevant service and use the "keep connections open" option shown below:

[Timothy_Hall]

> It seems to happen when it has been longer than about 1h after the latest install, if an installation is done in 20-30 minutes since the last one we don´t seem to get the issue.

Whenever I hear about odd timing issues such as these, I tend to suspect SecureXL because it has its own separate rules about connection timers and such.  Try disabling SecureXL (fwaccel off) then start new VDI connections (very important as only new connections are not accelerated after running fwaccel off in R80.20 and later) then install policy after an hour or two and see if the new connections started since SecureXL was disabled are affected.

[Svante_Oskarsso]

"keep connections open" is not an option for us since we want to get the new policy enforced on all connections.

I opened a case with CheckPoint and it is the new design of SecureXL that caused this since a queue went full and then packets were dropped. We could see "simi_reorder_enqueue_packet: reached the limit of maximum enqueued packets for conn" in var/log/messages

This is resolved with a hotfix provided from CheckPoint, more about the cause and solution in sk148432.
Hope this HF will be included in upcoming Jumbos.. 

Regards
Svante