Browser Access Troubleshooting

Overview

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.

Symptoms

User accessing the Browser Access Portal gets an Access Denied Page
The application doesn't show up in the Browser Access Portal
The application fails to load.
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.

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.
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.
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.
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.

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.
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.
For instructions on resolving these issues, refer to Adding application to browser access portal and Configure access policy for allowed users.

The Application Fails to Load

When clicking the Application icon, the browser may show no content, and the Application stays loading until it times out.

If the above occurs, collect the following data:

Collect a PCAP capture from the Socket from the site where the Application server is hosted, as explained in How to Capture Traffic on a Socket. Filter the web server's IP address and port 80 or 443, depending on the port configured for the application in CMA. Confirm whether there is traffic flow from the web server.
Collect an HAR file through the Browser Access Portal while accessing the application by following these steps:
1. From the browser access portal, right-click anywhere on the page and select "Inspect" from the context menu.
2. Click on the settings button located in the top right corner. This option is available in Chrome. If you're using a different browser, proceed to step #4.
3. Under Preferences > Global, select 'Auto-open DevTools for popups'.
4. Click on the application from the browser access portal. A second tab will open. This is where the recording must take place. Unless your browser records from this second tab automatically (step #3), you will need to perform this action manually in the next step.
5. Follow the instructions from How-to-Collect-HAR-Data to reproduce the issue and collect the HAR file.
6. Submit this information to Cato Support for further investigation. See Raising cases to Cato Support
If the HAR file shows a redirection to an internal domain, the external browser won't be able to resolve it since it does not perform DNS resolution with the internal network. This is currently a limitation of the Browser Access solution, and the user should connect to Cato via SDP Client.

Submit this information to Cato Support for further investigation. See Raising cases to Cato Support.

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.

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.
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.
Right-click anywhere on the page and select "View Page Source." This will open up the website's source code.
Examine for any links beginning with "http://" as illustrated below:
<link href="http://nms-ubuntuserver.via.catonetworks.com/css/bootstrap.min.css" rel="stylesheet" type="text/css" />
The presence of the HTTP links in the source code is why the browser is blocking the content.
Follow the suggestions outlined in Formatting Issues to resolve this problem.

Resolving Discovered Issues

Misconfiguration

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:

href="http://www.mywebsite.com/css/stylesheet.css"

A protocol-relative link would be like this:

href="//www.mywebsite.com/css/stylesheet.css"

A root-relative link would look something like this:

href="/css/stylesheet.css"

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::

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