Support Center > Search Results > SecureKnowledge Details
ATRG: Mobile Access Blade
Solution

Table of Contents

  • Introduction
  • Process Flow Diagrams and Description
  • Troubleshooting
  • Debug Procedures
  • Recommended Documents and Solutions

 

Show the Entire Article

 

Introduction

Show / Hide this section

Check Point Mobile Access Software Blade is the safe and easy solution to connect to corporate applications over the Internet with your Smartphone, tablet or PC. The solution provides enterprise-grade remote access via both Layer-3 VPN and SSL VPN, allowing you simple, safe and secure connectivity to your email, calendar, contacts and corporate applications.

For more information about the Mobile Access Blade, refer to R77 versions Mobile Access Administration Guide.

 

Motivation for Mobile Access Blade

Remote access market is growing:

  • Wireless devices are all over.
  • People are working from home or on the road.
  • People want access from any type of device.
  • Traditional IPSec VPN products do not offer this type of connectivity:
    • Preinstalled "fat" client software
    • Difficult to connect from other local networks (using different port than 80 / 443)

 

What Mobile Access Blade does?

Using SSL "Clientless" VPN

  • Enables using resources from an organization's internal network.
  • Only a browser is required on the client side.
  • Traffic from the client to Mobile Access Blade gateway is encrypted (using SSL, not IPSec).
  • Some features require a thin client (either ActiveX or Java applet) which is deployed automatically (on demand).
  • Smartphones can access with dedicated application without establishing VPN tunnel.

 

Feature Overview: Access

  • Provides pure clientless access to applications deployed on the internal network:
    • Web applications (using Link Translation)
    • Windows file shares (using CIFS mounts)
    • Mail applications (Webmail for IMAP)
  • Provides "thin client" access to network-level applications:
    • TCP/UDP (SNX Network Mode)
    • TCP only for non-admin users (SNX Application Mode)
    • Embedded applications (Telnet, SSH, FTP, RDP, Jabber, etc.)

 

Feature Overview: Authentication

  • Provides authentication based on:
    • Realm based authentication with support for multi-factor authentication
  • Provides authorization based on:
    • User groups (Internal, LDAP/AD, Radius)
    • Resource’s Protection Level
      • Endpoint Security scan results
      • Authentication strength

 

Feature Overview: Audit and Platforms

  • Provides auditing:
    • Administrator's actions are logged
    • Traffic events are logged
  • Supports different end-user platforms: Windows, Linux, Mac OS X, Android, iOS

 

Feature Overview: Security

  • Provides a unique security solution:
    • Gateway
      • FW, IPS, AV
      • 'Stateful Inspection' on tunneled traffic
      • Web Intelligence
    • Endpoint Security On Demand (ESOD)
      • Compliance Scanner (formerly known as ICS)
      • Secure Workspace (formerly known as ISW)
    • Update service (IPS, AV, ESOD)

 

Feature Overview: Reverse Proxy

  • This feature adds support for Reverse Proxy for standard Web Applications on your servers, using Mobile Access. Reverse Proxy users browse to an address (URL) that is resolved to the Mobile Access Gateway's IP address. Then, the Mobile Access Gateway passes the request to an internal server, according to the Reverse Proxy rules. 
  • Administrator controls the security level (HTTP or HTTPS) of connections between users and resources.

 

Feature Overview: Unified Policy (since R80.10)

  • Mobile Access, in the R80.10 release, supports both Legacy Policy (as in R77.30 and below) and Unified Policy.
  • By default, the Mobile Access blade is set to Legacy Policy. The Administrator can switch to Unified Policy (requires policy install).
  • For more detailed Troubleshooting information, refer to the Troubleshooting section of this document.
  • When you include Mobile Access in the Unified Policy, you configure all rules related to the Mobile Access portal, Capsule Workspace, and on-demand clients in the Access Control Policy.
  • In the Access Control Rule Base, you can configure rules that:
    • Apply to all Mobile Access gateways, or some of them.
    • Now you can apply to one or more Mobile Access clients, such as the Mobile Access portal or Capsule Workspace.
  • Mobile Access features such as Protection Levels, Secure Workspace, and Endpoint Compliance also apply.
  • Note that when you use the Unified Access Policy, some Mobile Access features and settings are still configured in the 'SmartDashboard > Mobile Access tab'.
  • For more extensive information about this feature, refer to the "Mobile Access and the Unified Access Policy" section in the Mobile Access R80.10 Administration Guide.
  • For information about Unified Policy, refer to the "Creating an Access Control Policy" section in the Next Generation Security Gateway R80.10 Guide.

 

Feature Overview: Application Wrapping (since R80.10)

  • Capsule Workspace App Wrapping leverages Capsule Workspace and extends it to offer 3rd party apps in a security container that provides multi security layers and access for both iOS and Android apps. 
  • For more detailed information, refer to sk111558 - Capsule Workspace App Wrapping.

 

Process Flow Diagrams and Description

Show / Hide this section

  • Mobile Access Blade Network Deployment

    In the simplest Mobile Access deployment, one Mobile Access enabled Security Gateway inspects all traffic, including all Mobile Access traffic. IPS and Anti-Virus can be active on all traffic as well. The Security Gateway can be on the network perimeter.

    This is the recommended deployment. It is also the least expensive and easiest to configure, as it only requires one gateway machine for easy and secure remote access.

  • Mobile Access Blade as a Reverse HTTP Proxy

    A reverse proxy appears to the client just like an ordinary web server. No special configuration on the client is necessary.

  • Link Translation is the process by which Mobile Access converts internal URLs to public URLs that are valid on the Internet, so that internal resources become accessible via any Internet-connected browser.

    Mobile Access supports different methods of Link Translation:

    • URL Translation (UT) the original link translation method, maintained for backward compatibility.

    • Hostname Translation (HT) provides dramatically improved performance for Mobile Access gateways and end users, resulting in faster Web access and fewer connectivity issues. It gives access a wider range of websites, with enhanced support for HTML pages, JavaScript, VBscript, and Web applications (such as the SAP Portal).

    • Path Translation (PT) is the newest Link Translation method. It offers the same connectivity level as Hostname Translation, without the more difficult and costly configurations. (Hostname Translation requires a more expensive server certificate.)

  • File Shares: Protocols Involved

    A file share defines a collection of files, made available across the network by means of a protocol, such as SMB for Windows, that enables actions on files, including opening, reading, writing and deleting files across the network.

  • Web Mail Support: Protocols Involved

    Mobile Access supports built-in Web mail. Web mail provides a simple way for remote users, through a web browser interface, to access their email. Employees can access their email from any computer that has access to the Internet, such as a computer in a library, or Internet cafe. There is no need to install special email or remote access software. This is helpful for employees who work outside the office on a regular basis.

    Mobile Access provides a Web front-end for any email application that uses the IMAP protocol for incoming mail, and SMTP for outgoing mail.

    E-mail stored on the IMAP server is manipulated through the browser interface without having to transfer the messages back and forth. Users can connect to several mail servers depending on their authorization.

  • Authentication: Single Sign-On (SSO)

    Native applications that you access with SSL Network Extender can use Single Sign-On (SSO) functionality. With SSO support, users connect automatically to native applications that require login. The native application gets the Mobile Access portal login username and password parameters from the internal server. This feature is supported in R77.20 and higher. It requires a SSL Network Extender client upgrade.

 

Troubleshooting

Show / Hide this section

Refer to Troubleshooting Mobile Access in the R77 versions Mobile Access Administration Guide for detailed information about:

 

Mobile Access Blade Troubleshooting by Topic

  1. Unified Policy (since R80.10)
  2. Cannot access Mobile Access portal
  3. Web application appears broken due to
  4. Application Wrapping (since R80.10)
  5. File Shares
  6. ESOD
  7. SNX
  8. Capsule Workspace
  9. ActiveSync
  10. CVPND process is not starting
  11. Reverse Proxy

 

  1. Troubleshooting Topic: Unified Policy (since R80.10)


    Mobile Access, in the R80.10 release, supports both Legacy Policy (as in R77.30 and below and Unified Policy).

    By default, the Mobile Access blade is set to Legacy Policy. The Administrator can switch to Unified Policy (requires policy install).



    Notes regarding Unified Policy as the Policy Source:

    • A single Gateway cannot be set to both Unified and Legacy. (see screen capture above)
    • You cannot migrate Legacy Policy (i.e. Mobile Access rules) to the Unified Policy.
      • The Administrator needs to create the rules manually.
      • The Administrator must enable Mobile Access on each Policy layer, in the unified Policy, that contains Mobile Access rules (applications). (see screen capture below)
      • The same Mobile Access applications that were used in Legacy Policy can and should be used in Unified Policy.
    • For information on the use of Access Roles and client type in the Access Role, refer to the “Access Roles for Remote Access” section in the Mobile Access R80.10 Administration Guide.
    • For best practice on how to define Mobile Access rules, refer to the “Best Practices for Rules” section in the Mobile Access R80.10 Administration Guide.

    Related Solution


    Unified Policy Logs

    The Mobile Access Authorization log, in Unified Policy, always contains both Mobile Access and Firewall blades. As a result:
    • The log's "blade" icon will be a Multiple blade icon. Example:


    • When you cick on the log line, you wil display the full Unified Policy log. Example:


    • Filtering using 'blade:"Mobile Access"', will match such logs if SmartLog indexing is enabled. (In Standalone installation, SmartLog indexing is disabled, by default).

  2. Troubleshooting Topic: Cannot access Mobile Access portal

    • Mobile Access portal does not respond

      1. First check out for any recent configuration changes that may have caused the MAB portal not to respond.

      2. Look up SmartView Tracker log for any related logs.

      3. Check for core dumps at : /var/log/dump/usermode/

      4. Check under the 'Portal settings' tab that the gateway has the expected certificate configured.

      5. If you get the wrong certificate, check in other portals, as we only use one certificate on a given IP address. Note that "All portals on the same IP address use the same certificate" (see sk94965).

      6. Try to figure out whether SSL handshake was established (look for the certificate in the address bar, or use Wireshark and look for client_hello and server_hello).

      7. In case of an SSL problem, you need to collect kernel debug:
        # fw ctl zdebug -m fw + drop crypt cptls

      8. Check VPND debugs, as described in the section "Debug Procedures" - "Debugging the Gateway side" - "vpnd process"

      9. Check MPDAEMON the 'matching component' that is also responsible for launching HTTPD (its parent process) - see sk87920.

      10. Check that the SSLVPN Portal is running: # mpclient status sslvpn

      11. Get the HTTPD's high port:

        # mpclient getdata sslvpn

        For HTTPD:

        # ps -ef |grep httpd |grep sslvpn
        # telnet localhost [HTTPD_HIGH_PORT]
        # GET /sslvpn
      12. Check HTTPD's starting log:

        $CVPNDIR/log/httpd.starlog
      13. Enable HTTPD debugs, as described in the section "Debug Procedures" - "Debugging the Gateway side" - "httpd process", and check: $CVPNDIR/log/httpd.log

      Related solutions:



    • Mobile Access portal does not respond after upgrade

      Common issue at upgrade when DNS is not yet configured or reachable - See sk98805

      Related solutions:



    • Authentication fails due to:

      • Realms configuration (Pre-R80.10)

        • Mistake in realm configuration: if there is a problem, cvpnd is not starting and MAB portal is not accessible, log line in $CVPNDIR/log/cvpnd.elg (Failed to init cvpnauth). Check $FWDIR/database/authentication_objects.C (which contains the realms configuration).

        • Additional realm was configured but is not shown to the users in the portal (no drop down list/drop down without the new realm).
          Check that the correct realm is in $CVPNDIR/conf/cvpnd.C - attribute portalRealmNames



      • Multiple Login Options configuration (Since R80.10)

        • The Pre-R80.10 gateway, uses Single Authentication settings only. (Old style UX)


        • The R80.10 gateway, by default, uses Single Authentication settings. (New style UX)

        • In addition, you can (and should) use the Multiple Authentication Option configuration.


        • User Look and feel in the Mobile Access Portal, configured with Multiple Login options.


        • R80.10 gateway can prevent Single Authentication clients (i.e. clients not listed in sk111583), from accessing the gateway.


        • R80.10 gateway can prevent authentication done using Single Authentication configuration.


        • Proxy configuration for DynamicID authentication is now defined in the Gateway's proxy configuration, instead of the Mobile Access Proxy configuration.



        For more information on Multiple Login Options for R80.x Gateways, refer to the “Multiple Login Options for R80.x Gateways” section in the Mobile Access R80.10 Administration Guide.
      • User record lookup

        • Looking in wrong directory (symptom might be latency):

          • Might be indicated by log in $CVPNDIR/log/cvpnd.elg / capture of traffic.

          • Look in realm configuration.

          • Make sure that in Security Gateway properties > Other > User directory everything is configured properly.

        • Looking with wrong identifier (certificate with DN that contain also the e-mail address, certificate with wrong (old) directory path, directory expects different value like e-mail instead of username):

          • User will get "Wrong user name or password" / "Certificate authentication failed"

          • Admin should know which identifier his directory is expecting to get.

          • Most of the problems might be solved by realm configuration, sometimes you also need to configure the directory settings (wide impact) - (both with GuiDbEdit)

            • Example 1 - Microsoft_AD > Common > UserLoginAttr
            • Example 2 - Directory Settings > UserLoginAttr / lookup_type


      • User group mapping

        • Symptom: user is not allowed to a specific resource (application link is not shown in the portal) / user get "User is not authorized" after login.

        • You could see the groups of the user in $CVPNDIR/log/cvpnd.elg (during Login only) = au_fetchuser_callback user obj:

        • Keep in mind, if user was added/removed to/from a group after login, it will take affect only after next login (Known limitation).

        Related solutions:



      • Credential validation

        • Symptom: user cannot login (Wrong user name or password)

        • Check that account is not locked (in the directory).

        • Make sure that other users can login.

        • Make sure user is not expired and time is allowed (on the user record, mostly for internal users also relevant from templates or generic*).

        • $CVPNDIR/log/cvpnd.elg might contain details if this is not a problem with the credentials (such as expiration).

        Related solutions:



      • Admin LDAP AU credentials

        Related solutions:



      • Client certificate issues

        • CRL is not available (might happen 24 hours after the problem started) - should be stated in SmartView Tracker Log.

          • Internal CA: make sure the Management is available

          • External CA: make sure there is no firewall in the middle that blocks the traffic.

        • Certificate is expired - should be stated in SmartView Tracker Log. If not, it is in $CVPNDIR/log/cvpnd.elg

        • Using the "wrong" info from the certificate. Refer to the "Troubleshooting Topic: Cannot access Mobile Access portal" - section "Authentication fails due to:" - subsection "User record lookup".



      • Multi-challenge issues (AD password remediation, LDAP/RADIUS challenges, SMS OTP, SecurID challenges)

        • Password remediation require LDAPs should be configured on the Account unit (LDAP server properties -> Encryption -> Use Encryption (SSL).

        • Server might not be trusted: wrong fingerprint.

        Related solutions:



      • Kerberos

        • Kerberos is an authentication method that is used to identify the user in front of the internal servers.

        • Kerberos creates a ticket which it uses to authenticate the user instead of using credentials.

        • Inside the ticket, the user name, allowed servers and amount of time for which the ticket is active are listed.

        • In order to create a Kerberos ticket, Mobile Access Blade uses the portal credentials (user name and password).THis is done in order to create the ticket and to authenticate to the internal server.

        • When a user logs in to Mobile Access Blade without user name and password, e.g. with a certificate. Kerberos Constrained Delegation (KCD) is used. KCD allows you to create tickets for other users based on a delegate ticket which was created from credentials that are allowed.

        Troubleshooting & Debugging Kerberos Constrained Delegation (KCD)

        • See if there is a Kerberos Constrained Delegation failure entry in SmartView Tracker or SmartLog. Under Mobile Access logs and run cvpnrestart on the Security Gateway through SSH.

        • KCD flow consist of 2 main steps:

          1. Creating a Kerberos ticket for the delegate user (that was configured previously).

            1. In order to see that the ticket was created successfully, see that $CVPNDIR/tmp/krbcc/krbkt_* and $CVPNDIR/tmp/krbcc/krbtgt_* exist (krbkt_* and krbtgt_* are the prefixes of the files.)

            2. Run the command on the Security Gateway "klist $CVPNDIR/tmp/krbcc/krbtgt_*", where krbtgt_* is the prefix of the file and see that the ticket contains information such as date and user name.

            3. If the ticket does not contain information, please check your AD and SmartDashboard configuration again.

          2. Creating a ticket for the end user.

            1. In order to see that the ticket was created successfully, see that $CVPNDIR/tmp/krbcc/krbcc_* exists (krbcc_* is the prefix of the file.)

            2. Run the command on the Security Gateway "klist $CVPNDIR/tmp/krbcc/krbcc_*", where krbcc_* is the prefix of the file and see that the ticket contains information such as date and user name.

            3. If the ticket does not contain information, please check your AD and SmartDashboard configuration again.

        • In case of other problems, please attach the following logs after reproduction of the login problem:

          • Mobile Access httpd log - $CVPNDIR/log/httpd.log*

          • Mobile Access cvpnd log - $CVPNDIR/log/cvpnd.elg*

          • KCD logs - $CVPNDIR/log/KCDUtil.elg after enabling them

            To enable KCD logs:

            1. Edit the $CVPNDIR/conf/cvpnd_internal_settings.C on the Security Gateway

            2. Change the value of EnableKCDDebug from "false" to "true"

            3. Run cvpnrestart

        Known Limitations:

        • The Kerberos Constrained Delegation user must be configured on the Account Unit object in SmartDashboard - no UI is available.

        Related solutions:



    • 'vpnd', server certificate, multi-portal (port conflicts), fw policy, SSL version/ciphersuite, proxies

      • For discussion of possible port conflict, see sk66607

      • For server settings of SSL version: 'Policy menu > Global Properties > SmartDashboard Configuration > Configure > Portal Properties'

      • Also have a look at: SmartDashboard > 'Policy' menu > 'Global Properties...' > 'Remote Access' > 'SSL Network Extender' > 'Encryption'

      • For a discussion of the limitation of both MAB and gateway as proxy, see sk110013.

      Related solutions:



    • Conflicts with SNX setup / proxy replacement

      Related solutions:




  3. Troubleshooting Topic: Web application appears broken due to

    • Link Translation (LT) issues (UT/HT/PT)

      See description of Link Translation in the section "Process Flow Diagrams and Description" above.

      For detailed information about configuration of LT method per Security Gateway and per application, refer to R77 versions Mobile Access Administration Guide.

      To troubleshoot Link Translation issues:

      • You need to understand the 4 parts of the Client-to-Server communication:

        • Request from Client to Security Gateway
        • Request from Security Gateway to Server
        • Response from Server to Security Gateway
        • Response from Security Gateway to Client
      • Check Client-to-Server communication without Mobile Access Blade - is it working?

        Use Fiddler in order to see the original requests and responses. (Important: Use Fiddler only after cleaning the browser cache.)

        You can use the following tools to see the requests from client to Security Gateway and from Security Gateway to Server, in addition to the response from Server to Security Gateway and gateway to client:

        • Client to Security Gateway requests & responses: Fiddler
        • Server to Security Gateway requests & responses: trace_log
      • Check Browser JavaScript errors. Pressing F12 key usually opens a console to see JavaScript errors, which can help identify the LT problems.

      • Various LT problems:

        • Wrong translation of the strings:

          • When find wrong LT value, then we need to search which rule causes the problem.

          • After finding the rule, understand why we had a match on the original text.

            Example: url == link is translated as url = CP_PT_TRANS(= link)
        • Missing translation: the HTML code was not translated by the Security Gateway, which results in bad links

          • Compare the behavior of the server with Mobile Access Blade, and without Mobile Access Blade using Fiddler.
      • When troubleshooting PT issues, you need to understand PT Substitute.features.conf file.

        • You need to understand how to use and read Apache regular expressions.
      • When troubleshooting LT issues, it is very useful to enable LT logs in Mobile Access Blade:

        • LT logs appear in the $CVPNDIR/log/httpd.log file after setting the value:

          From:

          CvpnLogTDError "LTFLOW" 0
          CvpnLogTDError "LTCONTENT" 0

          To:

          CvpnLogTDError "LTFLOW" 5
          CvpnLogTDError "LTCONTENT" 5

          in the $CVPNDIR/conf/httpd.conf file and running the "cvpnd_admin policy" command.

          This is especially helpful for UT and HT.

      Related solutions:



    • Cookie management issues (on Security Gateway, on client-side, same origin policy)

      Symptoms:

      • Web application not working.
      • User is asked for credentials over and over.
      • Receiving portal error 401 - Unauthorized (this might be SSO issue too).

      How to know:

      • Collect trace log from the Security Gateway, and Fiddler capture of this Web App without Mobile Access Blade.

      • Check that on the Fiddler requests (no Mobile Access Blade) there is a cookie sent to the server on the request header "Cookie".

      • A cookie should also appear in the parallel trace log requests to the internal server.

      • If you cannot see the cookie in the trace log, then this is causing the unauthorized response from the server.

      Possible solutions:

      • If this Web App is configured with PT, try using HT, since cookie handling in HT is different.

      • If this is already HT, try configuring the app with "Cookie on browser" mode:

      • Send Mobile Access Logs to Check Point Support.



    • Authorization configuration (check SmartView Tracker)

      Symptoms:

      • User cannot see a link that he should be allowed to see.
      • User receives an "Unauthorized" message when accessing an app.

      How to know:

      • Configuration issue: Check that one of this user's user groups is mapped in the Mobile Access Blade policy to that specific application.

      • Check in SmartView Tracker under Mobile Access logs for this user's unauthorized log. The message there might help. (For example: DNS Resolving issue, Certificate problem).

      Possible solutions:

      • Check Configuration: make sure the user is mapped to the application (check if the user was moved to other user groups.)

      • Send Mobile Access logs to Check Point Support.



    • Colliding host names (undefined behavior)

      Symptoms:

      • An app that should have SSO is prompting for credentials (SSO not working).

      How to know:

      • Check if the problematic app host name, is also the host name in another web app.

      • Check if this problem is reproducing for all users or for a specific user.

      • So, if there are 2 or more apps configured on the same host name with the same directories,
        there might be a mix-up between the apps, since we identify the app according to its authorized locations (host + directories),
        so the other configurations may be mixed (SSO, LT):

      Possible solutions:

      • If you need both apps, try not to have them both for the same users.

      • If you need 2 applications with the same exact "Authorized Locations". you should unite them to one app.

      • If you want 2 different configurations, try different directories for each app so no mix can happen, for example:
        One with "Directories" : "/example1", and the other web app with : "/example2".

      • Send Mobile Access logs to Check Point Support.



    • Browser compatibility (vendor, version, user-agent, mobile device)

      Symptoms:

      • Broken web app on one browser (usually IE is more problematic).
        For example: either received Blank page for web app, or web app not displayed correctly.

      How to know:

      • Clear browser Cache!

      • Try to reproduce the issue on other browsers.

      • See if this web app works fine on the problematic browser without Mobile Access Blade, to check if this is a Mobile Access Blade issue or not.

      Possible solutions:

      • If this is an IE issue only:

        1. Try commenting out the following lines in $CVPNDIR/conf/Web_inside.location.conf file:

          CvpnAddIECompResponseHeader
          CvpnAddIECompRequestHeader
        2. Clear cache!

        3. After commenting out, run cvpnd_admin policy command.

        4. Try to reproduce.

      • If this is a mobile computability issue, try using this web app on any mobile browser and see computability.

      • Clear browser cache and send Mobile Access logs to Check Point Support (with Fiddler also).



    • Large file uploads or POST requests ('httpd' and PHP configuration)

      Symptoms:

      • POST requests are failing (timeout / error 500).
      • Usually this happens in file uploads flow.

      How to know:

      • Test Fiddler without Mobile Access Blade, and compare it with trace log with Mobile Access Blade, and file the problematic upload request (in both).

      • Check if there is informative info on the response (example: missing cookie, not completed).

      • Is the Problematic POST request received from the browser with the header "Transfer-Encoding" "chunked" ? What is the "Content-length"?

        • NOTE: If it is "chunked" with "content-length 0", there was a bug recently discovered, where this type of request causes libcurl to not set an upload size. Servers may react differently to this.

        • Example for "chunked" issue: without Mobile Access Blade - the request is chunked, with Mobile Access Blade request is not chunked (The Security Gateway changed it). Maybe the internal server cannot handle such requests/ did not expect it.

      Possible solutions:

      • In the file $CVPNDIR/conf/includes/Web_inside.location.conf file, try to increase the value of CvpnMaxPostStoredSize (default is "10,000") - maybe try "50,000".

      • See if request without Mobile Access Blade is "chunked" or not.

      • If this is a timeout issue: maybe there is a mismatch between "KeepAliveTimeout" on the Security Gateway and the server. If you know what the "keep alive" of the server is, try increasing the one on the Security Gateway to match it.

      • Clear browser cache and send Mobile Access Logs to Check Point Support (with Fiddler also).



    • SSO does not work

      Symptoms:

      • SSO is not working.

      How to know:

      • If Web Form, is it automatic detect? if "Yes", try configuring a specific criterion, if you know what is the exact request:

      Notes:

      • Citrix Storefront WF SSO is still not supported automatically - you will need to configure it with the following parameters:

        • Sign in URL: https:///Citrix/StoreWeb/ExplicitAuth/Login
        • Post URL: https:///Citrix/StoreWeb/ExplicitAuth/LoginAttempt
        • Post data: username=$USERNAME&password=$PASSWORD&loginBtn=Log+On&StateContext
      • If regular SSO, make sure the internal server auth protocol is standard, and that the server is returning HTTP error "401".

        In libcurl trace logs, the authentication request to the internal should return HTTP error "401" with the header "WWW-Authenticate",
        check if this exists or we did not even get here (for example HTTP error "403" - not allowed to get this page).

        If HTTP error "401" is received from the server, then check that we sent a request again with the header "Authentication" to the internal server.
        This header should include the credentials somehow (or Kerberos ticket), then check the response.
        If "200 OK": this means SSO worked, but something else ruined the SSO (see example below).
        For example: Security Gateway did not pass the "200 OK" to the browser and failed the request.

      • If Security Gateway did not get "200 OK": Check if credentials forwarded are invalid.

      • Check that the authentication method the Security Gateway is trying is also supported by the server:

        The server returns on the header "WWW-Authentication" all the supported methods.
        Check that the Security Gateway is trying one that is supported on the header "Authentication".

        Options: the server changed its supported authentication methods, but the Security Gateway is still trying to use a cached auth method.

      • SSO success means we get a cookie from the server and "200 OK". If yes, that means something after that caused the problem.



    • Popular Web applications requiring special configuration



    • An exception or daemon crash ("Error while processing request")

      Symptoms:

      • Change was made in a configuration file in $CVPNDIR/conf/ directory
      • Core dump files for cvpnd or httpd appear in /var/log/dump/usermode/ directory

      How to know

      • This kind of issue is usually harder to track, without looking in the code, but if this a configuration issue that caused the httpd to crash with a core dump file - open the file $CVPNDIR/log/httpd.startlog and in the last line you should see a log describing why it failed.

      • Core dump files require code investigations. But try to understand what is causing the crash? Can you reproduce the core? If yes, what is the exact flow (example: web application link causes the crash / adding favorites / ...)?

      Possible solutions

      • Turn on Mobile Access Blade logs, and try to reproduce the crash with core dump file and logs - send the logs and the core dump files to Check Point Support.

      • If the core dump files are not generated / reproduced, send them with information on how it happened (if you know).



  4. Troubleshooting Topic: Application Wrapping


    To check whether the feature is enabled:

    1. Connect to the command line on the Mobile Access Gateway.
    2. Login to Expert mode.
    3. Backup the current $CVPNDIR/conf/includes/Web_inside.location.conf file:
      [Expert@HostName:0]# cp -v $CVPNDIR/conf/includes/Web_inside.location.conf{,_ORIGINAL}
    4. Edit the current $CVPNDIR/conf/includes/Web_inside.location.conf file:
      [Expert@HostName:0]# vi $CVPNDIR/conf/includes/Web_inside.location.conf
    5. To enable the feature, configure: CvpnClientSideLinkTrans on
    6. To disable the feature, configure: CvpnClientSideLinkTrans off
    7. Save the changes and exit from the Vi editor.
    8. Restart the Mobile Access software blade: [Expert@HostName:0]# cvpnstop ; cvpnstart

    To check whether the application is recognized by the gateway as a wrapped application:

    1. Enable trace log collection for the relevant user (instructions under "Debugging the Gateway side" in the Debug Procedures section).
    2. In the apache_request files, search for the X-CPCVPN-ClientSideTrans header and verify that its value is App.

    For additional troubleshooting information, refer to sk111558 - Capsule Workspace App Wrapping.

  5. Troubleshooting Topic: File Shares

    • General Troubleshooting:

      Example: We have configured \\server\path1

      • Server may be configured as host name or DNS. If DNS entry, may not be resolved (DNS server not configured). (Mounting issue)

        • Trace Log error > Mobile Access Category 'File Shares' : unresolved server name
      • Debug, when we do not know what is causing the permissions/authorization issues:

        • Check the $CVPNDIR/log/cvpnd.elg file - look for ERROR. We can see from the log if the problem is configuration, or a problem in the File Shares server.

        • Advanced:

          • Try to run 'Mount' locally in the shell and it will give us a clue where the problem is.

          • Send Wireshark packet capture to Check Point Support.

          • Debug the CvpnProc:

            1. [Expert@HostName:0]# cvpnstop
            2. [Expert@HostName:0]# ps aux | grep cvpnproc
            3. [Expert@HostName:0]# kill -KILL $(pidof cvpnproc)
            4. [Expert@HostName:0]# export TDERROR_ALL_ALL=5
            5. [Expert@HostName:0]# $CVPNDIR/bin/cvpnproc $CVPNDIR/log/cvpnproc.elg $CVPNDIR/conf/cvpnproc.C &
            6. [Expert@HostName:0]# cvpnstart
            7. Replicate the issue
            8. [Expert@HostName:0]# unset TDERROR_ALL_ALL
            9. [Expert@HostName:0]# cvpnstop
            10. [Expert@HostName:0]# kill -TERM $(pidof cvpnproc)
            11. [Expert@HostName:0]# kill -KILL $(pidof cvpnproc)
            12. [Expert@HostName:0]# cvpnstart
            13. Analyze $CVPNDIR/log/cvpnproc.elg*


    • SSO doesn't work (for most cases, see Web applications SSO) (Mounting issue)

      Check if expected to work with SSO, and if user is prompted to reenter his/her credentials. Check the configuration.



    • Cannot authenticate to new Windows File Share servers (NTLMv2/SSP) (Mounting issue)

      Admin might have configured File Share servers we are not supporting, e.g. NTLMv2/SSP.

      Error will be "server unreachable/no permissions".
      The server admin should give us details regarding the server.



    • Directory/file permission issues (File Access issue)

      • Error: "Access denied. The destination of your request has not been configured, or you do not have authorization to access it. (403) - Check configuration of your host:"

        • Trace Log error > Mobile Access Category 'File Shares' : The requested destination is not configured for this user's group in the Mobile Access policy.

      • Error: "Access denied. The destination of your request has not been configured, or you do not have authorization to access it. (403)"

        • Configuration: make sure that the path is not limited, that the path you are trying to reach was included. Error will show that you do not have permissions.

        • There could be an error in the link, and it is not matching the configured path.



    • DFS links do not work (File Access issue)

      Admin might have configured DFS links that we are not supporting.

      Error will be "server unreachable/no permissions".
      The server admin should know if these are DFS links.



    • Related solutions:



  6. Troubleshooting Topic: ESOD



  7. Troubleshooting Topic: SNX



  8. Troubleshooting Topic: Capsule Workspace

    • Report a Problem to Check Point RnD:

      Use case: User want to report general problem or give feedback. The logs will automatically reach R&D.

      How to perform:

      1. Tap the (i) button, top right (in login or passcode screen), or bottom right in home screen. About screen is displayed.

      2. In the "About" screen, tap "Report a Problem".

      3. Add feedback and send.



    • Send logs by e-mail:

      Use case: User want to send logs to specific person by e-mail.

      How to perform:

      1. Go to iOS setting > Capsule Workspace > turn on "Send As Mail".

      2. Go back to the application.

      3. Tap the (i) button, top right (in login or passcode screen), or bottom right in home screen. "About" screen is displayed.

      4. In the "About" screen, tap "Report a Problem". Native mail compose screen will open with logs zip file as attachment.

      5. Send this mail to the desired e-mail.



    • Send HAR (traffic) logs (iOS):

      Use case: The user would like to send traffic logs. Usually instructed by Check Point Support / RnD to do so.

      How to perform:

      1. Tap the (i) button, top right (in login or passcode screen), or bottom right in home screen. About screen is displayed.

        1. Double-tap on the logo.

      2. Determine the log capacity and the amount of time to capture the traffic values, as instructed by Check Point Support / RnD.

      3. Caution: Only turn on "log sensitive data" if certain. It will then contain full traffic body.
        Be aware that the log may contain e-mail data, passwords, and more.

      4. Tap on "Start".

      5. When you finish reproducing your issue, as instructed, proceed to "Send logs by e-mail" (above).



    • Cannot reach site:

      How to identify (iOS):

      • Pop up: Connection error, Network error during site creation.

      • Log: Look for "Site creation error of type" string.

      How to resolve:

      • Check for typo in site address
      • Check Internet connectivity using Safari to any web site - fix if needed.
      • Check connectivity using Safari to wanted site - fix if needed.


    • Wireless / 3G and DNS issues:

      • Check Internet connectivity.
      • Check using native browser to Mobile Access Web Portal.


    • Wrong QR-code type:

      How to identify:

      • Pop up:

        Enrollment Failed

        Failed to establish trust
        ...
        Reject ID: ...

      • Log: Look for "Entered activation key is not valid" string.

      How to resolve:

      • Make sure this is not "already used" QR code.
      • Check the reject ID in SmartLog.
      • Can validate the QR format (See sk102796).


    • Cannot browse to a Web application:

      How to identify:

      • All web apps are greyed out and disabled.
      • Log: You will see setting site's state from SITE_STATE_CONNECTED to SITE_STATE_CONNECTED_OFFLINE at the relevant time.

      How to resolve:



    • Cannot sync mail/calendar/contact:

      • Check Connectivity to 3G/Wireless
      • Check Connectivity to Site.
      • Check that Calendar is working and syncing.
      • Check that the user is not locked.
      • Check that the mailbox is not full.
      • Check that Outlook is syncing.
      • If nothing helps so far: Clear Persistent Storage.
      • If nothing helps: Delete and create new site.
      • If nothing helps: Delete and re-install the application.
      • If nothing helps: Contact Check Point Support.


    • Push messages:

      User does not receive mail updates (items added or deleted):

      Are we talking about push notifications or also in-app pull to refresh?

      For push notifications only:

      1. Check in the app settings that "Push Notifications" is on, and if unavailable that the policy allows it.
      2. Check in iOS 'Settings' > 'Capsule' > 'Notifications' that the OS allows notifications.
      3. Check logs for lines with the "PUSH::" prefix for possible errors.

      Related solutions:



    • Remote wipe:

      Push may not work - check push flow:

      • Token registration failed:



      • Push may be turned off on the client side:

        • iOS Settings > Push notifications.
        • iOS Settings > Capsule > app background.


      • User may be 'offline':

        • Check Internet connectivity.
        • Check using native browser to Mobile Access Web Portal.


    • Performance issues:

      The application is slow:

      • Narrow the sync window (Gateway or Client).

      • Consider performing "Clear Persistent Storage" (iOS Settings/General Settings).

        Application should be killed post toggling Clear Persistent storage
      • Check performance for the same user on another device.

      • Contact Check Point Support.

      Related solutions:



  9. Troubleshooting Topic: ActiveSync

    What is ActiveSync?

    • Additional client that can connect to the Mobile Access SSL VPN portal in addition to browser and capsule.

    • Provides secure mail through the mobile device native mail client.

    • Configuration is with ActiveSync application (see R77 versions Mobile Access Administration Guide).

    • Once you click on ActiveSync configuration in Check Point Capsule, a new window will open and the ActiveSync profile will appear.

    • ActiveSync profile configuration sets a new profile on the mobile device with the gateway properties.

    • Once you finish the ActiveSync profile configuration, the mail will be synced into the native mail client.

    Troubleshooting:



  10. Troubleshooting Topic: CVPND process is not starting

    To get more details about why cvpnd process is not starting:

    1. Empty the CVPND process's log file:

      [Expert@HostName:0]# echo '' > $CVPNDIR/log/cvpnd.elg
    2. Set the debug environment variable:

      [Expert@HostName:0]# export TDERROR_ALL_ALL=5
    3. Manually start the CVPND process:

      [Expert@HostName:0]# cvpnd $CVPNDIR/log/cvpnd.elg $CVPNDIR/conf/cvpnd.C
    4. Wait until you get the prompt back.

    5. Unset the debug environment variable:

      [Expert@HostName:0]# unset TDERROR_ALL_ALL
    6. Analyze the $CVPNDIR/log/cvpnd.elg file

  11. Troubleshooting Topic: Reverse Proxy


    For troubleshooting and debugging refer to sk110348 - Mobile Access Reverse Proxy.

 

Debug Procedures

Show / Hide this section

 

What to debug?

Issue area What to debug
Login / Portal traffic, Web traffic, Link Translation, DNS,
SSO (partial), Web Intelligence, CSRF protection
httpd process
Configuration from policy, Authentication, Authorization,
Session management, cluster sync, kernel tables, SSO (partial)
cvpnd process
SNX, SSL termination, client certificate verification vpnd process +
VPN kernel module

How to debug Mobile Access, SSL VPN?

  1. Debugging the Gateway side
    • httpd process
    • cvpnd process
    • vpnd process
    • cvpnproc process
    • pinger process
  2. Debugging MAB in Unified Policy Mode
  3. Debugging the user side
    • Problems with web application
    • Problems with Secure WorkSpace (SWS)
    • Problems with Native Applications
    • Thin-client deployment mechanism (C-Shell)
  4. Debugging Policy Installation (FWD and CPD)

 

(1) Debugging the Gateway side

  • Debugging the Gateway side - httpd process

    To start the debug:

    1. Backup the current $CVPNDIR/conf/httpd.conf file:

      [Expert@HostName:0]# cp -v $CVPNDIR/conf/httpd.conf $CVPNDIR/conf/httpd.conf_ORIGINAL
    2. Edit the current $CVPNDIR/conf/httpd.conf file:

      [Expert@HostName:0]# vi $CVPNDIR/conf/httpd.conf
    3. Change the "LogLevel" from "emerg" to "debug".

    4. In order to enable trace log collection:

      Version Instructions
      R75.40 and above

      Trace log is now collected for a specific user.

      Save the changes and exit from Vi editor. Then run:

      [Expert@HostName:0]# cvpnd_admin debug trace users=<USERNAME>
      R75.X (up to R75.30)

      Remove the # sign in front of this line:

      LoadModule trace_logger /opt/CPcvpn-R75/lib/libModTrace.so
      R71.X

      Remove the # sign in front of this line:

      LoadModule trace_logger /opt/CPcvpn-R71/lib/libModTrace.so
      R66.1 and older

      Remove the # sign in front of these lines:

      LoadModule trace_logger /opt/CPcvpn-R66/lib/libModTrace.so
      CvpnTraceLogDir /opt/CPcvpn-R66/log/trace_log/
      CvpnTraceLogMaxByte 10000000

    5. Save the changes and exit from Vi editor.

    6. Remove the rotated $CVPNDIR/log/httpd.log.* files, if they exist:

      [Expert@HostName:0]# rm -i $CVPNDIR/log/httpd.log.*
    7. Empty the $CVPNDIR/log/httpd.log file:

      [Expert@HostName:0]# echo '' > $CVPNDIR/log/httpd.log

      IMPORTANT: Do not delete this log file!
    8. If trace log was enabled, then make sure to delete all content from $CVPNDIR/log/trace_log/ directory

      IMPORTANT: Do not delete the directory itself!
    9. Reload the Mobile Access policy:

      [Expert@HostName:0]# cvpnd_admin policy

      Note:

      • If you see that the debug is not being collected in the $CVPNDIR/log/httpd.log file, the run: cvpnrestart
        (This will restart the cvpnd and httpd processes - all existing Mobile Access web connections will be disconnected, but the Mobile Access sessions will remain open)

    To stop the debug:

    1. Disable the trace log collection in R75.40 and above:

      [Expert@HostName:0]# cvpnd_admin debug off
    2. Restore the original $CVPNDIR/conf/httpd.conf file:

      [Expert@HostName:0]# cp -v $CVPNDIR/conf/httpd.conf $CVPNDIR/conf/httpd.conf_DEBUG

      [Expert@HostName:0]# cp -v -f $CVPNDIR/conf/httpd.conf_ORIGINAL $CVPNDIR/conf/httpd.conf
    3. Reload the Mobile Access policy:

      [Expert@HostName:0]# cvpnd_admin policy

      Notes:

      • This might disconnect the current users
      • If you see that the debug is still being collected, then run cvpnrestart
        (This will restart the cvpnd and httpd processes - all existing Mobile Access connections will be disconnected)

     

    Enabling Apache server status page:

    1. Backup the current $CVPNDIR/conf/httpd.conf file:

      [Expert@HostName:0]# cp -v $CVPNDIR/conf/httpd.conf $CVPNDIR/conf/httpd.conf_ORIGINAL
    2. Edit the current $CVPNDIR/conf/httpd.conf file:

      [Expert@HostName:0]# vi $CVPNDIR/conf/httpd.conf
    3. Add the following lines:

      LoadModule status_module /opt/CPshrd-R<version>/web/Apache/2.2.0/modules/libmod_status.so
      ExtendedStatus On
      <Location /Login/server-status>
      SetHandler server-status
      </Location>

      Examples:

      • For R77.X: /opt/CPshrd-R77/web/...
      • For R76: /opt/CPshrd-R76/web/...
      • For R75.40VS: /opt/CPshrd-R75.40VS/web/...
      • For R75.4x: /opt/CPshrd-R75.40/web/...
      • For R75.20 / R75.30: /opt/CPshrd-R75.20/web/...
      • For R75 / R75.10: /opt/CPshrd-R75/web/...
      • For R71.X: /opt/CPshrd-R71/web/...
      • For R70.X: /opt/CPshrd-R70/web/...
    4. Save the changes and exit from Vi editor.

    5. Reload the Mobile Access policy:

      [Expert@HostName:0]# cvpnd_admin policy

      Notes:

      • This might disconnect the current users
      • If you see that the debug is not being collected, then run cvpnrestart
        (This will restart the cvpnd and httpd processes - all existing Mobile Access connections will be disconnected)
    6. To view the status page, browse to:

      • On Mobile Access gateways:

        https://<IP_of_MAB_GW>/sslvpn/Login/server-status
      • On Connectra gateways:

        https://<IP_of_MAB_GW>/Login/server-status
    7. Known Issue ID 00922556: Experiencing a gradual slowdown in Mobile Access Blade performance, and on the status page there are many processes with "G" status that cannot be actually found running on the Mobile Access Gateway.

      Refer to sk92847 - Mobile Access portal is occasionally unresponsive.

    Enabling generation of Apache core dumps:

    1. Backup the current $CVPNDIR/conf/httpd.conf file:

      [Expert@HostName:0]# cp -v $CVPNDIR/conf/httpd.conf $CVPNDIR/conf/httpd.conf_ORIGINAL
    2. Edit the current $CVPNDIR/conf/httpd.conf file:

      [Expert@HostName:0]# vi $CVPNDIR/conf/httpd.conf
    3. Add the following line:

      CoreDumpDirectory /var/log/dump/usermode
    4. Restart the Mobile Access:

      [Expert@HostName:0]# cvpnrestart

      Notes:

      • This will restart the cvpnd and httpd processes - all existing Mobile Access connections will be disconnected
    5. If running a version older than R76, then run (refer to sk53363):

      [Expert@HostName:0]# um_core enable
      [Expert@HostName:0]# reboot

    To test that core dump files are indeed created:

    1. Manually crash the httpd process:

      (IMPORTANT: all existing Mobile Access connections will be disconnected)

      [Expert@HostName:0]# kill -11 <httpd pid>

    2. Check if a core dump file was created for the httpd process:

      [Expert@HostName:0]# ls -l /var/log/dump/usermode/httpd*
    3. In addition, the following line should appear in the $CVPNDIR/log/httpd.log file:

      child pid <pid> exit signal Segmentation fault (11), possible coredump in /var/log/dump/usermode


  • Debugging the Gateway side - cvpnd process

    To start the debug:

    1. It is recommended to enable the httpd debug every time you collect the cvpnd debug.

      Important: The cvpnrestart command will stop the cvpnd debug. So you need to initiate the httpd debug before the cvpnd debug.
    2. Remove the rotated logs $CVPNDIR/log/cvpnd.elg.*, if they exist:

      [Expert@HostName:0]# rm -i $CVPNDIR/log/cvpnd.elg.*
    3. Empty the log $CVPNDIR/log/cvpnd.elg file:

      [Expert@HostName:0]# echo '' > $CVPNDIR/log/cvpnd.elg

      IMPORTANT: Do not delete this log file!
    4. Start the debug:

      [Expert@HostName:0]# cvpnd_admin debug set TDERROR_ALL_ALL=5

    To stop the debug:

    [Expert@HostName:0]# cvpnd_admin debug off

  • Debugging the Gateway side - vpnd process

    The debug of vpnd process is needed if there is a problem with SNX / SecureClient / EndpointConnect client.

    To start the debug:

    1. Remove rotated logs $FWDIR/log/vpnd.elg.*, if they exist:

      [Expert@HostName:0]# rm -i $FWDIR/log/vpnd.elg.*
    2. Empty the log file $FWDIR/log/vpnd.elg:

      [Expert@HostName:0]# echo '' > $FWDIR/log/vpnd.elg

      IMPORTANT: Do not delete this log file!

    3. Make sure the logs are not corrupted by the log rotation issue. Read sk52120 (Log files can become corrupted when running debug of Check Point daemons on SecurePlatform / Gaia OS) about this issue.

    4. Start the debug:

      • For any other client except SNX:

        [Expert@HostName:0]# vpn debug on ALL_ALL=5
      • For SNX client:

        [Expert@HostName:0]# vpn debug on slim=5

    To stop the debug:

    [Expert@HostName:0]# vpn debug off

  • Debugging the Gateway side - cvpnproc process

    The cvpn process uses the cvpnproc process for asynchronous jobs that may take a long time to complete. This process is responsible for sending SMS, e-mails and access to files via file share.

    Currently, there is no easy way to collect the cvpnproc debugs. The only option is to start it in debug mode.

    To start the debug:

    1. Stop Mobile Access services:

      [Expert@HostName:0]# cvpnstop
    2. Empty the log file $CVPNDIR/log/cvpnproc.elg:

      [Expert@HostName:0]# echo '' > $CVPNDIR/log/cvpnproc.elg

      IMPORTANT: Do not delete this log file!
    3. Make sure procserver is down:

      [Expert@HostName:0]# ps aux | grep proc

      If procserver is still running, then kill it manually:
      [Expert@HostName:0]# kill -KILL <PID_of_procserver>

    4. Set the debug environment variable:

      [Expert@HostName:0]# export TDERROR_ALL_ALL=5
    5. Start the procserver process in the background:

      [Expert@HostName:0]# cvpnproc $CVPNDIR/log/cvpnproc.elg $CVPNDIR/conf/cvpnproc.C &
    6. Start the Mobile Access services:

      [Expert@HostName:0]# cvpnstart

    To stop the debug:

    1. Stop Mobile Access services:

      [Expert@HostName:0]# cvpnstop
    2. Kill the procserver:

      [Expert@HostName:0]# ps aux | grep proc
      [Expert@HostName:0]# kill -KILL <PID_of_procserver>
    3. Start the Mobile Access services:

      [Expert@HostName:0]# cvpnstart


  • Debugging the Gateway side - pinger process

    The Pinger process was introduced in R75.40 and its main purpose is to reduce the number of httpd processes performing ActiveSync. By default, all ActiveSync traffic in Mobile Access Blade is done via the Pinger process.

    If you suspect the problem is in Pinger process, then try to disable it.
    Then, the regular httpd processes will handle the ActiveSync.

    Follow these steps:

    1. Backup the current $CVPNDIR/conf/httpd.conf file:

      [Expert@HostName:0]# cp -v $CVPNDIR/conf/httpd.conf $CVPNDIR/conf/httpd.conf_ORIGINAL
    2. Edit the current $CVPNDIR/conf/httpd.conf file:

      [Expert@HostName:0]# vi $CVPNDIR/conf/httpd.conf
    3. Remove the # sign in front of the following line:

      # CvpnUsePinger Off
    4. Save the changes and exit from Vi editor.

    5. Restart Mobile Access services:

      [Expert@HostName:0]# cvpnrestart

      (This will restart the cvpnd and httpd processes - all existing Mobile Access connections will be disconnected)

    To start the debug:

    Important: Since Jumbo Hotfix Accumulator for R77.30 Takes 2xx and R80.10, there are two 'Pinger' processes running on the gateway.

    One is simply called 'Pinger' and handles WebSocket and Outlook Anywhere traffic.

    The other is called 'IdlePinger' and handles OWA and ActiveSync 'push mail' functionality.

    All 'PingerAdmin' commands below remain the same for 'Pinger'.

    For 'IdlePinger', add the word 'idle' as the first argument of each 'PingerAdmin' command.

    For example: PingerAdmin idle debug on

    1. Verify that Pinger process is running:

      [Expert@HostName:0]# ps aux | grep Pinger
    2. Enable debug for relevant users:

      [Expert@HostName:0]# PingerAdmin debug users <user1>,<user2>,<user3>
    3. Set the debug level:

      [Expert@HostName:0]# PingerAdmin debug set TDERROR_ALL_Pinger=3
      or
      [Expert@HostName:0]# PingerAdmin debug set TDERROR_ALL_ALL=5
    4. Set the debug type:

      [Expert@HostName:0]# PingerAdmin debug type All
    5. Delete all files from $CVPNDIR/log/trace_log/ directory:

      [Expert@HostName:0]# rm -i $CVPNDIR/log/trace_log/*

      Note: Do not delete the directory itself!
    6. Enable trace log:

      Warning: This might print passwords to local files!

       

      [Expert@HostName:0]# PingerAdmin debug trace on
    7. Empty the log file $CVPNDIR/log/Pinger.log:

      [Expert@HostName:0]# echo '' > $CVPNDIR/log/Pinger.log

      IMPORTANT: Do not delete this log file!
    8. Start the debug:

      [Expert@HostName:0]# PingerAdmin debug on

    To stop the debug:

    1. Stop debug:

      [Expert@HostName:0]# PingerAdmin debug off
    2. Disable the trace log:

      [Expert@HostName:0]# PingerAdmin debug trace off
    3. Reset the debug:

      [Expert@HostName:0]# PingerAdmin debug reset

 

(2) Debugging MAB in Unified Policy Mode

How to debug Authorization in the kernel - Rulebase matching

More comprehensive:

fw ctl debug -buf 16384; fw ctl debug -m UP + all; fw ctl kdebug -t -f >& /var/tmp/kernel_debug.txt

Less comprehensive, including only MAB modules, without rulebase matching debugging:

fw ctl debug -buf 16384; fw ctl debug -m UP + mab info; fw ctl kdebug -t -f >& /var/tmp/kernel_mab.txt

Stop debugging:

fw ctl debug 0

Important Note: Debugging MAB in Unified Policy Mode also requires debugging cvpnd process.

(3) Debugging the user side

  • Debugging the user side - Problems with web application

    1. Install the Fiddler web debugger (http://www.telerik.com/fiddler)
    2. Make sure that you enabled https capturing and decoding (http://docs.telerik.com/fiddler/configure-fiddler/tasks/decrypthttps)
    3. Make sure to empty the browser cache before starting the debug.
    4. Collect the same capture on a PC connected to the internal network (without Mobile Access Blade in the middle).

    Related solutions:



  • Debugging the user side - Problems with Secure Workspace (SWS)

    To enable the SWS debug:

    1. Go to Start menu - Run... - paste the following command - click on OK:
      "%WINDIR%\system32\rundll32.exe" sysdm.cpl,EditEnvironmentVariables

      Alternatively:

      1. Desktop - right-click on the "My Computer" icon - click on "Properties"
      2. Windows Vista/7/2012: In the left pane, click on "Advanced system settings".
      3. Go to "Advanced" tab.
      4. At the bottom, click on "Environment Variables..." button.
    2. In the "System variables" section, add a new variable with the name ISWLOG and the desired value:

      Logged category Value
      Success 0 (most verbose)
      Info 1
      Warning 2
      Error 3
      Important 4
      Dump 5 (least verbose)
    3. Verify that the new environment variable was applied - run this command in Windows Command Prompt:

      C:\> set | findstr ISWLOG

      Output should show "ISWLOG=<integer_value>"
    4. Reproduce the relevant issue.

    5. The debug output file(s) will appear in %Temp%\IswTmp\Logs\ directory.

    To turn off debug output:

    1. Remove the variable "ISWLOG" from the list of "System variables".

    2. Verify that the environment variable was removed - run this command in Windows Command Prompt:

      C:\> set | findstr ISWLOG

      Output should be empty


  • Debugging the user side - Problems with Native Applications

    In order to fully debug an SNX session, debug output must be simultaneously enabled on the SNX client and Mobile Access Gateway before the issue is reproduced. The following are the instructions for enabled the debug for each side of the connection.

    On the Mobile Access Gateway

    1. Start the debug of vpnd process as described in the "Debugging the Gateway side - vpnd process" section above.

    2. Start the VPN kernel debug:

      [Expert@HostName:0]# fw ctl debug 0
      [Expert@HostName:0]# fw ctl debug -buf 32000
      [Expert@HostName:0]# fw ctl debug -m fw + crypt
      [Expert@HostName:0]# fw ctl debug -m fw
      [Expert@HostName:0]# fw ctl debug -m VPN + tcpt
      [Expert@HostName:0]# fw ctl debug -m VPN
      [Expert@HostName:0]# fw ctl kdebug -T -f > /var/log/snx_debug.txt

    SNX client in Network Mode on Windows OS

    1. Change the value of the following registry key to "5":

      HKEY_CURRENT_USER > Software > CheckPoint > SSL Network Extender > parameters > dbg level
    2. Change the value of the following registry key to "5":

      HKEY_LOCAL_MACHINE > System > ControlSet001 > Services > cpextender > parameters > dbg_level
    3. Restart the SNX service by running the following commands in Windows Command Prompt:

      net stop cpextender
      net start cpextender
    4. Two debug output files will be created:

      • C:\Program Files\checkpoint\SSL Network Extender\slimsvc.log
      • %appdata%\check point\extender\activex.log

    SNX client in Application Mode on Windows OS

    1. Go to Start menu - Run... - paste the following command - click on OK:
      "%WINDIR%\system32\rundll32.exe" sysdm.cpl,EditEnvironmentVariables

      Alternatively:

      1. Desktop - right-click on the "My Computer" icon - click on "Properties"
      2. Windows Vista/7/2012: In the left pane, click on "Advanced system settings".
      3. Go to "Advanced" tab.
      4. At the bottom, click on "Environment Variables..." button.
    2. In the "System variables" section, add a new variable with the name TDERROR_ALL_ALL and the value 5.

    3. Verify that the new environment variable was applied - run this command in Windows Command Prompt:

      C:\> set | findstr TDERROR_ALL_ALL

      Output should show "TDERROR_ALL_ALL=5"
    4. Two debug output files will be created:

      • %TEMP%\SNXAC\stap.txt
      • %TEMP%\SNXAC\STALog.txt

    SNX client in Network Mode on Linux OS

    1. SNX Network Mode may be run from the command line in debug mode:

      snx -s <server> -u <user_name> -g
    2. The debug output file will be created in $HOMEDIR/snx.elg

    SNX client in Network Mode on Mac OS X

    1. In Terminal, create a file in the user's home directory named .snxrc:

      touch ~/.snxrc
    2. Add the line "debug yes" to the ~/.snxrc file:

      echo 'debug yes' > ~/.snxrc
      cat ~/.snxrc
    3. The debug output file will be created in $HOMEDIR/snx.elg

    SNX client in Application Mode on Linux OS and Mac OS X

    1. Create a file named /tmp/stadebug:

      touch /tmp/stadebug
    2. Two debug output files will be created:

      • /tmp/stalog.txt
      • /tmp/SNXAC/stap.elg (always created, regardless of the /tmp/stadebug file)


  • Thin-client deployment mechanism (C-Shell)

    C-Shell has a JavaScript component and a binary component that is either ActiveX or Java, depending on the client machine's environment. In order to debug each of the components, follow the instructions below:

    In order to debug the JavaScript component

    This is needed if ActivX or Java component is not launched correctly by the portal.

    1. Backup the current $CVPNDIR/phpincs/SNXController.php file:

      [Expert@HostName:0]# cp -v $CVPNDIR/phpincs/SNXController.php $CVPNDIR/phpincs/SNXController.php_ORIGINAL
    2. Edit the current $CVPNDIR/phpincs/SNXController.php file:

      [Expert@HostName:0]# vi $CVPNDIR/phpincs/SNXController.php
    3. Find the following line (approximately, line 162):

      ////////////////DEBUGGING UTILITY///////////////////
    4. Change the Function.DEBUG line:

      from:

      Function.DEBUG=Function.DEBUG_MODE_OFF;

      to:

      Function.DEBUG=Function.DEBUG_MODE_ON_ALL;
    5. Save the changes and exit from Vi editor.

    In order to debug the ActiveX component

    1. Change the value of the following registry key to "5":

      HKEY_CURRENT_USER > Software > CheckPoint > SNX Components Shell > parameters > dbg_level

      If dbg_level is missing, then create it (the type is "REG_DWORD").
    2. The debug output file is %temp%\CShell\SNXComponentsShell.log

      If the debug file is missing, then make sure the following registry key exists:

      HKEY_CURRENT_USER > Software > CheckPoint > SNX Components Shell > parameters > dbg_file

      Create it (the type is "REG_SZ"), if needed, and set its value to %temp%\CShell\SNXComponentsShell.log.

       

    In order to debug the Java component

    Java is debugged according to the JVM installed on the client machine. Usually, the JVM is either Microsoft's or Oracle's.

    • For Microsoft's JVM:
      From Internet Explorer's main menu, go to Tools > Options > Advanced > Microsoft VM, and check all the Java debugging related checkboxes.
    • For Oracle's JVM:
      Go to Start menu > Settings > Control Panel > Java > Advanced, and check all debugging related checkboxes (especially in Java Console and Debugging).

 

(4) Debugging Policy Installation

Recommended Documents and Solutions

Show / Hide this section

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment