Mobile Access Applications

Introduction to Applications for Clientless Access

Giving remote users access to the internal network exposes the network to external threats. A balance needs to be struck between connectivity and security. In all cases, strict authentication and authorization is needed to ensure that only the right people gain access to the corporate network. Defining an application requires deciding which internal LAN applications to expose to what kind of remote user.

Mobile AccessClosed Check Point Software Blade on a Security Gateway that provides a Remote Access VPN access for managed and unmanaged clients. Acronym: MAB. provides the remote user with access to the various corporate applications, including, Web applications, file shares, Citrix services, Web mail, and native applications.

File Shares

A file share is a collection of files, made available across the network by means of a protocol that enables actions on files, including opening, reading, writing, and deleting files across the network.

Configuring File Shares

To create a new File Share Application:

  1. In SmartConsoleClosed Check Point GUI application used to manage a Check Point environment - configure Security Policies, configure devices, monitor products and events, install updates, and so on., click Objects > Object Explorer (Ctrl+E).

  2. Click New Custom Application/Site > Mobile Application > File Share.

    The File Share Application window opens.

File Share Application - General Properties Page

Go to the General Properties page of the File Share Application object. Name is the name of the 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. object.

File Share Application - Authorized Locations Page

  1. Go to the Authorized Locations page of the File Share Application object.

    This page lets you configure the file shares that users are authorized to access. These settings take effect whenever a user attempts access, no matter what interface is used, whether by manually typing a path in the portal, browsing using the file viewer, clicking a user-defined file favorite, or clicking the predefined file favorite path defined by the administrator in the Link in Portal page.

  2. Fill in the fields on the page:

    • Servers are the machine(s) or DNS Name(s) on which the file server is hosted. Choose either a single Host or DNS name, or Multiple hosts.

    • Allow access to any file share gives the users access to all locations on the file server defined in Servers.

    • Allow access to specific file shares restricts user access to specific shares. For example My_Share. Use only the name of a share, such as My_share, $$user, or My_share$, without any slashes. Do not specify a sub-directory inside a share. The $$user variable represents the name of the currently logged-in user. This variable provides personalized authorization for users. If $$user is defined as a file share, then if the user currently logged-in is alice, she will be allowed access to the share called alice that was defined on the server, such as \\myserver\alice.

    If you configure two or more overlapping file share applications (for example, one for Any Share and one for a specific share on the same host), the application settings that are in effect are undefined.

File Share Application - Link in Portal Page

This page allows you to configure one predefined favorite link. This link is displayed in the Mobile Access Portal. By clicking the link the user is able to directly access the specified path. Note that you must authorize access to this location in the Authorized Locations page.

  1. Go to the Link in Portal page of the File Share Application object.

  2. Fill in the fields on the page:

    • Add a link to this file share in the Mobile Access Portal - If you do not enter a link, users will be able to access the application by manually typing its link in the portal, but will not have a pre-configured link to access it.

    • Link text (multi-language) - Shows in the Mobile Access Portal. It can include $$user, which represents the user name of the currently logged-in user. If more than one link is configured with the same (case insensitive) name, only one of them will be shown in the portal.

    • Path - The full file path that the link will attempt to access, specified using UNC syntax. It can be either a location of a share, or any path under the share. Can include $$user, which represents the user name of the currently logged-in user. For example, a path that is defined as \\host\Pub\users\$$user appears for user alice as \\host\Pub\users\alice and for user Bob as \\host\Pub\users\Bob.

      Note - The host defined here is the same host that is defined in the Authorized Locations page. The IP address of the host is resolved by the DNS Server that is defined on Mobile Access (not by the Mobile Access management).

    • Tooltip (multi-language) - Gives additional information. It can include $$user, which represents the user name of the currently logged-in user. The text appears automatically when the user holds the cursor over the link. It disappears when the user clicks a mouse button or moves the cursor away from the link.

File Share Application - Single Sign-On Page

To configure Single Sign On:

  1. Go to the Single Sign On page of the File Share Application object.

  2. Select Turn on single Sign On for this application.

  3. Configure the sign on method for the application. The default option is:

    Prompt the users for their credentials and store them for future use

File Share Application - Protection Level Page

  1. Go to the Protection Level page of the File Share Application object.

  2. Fill in the fields on the page:

    Security Requirements for Accessing this Application allows you to:

Completing the Configuration of the File Share Application

  1. Go to the Policy page of the Mobile Access tab.

  2. In the Policy page, make rules to associate:

    • User groups.

    • Applications that the users in those user groups are allowed to access.

    • Install On are the Mobile Access Security Gateways and Clusters that users in those user groups are allowed to connect to.

  3. Click Save and then close SmartDashboard.

  4. In SmartConsole, install the policy.

Using the $$user Variable in File Shares

You can configure personalized user locations that use the login name of the currently logged in user. To do this, use the Mobile Access Applications wherever you need to specify the name of the user. The $$user variable is resolved during the Mobile Access session to the login name of the currently logged-in user.

For example, a UNC file path that is defined as \\host\Pub\$$user is resolved for user Alice as \\host\Pub\Alice and for user Bob as \\host\Pub\Bob.

Protection Levels

Protection Levels are predefined sets of security settings that offer a balance between connectivity and security. Protection Levels allow Mobile Access administrators to define application protections for groups of applications with similar requirements.

Mobile Access comes with three default Protection Levels - Normal, Restrictive, and Permissive. You can create additional Protection Levels and change the protections for existing Protection Levels.

Using Protection Levels

You can include Protection Levels in the definition of most Mobile Access application types. Each application can have a Protection Level associated with it. A single Protection Level can be assigned for all native applications.

When you define an application, in the Protection Level page of the application object, you can choose:

Security Requirements for Accessing this Application:

  • This application relies on the security requirements of the gateway
    Rely on the Security Gateway security requirement. Users who have been authorized to the portal, are authorized to this application. This is the default option.

  • This application has additional security requirements specific to the following protection level
    Associate the Protection Level with the application. Users are required to be compliant with the security requirement for this application in addition to the requirements of the portal.

Defining Protection Levels

To access the Protection Level page from the Mobile Access tab:

  1. In SmartConsole, select Security Policies > Shared Policies > Mobile Access and click Open Mobile Access Policy in SmartDashboard.

    SmartDashboard opens and shows the Mobile Access tab.

  2. From the navigation tree click Additional Settings > Protection Levels page from the navigation tree.

  3. Click New to create a new Protection Level or double-click an existing Protection Level to modify it.

    The Protection Levels window opens, and shows the General Properties page.

To access the Protection Level page from a Mobile Access application:

  1. In SmartConsole, click Objects > Object Explorer (Ctrl+E). Or in SmartDashboard, Mobile Access tab, go to Applications > Application type.

  2. Search for the Mobile Access application.

  3. Double-click the application.

  4. From the navigation tree, select Additional Setting > Protection Level.

  5. To create a new Protection Level, select Manage > New.

  6. To edit the settings of a Protection Level, select the Protection Level from the drop down list and then select Manage > Details.

    The Protection Levels window opens, and shows the General Properties page.

To configure the settings for a Protection Level:

  1. From the General Properties page in the Protection Level window, enter the Name for the Protection Level (for a new Protection Level only).

  2. In the navigation tree, click Authentication and select one or more authentication methods from the available choices. Users accessing an application with this Protection Level must use one of the selected authentication schemes.

  3. If necessary, select User must successfully authenticate via SMS.

  4. In the navigation tree, click Endpoint Security and select one or both of these options:

    • Applications using this Protection Level can only be accessed if the endpoint machine complies with the following Endpoint compliance policy. Also, select a policy. This option gives access to the associated application only if the scanned client computer complies with the selected policy.

    • Applications using this Protection Level can only be accesses from within Secure Workspace. This option requires Secure Workspace to be running on the client computer.

  5. Click OK to close the Protection Level window

  6. Install the policy.

Web Applications

A Web application can be defined as a set of URLs that are used in the same context and are accessed via a Web browser, for example, inventory management or human resource management.

Mobile Access supports browsing to websites that use HTML and JavaScript.

Browsing to websites with VBScript, Java, or Flash elements that contain embedded links is supported using SSL Network Extender, by defining the application as a native application.

Additionally, some sites will only work through a default browser, and therefore cannot be defined as a Web application. If that is the case, use a native application.

Web Applications of a Specific Type

It is possible to configure a Web Application with a specific type as iNotes (Domino Web Access) application or as an Outlook Web Access application.

iNotes

IBM iNotes (previously called Lotus Domino Web Access) is a Web application that provides access to a number of services including mail, contacts, calendar, scheduling, and collaboration services.

Domino Web Access requires its files to be temporarily cached by the client-side browser. As a result, the endpoint machine browser caching settings of the Mobile Access Protection Level do not apply to these files. To allow connectivity, the cross site scripting, command injection and SQL injection Web Intelligence protections are disabled for Domino Web Access.

Note - To make iNotes work through the Mobile Access Portal, you must work with Mobile Access Applications.

These iNotes features are not supported:

  • Working offline

  • Notebooks with attachments.

  • Color button in the Mail Composition window.

  • Text-alignment buttons in the Mail Composition window.

  • Decline, Propose new time and Delegate options in meeting notices.

  • Online help- partial support is available.

Outlook Web Access

Outlook Web Access (OWA) is a Web-based mail service, with the look, feel and functionality of Microsoft Outlook. Mobile Access supports Outlook Web Access versions 2000, 2003 SP1, 2007, 2010, 2013, and 2016.

Configuring Mobile Applications

You can use SmartConsole to create and configure the settings for all the Mobile Access application objects. However, there are some Mobile Access settings that you can configure only from SmartDashboard.

To create a new Mobile application in SmartDashboard:

  1. In SmartConsole, select Security Policies > Shared Policies > Mobile Access and click Open Mobile Access Policy in SmartDashboard.

    SmartConsole opens and shows the Mobile Access tab.

  2. From the navigation tree click Applications.

  3. Click the applicable application category.

  4. Click New.

To create a new Mobile application in SmartConsole:

  1. In SmartConsole, click Objects > Object Explorer (Ctrl+E).

  2. Click New > Custom Application/Site > Mobile Application and select the Mobile application type.

    The Mobile application window opens.

Web Application - General Properties Page

Use the General Properties page to configure the basic settings for the Web Application.

Domino Web Access requires its files to be temporarily cached by the client-side browser. As a result, the endpoint machine browser caching settings of the Mobile Access Endpoint Compliance Profile do not apply to these files.

To allow connectivity, the cross site scripting, command injection and SQL injection Web Intelligence protections are disabled for Domino Web Access.

  • Name is the name of the application. Note that the name of the application that appears in the user portal is defined in the Link in Portal page.

  • This application has a specific type - Select this option if the Web application is of one of the following types:

    • Domino Web Access is a Web application that provides access to a number of services including mail, contacts, calendar, scheduling, and collaboration services.

    • Outlook Web Access (OWA) is a Web-based mail service, with the look, feel and functionality of Microsoft Outlook. OWA functionality encompasses basic messaging components such as email, calendaring, and contacts.

Web Application - Authorized Locations Page

Use the Authorized Locations page to define the locations that can access the Web Application.

For an application that is defined as an Outlook Web Access application, the following are set as the allowed directories:

  • Private Mailboxes: /exchange/

  • Graphics and Controls: /exchweb/

  • Client access: /owa/

  • Public Folders: /public/

When two or more overlapping applications are configured (for example, one for any directory and one for a specific directory on the same host), it is undefined which application settings take effect. If one of the overlapping applications is OWA or iNotes, it will take precedence.

  • Host or DNS name on which the application is hosted.

  • Allow access to any directory gives the user access to all locations on the application server defined in Servers.

  • Allow access to specific directories restricts user access to specific directories. For example /finance/data/. The pathscan include $$user, which is the name of the currently logged-in user.

  • Application paths are case sensitive improves security. Use this setting for UNIX-based Web servers that are case sensitive.

  • Services that are allowed are typically HTTP for cleartext access to the Web application, and HTTPS for SSL access.

    On Security Gateways R77.20 and higher, you can select which SSL version to use with HTTPS. Select an option from the list. The default is Automatic.

  • Advanced lets you select multiple services.

Web Application - Link in Portal Page

Use the Link in Portal page to configure a link to the Web Application in the Mobile Access user portal.

  • Add a link to this Web application in the Mobile Access Portal - If you do not enter a link, users will be able to access the application by typing its URL in the user portal, but will not have a pre-configured link to access it.

  • Link text (multi-language) - Shows in the Mobile Access Portal. Can include $$user, which represents the user name of the currently logged-in user. If more than one link is configured with the same (case insensitive) name, only one of them will be shown in the portal.

  • URL - The link to the location of the application. Can include $$user, which represents the user name of the currently logged-in user. For example, a URL that is defined as http://host/$$user appears for user aa as http://host/aa and for user bb as http://host/bb.

  • Tooltip (multi-language) - Gives additional information. It can include $$user, which represents the user name of the currently logged-in user. The text appears automatically when the user holds the cursor over the link. It disappears when the user clicks a mouse button or moves the cursor away from the link.

Web Application - Protection Level Page

Use the Protection Level page to choose the protection level for Web applications, and configure how browser caching is configured.

Security Requirements for Accessing this Application:

  • This application relies on the security requirements of the gateway

    Rely on the Security Gateway security requirement. Users who have been authorized to the portal, are authorized to this application. This is the default option.

  • This application has additional security requirements specific to the following protection level

    Associate the Protection Level with the application. Users are required to be compliant with the security requirement for this application in addition to the requirements of the portal.

Browser Caching on the Endpoint Machine - Control caching of web application content in the remote user's browser.

  • Allow caching of all content - Recommended setting for Hostname Translation, method of Link Translation. ActiveX and streaming media will use Hostname Translation.

  • Allow caching of these content types - Select type of web application content to cache: images, scripts, HTML.

  • Prevent caching of all content - Improves security for remote users who access a Web Application from a workstation that is not under their full control. Personal data is not stored on the workstation. Be aware! This setting prevents files that require an external application (for example, MS Office files) from opening. It can cause some applications to malfunction, if the application requires caching.

Configuring Web Content Caching

Protection Levels let administrators prevent browsers from caching Web content. The caching feature in most browsers presents a security risk because cache contents are easily accessible to hackers.

When the Prevent caching of all content option is enabled, users may not be able to open files that require an external viewer application (for example, a Word or PDF file). This requires the user to first save the file locally.

To let users open external files:

  1. Set the Protection Level to Allow caching of all content.

  2. Add Microsoft Office documents to the HTML caching category.

    1. Run: cvpnstop

    2. Backup the Apache configuration file: $CVPNDIR/conf/http.conf

    3. In this file, uncomment the CvpnCacheGroups directives related to Microsoft Office documents.

    4. In clusterClosed Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. setups, repeat these steps for all cluster members.

    5. Run: cvpnstart

  3. Install Policy.

Web Application - Link Translation Page

Use the Link Translation page to configure how the Web Application converts the internal URLs to valid links for the Internet.

  • Use the method specified on the gateway through accessing this application - Uses the method configured in the: Additional Settings > Link Translation page, in the Link Translation Settings on Gateways section.

  • Using the following method - Select the Mobile Access Applications that this application uses:

    • Path Translation - Default for new installations.

    • URL Translation - Supported by the Mobile Access Security Gateway with no further configuration

    • Hostname Translation - Mobile Access Applications.

Using the Login Name of the Currently Logged in User

Mobile Access applications can be configured to differ depending on the user name of the currently logged-in user. For example, portal links can include the name of the user, and a file-share can include the user's home directory. For this purpose, the $$user directive is used. During a Mobile Access session, $$user resolves to the login name of the currently logged-in user.

For such personalized configurations, insert the $$user string into the relevant location in the definitions of Web applications, file shares, and native applications.

For example, a Web application URL that is defined as http://host/$$user appears for user aa as http://host/aa and for user bb as http://host/bb.

If the user authenticates with a certificate, $$user resolves during the user's login process to the user name that is extracted from the certificate and authorized by the directory server.

For its use in configuring File Shares, see the "Mobile Access Applications" section.

Completing the Configuration of the Web Application

To complete the configuration, add the Web application to a policy ruleClosed Set of traffic parameters and other conditions in a Rule Base (Security Policy) that cause specified actions to be taken for a communication session. and install policy from SmartConsole.

For Unified Access Policy, see Mobile Access and the Unified Access Policy.

For legacy policy, see Getting Started with Mobile Access.

Configuring a Proxy per Web Application

It is possible to define an HTTP or HTTPS proxy server per Web application. This configuration allows additional control of access to Web resources allowed to users. For configuration details see sk34810.

Configuring Mobile Access to Forward Customized HTTP Headers

For proprietary Web applications that do not support a standard HTTP authentication method, the CvpnAddHeader directive can be used to forward end-user credentials (user name and IP address) that are carried in the HTTP header.

To configure Mobile Access to automatically forward a customized HTTP header, with a specified value, such as the user name or the client IP address:

  1. Edit $CVPNDIR/conf/http.conf. For a Mobile Access cluster, edit all members.

  2. Add or edit the line containing CvpnAddHeader according to the following syntax:

    CvpnAddHeader "customized_header_name" "customized_header_value"

You can use the following two macros for the customized_header_value string:

  • $CLIENTIP, which is resolved to the actual IP address of the end-user's client machine.

  • $USER NAME, which is resolved to the user name entered as a credential in the login page.

Examples:

  • CvpnAddHeader "CustomHTTPHeaderName" "MyCustomHTTPHeaderValue"

  • CvpnAddHeader "CustomIPHeader" "$CLIENTIP"

  • CvpnAddHeader "CustomUsernameHeader" "$USER NAME"

Web Application Features

Mobile Access contains various features to make working with Web Applications efficient and secure. Some of these are described in the following sections.

Reuse TCP Connections

The Reuse TCP Connections feature enhances performance by letting the network reuse TCP connections that would otherwise be closed. To enable Reuse TCP Connections, make a change to the Security Gateway configuration files.

>

Best Practice - We strongly recommend that you back up configuration files before you make changes.

In the General Properties page of a Web application, there is a section called Application Type. In this section, you can define the application as having a specific type, either Domino Web Access or Outlook Web Access.

In previous versions, if you chose one of these Application Type options, the TCP connections for the application are closed after each request. However, if you enable Reuse TCP Connections, the connections are reused. This leads to a boost in performance as the three-way handshake does not have to be renewed and the optimized authorization cache feature can be fully utilized.

By default, Reuse TCP Connections is enabled.

To turn off Reuse TCP Connections:

  1. Change this line in the $CVPNDIR/conf/http.conf configuration file:

    from:

    CvpnReuseConnections On

    to:

    CvpnReuseConnections Off

  2. Save the changes.

  3. Run the cvpnrestart command to activate the settings.

If your Mobile Access Security Gateway is part of a cluster, make the same changes on each cluster memberClosed Security Gateway that is part of a cluster..

Website Certificate Verification

Mobile Access lets you validate website security certificates, and either warn the user about problems, ignore any problems, or block websites with certificate problems.

By default, Website Certificate Verification is set to "monitor" this means that a record is entered in SmartLog and there is no effect on end-users. The setting can also be set to "warn" so that users are alerted to any potential security issues and can then decide what steps to take. The setting can also be set to "block," which blocks any website that has a problem with its SSL server certificate, or "ignore", to ignore any issues with a website's security. All settings create a record in SmartLog except for "ignore".

You must restart Mobile Access services after changing the website certificate verification setting.

You can configure Website Certificate Verification per Security Gateway and per application.

Website Certificate Verification is configured in Database Tool (GuiDBEdit Tool) (see sk13009).

To change the Website Certificate Verification default behavior for Web applications on the Security Gateway:

  1. In Database Tool (GuiDBEdit Tool), go to the Network Objects > network_objects > the Security Gateway object

  2. In the bottom pane, go to the Connectra_settings section.

  3. Search for:

    certificate_verification_policy

  4. Enter block, warn, monitor, or ignore as the value.

    The default setting is monitor.

If your internal web servers do not use a commonly known certificate (such as an internal CA), then either change the default setting, or add a trusted Certificate Authority for Website certification to Mobile Access.

If the Mobile Access Security Gateway is part of a cluster, be sure to make the same changes on the cluster object table.

To change the Website Certificate Verification default behavior per Web application:

  1. In Database Tool (GuiDBEdit Tool), go to the Network Objects > network_objects > the Web application object

  2. In the bottom pane, search for certificate_verification_policy.

  3. Type block, warn, or ignore as the value.

  4. For the use_gateway_settings parameter:

    • Enter true to use the Security Gateway settings.

    • Enter false to use the setting configured for the application.

  5. Save the changes in Database Tool (GuiDBEdit Tool) and close it.

  6. Install policy on the Security Management ServerClosed Dedicated Check Point server that runs Check Point software to manage the objects and policies in a Check Point environment within a single management Domain. Synonym: Single-Domain Security Management Server..

Adding a Trusted Certificate Authority for Website Certification

You can add specific Certificate Authorities that Mobile Access does not recognize by default, such as your organization's internal CA, to your trusted certificates. The list of default Certificate Authorities recognized by Mobile Access is the same as the list recognized by common browsers. To add CAs to this list, copy the certificate to a .pem file and then move the file to your Mobile Access Security Gateway. If your Mobile Access Security Gateway is part of a cluster, be sure to make the same changes on each cluster member.

Saving a Trusted Certificate in .pem Format

The procedure for saving a trusted certificate as a .pem file is similar for all browsers and versions with slight differences. Below is an example procedure, using Internet Explorer 7.0.

To save a trusted certificate in .pem format using Internet Explorer 7.0:

  1. Using your browser, View the certificate of a website that uses the Certificate Authority you want to add. Be sure to choose the Certificate Authority certificate: In the Certification Path tab, choose the CA and click View Certificate.

  2. Select the Details tab and click Copy to File.

    The Certificate Export Wizard opens.

  3. In the Export File Format page, select Base-64 encoded.

  4. In the File to Export page, type the File name under which you want to save the certificate information with a .pem file extension.

  5. Click Finish.

Moving the CA Certificate to the Mobile Access Security Gateway

To move the CA Certificate to the Mobile Access Security Gateway:

  1. Move the .pem file to your Mobile Access Security Gateway, into a directory called:

    $CVPNDIR/var/ssl/ca-bundle/

  2. Run the following command: rehash_ca_bundle

    The Certificate Authority should now be accepted by the Mobile Access Security Gateway without any warnings. You do not need to restart Mobile Access services for the change to take effect.

Deleting a Certificate Authority from a Trusted List

To delete a Certificate Authority from your trusted Certificate Authorities:

  1. Delete the .pem file from the $CVPNDIR/var/ssl/ca-bundle/ file of the Mobile Access Security Gateway.

  2. Run the following command: rehash_ca_bundle

    You do not need to restart Mobile Access services for the change to take effect.

Link Translation

Link Translation is the process by which Mobile Access converts internal URLs to public URLs that are valid on the Internet. In this way internal resources become accessible through all internet browsers.

Mobile Access converts HTTP requests into secure HTTPS requests and changes the port to 443. To accomplish this, Mobile Access translates the source URL into an HTTPS URL that routes traffic to its destination through the Mobile Access Security Gateway. The translated URL is returned to the browser and is shown to users.

Mobile Access supports different methods of Link Translation:

  • Path Translation (PT) - The default method that works with most web applications.

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

  • Hostname Translation (HT) - This method is faster and supports a wider range of Web applications than PT. It requires additional configuration and a certificate.

  • Client-side Link Translation - Works on the end user's browser through the Mobile Access browser plugin OR on a Wrapped Mobile application. It translates each request sent through Mobile Access on the client side.

How Translated URLs Appear in a Browser

A translated URL appears to users in their browser differently, for the different Link Translation methods.

Method

Translated http://www.example.com/path

UT

https://ssl.example.com/Web/path,CVPNHost=www.example.com,CVPNProtocol=http

HT

https://c-ds1q-itfgppae7oq.ssl.example.com/path

Note that the seemingly random character string, c-ds1q-itfgppae7oq, represents the destination URL.

PT

https://ssl.example.com/PT/http://www.example.com/path

Client-side

https://ssl.example.com/PT/http://www.example.com/path

SmartDashboard Configuration of Link Translation

You can configure Link Translation to meet the requirements of the application (a web application or a Citrix service) or of the Security Gateway through which the applications are accessed. For example, you can configure one Mobile Access application to work with URL Translation, while all other applications supplied by the Security Gateway use Path Translation.

  • You can set the default Link Translation method for all applications of a Security Gateway - Only applications that have a different method configured will not use the default method.

  • You can set the default Link Translation method for an application - This Web application uses the selected method, even if another method is default on the Security Gateways.

  • You can configure which domains are translated.

Configuring PT

Path Translation (PT) is selected by default for newly installed Security Gateways.

To configure PT as default method for Security Gateways:

  1. In SmartConsole, right-click the Security Gateway and select Edit.

    The Security Gateway properties window opens and shows the General Properties page.

  2. From the navigation tree, click Mobile Access > Link Translation.

  3. Under Supported Translation Methods, make sure that Path Translation (always supported) is selected.

  4. Under Default Translation Method, select Path Translation.

  5. Click OK.

To configure PT as default method for an application:

  1. In SmartConsole, click Objects > Object Explorer (Ctrl+E).

  2. Search for the Mobile Access application.

  3. Double-click the application.

    The Web Application window opens.

  4. Click Additional Settings > Link Translation.

    The Link Translation page of the Mobile Access application opens.

  5. Select Use the following method > Path Translation.

  6. Click OK and close the Web Application window

  7. Install the policy.

Configuring UT

URL Translation is supported by all versions of Security Gateways.

To configure UT as default method for Security Gateways:

  1. In SmartConsole, right-click the Security Gateway and select Edit.

    The Security Gateway properties window opens and shows the General Properties page.

  2. From the navigation tree, click Mobile Access > Link Translation.

  3. Under Supported Translation Methods, make sure that URL Translation (always supported) is selected.

  4. Under Default Translation Method, select URL Translation.

  5. Click OK.

To configure UT as default method for an application:

  1. In SmartConsole, click Objects > Object Explorer (Ctrl+E).

  2. Search for the Mobile Access application.

  3. Double-click the application.

    The Web Application window opens.

  4. Click Additional Settings > Link Translation.

    The Link Translation page of the Mobile Access application opens.

  5. Click URL Translation.

  6. Click OK.

  7. Install the policy.

Using Hostname Translation

Hostname Translation enhances security by replacing the destination host name with a seemingly random character string in the URL, as it appears in the client browser.

You must configure the DNS server to resolve wildcard hostnames, to enable HT.

Important - If the DNS server is not configured to resolve wildcard Mobile Access host names, users will be unable to connect to Mobile Access, because the portal changes to a sub-domain: portal.ssl.example.com.

If you use Hostname Translation as your method for link translation, users must enter an FQDN as the portal URL and not an IP address.
Configuring HT

To configure the DNS server for HT:

  1. Add a record to the DNS server, to resolve Mobile Access sub-domains to the Mobile Access IP address: *.domain

    For example, assume ssl.example.com is the Security Gateway. Configure the DNS to resolve *.ssl.example.com to the Security Gateway IP address. This wildcard includes all sub-domains of the parent domain, such as a.ssl.example.com and b.ssl.example.com.

  2. Define the parent domain (ssl.example.com) as a separate DNS record, to resolve Mobile Access IP address.

    This lets users access the Mobile Access Portal directly, with its FQDN.

  3. Server Certificates.

To configure HT as default method for Security Gateways:

  1. In SmartConsole, right-click the Security Gateway and select Edit.

    The Security Gateway properties window opens and shows the General Properties page.

  2. From the navigation tree, click Mobile Access > Portal Settings.

    If this message appears, clear Hostname Translation, for now:

    Hostname Translation requires Portal URL to be defined in the following format: 'https://hostname/'

  3. In Main URL, enter the portal URL of the Mobile Access Security Gateway.

  4. From the navigation tree, click Link Translation.

  5. Under Supported Translation Methods, click Hostname Translation.

  6. Under Default Translation Method, select Hostname Translation.

  7. Click OK.

  8. Install the policy.

To configure HT as default method for an application:

  1. In SmartConsole, click Objects > Object Explorer (Ctrl+E).

  2. Search for the Mobile Access application.

  3. Double-click the application.

    The Web Application window opens.

  4. Click Additional Settings > Link Translation.

    The Link Translation page of the Mobile Access application opens.

  5. Select Use the following method > Hostname Translation.

  6. Click Advanced Hostname Translation Settings.

  7. Select the HTTP Cookies Handling mode:

    • On the gateway - Default. All HTTP cookies that are sent to clients by internal Web servers are stored on Mobile Access, and are not passed on to the client's browser.

    • On the endpoint machine - If the default setting causes the JavaScript (from the internal servers that run on the client browser) that handles HTTP cookies to fail, select this option. Mobile Access passes HTTP cookies to the browser.

  8. Click OK and close the Web Application window.

  9. Install the policy.

Configuring Link Translation Domains in SmartDashboard

A Link Translation domain for Web applications:

  • Improves connectivity to external sites. For example, links to external sites displayed in emails are not broken, because they are not translated by Mobile Access.

  • Reduces the load on the Mobile Access machine, thereby increasing performance.

  • Saves the administrator the trouble of defining all external content as Web applications.

Configure which domains use link translation in SmartDashboard > Mobile Access tab > Additional Settings > Link Translation > Link Translation Domains.

For Security Gateways R77.30, to enable this feature, you must install the R77.30 Add-on.

This option is not supported in Security Gateways lower than R77.30.

To manually configure domains to translate:

  1. In the Mobile Access tab > Additional Settings > Link Translation > Link Translation Domains area, select Manually configure domains to translate.

  2. Click Add Domain to add a whole domain or host (URL) to be translated.

  3. Click Add Exception to configure a part of a domain or host within a domain that will not be translated.

  4. Install policy.

Link Translation Domains

The options are:

  • Translate all domains - This is the default behavior. Link translation is active for all traffic.

  • Manually configure domains to translate - Add internal domains to the list. Only domains on the list are translated. You can also add exceptions from within a domain. We recommend that you use this setting to improve performance. To keep communication secure, make sure all internal domains are on the list.

  • Do not translate any domain - This is relevant for companies that do not have internal domains.

Link Translation with Wrapped Applications

With Client-Side Link Translation with wrapped applications, Check Point Mobile App clients are responsible for link translation for specified, wrapped applications. These applications are wrapped in a security container that gives them secure access to network resources and prevents data leakage.

Wrapped applications are only available with mobile devices and do not show in the Mobile Access Portal.

To use Client-Side Link Translation with wrapped applications, see the App Wrapping Guide.

Link Translation Issues

These Link Translation configuration tips apply to Web applications.

  • For Web sites that use ActiveX and streaming media, configure Mobile Access Web applications to Allow caching of all content. This is configured in the Protection Level page of the Web application.

  • Domain cookies created in JavaScript are not supported. For example, if you create a cookie with this JavaScript code:

    document.cookie=Name=Value; domain=.example.com,

    The client browser cannot send the cookie to Mobile Access and the Web server if Mobile Access is not located under the domain .example.com.

    Note that domain cookies created in HTTP headers are supported, if they are not manipulated by JavaScript code.

  • With Hostname Translation, the URL shown in the client browser is:

    https://<Obscured Destination Host Name>.<Mobile Access FQDN>/path

    The maximum number of characters in each part of the host name (between https:// and the /path) is limited to 63 (see RFC 1034). Therefore, the entire internal host name, including the protocol and the port, Mobile Access Applications.

  • Hostnames displayed in client browsers appear as a seemingly random character string, instead of the complete destination path.

  • If you sign out from Outlook Web Access, Domino Web Access (iNotes), or Microsoft SharePoint, the Mobile Access session can become disconnected.

Citrix Services

Citrix Deployments Modes - Unticketed and Ticketed

Unticketed Mode

In the recommended Unticketed Mode scenario:

  • The remote access user logs into the Mobile Access user portal

  • Using the Mobile Access Web interface, the user is directed to the Citrix Web Interface server and then has access to the Presentation server.

Ticketed Mode

In the Ticketed Mode scenario:

  • The remote access user logs into the Mobile Access user portal.

  • Using the Mobile Access Web interface, the user is directed to the Citrix Web Interface server.

The user logs into the Citrix Web Interface server and is assigned a secure ticket by the Secure Ticket Authority. This ticket allows the user to access the Presentation server once it is verified by the Mobile Access Web Security Gateway.

You do not need to use Secure Ticketing authority (STA) servers because Mobile Access implements its own STA engine.

Configuring Citrix Services

To configure a new Citrix Service:

  1. In SmartConsole, click Objects > Object Explorer (Ctrl+E).

  2. Click New Custom Application/Site > Mobile Application > Citrix Services.

    The Citrix Services window opens.

Before Configuring Citrix Services

The server certificate for Mobile Access must be based on a FQDN (Fully Qualified Domain Name) and issued to the Mobile Access FQDN. For example www.sample.com.

Before you configure Citrix Services, change the Mobile Access server certificate to one that was issued to the FQDN. This is necessary to comply with the Citrix standards for server certificates. Additionally, end-users must browse to Mobile Access using the FQDN that is routable from their network.

Note - Make sure that the certificate is Server Certificates.

If your Web Interface server is configured to deploy ICAClosed Internal Certificate Authority. A component on Check Point Management Server that issues certificates for authentication. Web clients and the Mobile Access server certificate is issued by a private CA, the certificate's public key must be installed on the client side browser for the ICA Web Client to function properly. The Mobile Access certificate public key is located under: $CVPNDIR/var/ssl/server.crt

Citrix Service ? Web Interface page

  1. Go to the Web Interface page of the Citrix Service object.

  2. Fill in the fields on the page:

    • Servers are the machine(s) or DNS Name(s) on which the Web Interface server is hosted. Choose either a single Host or DNS name, or Multiple hosts. In order to keep the environment simple, it is recommended to configure a single Web Interface server per Citrix Application.

    • Services must match the settings on the Web Interface server. Select http or https, as required. Other services are NOT supported.

Citrix Service ? Link in Portal Page

  1. Go to the Link In Portal page of the Citrix Service object.

  2. Fill in the fields on the page:

    • Link text (multi-language) - Shows in the Mobile Access Portal. If more than one link is configured with the same (case insensitive) name, only one of them will be shown in the portal.

    • URL - The link to the location of the application, or to a sub-directory of the application.

    • Tooltip (multi-language) - Gives additional information. The text appears automatically when the user holds the cursor over the link. It disappears when the user clicks a mouse button or moves the cursor away from the link.

Citrix Service ? STA Servers Page

  1. Go to the STA servers page of the Citrix Service object.

  2. Get the Host from the current settings on the Web Interface (WI) server.

  3. Get the STA ID from the Secure Ticketing Authority (STA) servers.

Note - Mobile Access implements its own Secure Ticketing authority (STA) engine. STA servers are not necessary.

To get the host name or IP address:

  1. Login to the Web Interface Citrix administration page.

  2. Click Server-Side Firewall.

  3. Scroll to the Secure Ticket Authority list.

    • If the field is blank, you are in unticketed mode and you do not need to define any STA Servers on Mobile Access.

    • If the field contains entries, you are in ticketed mode. Each entry in this list is a URL containing the IP or FQDN of a Citrix server. Every entry in the Secure Ticket Authority list must be separately entered into Mobile Access.

To get the STA ID:

  1. Login to the STA server.

  2. From the Windows Start menu, select Programs > Citrix > Citrix Secure Gateway > Secure Ticket Authority Configuration.

  3. Click Next.

The STA ID is shown in the Enter the STA ID field.

Citrix Service - MetaFrame Servers Page

Go to the MetaFrame servers page of the Citrix Service object. In this page you can allow access to all Presentation Servers, or restrict access to defined MetaFrame servers.

If you select Restrict access to these servers only:

  • Define the servers using an IP address or Fully Qualified Domain Name (FQDN).

  • Make sure that the definition matches the configuration made on the XenApp server farm. If you do not, Mobile Access may not authorize the connection. The Presentation server configuration affects one of the parameters in the ICA file that is received by the client.

Citrix Service - XenApp Servers Page

Use the XenApp Servers page to configure access to the XenApp Servers.

Note - If you select Restrict access to these servers only,

  1. Define the servers using an IP address or Fully Qualified Domain Name (FQDN).

  2. Make sure that the definition matches the configuration made on the Metaframe server farm.

    If you do not, Mobile Access may not authorize the connection. (The XenApp server configuration affects one of the parameters in the ICA file that is received by the client).

Citrix Service - Single Sign On Page

Single Sign On increases application security.

To configure Single Sign On:

  1. Go to the Single Sign On page of the File Share Application object.

  2. Select Turn on single Sign On for this application.

    Configure the sign on method for the application.

Citrix Service - Protection Level Page

  1. Go to the Protection Level page of the Citrix Service object.

  2. Enter data in these fields:

    Security Requirements for Accessing this Application lets you:

    • Allow access to this application to any endpoint that complies with the security requirements of the Security Gateway,

    • OR make access to the application conditional on the endpoint being compliant with the selected Endpoint Compliance Profile.

    Note - The Citrix architecture requires ICA files and ActiveX executables to be temporarily cached by the client-side browser. As a result, Mobile Access's Protection Level settings do not apply to these files.

  3. Get the Host and the STA ID of the Secure Ticketing Authority (STA) servers from the current settings on the Web Interface (WI) server.

    Note - Mobile Access implements its own Secure Ticketing authority (STA) engine. STA servers are not necessary.

To get the hostname or IP address:

  1. Login to the Web Interface Citrix administration page.

  2. Click Server-Side Firewall.

  3. Scroll to the Secure Ticket Authority list.

    • If the field is blank, you are in unticketed mode and you do not need to define any STA Servers on Mobile Access.

    • If the field contains entries, you are in ticketed mode. Each entry in this list is a URL containing the IP or FQDN of a Citrix server. Every entry in the Secure Ticket Authority list must be separately entered into Mobile Access.

To get the STA ID:

  1. Login to the STA server.

  2. From the Windows Start menu, select Programs > Citrix > Citrix Secure Gateway > Secure Ticket Authority Configuration.

  3. Click Next.

    The STA ID is shown in the Enter the STA ID field.

Completing the Configuration of the Citrix Service

To complete the configuration, add the Citrix Service to a policy rule and install policy from SmartConsole.

For Unified Access Policy, see Mobile Access and the Unified Access Policy.

For legacy policy, see Getting Started with Mobile Access.

Web Mail Services

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.

Note - The traffic log does not show actions done by the user through the Web mail interface.

Mobile Access also supports the IBM Lotus Domino Web Access (DWA, formerly known as iNotes) and Outlook Web Access (OWA). DWA and OWA are configured in Mobile Access as Web Applications.

Web Mail Services User Experience

Remote users login to Mobile Access and authenticate themselves in order to gain access to the portal. They can then click a link to access the Web mail application. Mobile Access can be configured to reuse the login credentials when authenticating to the IMAP account on the mail server. If the reused credentials are incorrect, Mobile Access again presents the user with a login page. Valid credentials are saved for future logins.

Once authenticated to the mail application, users can:

  • Compose, send and receive email.

  • Create, delete, rename, and manipulate mail folders.

  • Index messages in various ways.

  • Stores addresses.

  • Search emails according to various criteria, such as body text, subject and sender's address.

  • Highlight messages with different background colors, enabling quick differentiation.

  • Display preferences.

Incoming (IMAP) and Outgoing (SMTP) Mail Servers

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

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

Configuring Web Mail Services

To configure a new Web Mail application:

  1. In SmartConsole, click Objects > Object Explorer (Ctrl+E).

  2. Click New Custom Application/Site > Mobile Application > Mail Service.

    The Web mail service window opens.

Web Mail Service - General Properties Page

  1. Go to the General Properties page of the Web mail service object.

  2. Fill in the fields on the page:

    • Name for the mail service, for example, my_mail_server

    • Outgoing Mail Server (SMTP)

      • Host or DNS Name, for example, smtp.example.com

      • Service is normally the standard predefined SMTP service.

    • Incoming Mail Server

      • IMAP server type

      • Host or DNS Name, for example, smtp.example.com

      • Service is normally the standard predefined IMAP service.

Web Mail Service - Link in Portal Page

  1. Go to the Link In Portal page of the Web mail service object.

  2. Fill in the fields on the page:

    • Link text (multi-language) - Shows in the Mobile Access Portal. If more than one link is configured with the same (case insensitive) text, only one of them will be shown in the portal.

    • Tooltip (multi-language) - Gives additional information. The text appears automatically when the user holds the cursor over the link. It disappears when the user clicks a mouse button or moves the cursor away from the link.

Web Mail Service - Single Sign-On Page

Configure the Single Sign On settings for the Web Mail Service.

  1. Go to the Single Sign On page of the Web mail service object.

  2. Select the sign on method for the application.

Web Mail Service - Protection Level Page

  1. Go to the Protection Level page of the Web mail service object.

  2. Fill in the fields on the page:

    Security Requirements for Accessing this Application lets you:

    • Allow access to this application to any endpoint machine that complies with the security requirements of the Security Gateway,

    • Give access to the application conditional on the endpoint being compliant with the selected Endpoint Compliance Profile.

Completing the Configuration of the Web Mail Service

To complete the configuration, add the Web Mail application to a policy rule and install policy from SmartConsole.

For Unified Access Policy, see Mobile Access and the Unified Access Policy.

For legacy policy, see Getting Started with Mobile Access.

Enabling LDAP Contacts Search in Web Mail Applications

By default, the contact search in Web Mail applications works only for internal users that are defined on the Mobile Access Security Gateway. To enable search on contacts that are defined on an LDAP server, see sk34997.

Native Applications

Native Applications are not clientless. They require the SSL Network Extender client on the endpoint machine. For more information, see the SSL Network Extender (SNX) Administration Guide.

DNS Names

If an internal application is hosted on a server inside the organization, using a DNS Name object in the definition of the Mobile Access application makes it possible to change the IP address of the server without having to change the definition of the host object in the Mobile Access application.

For example, if "myhost.example.com" is used in the definition of a Mobile Access application, Mobile Access resolves the IP address of "myhost" when authorizing access to the application.

If an internal application is hosted on multiple replicated servers, a single DNS Name object can be used in the definition of the Mobile Access application, instead of having to individually define each host.

The DNS server that is specified on Mobile Access resolves the DNS names. To set or change the DNS server, use the sysconfig command.

DNS Names and Aliases

A DNS name can have a number of aliases. For example, www.example.com, www.example.co.uk and www.example.co.fr could be aliases of the same DNS name.

In the definition of the DNS Name object, use the format "a.b? x.y.z", where each section of the DNS name is demarcated by a period. For example, mail.example.com or www.example.co.uk.

Wildcards can be used at the beginning of a domain name, but not at the end. For example, *.example.com includes www.example.com and mail.example.com. On the other hand, www.example.* is NOT valid.

Where DNS Name Objects are Used

DNS objects are used when defining hosts for Mobile Access Web applications, file share applications, Citrix services, and Web mail services. They are also used when configuring support for Hostname Translation.

DNS Name objects cannot be used in the Security Rule BaseClosed All rules configured in a given Security Policy. Synonym: Rulebase..

Defining the DNS Server used by Mobile Access

The DNS server that resolves the IP addresses of the DNS Name objects must be defined in one of these locations:

  • In SmartDashboard:

    On the Mobile Access tab, go to the Additional Settings > Network Accessories > Name Resolution page.

  • On the Mobile Access Security Gateway:

    For instructions, see the R80.40 Gaia Administration Guide - Chapter Network Management - Section Hosts and DNS.

Configuring DNS Name Objects

To create a new DNS Name object:

  1. In SmartConsole, select Security Policies > Shared Policies > Mobile Access and click Open Mobile Access Policy in SmartDashboard.

    SmartDashboard opens and shows the Mobile Access tab.

  2. From the navigation tree click Additional Settings > DNS Names.

  3. Click New.

  4. Enter a Name for the DNS Name object.

  5. Click DNS Names.

  6. Click Add.

  7. Type the DNS name.

  8. Click OK.

  9. Click Save and then close SmartDashboard.

  10. In SmartConsole, install policy.

Using the Login Name of the Currently Logged in User

Mobile Access applications can be configured to differ depending on the user name of the currently logged-in user. For example, portal links can include the name of the user, and a file-share can include the user's home directory. For this purpose, the $$user directive is used. During a Mobile Access session, $$user resolves to the login name of the currently logged-in user.

For such personalized configurations, insert the $$user string into the relevant location in the definitions of Web applications, file shares, and native applications.

For example, a Web application URL that is defined as http://host/$$user appears for user aa as http://host/aa and for user bb as http://host/bb.

If the user authenticates with a certificate, $$user resolves during the user's login process to the user name that is extracted from the certificate and authorized by the directory server.

For its use in configuring File Shares, see the "Mobile Access Applications" section.

WebSockets

WebSockets support in the Mobile Access Software BladeClosed Specific security solution (module): (1) On a Security Gateway, each Software Blade inspects specific characteristics of the traffic (2) On a Management Server, each Software Blade enables different management capabilities. gives remote terminal access from a browser, without a pre-installed RDP/VDI client.

This feature is supported in R77.10 and above.

For WebSockets system requirements, see sk95311.

Check Point appliances can support hundreds of concurrent WebSocket users. The amount depends on the power of the appliance and their deployment (Load Sharing an appliance cluster can support more users). To get the best appliance that best suits your needs, contact your Check Point sales engineer.

Using WebSockets

To use WebSockets support:

Create a regular Web application to the WebSocket server.

  • Make sure to include the port used for the WebSocket connection in the Authorized Locations of the Web application.

  • The Web applications related to the WebSocket application must use Path Translation as their Link Translation method. It can be inherited from the Security Gateway setting or configured in the Web application.

Monitoring WebSockets

To monitor WebSocket connections:

  1. Connect to the command line on the Security Gateway.

  2. Log in to the Expert mode.

  3. Run:

    PingerAdmin report type ws

    Alternatively, to see all connections currently handled by the Pinger daemon (such as ActiveSync push), run:

    PingerAdmin report all