Check Point Vpn-1/Securemote/Secureclient Version 4.1 SP2 ...
Check Point Vpn-1/Securemote/Secureclient Version 4.1 SP2 ...
Check Point Vpn-1/Securemote/Secureclient Version 4.1 SP2 ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Introduction<br />
<strong>Check</strong> <strong>Point</strong> VPN-1/SecuRemote/SecureClient<br />
<strong>Version</strong> <strong>4.1</strong> <strong>SP2</strong> Release Notes<br />
August 2000<br />
Thank you for using <strong>Check</strong> <strong>Point</strong> VPN-1/SecuRemote/SecureClient <strong>Version</strong> <strong>4.1</strong> <strong>SP2</strong>.<br />
This document contains important information not included in the VPN-1/SecuRemote/SecureClient<br />
documentation. Please review this information before installing VPN-1/SecuRemote/SecureClient <strong>Version</strong> <strong>4.1</strong><br />
<strong>SP2</strong>.<br />
This service pack can be applied to VPN-1/SecuRemote/SecureClient <strong>Version</strong> <strong>4.1</strong> and <strong>Version</strong> <strong>4.1</strong> SP1.<br />
Non-VPN and VPN users should install the DES edition. No new license is required.<br />
The up-to-date version of the VPN-1/SecuRemote/SecureClient Release Notes can be found at<br />
http://www.checkpoint.com/support/technical.<br />
Additional informatin can be found in the VPN-1/FireWall-1 Release Notes for <strong>Version</strong> <strong>4.1</strong> <strong>SP2</strong>, also<br />
available at http://www.checkpoint.com/support/technical.<br />
Service Pack Availability<br />
This Service Pack is available for the DES and Strong (3DES) editions for all supported product platforms.<br />
SecuRemote/SecureClient<br />
SecuRemote/SecureClient<br />
1 UDP Encapsulation Mode enables IKE/IPSec SecuRemote users to traverse Network Address Translation<br />
devices, firewalls and other devices that fail to handle IPSec packets. It also enables more than one<br />
SecuRemote user to work with IPSec behind a port-mapping NAT device, also known as dynamic NAT, (e.g.,<br />
FireWall-1 Hide NAT mode) with the same VPN-1/SecuRemote/SecureClient gateway. This is achieved by<br />
encapsulating IPSec packets inside UDP datagrams. This option is negotiated in IKE. VPN-1/SecuRemote/<br />
SecureClient supports this feature only in IPSec ESP mode (AH is not supported). Two modes of UDP<br />
Encapsulation are available:<br />
■ Automatic mode in which UDP encapsulation is performed only when the SecuRemote client is behind<br />
a dynamic Network Address Translation device configured for Hide mode. In other cases, IPSec packets<br />
are transmitted in the standard manner. The server determines how to transmit IPSec packets according<br />
to value of the source port in IKE packets.<br />
■ Forced mode in which the client can work only in UDP Encapsulation Mode. Communication is enabled<br />
only if the gateway supports UDP encapsulation and always uses UDP Encapsulation Mode. Forced<br />
mode should be used if the client is behind devices which drop or damage IPSec packets but do not<br />
modify IKE packets.<br />
Note – Before configuring UDP Encapsulation Mode, make sure that both the VPN-1/SecuRemote/SecureClient Module (gateway)<br />
and the SecuRemote/SecureClient are <strong>Version</strong> <strong>SP2</strong> or higher.<br />
Automatic mode is the default mode and does not require any configuration changes. However several<br />
manual configurations are available:<br />
■ To activate Forced mode, modify the users.C file on the SecuRemote Client as follows: in the<br />
options set, add the attribute force_udp_encapsulation with the value true. Changing the<br />
attribute value to false disables the attribute.<br />
■ VPN-1/SecuRemote/SecureClient uses <strong>Check</strong> <strong>Point</strong> registered port 2746 as the UDP Encapsulation<br />
service. Designating another port for this purpose will block the UDP service on the VPN-1/<br />
SecuRemote/SecureClient machine which uses this port. If the UDP service of the chosen port is not<br />
predefined, use the Policy Editor to define it.
SecuRemote/SecureClient<br />
Assume the service name is “CP_IPSec_transport_encapsulation”. To define it, add the set<br />
isakmp.udpencapsulation to the gateway object in the objects.C file on the VPN-1/SecuRemote/<br />
SecureClient Management Station as follows:<br />
:isakmp.udpencapsulation (<br />
:resource (<br />
:type (refobj)<br />
:refname (“#_CP_IPSec_transport_encapsulation”)<br />
)<br />
:active (true)<br />
)<br />
■ To disable UDP encapsulation, configure the VPN-1/SecuRemote/SecureClient gateway by adding the<br />
set isakmp.udpencapsulation with the attribute :active (false) to the gateway object in the<br />
objects.C file.<br />
Warning – Make sure you observe the following basic rules for configuring the objects.C file:<br />
■ The objects.C file should be configured on the VPN-1/SecuRemote/SecureClient Management<br />
Station only.<br />
■ Before configuring the objects.C file, stop the Management Station using the fwstop command<br />
and delete the files objects.C.sav and objects.C.bak.<br />
■ The changes made in the objects.C file take effect only after the Security Policy has been<br />
installed.<br />
Warning – Please note the following:<br />
If UDP encapsulation mode is used (to convey IPsec traffic from a SecuRemote or SecureClient to a<br />
VPN-1 gateway through a machine that performs NAT), make sure that:<br />
■ The primary gateway’s IP address is the one closest to the SecuRemote client (that is, the external IP<br />
address).<br />
■ The user’s IKE Data Integrity method is SHA1 (the default). This parameter is defined in the<br />
Encryption tab of the user’s IKE Properties window, which can be accessed by editing the IKE Client<br />
Encryption Method in the Encryption tab of the user’s User Properties window.<br />
2 Branding — It is possible to “brand” the SecuRemote authentication dialog boxes, in two ways:<br />
■ Add a custom bitmap, which will be displayed in the empty space on the left side of the dialog box<br />
■ Add text that will be shown when authentication ends (with different texts for success and failure).<br />
To use this feature, proceed as follows:<br />
a. Overwrite logo.bmp on the installation package with the required bitmap (maximum 140 x 111 pixels:<br />
width times height).<br />
b. Edit the AuthMsg.txt file and insert the required authentication success/failure messages as described<br />
in the file.<br />
c. Edit the product.ini file and set “IncludeBrandingFiles=1”.<br />
To disable the custom message feature, edit the “:options” setting in userc.c, and add:<br />
:use_ext_auth_msg (false)<br />
For your convenience, RGB (192, 192, 192) is considered “transparent”. This color will be displayed as the<br />
dialog background color, whatever it is (not necessarily gray). You may take advantage of this to disable the<br />
customized logo feature by providing a (small) transparent bitmap.<br />
PLEASE REVIEW THE LICENSE AGREEMENT BEFORE USING THIS OPTION!<br />
3 Multiple interface resolution for gateways — A gateway’s interfaces may not all be routable from all IP<br />
addresses. Internal interfaces may be routable only from the LAN, and exportable interfaces may be routable<br />
only from the WAN. SecuRemote can be configured to try all of a gateway’s interfaces, in the event that the<br />
interface it should use depends on the client’s location. The connection will be opened with the first address<br />
to reply.<br />
Limitations —<br />
■ This feature applies only to IKE key exchange, not to FWZ, or to topology download (defining or<br />
updating sites).<br />
■ There is no High Availability between interfaces. Therefore, a SecuRemote client which remains at the<br />
same IP address will not be able to switch to another interface if the interface it works with is down.<br />
■ Topology must be downloaded only from the canonical IP.<br />
■ For SecureClient Policy Server (PS) logon, it will work for logon to Policy Servers if:<br />
Logon was “implicit”, that is, the PS logon is triggered by a packet needing encryption, and<br />
2 VPN-1/SecuRemote/SecureClient <strong>Version</strong> <strong>Version</strong> <strong>4.1</strong> <strong>SP2</strong> - Release Notes
SecuRemote/SecureClient<br />
Communication with the Policy Server is encrypted, that is, the Policy Server has an encryption domain<br />
(probably its own) and SecureClient is not in this encryption domain.<br />
This means that if the feature is needed, the interface order should be such that the internal interface is<br />
attempted first, since the second interface will be used only in encryption scenarios.<br />
This feature requires both SecuRemote and the gateways to be running <strong>Version</strong> <strong>4.1</strong> <strong>SP2</strong>.<br />
This feature is not enabled by default and must be configured per gateway. To configure the feature, add the<br />
set :resolve_multiple_interfaces with the true value to the gateway object.<br />
4 The SDL feature may be enabled on the installation package, sparing the need for an additional reboot. To do<br />
this, edit product.ini on the package, adding “EnableSDL=1”.<br />
SecureClient-specific<br />
1 Optionally allow unencrypted LAN connections with "Encrypted Only" policy — If enabled, unencrypted<br />
connection will be accepted with an”Encrypted Only” policy, as long as both the source and the destination<br />
IP addresses are in the encryption domain of a single VPN-1 gateway. The same behavior applies to<br />
unencrypted connection to the client with “Encrypted and Outgoing”.<br />
This feature is controlled on the client, in userc.C, by adding the following attribute under “options”:<br />
:allow_clear_in_enc_domain (true)<br />
The default setting is false.<br />
2 Optionally allow DHCP (unencrypted) with “Encrypted Only” policy — If enabled, “Encrypted Only” policy<br />
will not interfere with DHCP. This feature is controlled on the client, in userc.C by the following attribute<br />
under “options”:<br />
:disable_stateful_dhcp (true)<br />
The default setting is false, allowing DHCP.<br />
Platform Specific<br />
WIndows NT<br />
1 The SDL and SSO features, which replace the active GINA DLL, can be configured to support non-Microsoft<br />
GINA DLLs. If this feature is enabled, ckpgina.dll, which acts as a “pass-through” GINA DLL, will pass<br />
handling on to whatever the active GINA DLL was when SecuRemote was installed, and not automatically to<br />
msgina.dll. This feature should be used with caution, <strong>Check</strong> <strong>Point</strong>’s GINA DLL has been tested only with<br />
msgina.dll.<br />
2 If SecuRemote is installed on Dialup Only, but no dialup adapter is active (in a particular hardware profile,<br />
for example), SecuRemote will terminate with an error message. This message can be suppressed by setting<br />
“:load_fail_silent (true)” in userc.C.<br />
Bug Fixes<br />
The following bugs were fixed in <strong>Version</strong> <strong>4.1</strong> <strong>SP2</strong>.<br />
1 IKE hybrid mode did not work with protocols that involved more than a single challenge, in particular<br />
SecurID New PIN Mode.<br />
2 CRLs were sometimes wrongly considered to be invalid (expired).<br />
3 Large IPSec packets (near MTU) were fragmented, even if the Don't Fragment flag was set. Now they are not<br />
fragmented, and instead he MTU is reduced. This behavior can be overwritten by setting<br />
IPSecAlwaysFragment=1 in the registry, under HKLM\software\checkpoint\securemote on Windows<br />
9x and under HKLM\System\CurrentControlSet\Services\FW1\Parameters on Windows NT.<br />
4 Sporadic application errors would occur up to 24 hours after disabling a site.<br />
5 Using Roaming Profiles, the modified profile was not always written successfully to the domain controller.<br />
This problem can now be solved by adding :no_clear_tables (true) to the “options” section of<br />
userc.C.<br />
Using this feature will have the following side effect: If you start encrypting and then kill SecuRemote and<br />
restart it, you may be able to open new encrypted connections without re-authenticating. This anomaly will<br />
last less than 15 minutes.<br />
Limitation — This feature does not honor the MEP High Availability feature.<br />
6 Automatic topology update, configured to run when SecuRemote was launched, did not work properly (bug<br />
was introduced in hotfix build 4157)<br />
7 If automatic topology update failed for any reason, the key exchange that triggered it was also canceled.<br />
8 Encryption key exchanges were blocked for 60 seconds after canceling an automatic topology update.<br />
9 Unusually long text did not always fit into designated controls in dialog boxes.<br />
10 Cached authentication data (user name, password) was not properly expired when machine was suspended<br />
(or hibernated).<br />
<strong>Version</strong> <strong>Version</strong> <strong>4.1</strong> <strong>SP2</strong> — August 2000 3
SecuRemote/SecureClient<br />
11 Non-Entrust certificates were sometimes considered invalid for as early as 3-4 months before they actually<br />
expired. This was fixed by ignoring the “PrivateKeyUsagePeriod” extension, which in effect allows the private<br />
key to expire before the certificate does. If this extension is important in your environment, you may instruct<br />
SecuRemote to honor it by adding “:check_PrivateKeyUsagePeriod (true)” in the “options” section<br />
of userc.C.<br />
12 There was a problem running alongside Citrix clients. This problem appears to have been solved by Citrix in<br />
their version 4.20.779.<br />
SecureClient specific Bug Fixes<br />
1 Excessive memory consumption (possible application errors) when SecureClient was blocking heavy load of<br />
unauthorized connections.<br />
2 If you logged on to a Policy Server implicitly (during encryption key exchange), then disabling the Security<br />
Policy did not always block the connection that initiated the key exchange. In particular, in the case of FTP,<br />
data connections may have been blocked while the control connection was not blocked.<br />
3 If a Security Policy was lost implicitly, by logging on to a Policy Server with a user not authorized to receive<br />
a Security Policy, then open connections were not blocked.<br />
Platform specific bug fixes<br />
Windows NT specific<br />
1 SecuRemote did not always recognize the need to re-negotiate IKE keys when its IP address changed (e.g.,<br />
disconnect and re-dial).<br />
2 If SDL was enabled, SecureClient’s IP forwarding is enabled dialog appeared too early, interfering with the<br />
logon process.<br />
3 SecuRemote would fail to initialize if the etc/hosts file was read-only (on NTFS).<br />
Windows 9x specific<br />
1 Occasional blue screen if PCI or PCMCIA slots were not functioning.<br />
2 SecuRemote did not always survive Suspend/Standby events. Now, if severe error conditions are encountered,<br />
SecuRemote will automatically be re-launched. It is possible to configure how long SecuRemote waits before<br />
giving up and re-launching, but it should not be necessary. If defaults are not satisfactory, please contact<br />
Technical Support.<br />
Known Limitations<br />
1 SecuRemote has only limited support for environments using multiple hardware profiles. In particular, there<br />
may be DHCP problems on NT, and there may be unexpected behavior on 9x platforms.<br />
2 In some rare cases, DHCP does not function correctly on the first reboot after installation (NT only). In some<br />
even rarer cases, this problem may persist on subsequent boots. If you encounter this problem, please contact<br />
your <strong>Check</strong> <strong>Point</strong> Technical Support.<br />
NTFS permission issues<br />
3 If etc/LMHOST is read-only (NTFS on NT), then the SDL feature will not function properly.<br />
4 SecuRemote will not function correctly in the unlikely event that the directory SecuRemote is installed on<br />
does not grant the interactive user write permissions.<br />
5 For logging to NTFS, you need to make sure the interactive user have write privileges on the log file.<br />
SecureClient specific<br />
6 When a new Security Policy is installed, it will not be applied to existing connections.<br />
7 Even if the Security Policy restricts incoming connections, IKE packets (UDP port 500) will be accepted from<br />
any IP address. SecuRemote will respond to these packets only if they are received from an authorized<br />
source.<br />
8 The Security Policy is applied very early during boot (by means of a service), but some unauthorized packets<br />
may make it through nonetheless.<br />
This applies to protocols that occur very early, for example DHCP.<br />
9 Switching between Policy Servers should be done explicitly. Implicit logon to a Policy Server when already<br />
logged on to some other Policy Server may cause the logon to fail.<br />
10 Some complex services involve opening back connections to the client. In general, a policy of “Outgoing<br />
Only” will prevent these services from running properly. The following complex services are supported with<br />
an Outgoing policy: DHCP, Ping, FTP PORT, FTP PASV, Real Audio (no G2/RTSP), VDOlive.<br />
11 If SecureClient is killed, the policy reverts to “Allow Outgoing and Encrypted”, regardless of the previously<br />
active policy.<br />
12 If you install SecureClient (SecuRemote with Desktop Security), you may receive messages advising you to<br />
logon to a Policy Server, even if no Policy Server is defined. If no Policy Servers are defined, Required Policy<br />
for All Desktops should be set on the management to “No Policy”.<br />
4 VPN-1/SecuRemote/SecureClient <strong>Version</strong> <strong>Version</strong> <strong>4.1</strong> <strong>SP2</strong> - Release Notes
SecuRemote/SecureClient<br />
<strong>Version</strong> <strong>Version</strong> <strong>4.1</strong> <strong>SP2</strong> — August 2000 5