READ-ME File Check Point VPN-1 SecuRemote/SecureClient version 4.1 SP-3 build 4176 for Windows 95/98
====================================================================================================

Content
=======
1. New Features
2. Fixed Bugs
3. Limitations
4. Known Bugs.

New Features since SP-2
=======================
1. The automatic site update feature can be configured to work in a silent mode. 
   Add or modify ":silent_topo_update (true)" in userc.C
2. H.323 services are now supported statefully.
3. IKE co-existence
   If your machine is running a Microsoft IKE client (VPN), SecuRemote's IKE 
   will not interfere.

New Features (Since version 4.1)
================================
1. Secure Domain Logon (SDL)
   Enabling this feature will launch SecuRemote early enough to encrypt the logon 
   session with a domain controller. SecuRemote's main window will not be visible
   till after user logs on, but the relevant authentication dialogs will popup.
2. Software version control
   After defining or updating a Site, you may be notified that you should upgrade
   to a newer version of SecuRemote. It is your VPN-1/FireWall-1 administrator 
   who decides on the version you should be using. You may also be sent the location 
   of the new version. In this case, SecuRemote can launch your default web browser 
   with the specified location.
3. Automatic Topology update
   SecuRemote may update Site information without the user's initiative, based on 
   timeout values set by the VPN-1/FireWall-1 administrator.
4. Error logging
   In previous versions, logging, if active, was to C: drive only. In this version 
   it is possible to specify an alternate drive, through the registry. To do this, 
   add a string value named "LogDrive" under 
   HKEY_LOCAL_MACHINE\Software\CheckPoint\SecuRemote, and set it to some drive letter.
   To enable logging, you must pre-create the log file. For Regular SecuRemote logging, 
   you should create "fwenc.log" at the root (on C:\ by default). For SecureClient
   logging you may want to create sr.log for logging of blocked connections. You may
   additionally want to create b_fwenc.log and b_sr.log, for logging before the user
   logs on to the Operating System.
5. UDP encapsulation of IPSec traffic to support SecuRemote behind NAT devices.
6. Optionally allow clear LAN connections with "Encrypted Only" policy.
7. Optionally allow DHCP (un-encrypted, of course) with "Encrypted Only" policy.

Platform specific features
--------------------------
1. "Split Driver" kernel architecture
   This version of SecuRemote uses a new kernel architecture called Split Driver.
   This will solve a long list of outstanding issues (see Fixed Bugs).

Bugs fixed since SP2
====================
1. Sometimes the "Logging out of Policy Server" dialog holds up Shutdown. This 
   can be prevented by setting a timout in userc.C. Setting
   :dtm_logout_timeout (nnn) 
   will guarantee that the dialog is closed within nnn seconds.
2. ICMP destination unreachable, need fragmentation - accepted (statefully)
   even with "Outgoing Only" and "Encrypted and Outgoing" policies.
3. In some cases of challeng/response authentication, the response to the second
   challenge was automatically populated with the response to the first challenge.
4. It is now possible to communicate with a Policy Server behind static NAT 
   (FireWall-1 version 4.1 SP3 is required for this).
5. It was possible to re-set your password, if cached in memory, without knowing it, 
   by selecting "Set Password", and choosing OK. This could, in some cases, allow
   the password to be re-used for a longer period than configured on the Firewall.
6. In some cases, after multiple re-authentications with the Firewall, further 
   authentications would fail ("No answer received from a firewall..." until 
   SecuRemote was re-started.

Bugs fixed since SP1
====================
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 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 - the MTU is reduced. 
   This behavior can be overwritten by setting IPSecAlwaysFragment=1 in the registry, 
   under HKLM\software\checkpoint\securemote
4. Sporadic application errors that occurred up to 24 hours after disabling a site.
5. Excessive memory consumption (possible application errors) when SecureClient 
   was blocking heavy load of unauthorized connections.
6. 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. Please consult the release notes for more 
   details.
7. 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.
8. 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.
9. Automatic topology update, configured to run when SecuRemote was launched, 
   did not work properly (bug introduce in hotfix build 4157).
10.If automatic topology update failed for any reason, the key exchange that 
   triggered it was also canceled.
11.Encryption key exchanges were blocked for 60 seconds after canceling an automatic
   topology update.
12.Unusually long text did not always fit into designated controls in dialog boxes.
13.Cached authentication data (user name, password) was not properly expired when 
   machine was suspended (or hibernated).

Platform specific fixed bugs
----------------------------
1. Occasional blue screen if PCI or PCMCIA slots were malfunctioning.
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.


Limitations
===========
1. The following data items are not encrypted:
   * The connection between the PC and the Manager when performing
     "Add New Site" or "Update", unless encryption of this data is
	 enforced on the Manager. Even so, the information is signed.
   * The connection between the PC and a FireWall in which an FWZ key is exchanged.
     However the information is signed and the password and the session key
     are encrypted. IKE key exchange is encrypted as the protocol dictates.
   * DNS information, unless otherwise configured (see Firewall User Guide).
   * If the SecuRemote client runs the Check Point Policy Editor, the communication 
     with the  management station is not encrypted by SecuRemote, unless configured 
	 otherwise.
	 The GUI client/server protocol (VPN version) implements encryption on its own.
   * Using FWZ encryption, in FTP, RealAudio, and VDOLive connections, some packets
     are not encrypted. These packets only contain information needed to
     open a back connection from the FireWall to the PC (e.g., data connection
     in FTP.)
   * Local connections are not encrypted. A connection is "local" if
     both the IP of the PC (i.e., the client) and the IP of the destination
     (i.e. the server) are both inside the same encryption domain of
     the same firewalled gateway.
2. For users to create their own certificates ("Entrust/Create User"), the client 
   must be able to open a TCP connection with the CA on the relevant port (usually 709). 
   If this communication is blocked (by the firewalled gateway), users will need 
   to receive their certificates out of band. 
   This communication may be enabled for SecuRemote users (Client Encrypt rule).
   In this case, you should use existing credentials (password, etc.) to authenticate
   yourself, until your certificate is successfully created.
3. tracert to a destination in an encryption domain will have limited functionality
   if the encryption scheme encapsulates packets (IKE, FWZ with Encapsulation).
   All hops before the encrypting gateway will be shown without data (***), since
   they will not know how to decrypt the ICMP packet. ICMP data will be returned 
   only from the encrypting gateway and beyond.
4. SecuRemote has only limited support for environments using multiple hardware profiles.
5. New Security Policies will not be applied to existing connections.

Platform specific limitations
-----------------------------
1. This version of SecuRemote has been tested only on Windows 95 and Windows 98. 
   It may function correctly on Windows Millennium (ME). Windows ME will be validated
   at a later date. An update will be posted to our Support site.
   For Windows NT or Windows 2000, please download the respective version.
2. Memory restrictions: SecuRemote will, by default, allocate approximately 1.5Mb
   of "kernel" memory at boot time. This may be too much for your system to handle, 
   depending on installed memory, and on what other drivers are installed. 
   SecuRemote can run with less memory allocated, though performance may be 
   impaired. If you cannot re-boot after installing SecuRemote, then re-boot in 
   safe mode, and edit the registry (using regedit) as follows: Under 
   HKEY_LOCAL_MACHINE\SOFTWARE\CheckPoint\SecuRemote create a new string value 
   named "Memory", and give it a value less than "1500000". It is not recommended 
   to try values less than "100000".
3. SecuRemote on Windows 95b and Windows 98 will work only with Ethernet, Dialup
   and Token Ring adapters.

Known Bugs
==========
