Check Point Vpn-1/Securemote/Secureclient Version 4.1 SP2 ...

Introduction
Check Point VPN-1/SecuRemote/SecureClient
Version 4.1 SP2 Release Notes
August 2000
Thank you for using Check Point VPN-1/SecuRemote/SecureClient Version 4.1 SP2.
This document contains important information not included in the VPN-1/SecuRemote/SecureClient
documentation. Please review this information before installing VPN-1/SecuRemote/SecureClient Version 4.1
SP2.
This service pack can be applied to VPN-1/SecuRemote/SecureClient Version 4.1 and Version 4.1 SP1.
Non-VPN and VPN users should install the DES edition. No new license is required.
The up-to-date version of the VPN-1/SecuRemote/SecureClient Release Notes can be found at
http://www.checkpoint.com/support/technical.
Additional informatin can be found in the VPN-1/FireWall-1 Release Notes for Version 4.1 SP2, also
available at http://www.checkpoint.com/support/technical.
Service Pack Availability
This Service Pack is available for the DES and Strong (3DES) editions for all supported product platforms.
SecuRemote/SecureClient
SecuRemote/SecureClient
1 UDP Encapsulation Mode enables IKE/IPSec SecuRemote users to traverse Network Address Translation
devices, firewalls and other devices that fail to handle IPSec packets. It also enables more than one
SecuRemote user to work with IPSec behind a port-mapping NAT device, also known as dynamic NAT, (e.g.,
FireWall-1 Hide NAT mode) with the same VPN-1/SecuRemote/SecureClient gateway. This is achieved by
encapsulating IPSec packets inside UDP datagrams. This option is negotiated in IKE. VPN-1/SecuRemote/
SecureClient supports this feature only in IPSec ESP mode (AH is not supported). Two modes of UDP
Encapsulation are available:
■ Automatic mode in which UDP encapsulation is performed only when the SecuRemote client is behind
a dynamic Network Address Translation device configured for Hide mode. In other cases, IPSec packets
are transmitted in the standard manner. The server determines how to transmit IPSec packets according
to value of the source port in IKE packets.
■ Forced mode in which the client can work only in UDP Encapsulation Mode. Communication is enabled
only if the gateway supports UDP encapsulation and always uses UDP Encapsulation Mode. Forced
mode should be used if the client is behind devices which drop or damage IPSec packets but do not
modify IKE packets.
Note – Before configuring UDP Encapsulation Mode, make sure that both the VPN-1/SecuRemote/SecureClient Module (gateway)
and the SecuRemote/SecureClient are Version SP2 or higher.
Automatic mode is the default mode and does not require any configuration changes. However several
manual configurations are available:
■ To activate Forced mode, modify the users.C file on the SecuRemote Client as follows: in the
options set, add the attribute force_udp_encapsulation with the value true. Changing the
attribute value to false disables the attribute.
■ VPN-1/SecuRemote/SecureClient uses Check Point registered port 2746 as the UDP Encapsulation
service. Designating another port for this purpose will block the UDP service on the VPN-1/
SecuRemote/SecureClient machine which uses this port. If the UDP service of the chosen port is not
predefined, use the Policy Editor to define it.

SecuRemote/SecureClient
Assume the service name is “CP_IPSec_transport_encapsulation”. To define it, add the set
isakmp.udpencapsulation to the gateway object in the objects.C file on the VPN-1/SecuRemote/
SecureClient Management Station as follows:
:isakmp.udpencapsulation (
:resource (
:type (refobj)
:refname (“#_CP_IPSec_transport_encapsulation”)
)
:active (true)
)
■ To disable UDP encapsulation, configure the VPN-1/SecuRemote/SecureClient gateway by adding the
set isakmp.udpencapsulation with the attribute :active (false) to the gateway object in the
objects.C file.
Warning – Make sure you observe the following basic rules for configuring the objects.C file:
■ The objects.C file should be configured on the VPN-1/SecuRemote/SecureClient Management
Station only.
■ Before configuring the objects.C file, stop the Management Station using the fwstop command
and delete the files objects.C.sav and objects.C.bak.
■ The changes made in the objects.C file take effect only after the Security Policy has been
installed.
Warning – Please note the following:
If UDP encapsulation mode is used (to convey IPsec traffic from a SecuRemote or SecureClient to a
VPN-1 gateway through a machine that performs NAT), make sure that:
■ The primary gateway’s IP address is the one closest to the SecuRemote client (that is, the external IP
address).
■ The user’s IKE Data Integrity method is SHA1 (the default). This parameter is defined in the
Encryption tab of the user’s IKE Properties window, which can be accessed by editing the IKE Client
Encryption Method in the Encryption tab of the user’s User Properties window.
2 Branding — It is possible to “brand” the SecuRemote authentication dialog boxes, in two ways:
■ Add a custom bitmap, which will be displayed in the empty space on the left side of the dialog box
■ Add text that will be shown when authentication ends (with different texts for success and failure).
To use this feature, proceed as follows:
a. Overwrite logo.bmp on the installation package with the required bitmap (maximum 140 x 111 pixels:
width times height).
b. Edit the AuthMsg.txt file and insert the required authentication success/failure messages as described
in the file.
c. Edit the product.ini file and set “IncludeBrandingFiles=1”.
To disable the custom message feature, edit the “:options” setting in userc.c, and add:
:use_ext_auth_msg (false)
For your convenience, RGB (192, 192, 192) is considered “transparent”. This color will be displayed as the
dialog background color, whatever it is (not necessarily gray). You may take advantage of this to disable the
customized logo feature by providing a (small) transparent bitmap.
PLEASE REVIEW THE LICENSE AGREEMENT BEFORE USING THIS OPTION!
3 Multiple interface resolution for gateways — A gateway’s interfaces may not all be routable from all IP
addresses. Internal interfaces may be routable only from the LAN, and exportable interfaces may be routable
only from the WAN. SecuRemote can be configured to try all of a gateway’s interfaces, in the event that the
interface it should use depends on the client’s location. The connection will be opened with the first address
to reply.
Limitations —
■ This feature applies only to IKE key exchange, not to FWZ, or to topology download (defining or
updating sites).
■ There is no High Availability between interfaces. Therefore, a SecuRemote client which remains at the
same IP address will not be able to switch to another interface if the interface it works with is down.
■ Topology must be downloaded only from the canonical IP.
■ For SecureClient Policy Server (PS) logon, it will work for logon to Policy Servers if:
Logon was “implicit”, that is, the PS logon is triggered by a packet needing encryption, and
2 VPN-1/SecuRemote/SecureClient Version Version 4.1 SP2 - Release Notes

SecuRemote/SecureClient
Communication with the Policy Server is encrypted, that is, the Policy Server has an encryption domain
(probably its own) and SecureClient is not in this encryption domain.
This means that if the feature is needed, the interface order should be such that the internal interface is
attempted first, since the second interface will be used only in encryption scenarios.
This feature requires both SecuRemote and the gateways to be running Version 4.1 SP2.
This feature is not enabled by default and must be configured per gateway. To configure the feature, add the
set :resolve_multiple_interfaces with the true value to the gateway object.
4 The SDL feature may be enabled on the installation package, sparing the need for an additional reboot. To do
this, edit product.ini on the package, adding “EnableSDL=1”.
SecureClient-specific
1 Optionally allow unencrypted LAN connections with "Encrypted Only" policy — If enabled, unencrypted
connection will be accepted with an”Encrypted Only” policy, as long as both the source and the destination
IP addresses are in the encryption domain of a single VPN-1 gateway. The same behavior applies to
unencrypted connection to the client with “Encrypted and Outgoing”.
This feature is controlled on the client, in userc.C, by adding the following attribute under “options”:
:allow_clear_in_enc_domain (true)
The default setting is false.
2 Optionally allow DHCP (unencrypted) with “Encrypted Only” policy — If enabled, “Encrypted Only” policy
will not interfere with DHCP. This feature is controlled on the client, in userc.C by the following attribute
under “options”:
:disable_stateful_dhcp (true)
The default setting is false, allowing DHCP.
Platform Specific
WIndows NT
1 The SDL and SSO features, which replace the active GINA DLL, can be configured to support non-Microsoft
GINA DLLs. If this feature is enabled, ckpgina.dll, which acts as a “pass-through” GINA DLL, will pass
handling on to whatever the active GINA DLL was when SecuRemote was installed, and not automatically to
msgina.dll. This feature should be used with caution, Check Point’s GINA DLL has been tested only with
msgina.dll.
2 If SecuRemote is installed on Dialup Only, but no dialup adapter is active (in a particular hardware profile,
for example), SecuRemote will terminate with an error message. This message can be suppressed by setting
“:load_fail_silent (true)” in userc.C.
Bug Fixes
The following bugs were fixed in Version 4.1 SP2.
1 IKE hybrid mode did not work with protocols that involved more than a single challenge, in particular
SecurID New PIN Mode.
2 CRLs were sometimes wrongly considered to be invalid (expired).
3 Large IPSec packets (near MTU) were fragmented, even if the Don't Fragment flag was set. Now they are not
fragmented, and instead he MTU is reduced. This behavior can be overwritten by setting
IPSecAlwaysFragment=1 in the registry, under HKLM\software\checkpoint\securemote on Windows
9x and under HKLM\System\CurrentControlSet\Services\FW1\Parameters on Windows NT.
4 Sporadic application errors would occur up to 24 hours after disabling a site.
5 Using Roaming Profiles, the modified profile was not always written successfully to the domain controller.
This problem can now be solved by adding :no_clear_tables (true) to the “options” section of
userc.C.
Using this feature will have the following side effect: If you start encrypting and then kill SecuRemote and
restart it, you may be able to open new encrypted connections without re-authenticating. This anomaly will
last less than 15 minutes.
Limitation — This feature does not honor the MEP High Availability feature.
6 Automatic topology update, configured to run when SecuRemote was launched, did not work properly (bug
was introduced in hotfix build 4157)
7 If automatic topology update failed for any reason, the key exchange that triggered it was also canceled.
8 Encryption key exchanges were blocked for 60 seconds after canceling an automatic topology update.
9 Unusually long text did not always fit into designated controls in dialog boxes.
10 Cached authentication data (user name, password) was not properly expired when machine was suspended
(or hibernated).
Version Version 4.1 SP2 — August 2000 3

SecuRemote/SecureClient
11 Non-Entrust certificates were sometimes considered invalid for as early as 3-4 months before they actually
expired. This was fixed by ignoring the “PrivateKeyUsagePeriod” extension, which in effect allows the private
key to expire before the certificate does. If this extension is important in your environment, you may instruct
SecuRemote to honor it by adding “:check_PrivateKeyUsagePeriod (true)” in the “options” section
of userc.C.
12 There was a problem running alongside Citrix clients. This problem appears to have been solved by Citrix in
their version 4.20.779.
SecureClient specific Bug Fixes
1 Excessive memory consumption (possible application errors) when SecureClient was blocking heavy load of
unauthorized connections.
2 If you logged on to a Policy Server implicitly (during encryption key exchange), then disabling the Security
Policy did not always block the connection that initiated the key exchange. In particular, in the case of FTP,
data connections may have been blocked while the control connection was not blocked.
3 If a Security Policy was lost implicitly, by logging on to a Policy Server with a user not authorized to receive
a Security Policy, then open connections were not blocked.
Platform specific bug fixes
Windows NT specific
1 SecuRemote did not always recognize the need to re-negotiate IKE keys when its IP address changed (e.g.,
disconnect and re-dial).
2 If SDL was enabled, SecureClient’s IP forwarding is enabled dialog appeared too early, interfering with the
logon process.
3 SecuRemote would fail to initialize if the etc/hosts file was read-only (on NTFS).
Windows 9x specific
1 Occasional blue screen if PCI or PCMCIA slots were not functioning.
2 SecuRemote did not always survive Suspend/Standby events. Now, if severe error conditions are encountered,
SecuRemote will automatically be re-launched. It is possible to configure how long SecuRemote waits before
giving up and re-launching, but it should not be necessary. If defaults are not satisfactory, please contact
Technical Support.
Known Limitations
1 SecuRemote has only limited support for environments using multiple hardware profiles. In particular, there
may be DHCP problems on NT, and there may be unexpected behavior on 9x platforms.
2 In some rare cases, DHCP does not function correctly on the first reboot after installation (NT only). In some
even rarer cases, this problem may persist on subsequent boots. If you encounter this problem, please contact
your Check Point Technical Support.
NTFS permission issues
3 If etc/LMHOST is read-only (NTFS on NT), then the SDL feature will not function properly.
4 SecuRemote will not function correctly in the unlikely event that the directory SecuRemote is installed on
does not grant the interactive user write permissions.
5 For logging to NTFS, you need to make sure the interactive user have write privileges on the log file.
SecureClient specific
6 When a new Security Policy is installed, it will not be applied to existing connections.
7 Even if the Security Policy restricts incoming connections, IKE packets (UDP port 500) will be accepted from
any IP address. SecuRemote will respond to these packets only if they are received from an authorized
source.
8 The Security Policy is applied very early during boot (by means of a service), but some unauthorized packets
may make it through nonetheless.
This applies to protocols that occur very early, for example DHCP.
9 Switching between Policy Servers should be done explicitly. Implicit logon to a Policy Server when already
logged on to some other Policy Server may cause the logon to fail.
10 Some complex services involve opening back connections to the client. In general, a policy of “Outgoing
Only” will prevent these services from running properly. The following complex services are supported with
an Outgoing policy: DHCP, Ping, FTP PORT, FTP PASV, Real Audio (no G2/RTSP), VDOlive.
11 If SecureClient is killed, the policy reverts to “Allow Outgoing and Encrypted”, regardless of the previously
active policy.
12 If you install SecureClient (SecuRemote with Desktop Security), you may receive messages advising you to
logon to a Policy Server, even if no Policy Server is defined. If no Policy Servers are defined, Required Policy
for All Desktops should be set on the management to “No Policy”.
4 VPN-1/SecuRemote/SecureClient Version Version 4.1 SP2 - Release Notes

SecuRemote/SecureClient
Version Version 4.1 SP2 — August 2000 5