Remote Access Advanced Configuration

Non-Private Client IP Addresses

Suppose a Remote Access Client user connects from behind a NAT device, using a non-private IP address that belongs to another organization. During the life of the connection, the Security Gateway routes all traffic intended for that non-private IP address to the client user, even traffic intended for the real owner of the IP address.

Solving Remote Access Issues

Set the vpn_restrict_client_phase2_id in the Objects_5_0.C file to the appropriate value, as follows:

Preventing a Client Inside the Encryption Domain from Encrypting

The Problem

If a Remote Access Client located inside the VPN domain of one Security Gateway opens a connection to a host inside the VPN domain of another Security Gateway, the connection will be encrypted twice (once by the client and again by the Security Gateway) and decrypted only once (by the peer Security Gateway).

The Solution

To prevent this from happening, configure the client not to encrypt if both the client and the host (the end-points of the connection) are in the VPN domains of Security Gateways managed by the same Security Management server.

To do this, enable the send_clear_traffic_between_encryption_domains property in objects_5_0.C.

When the Client Has a Private Address

If the send_clear_traffic_between_encryption_domains property is enabled, a problem can arise when the Security Gateway's VPN domain includes private addresses, where the meaning of "private" is specified in the Non Unique IP Address Ranges page of the Global Properties window.

If the client connects from outside the VPN domain (for example, from a hotel) and is assigned (by the ISP or a NAT device) a private IP address which happens to be in the Security Gateway's VPN domain, then the client will not encrypt when connecting to the VPN domain, and the connection will be dropped because it is in the clear.

You can configure the client to encrypt this traffic as follows:

1. To encrypt traffic from private addresses, enable the send_clear_except_for_non_unique property in objects_5_0.C.
2. To encrypt traffic from specific IP addresses, proceed as follows:
3. Define a group consisting of those addresses.
4. Enable the send_clear_except_for_specific_addresses property in objects_5_0.C.
5. Set send_clear_except_for_address_group to the name of the group defined in step 1.

   Note - This feature is disabled when more than one site is defined on the client.

Working in Connect Mode While Not Connected

For users connected in Connect Mode, you can reduce the frequency of authentication by enabling the allow_clear_traffic_while_disconnected property in objects_5_0.C. The client will then not encrypt traffic to the peer encryption domain when not connected. This will prevent unnecessary authentication when connecting to unencrypted services in the peer encryption domain.

For example, if the site includes both private and public HTTP servers, there is no need to encrypt traffic to the public site. To prevent a user from unnecessarily authenticating only because she is an internal user, configure the following two rules in the Desktop Policy:

Authentication Timeout Interval

To specify the length of time between re-authentications, select Policy> Global Properties - Remote Access and in the Authentication Timeout section, enter a value in Validation timeout. Alternatively, check Use default value.

For Connect Mode, the countdown to the timeout begins from the time that the Client is connected.

Password Caching

When the timeout expires, the user will be asked to authenticate again. If password-caching is enabled, clients will supply the cached password automatically and the authentication will take place transparently to the user. In other words, the user will not be aware that re-authentication has taken place.

Password caching is possible only for multiple-use passwords. If the user's authentication scheme implement one-time passwords (for example, SecurID), then passwords cannot be cached, and the user will be asked to re-authenticate when the authentication time-out expires. For these schemes, this feature should not be implemented.

Password caching is specified in the client's Authentication window.

Enabling and Disabling Secure Domain Logon

To enable Secure Domain Logon (SDL), select Enable Secure Domain Logon from the Passwords menu.

Note the following:

• If you are using WINS (see WINS (Connect Mode Only)), configure WINS before enabling SDL.
• Do not change the machine domain configuration when Secure Domain Logon is enabled.

Domain Controller Name Resolution

If clients are configured in Connect Mode and Office Mode, clients automatically resolve the NT domain name using dynamic WINS.

Otherwise, clients resolve the NT domain name using either LMHOSTS or WINS.

LMHOSTS

The LMHOSTS name resolution service can be used in both LAN and dial-up configurations as follows:

Enter the relevant information (see below) the $FWDIR/conf/dnsinfo.C file on the Security Gateway, and install the policy.

(

     :LMdata(

            :(

                    :ipaddr (<IP address>)

                    :name (<host name>)

                    :domain (<domain name>)

            )

            :(

                    :ipaddr (<IP address>)

                    :name (<host name>)

                    :domain (<domain name>)

            )

     )

) 

When the topology is updated, the name resolution data will be automatically transferred to the dnsinfo entry of the userc.C file and then to its LMHOSTS file.

The WINS name resolution service can be used in dial-up configurations only. It is not supported on Win 9x platforms.

To use the WINS, proceed as follows on the virtual adapter:

1. Specify the primary and, optionally, the secondary WINS servers protected by the Security Gateway.
2. Reboot the machine.

Configuring the SecuRemote DNS Server

1. Create a new SecuRemote DNS Server from the Objects Tree. Select Servers and OPSEC and right-click Servers > New > SecuRemote DNS.
2. In the SecuRemote DNS Properties window
   • General tab — Configure the general settings of the SecuRemote DNS Server as well as the host on which the SecuRemote DNS Server.
   • Domains tab — Add new domains or edit and remove existing domains.

     

3. In the Domain tab, define the domain suffix and the matching rule. Names in the domain that correspond to the rule will be resolved by the SecuRemote DNS Server. All other names will be resolved by the SecuRemote client's default DNS server.
   • Specify the Domain Suffix for which the SecuRemote DNS Server will resolve the internal names (for example, checkpoint.com).
   • Select Match only *.suffix to specify that the maximum number of labels resolved will be 1.

     For example, if Domain Suffix is "checkpoint.com" and Match only *.suffix is selected (that is, the maximum prefix label count is in effect 1) then the SecuRemote DNS Server will be used to resolve "www.checkpoint.com" and "whatever.checkpoint.com" but not "www.internal.checkpoint.com."

   • Select Match up to...labels preceding the suffix to increase the number of labels to be matched.

     For example, if Domain Suffix is "checkpoint.com" and Match up to...labels preceding the suffix is selected and set to 3, then the SecuRemote DNS Server will be used to resolve "www.checkpoint.com" and "www.internal.checkpoint.com" but not "www.internal.inside.checkpoint.com".

Additional Considerations

Split DNS is disabled in the following cases:

• In Connect mode, while disconnected.

  To override, set disable_split_dns_when_disconnected in the SecuRemote/SecureClient userc.C file to false.

• In connect mode, while connected in Office Mode.

  To override, set disable_split_dns_in_om in the SecuRemote/SecureClient userc.C file to false.

Authentication Timeout and Password Caching

The Problem

Users consider multiple authentications during the course of a single session to be a nuisance. At the same time, these multiple authentications are an effective means of ensuring that the session has not been hijacked (for example, if the user steps away from the client for a period of time). The problem is finding the correct balance between convenience and security.

The Solution

Multiple authentication can be reduced by two means:

• Increasing the authentication timeout interval
• Caching the user's password

Secure Domain Logon (SDL)

The Problem

When a SecuRemote/SecureClient user logs on to a domain controller, the user has not yet entered his or her SecuRemote/SecureClient credentials and so the connection to the domain controller is not encrypted.

The Solution

When the Secure Domain Logon (SDL) feature is enabled, then after the user enters the OS user name and password (but before the connection to the domain controller is started), SecuRemote Client User Authentication window is displayed. When the user enters the SecuRemote/SecureClient credentials, the connection to the domain controller takes place over an encrypted tunnel.

Configuring SDL Timeout

Because SDL depends on the synchronization of concurrent processes, flexibility in defining timeouts is important.

The SDL Timeout feature of Secure Domain Logon allows you to define the period during which a user must enter his or her domain controller credentials. When the allocated time expires and no cached information is used (if applicable), the logon fails.

The timeout is controlled by the sdl_netlogon_timeout (<value in seconds>) parameter in the file Objects_5_0.C.

Cached Information

When the SecuRemote/SecureClient machine successfully logs on to a domain controller, the user's profile is saved in cache. This cached information will be used if subsequent logons to the domain controller fail, for whatever reason.

To configure this option in the client registry, proceed as follows:

1. Go to HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon.
2. Create a new key CachedLogonCount with the valid range of values from 0 to 50. The value of the key is the number of previous logon attempts that a server will cache.

   A value of 0 disables logon caching and any value above 50 will only cache 50 logon attempts.

Configuring Secure Domain Logon

1. Configure the SecuRemote Client to use LMHOSTS (all platforms) or WINS (all platforms except Win 9x).
2. For Win NT and Win 2000, configure the SDL timeout.
3. Define the site where the domain controller resides and download/update the topology.
4. If the client is not already a domain member, configure the machine as a domain member.
5. For Win NT and 2000:
   • Enable Auto Local Logon (optional)
   • Enable Secure Domain Logon
6. Reboot the computer and logon.

Using Secure Domain Logon

After you have rebooted the computer:

1. When the Windows NT Logon window is displayed, enter the operating system credentials.
2. Click OK.

   The SecuRemote Logon window is displayed.

3. Enter the SecuRemote credentials in the defined time (see Configuring SDL Timeout).

If you fail to logon and no cached information is used, wait one minute and try again.

If SDL is already configured on the client, the administrator can customize SecuRemote/SecureClient installation packages with SDL enabled by default, thereby relieving the user of the need to configure SDL manually. This can be done in two ways:

• Create a self-extracting client package using the SecureClient Packaging Tool (see Packaging SecureClient) and select Enable Secure Domain Logon (SDL) in the Operating System Logon window or
• Edit the product.ini file in the SecuRemote installation package by setting the value of EnableSDL to 1. See Userc.C and Product.ini Configuration Files for more information.

Back Connections (Server to Client)

Back connections (connections from the server to the client) are required by certain applications, such as Xterm. These connections do not have to be explicitly defined in the Rule Base. To achieve this, when a user logs on to a site, the username and IP address are stored in an authentication database for 15 minutes (this time frame is configurable). During this time, all back connections from server to client are allowed. After this time, back connections are sent in clear.

Sending Keep-Alive Packets to the Server

To enable the 15 minute interval, configure back connections so that Keep Alive transmissions are sent by the client to the server. This is especially necessary when a NAT device is used.

By sending Keep Alive packets, the IP Address maintained in the authentication database is constantly renewed. In the Remote Access page of the Global Properties window, check Enable back connections (from Security Gateway to client) and specify a value for Send Keep-Alive packet to the Security Gateway.

Auto Topology Update (Connect Mode only)

You can configure SecuRemote Clients to automatically update a site's topology either when starting SecuRemote or just before the IKE key exchange in the Remote Access page of the Global Properties window.

In this window, the system administrator can:

• Update topology every ... hours — The site's topology will be updated before the next key exchange if the defined period has elapsed since the last topology update.

The following features become available if Update topology every ... hours is enabled:

• Automatic update — If enabled, the site will be updated after the key exchange (according to the value of Update topology every ... hours). This will allow to avoid prompting the user to update sites.
• Upon VPN-1 SecuRemote/SecureClient startup — If enabled, the user will be prompted to update the topology when the SecuRemote Client starts. If the user is not connected to the network when the SecuRemote Client starts, he or she can reject the prompt. In this case the topology will be automatically updated after the next key exchange with the site.

How to Work with non-Check Point Firewalls

If a SecuRemote/SecureClients is located behind a non-Check Point firewall, the following ports must be opened on the firewall to allow SecuRemote/SecureClient traffic to pass:

Resolving Internal Names with the SecuRemote DNS Server

The Problem

The SecuRemote/SecureClient must resolve the names of internal hosts (behind the Security Gateway) with non-unique IP addresses using an internal DNS server.

The Solution

The simplest solution is to use Connect Mode and Office Mode. Otherwise, use the split DNS feature by defining a SecuRemote DNS Server.

The SecuRemote DNS Server is an object that represents an internal DNS server that can be used to resolve internal names with unregistered, (RFC 1981-style) IP addresses. It is best to encrypt the DNS resolution of these internal names. Not all DNS traffic should be encrypted, as this would mean that every DNS resolution would require authentication.