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