SSL DPI analysis before implementing

@doncacciatoconsuting ,

As you rightly mentioned, it is always better to have proper segmentation of the network and have few test users from each of these networks for testing the DPI. Have all the possible test cases 

(URL's/Services to be accessed and bypassed) ready for testing. Make sure you install the Fortigate CA on all your Client machines so that you don't receive certificate warning while accessing services after enabling DPI. Have them tested against each of the Secuirty Profiles one by one instead of applying them all at one go. This way you build your test policy which can later moved to production by adding remaining users subnet by subnet.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-enable-deep-inspection-and-import-a/ta-p/196840

Certain cloud applications ( ex: o365) and patch update URL's should be bypassed from SSL interception as some of the features maynot work as expected. 

Regards

In no particular order:

• Destination exceptions (some apps/services are hardened and will refuse to communicate through MITM'd TLS channels)
• Source exceptions (guest networks are typically unmanageable and thus you can't block without certificate warnings, IoT also tends to be hard to "onboard" to DPI, etc.)
• Legal exceptions (some comms you just aren't allowed to eavesdrop on in some jurisdictions)
• Endpoint management (how will you distribute your CA to clients?)
• Performance impact (basic non-DPI flow-inspection can and will offload quickly, but once you start doing DPI everything has to touch the CPU and you will lose some of the benefits of NP offloading)

As far as the app exceptions go, the default "deep inspection" profile already comes with a nice list of exempted destinations, you can start with that.