I'll pass on my experience with this error in case it helps someone in the future. Pushed out inline policy rules on Wednesday. On Friday, DHCP broke. It was going through the firewall, and we found the below in /var/log/messages and zdebug:
[Expert@CPFW2:0]# less /var/log/messages
Jan 18 12:41:38 2019 CPFW2 kernel: [SIM4];simi_reorder_enqueue_packet: reached the limit of maximum enqueued packets for conn:<*.*.*.*,67,*.*.*.*,67,17>, fw_key:<*.*.*.*,67,*.*.*.*,67,17> !
Before the inline policy, DHCP request were going through the firewall on a rule with DHCP specificed in the service, and replies were coming back on UDP 68 on a rule with Any as Dest and Service. When that rule was changed to inline, I can look back in the logs and no longer see the UDP 68 replies. Not sure why it didn't log on that Any rule because there was any Any allow inline app control rule at the bottom of it. Anyway, after 1 and 1/2 days of UDP 68 traffic not getting through, this simi_reorder queue got full?
We made a return rule specifying udp 68, with Accept and no inline layers, and pushed it out. That didn't fix it. We had to uncheck UDP 67 and 68 from Sync, push policy, and force a failover. That forced DHCP into a new connection, and then we could see logs from the UDP 68 DHCP reply traffic (from DHCP servers back to wireless controllers). Don't know if that will permanently solve the issue or not.
Asking Check Point TAC for info about this queue, if there's a way to check it, and clear it out. What it does, and why this happened. I've got nothing back so far.