Infinitely loading white pages after a fresh install/upgrade of Web Isolation

Products

• Web Isolation

Issue/Introduction

After a fresh install/upgrade of Web Isolation, the following is observed:

• infinitely loading white pages
• error message in the browser 'The webpage could not be isolated.'
• web socket messages from the browser developer tools show the connection starts, but is closed by the gateway after receiving the tab information.

Environment

On-Premise deployment.

Cause

The browser engine(s), which control the loading of the isolated pages, is expected to auto-start. However, in some cases this may not happen after a fresh install/upgrade.

To detect and verify this challenge, complete the following.

• Execute the fireglass diagnostics test for a webpage using the path /fgdiag. For example, https://www.cnn.com would appear as https://www.cnn.com/fgdiag. The Connectivity Diagnostics area in the FGDiag window represents the flow of the diagnostic stations. The station where an issue is found, appears red. For example, in the figure below, the issue was found in "Server Side Page Load". This is typically the status that would be seen, with this specific issue.
  
  
  
  
• Run fgcli services status on gateways with the Threat Isolation Engine (TIE) role. This is the expected results in this scenario:
  
  
  
  
• Run fgcli service get-engine-count . The expected results in this scenario is 0 since no engines are up.

Resolution

Complete the following solution steps, to resolve this challenge.

1. In the mgmt - go to System Configuration > Gateway Advanced Settings > Edit > scroll down to Advanced > Edit > search k_engine_count. This would show you the manually set engine count, if such a count exists. Usually, this is an empty value - and our flow “auto detect” the preferred number of engines based on the TIE machine resources (CPU, memory…). See snippet below. 
   
   
   
   
2. If there is no manual  k_engine_count value - please perform the following actions:
   
   
   
   
3. The focus here is to look for the final_engine_count value. This value is the engine count that this environment should have - either the manual k_engine_count or, if that value is empty - it is the auto detected, calculated preferred engine based on the environment’s CPU and memory. See snippet below.
   
   
   
   
4. The solution here is always to set the engine count to the final engine count, to start the browser engines. See the command below. Perform on TIE gateways.
   

   fgcli service set-engine-count <final_engine_count>

   
   
5. The expected end result that would confirm that the Browser Engines are now started would be an "OK" status seen, for the Browser Engine. See sample result in the snippet below.
   
   
   
   

Once this is started, it wouldn't go down anymore. Please note that this challenge usually happens with new deployments or upgrades. Repeat the same solution steps, if it ever happens with any other deployment/upgrade.