Not able to access HTTPS websites

[#1]

I am having problems accessing certain(not all) SSL websites behind a FortiGate 110c running 4.0 MR2. Sites I cannot access include gmail.com and a local banking website. It is quite odd because last week I was unable to access gmail.com and Firefox would give the error: " Connection Interrupted" . Today in the morning I was able to access the sites for a few hours, however, within an hour from the last successful access I could no longer access the sites and Firefox would give the error: " The connection was reset." During this time-frame no changes were made to the FortiGate - which is weird why all of the sudden the sites would go from not working, to working, then back to not working. Anyone have any idea what could be causing this or where to start troubleshooting?

[rwpatterson]

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

[#3]

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.

[rwpatterson]

Does it happen in all browsers or is it browser specific?

[#5]

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?

[#6]

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?

[#7]

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.

[#8]

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.

[ibm_ioman]

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?

[rwpatterson]

Follow the lead from the above post (by bUZZer) and change the tcp-mss on the interface to a smaller value. I would start with 1428 - 40.