Skip to main content

Check out Interactive Visual Stories to gain hands-on experience with the SSE product features. Click here.

Skyhigh Security

Troubleshooting Common Issues

Public Wi-Fi and Hotels

Hotels and other public places often require a login after connecting to their Wi-Fi.

SCP performs a Captive Portal check by checking the URL: The Connectivity Status changes to No Connectivity, and Status changes to No redirection, Blocked - Proxy unavbl, or Bypass active.

To troubleshoot, use the Wireshark packet analyzer to check for the HTTP request and webwasher using the filter http.request and http contains webwasher.


  • If the Time to Live result is 64 or 63, it probably has never left the network.
  • If Time to Live is lower, like 51, it has probably left the network and reached Skyhigh. 


Possible solutions include:

  • Login to the portal and SCP should connect to Captive Portal successfully.
  • Trigger a policy change where Secure Channel is enabled. This will bypass the CONNECT request and go to the destination on port 8081. This should allow connectivity. 

VPN Issues

Connections to specific domains may interfere between SCP and VPN, for example, if domains are not reachable. VPN domains must be bypassed from SCP by adding these Services, Domains, and IP addresses to the bypass list of the SCP policy. If you experience issues that the VPN Client e.g. Checkpoint VPN, cannot connect after installation of SCP, then this might be due to SCP competing with the VPN client for traffic / redirection. You need to bypass traffic from the VPN Client to your VPN servers from being redirected by SCP.

To troubleshoot VPN issues:

  • In packet capture, check the domain and VPN IP, to see if traffic goes directly to the VPN IP. 
    • If so, it should not be an SCP issue, since in this scenario the VPN itself may have made a request that hits SCP and is redirected.
    • If not, Domains or IP addresses are not bypassed in the SCP policy. Now check with the official URL/IP list from the vendor and compare it to the SCP bypass list. 
  • Is SCP in bypass mode?
  • Can you access the VPN hostname on port 443 / via  https:// using the system browser?
  • Try accessing the VPN hostname using the system browser and check the certificate. the TLS certificate should not be from Skyhigh proxy, but the certificate directly form the VPN concentrator.
  • Is the option Block UDP Traffic on Ports 80/443 for IPv4 and IPv6 enabled in the SCP policy?


Possible solutions include:

  • Make sure SCP is NOT in bypass mode
  • In SCP Policy, under "Proxy Bypass" create an entry to "Bypass all the proxies for traffic from these processes" and enter the name of the VPN Client executable.
  • In SCP Policy, under "Proxy Bypass" create an entry to "Bypass all proxies for traffic to these domains" and enter the hostname of your VPN concentrators / servers.
  • Make sure the option Block UDP Traffic on Ports 80/443 for IPv4 and IPv6 is NOT enabled. (A lot of new VPNs use DTLS which is a UDP protocol since UDP traffic has no bypass list.)

NOTE: Support shouldn't necessarily know all IPs, domains, and services being used within your network or third-party VPN. It's of great help and saves time if you include all details in your SR.

Can't Reach a Website

Connections can be blocked for many reasons by different network devices and may give an HTTP 502 response code.


The fastest way to check requests and responses in clear text is to take a HAR trace. Click F12 developer tools > Network tab, then enable options Preserve log and Disable cache.

  • Response code 403 implies that access is blocked by the policy (SWG or any other third-party service).
  • Response code 502 can mean different things such as DNS host not resolvable, or Could not connect to destination in time.


Check the HTTP problem with packet capture by searching for the host or response code. Use the display filter http contains <hostname> or http.response.code eq 502 and follow the TCP stream.

HTTPS traffic is encrypted, so you will not see the GET requests and HTTP response codes in tcpdump, only CONNECT requests. But response codes remain unencrypted, so you can see them. 

Possible solutions include:

  • Check the network to confirm that nothing is blocking the connections, such as the TCP connection or policy block.
  • For response code 403, if all traffic is allowed in the network, check that nothing is blocked in the SWG web policy.
  • For SWG Hybrid deployment, try to reproduce with the local SWG and troubleshoot with the rule trace there.
  • If no issues are traceable, raise an SR with the relevant details.

Wrong Display Language

If the user interface is displayed in the wrong language, this can be caused by the following scenarios: 

  • The client is being redirected through a PoP located in another country or prefix (due to policy configuration) resulting in an incorrect public IP address. 
  • The website has its own geolocation service that logs the incorrect country for our PoP egress IP address. 

IMPORTANT: The client connects to Skyhigh's cloud ingress IP, and the physical location can be in another country. Traffic goes through the cloud POP, and uses the egress IP to connect to the website. The geolocation of the public IP must be correct and should match the geofeed table.

Example: If a client in the UK connects to (with a physical location in Germany), but the assigned public IP is (in the UK). 

To troubleshoot:

  • Check if any alternate redirection is configured correctly, and the domain is not in the alternate redirection list.
  • Get your own public IP (using for example, and search for its geolocation (using for example,

Possible solutions include:

  • Amend the alternate redirection list in case the domain is configured there.
  • If the egress IP address displays the incorrect country compared to the geofeed data, then submit an SR with all relevant information.

NOTE: If everything remains error-free, Support can assist you to connect with the website owner to check the geolocation error. However, ideally, you should contact the website owner on your own.

Policy Revision not updating on SCP

If your policy revision number is not updating and you are using proxy domains of c******* as the redirect URL, you may see issues with policy .OPG files updating if you are also using Secure Channel as this is not a supported feature at this time for hybrid as per


  • Do not use secure channel with a hybrid setup.
  • Was this article helpful?