SecuRemote and Secure Client Introduction

[roadrunner]

SecuRemote and Secure Client Introduction
SecuRemote and Secure Client are really just two different names for the same piece of software: Check Point's VPN client software for Microsoft Windows. This software is designed to allow a single Windows client to transparently initiate a client-to-site VPN with a Check Point firewall. References to SecuRemote also include Secure Client, which has some additional features that allow network administrators to enforce a security policy on the client. If the client has a policy that does not match the one prescribed or is configured in an undesirable manner, the client can be denied access to the VPN. Thus references to SecuRemote include Secure Client, but not necessarily the other way around.

Much like FireWall-1 on Microsoft Windows, SecuRemote binds to the Windows TCP/IP stack. This allows it to intercept connections destined for a remote encryption domain and encrypt them. Likewise, it can decrypt incoming encrypted packets. There is also a user-level process that allows you to fetch the remote encryption domain, be authenticated, and otherwise control SecuRemote. This manifests itself on the client as a little envelope in the Windows taskbar.

Much of the planning that goes into using SecuRemote is pretty much the same as planning for site-to-site encryption; that is, you still have to define an encryption domain and configure network objects. However, you can do things on a user-by-user basis. For example, some users can use different encryption parameters. You can restrict some users from going some places but not others. You get all the flexibility of User Authentication with encryption.

One issue you do have to worry about with SecuRemote is end-user support. Although the client is generally easy to install and use, sometimes it does not go well. While most general installation problems have gone away, exotic network configurations or hardware can sometimes confuse SecuRemote or cause issues with your TCP/IP stack. I've encountered more than my share of destroyed TCP/IP stacks over the years. Also, users may not know what to do when various dialog boxes appear or even fully understand what is going on, especially if they are behind a NAT device.

SecuRemote uses one of three methods to exchange keys and encrypt data, depending on what you choose:


IKE: Allows for DES or 3DES to be used to encrypt the packets. Packets are encapsulated in IP Protocol 50 (i.e. IPSEC) or UDP port 2746, depending on whether or not UDP Encapsulation is used.
FWZ without encapsulation (available in NG FP1 and before): Uses FWZ1 or DES to encrypt the packets. Only the data portion of the packet is encrypted. The IP headers are left alone.
FWZ with encapsulation (available in NG FP1 and before): Same as above, except packets are encapsulated in IP Protocol 94 packets.
Visitor Mode (NG AI R54 and above): Tunnels using a standard HTTPS stream. By default, runs over port 443, but can use any port.
When using Transparent Mode in NG, or using 4.1 and earlier, the SecuRemote client will, as it deems necessary, establish an encrypted session with the firewall. Before it can do this, the SecuRemote client needs to know what hosts it can talk to encrypted and what the encryption keys are. This is accomplished by fetching the site from the remote server. This happens on TCP port 264 to the firewall module. SecuRemote 4.0 used TCP port 256 to the management station.

In NG when using Connect Mode, the connection to the encryption domain is controlled by the end user. The connection dialog looks very similar to a dial-up networking. The user can select the site he wishes to connect to, change options, and then connect. Optionally, the start of the VPN connection can be tied into the domain logon in Windows 2000/XP.

Once SecuRemote determines that it needs to encrypt traffic to the firewall, authentication is performed. Authentication can be a simple password, SKey (if NG FP3 and before), SecurID, or a certificate, but all data between the firewall and the client is encrypted so the password (even if it is a simple password) is not divulged in the clear. This happens between the firewall and the client on UDP port 259 (source port and destination port) if FWZ is used or on UDP port 500 if IKE is used.

-- PhoneBoy - 10 Apr 2004


FAQForm
FAQs.Class: SecureClientFAQs
FAQs.OS:
FAQs.Version: