Remote Access Advanced Configuration

In This Section: Non-Private Client IP Addresses Preventing a Client Inside VPN Domain from Encrypting Authentication Timeout and Password Caching Secure Domain Logon (SDL) Auto Topology Update (Connect Mode only) How to Work with non-Check Point Firewalls Resolving Internal Names with the SecuRemote DNS Server

Note - The procedures in this section are relevant for SecureClient. For other clients, see the most updated documentation for that client.

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:

value		meaning
om_only		Clients behind NAT devices can only connect using Office Mode.
private_and_om		Clients can connect using either: using Office Mode, or when using private IP addresses (where the meaning of "private" is specified in the NAT page of the Global Properties window)
none		This setting (the default) does not address the problem described above.
	Note - If the user is restricted to Office Mode or to the use of a private IP address, and attempts another type of connection, the connection will be dropped and a log will be sent to the SmartView Tracker.

Preventing a Client Inside VPN Domain from Encrypting

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

Note - If you enable this feature, ensure that a VPN is defined between the Security Gateways. This feature is disabled when more than one site is defined on the client.

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:

Source		Destination	Service	Action
encryption domain		encryption domain	Any	Accept
Any		encryption domain	Any	Encrypt
	Note - If you enable this feature, you must ensure that a VPN is defined between the Security Gateways. This feature applies only to Connect Mode. This feature is disabled when more than one site is defined in the client.

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

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.

WINS (Connect Mode Only)

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:

Important - You must do this before enabling SDL. See Enabling and Disabling Secure Domain Logon.

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:

• Increasing the re-authentication interval
• Caching the user's password

Secure Domain Logon (SDL)

The Problem

When a Remote Access client user logs on to a domain controller, the user has not yet entered 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), the User Authentication window is displayed. When the user enters the client 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.

Note - This feature is not applicable if Auto Local Logon is enabled (Connect Mode Only).

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

Auto Topology Update (Connect Mode only)

You can configure 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 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 client starts. If the user is not connected to the network when the 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 / SecureClient is located behind a non-Check Point firewall, the following ports must be opened on the firewall to allow SecuRemote / SecureClient traffic to pass:

Port	Description
UDP port 500	Always, even if using IKE over TCP
TCP port 500	Only if using IKE over TCP
IP protocol 50 ESP	Unless always using UDP encapsulation
UDP port 2746	Only if using MEP, interface resolving or interface High Availability
UDP port 259	Only if using MEP, interface resolving or interface High Availability

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 private IP addresses (RFC 1918). 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.

Multiple Entry Point for Remote Access VPNs

Note - The procedures in this section are relevant for SecureClient. For other clients, see the most updated documentation for that client.

The Need for Multiple Entry Point Security Gateways

The Security Gateway provides a single point of entry to the internal network. It is the Security Gateway that makes the internal network "available" to remote machines. If the Security Gateway fails, the internal network is no longer available. It therefore makes good sense to have Multiple Entry Points (MEP) to the same network.

The Check Point Solution for Multiple Entry Points

In a MEP environment, more than one Security Gateway is both protecting and giving access to the same VPN domain. How a remote user selects a Security Gateway in order to reach a destination IP address depends on how the MEP Security Gateways have been configured, which in turn depends on the requirements of the organization.

For more information, see Multiple Entry Point VPNs.

The Check Point solution for multiple entry points is based on a proprietary Probing Protocol (PP) that tests Security Gateway availability. The MEP Security Gateways do not have to be in the same location; they can be widely-spaced, geographically.

Note - In a MEP Security Gateway environment, the only remote client supported is the Check Point SecuRemote / SecureClient.

SecureClient Connect Profiles and MEP

There are three methods used to choose which Security Gateway will be used as the entry point for any given connection:

• First to reply. In a First to Reply MEP environment, SecureClient attempts to connect to the Security Gateway configured in the profile. If the configured Security Gateway does not reply, the first Security Gateway to respond is chosen.
• Primary/Backup. With this method, SecureClient attempts to connect to the Primary Security Gateway first. If the Primary Security Gateway does not reply, SecureClient attempts to connect to the Backup Security Gateway. If the Backup Security Gateway does not reply, there are no further attempts to connect.
• Random Selection. In a Load Sharing MEP environment, SecureClient randomly selects a Security Gateway and assigns the Security Gateway priority. The remote peer stays with this chosen Security Gateway for all subsequent connections to host machines within the VPN domain. Load distribution takes place on the level of "different clients", rather than the level of "endpoints in a connection". In addition, SecureClient ignores whatever Security Gateway is configured as the "connect to Security Gateway" in the profile.

Preferred Backup Security Gateway

Preferred Backup Security Gateway allows remote hosts to choose which Security Gateway in the MEP configuration will be the backup Security Gateway. All other Security Gateways in the MEP configuration will be ignored should the first two Security Gateways become unavailable.

In this scenario:

• The VPN Domain is behind three Security Gateways: A, B and C.
• Security Gateway A is the Primary Security Gateway.
• Security Gateway B is the Backup Security Gateway when Security Gateway A is not available.
• Should Security Gateway A and Security Gateway B become unavailable, the remote host will not attempt to connect to Security Gateway C.

Visitor Mode and MEP

Since the RDP Security Gateway discovery mechanism used in a MEP environment runs over UDP, this creates a special challenge for SecureClient in Visitor Mode, since all traffic is tunneled over a regular TCP connection.

In a MEP environment:

• The RDP probing protocol is not used; instead, a special Visitor Mode handshake is employed.
• When a MEP failover occurs, SecureClient disconnects and the user needs to reconnect to the site in the usual way.
• In a Primary-Backup configuration, the connection will failover to the backup Security Gateway should the primary Security Gateway become unavailable. Even if the Primary Security Gateway is restored, the connection does not return to the primary Security Gateway.
• All the gateways in the MEP:

Must support visitor mode.

The user must be working with a Visitor Mode enabled profile.

Routing Return Packets

To make sure return packets are routed correctly, the MEP Security Gateway makes use of IP pool NAT.

IP Pool NAT

IP pool NAT is a type of NAT in which source IP addresses from remote VPN domains are mapped to an IP address drawing from a pool of registered IP addresses. In order to maintain symmetric sessions using MEP Security Gateways, the MEP Security Gateway performs NAT using a range of IP addresses dedicated to that specific Security Gateway and should be routed within the internal network to the originating Security Gateway. When the returning packets reach the Security Gateway, the Security Gateway restores the original source IP address and forwards the packets to the source.

Note - When Office Mode is enabled, there is no need to configure IP Pool NAT since Office Mode dynamically assigns IP's to remote hosts.

Disabling MEP

When MEP is disabled, MEP RDP probing and fail over will not be performed. As a result, remote hosts will connect to the Security Gateway defined without considering the MEP configuration.

Configuring MEP

To configure MEP, decide on the MEP selection method:

• First to Respond
• Primary/Backup
• Load Distribution

First to Respond

When more than one Security Gateway leads to the same (overlapping) VPN domain, they are considered MEP by the remote peer, and the first Security Gateway to respond to the probing protocol is chosen. To configure first to respond, define that part of the network that is shared by all the Security Gateways into a single group and assign that group as the VPN domain.

On the Properties window of each Security Gateway network object, Topology page > VPN Domain section, select Manually defined, and define the same VPN domain for all Security Gateways.

Primary-Backup

1. In the Global Properties window, VPN > Advanced page, select Enable Backup Security Gateway.
2. In the network objects tree, Groups section, create a group consisting of the Security Gateways that act as backup Security Gateways.
3. On the VPN page of the network object selected as the Primary Security Gateway, select Use Backup Security Gateways, and select the group of backup Security Gateways from the drop-down box. This Security Gateway now functions as the primary Security Gateway for a specific VPN domain.
4. Define the VPN for the backup Security Gateway(s). Backup Security Gateways do not always have a VPN domain of their own. They simply back-up the primary.
   • If the backup Security Gateway does not have a VPN domain of its own, the VPN domain should include only the backup Security Gateway itself:
     • On the Properties window of the backup network object, Topology page > VPN Domain section, select Manually defined.
     • Select a group or network that contains only the backup Security Gateway.
   • If the backup does have a VPN domain:
     • Verify that the IP address of the backup Security Gateway is not included in the VPN domain of the primary.
     • For each backup Security Gateway, define a VPN domain that does not overlap with the VPN domain of any other backup Security Gateway.

   Note - There must be no overlap between the VPN domain of the primary Security Gateway and the VPN domain of the backup Security Gateway(s); that is, no IP address can belong to both.

5. Configure IP pool NAT to handle return packets. See: Configuring Return Packets.

Load Distribution

1. In the Global Properties window, Remote Access > VPN Basic page, Load distribution section, select Enable load distribution for Multiple Entry Point configurations (Remote Access connections).
2. Define the same VPN domain for all Security Gateways.

Checking this option also means that load distribution is dynamic, that is the remote client randomly selects a Security Gateway.

Configuring Return Packets

Return packets are handled with IP pool NAT addresses belonging to the Security Gateway.

Configuring IP pool NAT

In Global Properties > NAT page, select Enable IP Pool NAT for SecuRemote / SecureClient and Security Gateway to Security Gateway connections. Then:

1. For each Security Gateway, create a network object that represents the IP pool NAT addresses for that Security Gateway. The IP pool can be a network, group, or address range. For an address range, for example:
   • On the network objects tree, right-click Network Objects branch > New > Address Range... The Address Range Properties window opens.
   • On the General tab, enter the first IP and last IP of the address range.
   • Click OK. In the network objects tree, Address Ranges branch, the new address range appears.
2. On the Security Gateway object where IP pool NAT translation is performed, Security Gateway Properties window, NAT page, IP Pools (for Security Gateways) section, select either (or both):
   • Use IP Pool NAT for VPN client connections.
   • Use IP Pool NAT for Security Gateway to Security Gateway connections.
   • In the Allocate IP Addresses from field, select the address range you created.
   • Decide after how many minutes unused addressees are returned to the IP pool.
   • Click OK.
3. Edit the routing table of each internal router, so that packets with an IP address assigned from the NAT pool are routed to the appropriate Security Gateway.

Configuring Preferred Backup Security Gateway

In SmartDashboard:

1. Click Manage > Remote Access > Connection Profiles.
2. Select existing profile and click Edit or click New > Connection Profile.

   The Connection Profile Properties opens.

3. In the Connect to Security Gateway and Backup Security Gateway fields, use the drop down menu to select the Security Gateways that will function as the primary and backup Security Gateways for this profile.
4. Click OK.

Disabling MEP

Disabling MEP is configured by setting the following command to true in DBedit, the Check Point database tool:

• desktop_disable_mep