Okay, I have been digging into this a little more and I think I have some leads. Seadave is on point with proxy vs flow mode in my testing. I found that AV, certificate settings, or any other security profiles made no difference being enabled or disabled. I am interested to hear from anyone who has a situation different to this. I expect to be affected, you will need to be using:
- Proxy mode in the policy
- HTTP proxy in the proxy profile (on port 80 in my case which is confusing for a secure site?)
Since you can now choose Flow Based vs Proxy on a per policy level now in 6.2 - you have a couple of work around options.
1. When the issue starts occurring, access the device CLI and execute the following command to restart the proxy service:
diagnose test application wad 99
I ran this command in the middle of the day without noticing any problems, but use this at your own risk!
2. Reboot the firewall
3. Create a new copy of the policy above the affected policy, targeting affected destination websites IP addresses (least impact on security, but a pain to manage). Set this policy to flow mode or use a proxy policy that has HTTP proxy disabled.
4. Create a new policy using a proxy policy that has HTTP disabled and apply this to the proxy settings on the affected firewall policy.
5. Change the policy from proxy to flow mode.
Obviously you will need to consider how the reduction in protection affects your risk, and don't forget to change back after the issue is resolved in a future firmware update. Hope this helps.
We are pushing on this because we really want to leverage new features in 6.2 - Please fix this soon FortiNet!
Hope this helps, please consider giving me a vote if you found this useful!
post edited by GregAndo - 2019/09/04 17:00:50