Not able to access HTTPS websites

Check the Application Control log to see if false positives are being triggered on those web sites. Has happened before.

Thanks for the response rwpatterson. I checked the Application Control logs on the FortiAnalyzer and have no entries relating to either site (gmail and/or local banking site). Essentially every entry in the Application Control logs is streaming media or Webex and all ' pass' . Any other suggestions? The weird thing is, like I said before, earlier in the day I was able to access the sites just fine. Within an hour later I was getting " The connection was reset" errors in Firefox. During this time no changes were made to the FortiGate. When trying to load the sites the status in the lower left of the browser jumps back and forth between " Connecting to site" and " Connected to site" . It alternates about 10 times between the two before the " The connection was reset" error is displayed in the browser. Any other input would be greatly appreciated.

Well on my work machine I have only been testing it using Firefox since I am running Ubuntu. Firefox gives the " The connection has been reset" error within 3-5 seconds of requesting the page. Towards the end of the day I created a virtual machine with a fresh install of XP on it and tried testing gmail.com using Internet Explorer (IE 6 at the time since I had just installed ) and when I would request the page I would get prompted about the the Fortinet SSL Certificate (IE6 prompt looks like this: http://en.flossmanuals.net/floss/publish/CircumventionTools/rsrc/CircumventionTools/UsingPsiphon2/ie6_ssl_error.png). I would go to View Certificate and tried to install it both using the automatic wizard and by manually selecting the certificate store. If I remember correctly, it would prompt as saying the certificate was installed successfully, but attempting to re-access the page I would get the same prompt. When clicking ' Yes' at the IE6 SSL prompt, it would bring me to a " The page cannot be displayed" within the browser. So it appears to be browser independent and I am sure the clients who first discovered this problem were using a mixture of browsers. Any ideas?

I have the same issue with a fgt310B box. No policyes applied with web filtering. But still some website internet banks will not work. The websites work fine directly on the ISPs internet connection, outside of the fortigate. Did you get it to work Mike?

This is an issue with the MTU size. If you have a DSL connection the default MTU 1500 is to large and the SSL package does not accept to be segmented. This can be configured on either the policy or the interface: (Ignore the PPPoE statement) See this page how to get the correct MTU size. http://help.expedient.com/broadband/mtu_ping_test.shtml Problem: Certain web sites are not viewable. The Fortigate is configured to use PPPoE to connect to the ISP. Solution:Use the " tcp-mss-sender" option in the firewall policy configuration. Topology: HTTP Client----(internal)FGT(pppoe)----dsl----ISP----Internet----Web Server ----Ethernet MTU 1500----PPPoE MTU 1492………..Ethernet MTU 1500 The reason for this is that a PPPoE frame takes an extra eight bytes off the standard Ethernet MTU of 1500. When the server sends the large packet with DF bit set to 1, the ADSL provider' s router either does not send an ' ICMP fragmentation needed' packet or the packet gets dropped along the path to the web server. In either case, the web server never knows a fragmentation is required to reach the client. After you configure ' set tcp-mss-sender' on the firewall policy setting, this command changes the incoming packets and sends the packets with a new TCP MSS (maximum sending size) value out the downstream (external) interface. By default the MSS is MTU minus 40 byes (TCP and IP headers). When the HTTP client initiates a TCP connection, the following example changes the MSS value from 1460 to 1452 when leaving the PPPoE interface and eventually reaches the web server. The web server will also choose the smaller MSS, and therefore no fragmentation is needed. The client can now view web pages properly. config firewall policy edit 1 set srcintf " internal" set dstintf " external" set srcaddr " all" set dstaddr " www.canada.com" set action accept set schedule " always" set service " ANY" set tcp-mss-sender 1452 set nat enable next end Alternatively, you can also edit the option on the internal interface(s) of the FortiGate unit rather than individual firewall policies. For example: config system interface edit <port_name> set tcp-mss 1452 end The <port_name> can be replaced by any internal-facing port.

Update: I contacted support regarding this issue and they advised me to disable HTTPS Deep Scanning. This solved the issue and now I am able to access all HTTPS websites.

Reviving this post, because I believe the solution to my problem can be found in here. I use VPN to connect to my office, where I have a call recorder. My home connection is PPPoE, and each time I connect to VPN and try to listen a call, I can' t. I see from a diag sniffer packet port8 ' host x.x.x.x' (port 8 is where the call recorder is connected directly) an output like: ' icmp: y.y.y.y unreachable - need to frag (mtu 1428)' (y.y.y.y is the ip of port8) My vpn policy is: config firewall policy edit 12 set srcintf " vpn" set dstintf " port8" set srcaddr " VPN_address" set dstaddr " VidiCode" set action accept set schedule " always" set service " ANY" set nat enable next end I saw that there might be a MTU value problem, and I need to modify some tcp parameters, but I don' t know exactly what parameters and with what value. Can someone help me?

Update: I contacted support regarding this issue and they advised me to disable HTTPS Deep Scanning. This solved the issue and now I am able to access all HTTPS websites.

Mike0 - I have a bug ticket in with a level 3 tech regarding this issue. The problem is with the deep ssl scanning. I hope to have more info soon.

That' s good to know ejhardin, please keep us informed. I have not really experimented with SSL deep scanning since support told me to turn the feature off to resolve the issue. However, I have an upcoming deployment where SSL AV scanning / Deep scanning is important and I need this feature to work correctly.

I did exactly like in the post, I had already found the info on knowledge base. I modified tcp-mss to 1388 and also 1380, both on vpn interface and also wan1 (on which vpn interface is tight) and the same result -> no change, exactly the same message on sniffer. L.E.: I also modified it on port8, the same result: need to frag (mtu 1428)