Troubleshooting Mobile Access

Troubleshooting Web Connectivity

Web connectivity issues can occur in Mobile AccessClosed Check Point Software Blade on a Security Gateway that provides a Remote Access VPN access for managed and unmanaged clients. Acronym: MAB. Web Applications, while working with applications that use/require HTTP cookies. This is because some cookies usually forwarded by Microsoft Internet Explorer to a Web server are not forwarded by Mobile Access in the same scenario. To solve this, see sk31636.

Troubleshooting Outlook Web Access

Note - This section applies to Outlook Web Access-related issues occurring when working through Mobile Access without SSL Network Extender.

If you have problems with Outlook Web Access (OWA) after deploying Mobile Access:

  1. Read the relevant sections in this Administration Guide. See Mobile Access Applications.

  2. Go over the Troubleshooting OWA Checklist.

  3. Look for a description that matches your issues in the "Common OWA problems" section.

Troubleshooting OWA Checklist

The following sections describe steps to take if you are experiencing problems using Outlook Web Access with Mobile Access.

  1. Check your traffic logs for errors. The logs may help you to pinpoint the problem.

  2. Reproduce the scenario without Mobile Access and ensure that the problem does not occur.

  3. Verify connectivity. Make sure that:

    • The Mobile Access machine has a network route to all relevant Microsoft Exchange servers and relevant server ports are accessible, usually port 80 or 443.

      HTTP and/or HTTPS packets must be able to reach Microsoft Exchange servers.

    • Mobile Access users have a network route to the Mobile Access machine.

  4. Verify that your configuration is valid. Make sure that:

    • The Outlook Web Access version is supported by Mobile Access.

    • Client-side browsers are supported by OWA and by Mobile Access.

    • OWA Services are configured to use protocols acceptable by the servers in question. For example, if an Exchange server is configured to accept HTTPS traffic only, the corresponding OWA Web application on Mobile Access must utilize HTTPS.

    • Security restrictions are disabled (see the "Troubleshooting Security Restrictions in OWA" section).

    • Users are authorized to access all necessary resources.

    • OWA services are configured with correct paths, according to the specific version of the Microsoft Exchange server.

Unsupported Feature List

The following OWA features, platforms and product versions are not supported by Mobile Access:

  • Outlook Web Access (OWA) 5.5.

  • OWA 2000 on Microsoft Exchange 2003. (*)

  • Outlook Mobile Access.

(*) These products and platforms have not been tested with Mobile Access. However, Mobile Access has been successfully integrated in such environments.

Note - According to Microsoft, only the following OWA configuration supports non-IE browsers: OWA 2000 / 2003 running on Microsoft Exchange 2003 using "Outlook Web Access Basic" scheme.

If you must use one of these features, use SSL Network Extender.

Common OWA problems

These sections describe issues related to browsing to OWA through Mobile Access.

Note - Examine your traffic logs for errors, to pinpoint the problem.

Troubleshooting Authentication with OWA

After users log in to Mobile Access, and attempt to access an OWA application, they are required by OWA to provide authentication credentials.

Outlook Web Access has two authentication schemes: the regular HTTP-based authentication (HBA), which is the default, and Form-Based authentication (FBA). In addition, Mobile Access supports single sign-on (SSO) through HBA and FBA.

HBA Problems

If an internal Web Server requests Integrated Windows Authentication (NTLM) or any other HTTP-based authentication, Mobile Access either displays a dialog box requesting login credentials, or tries to use the user's portal credentials, depending on the configuration of the Mobile Access Web application. HBA-related problems may result from the use of IIS web-based password management services.

IIS Web applications (such as Outlook Web Access) can be configured to use IIS Web-based password management services. These services make it possible for users to change their Windows NT passwords via a web server. These services use IIS HTR technology which is known to be vulnerable to attack, and can allow an attacker to run malicious code on the user system. Microsoft has long advocated that customers disable HTR on their Web servers, unless there is a business-critical need for the technology (Microsoft Security Bulletin MS02-028).

In keeping with the Microsoft recommendation, IPSClosed Check Point Software Blade on a Security Gateway that inspects and analyzes packets and data for numerous types of risks (Intrusion Prevention System). protects against HTR exploits by default. If you wish to allow the use of the HTR mechanism, deactivate the "htr" worm pattern in the IPS General HTTP Worm Catcher protection. Install the Security policyClosed Collection of rules that control network traffic and enforce organization guidelines for data protection and access to resources with packet inspection. from SmartDashboardClosed Legacy Check Point GUI client used to create and manage the security settings in versions R77.30 and lower. In versions R80.X and higher is still used to configure specific legacy settings. after making these changes.

Single Sign On Problems

When troubleshooting, eliminate the possibility of Single Sign On problems by removing the OWA user credentials from the credentials list in the Mobile Access user portal.

Troubleshooting Authorization with OWA

The authorization mechanisms of Mobile Access allow administrators to grant access to various resources on a per-path, per-host and per-port basis. Mobile Access views Outlook Web Access as a Web application with special properties, connecting to a special Web server.

Authorization-related problems may result from:

  • Possible discrepancies may occur in the configuration of the OWA port, protocol or paths versus the setup of the corresponding Microsoft Exchange server.

    OWA Service must be configured in accordance with the Microsoft Exchange server configuration. Otherwise, Mobile Access will not be able to authorize access to the application.

    Authorization Example Scenario

    A user launches an OWA application, gets to the Form-Based Authentication (FBA) page and authenticates using his/her credentials. Subsequently, the user gets the "Access denied" page.

    Cause: The Microsoft Exchange server side component (IIS or other) is configured to accept both HTTP and HTTPS traffic, whereas the Mobile Access OWA Web application is configured to authorize HTTP traffic only.

    Explanation: The Form Based Authentication setting on the Microsoft Exchange server requires clients to use SSL, which means that some server-side component (be it IIS or other) must also accept SSL traffic. The following message is displayed to the Microsoft Exchange administrator upon FBA configuration:

    Forms Based Authentication requires clients to use a SSL connection. If SSL encryption is not off-loaded to another source, complete the following steps:

    • Configure SSL

    • Restart the IIS service

    This means that IIS is likely to be configured to work over SSL. However, in complex cases, such as SSL encryption being off-loaded to another source, and the IIS server itself allowing HTTP traffic, the Mobile Access administrator may not be aware of the need to authorize HTTPS traffic. As a result, discrepancies may occur.

    Note - When FBA is in use, always set the OWA Web application to allow HTTPS traffic.

    Solution - Make sure that the OWA application configuration on the Mobile Access blade matches the configuration requirements of the Microsoft Exchange server.

  • Some companies access their OWA applications via intermediary websites. These intermediary websites may reference the OWA server by its IP(s) or host name(s). If, when defining access to the OWA server, the intermediary website is ignored, it can cause an authorization failure in Mobile Access.

    User experiences may vary. In some cases the problem may result in a run-time JavaScript error or OWA becomes unresponsive (see Insufficient User Permissions for more information).

    To troubleshoot such problems, test OWA operations without using any mediator (such as proxies, Security Gateways, or websites).

User experiences may vary widely. However, most authorization failures will result in the following error message: Error: Access denied. The destination of your request has not been configured , or you do not have authorization access to it. (401).

Troubleshooting Security Restrictions in OWA

Mobile Access utilizes many built-in security features that screen inner networks from external threats. In addition, the Mobile Access endpoint security features protect the endpoint devices.

Occasionally, protection mechanisms may interfere with legitimate user activities. To eliminate this possibility, switch off all Web Intelligence protections during troubleshooting and the install the security policy.

User experiences may vary widely so they are not detailed here. Use the following steps to troubleshoot issues with security restrictions.

  1. Check the traffic log to see if any relevant URL was blocked due to security restrictions.

  2. To reduce the number of false-positives:

    • In SmartDashboard, in the IPS tab, go to Protections > By Protocol > Integrated > Web Intelligence and turn all settings of Application Layer Protection Level to Low.

    • In the ASCII Only Request protection, clear Block non ASCII characters in form fields.

    • Install the Security policy from SmartDashboard.

  3. If Step 2 did not solve the problem, try the following:

    • Modify the Endpoint Compliance page of the Mobile Access Web Application to Allow caching of all content.

    • In SmartDashboard, in the IPS tab, go to Web Intelligence and

      • In the HTTP Protocol Inspection > HTTP Methods protection, clear Block standard Unsafe HTTP methods.

      • In the Malicious Code > General HTTP Worm Catcher protection, disable the "htr" worm pattern.

    • Install the Security Policy from the administration portal.

  4. If Step 3 did not solve the problem, try the following steps in order:

    1. Turn off all Web Intelligence protections.

    2. Turn off all IPS protections.

    3. Install the Security policy from SmartDashboard.

Troubleshooting Performance Issues in OWA

Performance issues may occur with OWA for the following reasons:

  • Generations of Debug and Trace logs (that are accessed via the console), and the storage of these log records when they grow too big, may considerably degrade the performance of the machine.

    Notes:

    To turn off Debug logs and Trace logs:

    1. Modify the $CVPNDIR/conf/httpd.conf file as follows;

      1. Set the LogLevel parameter to emerg.

      2. Make sure the following lines are commented. Commented lines are preceded by #:

        #CvpnTraceLogMaxByte 10000000

        #CvpnWsDebugSubjects ...

    2. Run the cvpnrestart command

    3. If you have a Mobile Access clusterClosed Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing., repeat on all cluster members.

    To purge existing Debug logs and Trace logs:

    1. Empty or delete all httpd.log* files located in $CVPNDIR/log directory

    2. Empty or delete the mod_ws.log file located in $CVPNDIR/log directory

    3. Empty or delete the mod_ws_boa.log file located in $CVPNDIR/log directory

    4. Delete all files located under $CVPNDIR/log/trace_log directory

    5. If you have a Mobile Access cluster, repeat on all cluster members.

  • The Outlook Web Access service can be configured to work over SSL inside secure networks. This option is normally used if the Microsoft Exchange server is configured to accept SSL-encrypted traffic (HTTPS).

    This is the case if OWA is configured to use Form Based Authentication (FBA). Upon enabling FBA, the Exchange administrator is prompted by the IIS to change the Web application to work over SSL.

    Configuring OWA to use SSL inside secure networks may cause degradation in performance and browsing experience. This is because, in such a topology, the amount of SSL negotiations grows considerably. SSL negotiations are very CPU-intensive, and therefore may cause performance degradation.

    To solve this problem:

    • Change the topology to use HTTP instead of HTTPS inside secure networks.

    • Use a stronger machine.

  • Introducing Mobile Access into an OWA topology allows users to connect to enterprise resources from remote locations.

    Users connecting from remote locations may be subject to temporary or permanent network problems. The rate of packet loss in those networks can vary widely, as can the throughput.

  • Mobile Access inspects and modifies all HTTP traffic passing through the Security GatewayClosed Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources.. It takes time to process each particular packet of information.

    There is therefore a difference in latency between connections passing through Mobile Access and those that do not. The overhead in absolute elapsed time is proportional to the amount of data passed through the network.

    Latency and therefore performance problems when working through Mobile Access may be felt in particular by users with large numbers of emails, calendar events, task items and the like.

    To solve this problem:

    Minimize the latency overhead by increasing the performance of Mobile Access. You can do this by using a stronger machine.

  • SSL time-out problems can occur with Internet Explorer while working through Mobile Access. They can cause slowness and even temporary or permanent unresponsiveness of the browser.

    To solve this problem:

    • If feasible, upgrade Internet Explorer by following the instructions in the relevant Microsoft articles below.

    • Alternatively, configure Mobile Access, so that it does not use keep-alive packets when communicating with those hosts or paths.

    To configure Mobile Access to work without keep-alive packets to specific locations:

    1. Supply additional LocationMatch directives for each host used by the Web Application in question. All directives go in the $CVPNDIR/conf/includes/Main.virtualhost.conf file, in the VirtualHost section.

      For more information, see: http://httpd.apache.org/docs/2.0/mod/core.html#locationmatch

      <LocationMatch "CVPNHost=<IP or DNS namedelimited by dots>">
  SetEnv nokeepalive
</LocationMatch>

      For example:

       <LocationMatch "CVPNHost=208\.77\.188\.166">
  SetEnv nokeepalive
</LocationMatch>
........
<LocationMatch "CVPNHost=myhost\.example\.com|CVPNHost=myhost">
  SetEnv nokeepalive
</LocationMatch>

    2. Run cpstop and then cpstart.

    3. Repeat for each Mobile Access cluster memberClosed Security Gateway that is part of a cluster..

  • Authorization Problems

Saving File Attachments with OWA

When trying to save a file attachment with Outlook Web Access (OWA), Mobile Access adds the full path to the file name. For example, the file name appears something like:

Bulletin1H.PDF,CVPNHost=192.168.201.6,CVPNProtocol=http,CVPNOrg=full,CVPNExtension=.PDF

To solve this, configure the Web Application to use Path Translation or Hostname Translation (see Mobile Access Applications).

Troubleshooting Citrix

Note - This section refers to Citrix-related issues occurring when working through Mobile Access without the use of SSL Network Extender.

If you have issues with Citrix after the deployment of Mobile Access, see Mobile Access Applications > section about Citrix Services. Then try the troubleshooting checklist.

Troubleshooting Citrix Checklist

Follow the steps below to pinpoint the issue that may be causing trouble with Citrix.

Connectivity Issues

  1. Make sure that Mobile Access has a network route to all Web Interface servers intended to be used and relevant server ports are accessible. Usually ports 80 or 443.

    HTTP and/or HTTPS protocols must be traversible towards Web Interface servers.

  2. Make sure that Mobile Access has a network route to all Presentation servers intended to be used and relevant server ports are accessible. Usually ports 1494 or 2598.

    ICAClosed Internal Certificate Authority. A component on Check Point Management Server that issues certificates for authentication. protocol must be traversible towards Presentation servers.

  3. Make sure that Mobile Access machine has a network route to all STA servers intended to be used, if any, and port 80 on STA servers is accessible, and HTTP protocol is traversible.

  4. Make sure that Mobile Access users have a network route to the Mobile Access machine.

Configuration Issues

  1. Make sure that Citrix servers and clients are of those versions supported by Mobile Access.

  2. Make sure that all necessary STA servers are configured with corresponding Citrix Services on Mobile Access.

  3. Make sure that the Mobile Access server certificate:

    • is issued to the Fully Qualified Domain Name (such as www.example.com) of the Security Gateway

    • is properly configured

    • is trusted by the client-side

Troubleshooting File Shares

  • Mobile Access gives an informative error message when an attempt to access a file share fails. However, if a user tries to access a share that does not exist on the file server, Mobile Access cannot always distinguish this error from an Access Denied error. In this case the user may be presented with the credentials input form again, or get an Access Denied error.

  • The Windows Explorer viewer can normally be used for browsing website. However, the Mobile Access SSL Network Extender window may not load properly when using it, and the user may be presented with the Mobile Access login page. It is recommended to use the Web-based viewer instead.

  • When browsing file shares through the Mobile Access user portal, users can open most files by clicking them. However, some files, for example .wmv extension files, cannot be opened that way, and must be downloaded to the local desktop and opened from there. When using the Mobile Access Web-based file viewer, download the file by right-clicking on the file and choosing "Save Target As...". When using the Windows File Explorer viewer, download the file by copying or drag-and-dropping it to the local desktop.

  • When accessing files via Mobile Access, the client application used to view a file depends on the file type. Some file types (such as jpg files) can be configured to be opened by a Web browser. In some client configurations, the result of opening such a file may show the Mobile Access login page instead of the requested file. If this happens, verify that the client uses the latest recommended browser version including all patches and fixes. Specifically, install Internet Explorer patch Q823353 on the endpoint.

  • When using Mobile Access file shares with VSXClosed Virtual System Extension. Check Point virtual networking solution, hosted on a computer or cluster with virtual abstractions of Check Point Security Gateways and other network devices. These Virtual Devices provide the same functionality as their physical counterparts., the DNS resolving of the hostname might not work correctly with file shares. Make sure that the /etc/resolve.conf file is configured correctly or change the value of vsxMountWithIPAddress in the $CVPNDIR/conf/cvpnd.C from false to true. The file share will use the host ip for the mount instead of the hostname.

Troubleshooting Push Notifications

Scenario: Push notifications are configured but users do not see push notification in Capsule Workspace.

Use the Push Notification Status Utility and Monitoring Push Notification Usage to troubleshoot Push Notifications with Mobile Access (see Mobile Access for Smartphones and Tablets) .

Also see sk109039.