readme.txt Driver File Contents (SecuRemoteXClients.zip)

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

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.
8. The SDL and SSO features, which replace the GINA DLL, can be configured to support 
   non-Microsoft GINA DLLs. For details please consult the release notes.


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.
7. In some hardware configurations, with more than one LAN card, DHCP did not 
   work reliably.

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\System\CurrentControlSet\Services\FW1\Parameters
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 (NT + 2000)
----------------------------------------
1. SecuRemote did not always recognize the need to re-negotiate IKE keys when the 
   client's IP address changed (disconnect and re-dial).
2. If SDL was enabled, SecureClient's "IP forwarding is enabled" appeared too early, 
   interfering with the logon process.
3. SecuRemote would fail to initialize if the etc/hosts file was read-only (on NTFS). 


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 can work only on Windows NT 4.0. For Windows 95 and 
   Windows 98, please download the 9x version. For Windows 2000, please download
   the appropriate version.

Known Bugs
==========
Download Driver Pack

How To Update Drivers Manually

After your driver has been downloaded, follow these simple steps to install it.

  • Expand the archive file (if the download file is in zip or rar format).

  • If the expanded file has an .exe extension, double click it and follow the installation instructions.

  • Otherwise, open Device Manager by right-clicking the Start menu and selecting Device Manager.

  • Find the device and model you want to update in the device list.

  • Double-click on it to open the Properties dialog box.

  • From the Properties dialog box, select the Driver tab.

  • Click the Update Driver button, then follow the instructions.

Very important: You must reboot your system to ensure that any driver updates have taken effect.

For more help, visit our Driver Support section for step-by-step videos on how to install drivers for every file type.

server: web2, load: 1.25