IE10/IE11 trouble loading https sites

[Zeihold_von_SSL]

Hello everybody, I have a problem what I really don' t understand. Since we upgraded our IE (Windows 7 x64) to IE10 or IE11 we ran into a problem. If you open the IE and navigate to a https site (for example https://www.google.com) the IE loads for at least 10-15 seconds before he is finished loading the website. But _only_ the FIRST https site. After that you can open any other https site and it loads as fast as in Firefox/... When I use Firefox, Chrome or Safari the website is loaded within a second after I finished typing. Even if I use IE8/IE9 the website loads faster then 10 seconds. So I did some research (first I tought it might be a problem with our wpad file). I noticed that this behaviour only applys on https sites or https sites which includes some https elements. A plain http website is also loaded within a second. But when I' am at home (with my laptop) this issue doesn' t occur (I' am also behind a Fortigate, but a smaller one). So I locked at the differences between my ruleset and the companys ruleset. After that I unchecked application control and et voila, the issue is gone. The problem is, I don' t understand why and so far I don' t know how to solve this. I have attatched three screenshots of my config so I hope someone is able to help. Thanks in advance.

[Zeihold_von_SSL]

Here are the other screenshots.

[Zeihold_von_SSL]

Here are the other screenshots.

[ShrewLWD]

Hi Zeihold, One thing I do notice that stands out, is that you do not have SSL/SSH inspection enabled. This is not the same as Deep Packet Inspection; instead it allows the Fortinet to inspect the SSL certificates of the sites/apps attempting to be communicated with, then compares them against the list of things you want blocked. Without that on, it really cannot inspect any SSL traffic. Does your home router have that enabled?

[Zeihold_von_SSL]

Hi ShrewLWD, yeah I had to disable SSL/SSH inspection (we used deep packet inspection) because of some trouble with services like webex, netviewer and so on. This could not be solved by just disabling dpi, I had to disable SSL/SSH inspection completly. Since that, I didn' t had the time to give it another try. At home I don' t use any kind of application control right now (or SSL/SSH inspection). I' am playing around with the ruleset every few days, but right now I don' t have any inspection rules on outgoing traffic (at home!). The interesting thing is, that this issue only occurs with these two specific browsers. Every other browser just works fine. First I thought that this could be a problem with SPDY, but that was misleading. Cause I disabled SPDY (with a group policy) without any luck. So right now, I don' t have any clues...

[Zeihold_von_SSL]

Okay, the problems seems to be solved now. I had to disable application control, then surf to one of the websites that didn' t work, an then re-enable application control. Maybe the network processors were stuck... and due to session pickup the problem was replicated from one cluster member to the other... I will monitor that and keep you updated if the problem still occurs.