Browser Access Troubleshooting



Browser access portals allow users to access their internal corporate resources by establishing a secure tunnel via the Internet. This service doesn't require an SDP connection, but it does require users to be licensed SDP users. This playbook discusses common Browser Access issues and provides troubleshooting steps to address them.


  • User accessing the Browser Access Portal gets an Access Denied Page

  • The application doesn't show up in the Browser Access Portal
  • Missing contents in web application

  • Wrong format of contents in web applications. For example, the elements are arranged randomly on the page, text is in the wrong font size, images are not correctly aligned, etc.

Possible Causes

  • Misconfigurations
  • Use of HTTP protocol and web application contains absolute HTTP links to other contents

Troubleshooting the Issue

This section will investigate the steps for troubleshooting common browser access portal issues.  

Users Cannot Access Browser Access Portal

When the user accesses the Browser Access Portal using the Portal URL specified in Access > Browser Access > Settings, they are greeted with the Access Denied message.

  1. Validate that the subdomain does not contain special characters. Characters such as hyphens are not supported. Refer to Changing the subdomain to exclude special characters for instructions on how to validate that special characters are used in the Subdomain.
  2. Verify the user is an SDP (licensed) user. Only users that have been assigned a license can access the Browser Access Portal. Refer to Assigning license to users for instructions on how to validate this.  
  3. If SSO authentication is enabled and "Allow login with Single Sign-On" is checked (Access > Single Sign-On), verify that the user domain is included in the Allowed Domains.
  4. Check in the Events for any obvious errors. Go to Monitoring > Events and add a Filter as shown below. 

    All events related to the browser access portal will be shown. Below is an example of an Access denied event.  

Applications Didn't Show Up In Application Home Page

When the user logs into the Browser Access Portal, specific applications do not appear.

  1. Validate that the application is added in Access > Browser Access > Applications. If it is not added there, it won't reflect on the Application Portal homepage.
  2. Ensure that the user has access to the application. If not, he won't be able to see it on the application's home page. This can be done in the Access > Browser Access > Access Policy.
  3. For instructions on resolving these issues, refer to Adding application to browser access portal and Configure access policy for allowed users.

The Web Application Exhibits Formatting Issues

The formatting of the web application is problematic, with elements placed in a disorderly manner on the page, text displaying inconsistent font sizes, and images appearing misaligned. This problem may arise when a customer accesses a web application through the Browser Access Portal using the HTTP protocol, and the HTML code of the web application includes absolute HTTP links to other contents. Because the Browser Access Portal connection operates on HTTPS, contemporary web browsers will restrict access to HTTP content, commonly referred to as "mixed content.

Follow these steps to verify if you are encountering this issue.

  1. You can collect the HAR file through the Browser Access Portal while accessing the application. For detailed instructions, refer to How-to-Collect-HAR-Data.
  2. If this is the problem, web developer tools will display mixed content blocks, accompanied by a warning indicating that the connection to the website is not secure.

  3. Right-click anywhere on the page and select "View Page Source." This will open up the website's source code.
  4. Examine for any links beginning with "http://" as illustrated below:
    <link href="" rel="stylesheet" type="text/css" />

  5. The presence of the HTTP links in the source code is why the browser is blocking the content.
  6. Follow the suggestions outlined in Formatting Issues to resolve this problem.

Resolving Discovered Issues


Many of the issues mentioned above are related to configuration. Once you've identified the misconfigured areas, resolving them should address the problem.

Changing the Subdomain to Exclude Special Characters

Navigate to Access > Single Sign-On and ensure no special characters are in the Subdomain field. This requirement is also mentioned in Configuring-the-Browser-Access-Portal. For more information on the impact of changing the subdomain, refer to Changing-your-Account-Name-and-Subdomain.

Assigning Licenses to Users

Navigate to Access > Users > Users Directory and validate that the user accessing the browser access portal is a licensed SDP user

To assign a license to a user, refer to Assigning-SDP-Licenses-to-Users 

Adding an Application to the Browser Access Portal

Navigate to Browser Access > Application and validate that the application is added. Refer to Managing-Applications-for-the-Browser-Access-Portal for configuration details.

Configure Access Policy for Allowed Users

Navigate to Access > Browser Access > Access Policy and validate that the user can access the applications. For configuration details, refer to Defining-the-Browser-Access-Policy

Formatting Issues

The solution involves modifying the application's source code as the browser is responsible for blocking mixed content, not Cato. The customer is advised to transform absolute links (those starting with http://) in the HTML code into relative links. Relative links can be either protocol-relative or root-relative.
For instance, if you have a link resembling:


A protocol-relative link would be like this:


A root-relative link would look something like this:


For more information on absolute and relative links, you can refer to absolute-vs-relative-urls

Raising cases to Cato Support

Submit a Support ticket with the results of the troubleshooting steps outlined above. For issues related to accessing browser portal applications, please also include answers to the following questions::

  1. What is the affected application server? (IIS, Nginx, etc.)
  2. Does the application require additional authentication?
  3. Does the user have access to application logs or configuration files? If so, do these logs capture the issue?
  4. What are the locations from which users are connecting to the SDP portal?
  5. Can users connect to the application when using the Cato Client or when they are behind a Socket site?
  6. Is there a load balancer/API server/firewall between them? 

Was this article helpful?

0 out of 0 found this helpful


Add your comment