This section answers some frequently asked questions about SecuRemote.
Unless you specifically disable UDP encapsulation, clients should work just fine if they are subject to NAT. However, clients behind some NAT routers or DSL connections may have issues. See FAQ 12.15 later in this chapter for troubleshooting hints.
If your firewall was upgraded from FireWall-1 4.1 or earlier and you did not enable SecuRemote clients to work over NAT, double-check that userc_NAT and userc_IKE_NAT are both set to true in $FWDIR/conf/objects_5_0.C. If they are not, you should change these properties. See FAQ 4.2 for details on how to do this. The commands in dbedit to make these changes are:
dbedit> modify properties firewall_properties userc_NAT true dbedit> modify properties firewall_properties userc_IKE_NAT true dbedit> update properties firewall_properties
Generally speaking, yes. However, some routers (most notably ones by Nexland/Symantec) attempt to track IKE negotiations. Instead of giving the outgoing IKE packet a different source port, the router will keep the packet at port 500. While this allows some IKE implementations to work, it can cause a problem with FireWall-1 NG when using UDP encapsulation and when multiple clients from behind the same NAT router talk to the firewall.
Use the dbedit utility to set the udp_encapsulation_by_qm_id property to false, as shown below. (You may also do this with the Database Tool, also called the GUIdbedit tool, or with manual editing as described in FAQ 4.2.)
dbedit> modify properties firewall_properties udp_encapsulation_by_qm_id false dbedit> update properties firewall_properties
Open Smart Dashboard/Policy Editor and click Yes when asked to update your topology data due to inconsistencies. Install the security policy
SecuRemote was designed to handle encrypted connections initiated only from the client side. To handle the possibility of connections back to the client, FireWall-1 keeps track of IPs that are SecuRemote clients in a table called userc_rules. As long as the SecuRemote client has initiated a connection to the encryption domain within the previous 15 minutes, its IP address will be listed in this table. Any outgoing connection that is accepted by FireWall-1 is checked against this table. If the connection is going to an IP in this table, it is automatically encrypted. Note that this occurs despite the fact that the action of the rule is Accept versus Encrypt or Client Encrypt. If you want to allow certain services out, but only to those machines that have authenticated with SecuRemote (i.e., you wouldn't want to permit these services outbound in an unencrypted fashion), you can make this work.
In the case of using VPN Communities, you simply need to create the appropriate rule using your Remote Access community in the If Via column. This will allow the service only if the destination currently has a VPN established with the firewall.
In a Traditional mode policy, you need to create the service srMyApp of type Other. Use 6 as the protocol number and have the following in the Match field (assuming for a moment that myApp is a TCP service on port 5555):
Then simply put this service in an Accept rule. This rule matches only if it is going to the correct port and to an IP address that has recently initiated an encrypted session through the gateway.
Chapter 14 provides a more detailed explanation of what this code does.
In some circumstances you may need to run SecuRemote to access an encryption domain where the client is behind a Check Point FireWall-1 gateway. Assuming that UDP encapsulation is enabled and you are not doing address translation (or can work around it, as explained in FAQ 12.1), part of what needs to be done depends on whether or not the remote FireWall-1 gateway is configured to use encapsulation for SecuRemote connections.
TCP port 264 from client to firewall is needed only to fetch and update the site information.
TCP port 18231 is used if SecureClient needs to authenticate with a policy server.
UDP port 18234 is used for testing VPN tunnel availability in NG FP1 when Office Mode is enabled.
UDP port 500 is needed to negotiate encryption keys when IKE is used.
UDP port 2746 is needed when UDP encapsulation is used.
IP protocol 50 is needed when IKE without UDP encapsulation is used.
Figure 12.42 shows a rule that permits all of these services.
Generally speaking, the protocols used by SecureClient do not work well through a proxy. However, NG AI supports Visitor Mode, which permits clients to connect using a standard HTTP proxy. This is configured in the gateway object in the Remote Access frame. Figure 12.43 shows the configuration options.
The administrator enables Visitor Mode support, selects the service on which the Visitor Mode service will run (the port for HTTPS is recommended), and sets the allocated IP address FireWall-1 will use to bind the special service that will listen on the specified service port. This is necessary only if another service running on the firewall platform must also bind to this same TCP port number.
Once these settings are changed, a policy installation is required for these changes to take effect.
In SecureClient NG AI, when needed, you will configure the client to use Visitor Mode. From the Tools menu, select Visitor Mode. You will see a screen similar to Figure 12.44.
This screen includes the following options.
Detect proxy from Internet Explorer settings: Use the same proxy settings that Internet Explorer would use. Even if you use a proxy auto-configuration file, you may have to manually define a proxy server and port in Internet Explorer for this option to work.
Manually define proxy: If using a different browser (e.g., Mozilla) and an HTTP proxy server is needed, define the IP address and port of the proxy server to use.
No proxy/transparent proxy: Use this setting if either no proxy is needed or the proxy functions transparently (i.e., without requiring the end-user machine to terminate the HTTP connection on the outbound firewall).
Once the client and firewall have been configured accordingly, Visitor Mode will allow access through a standard HTTP proxy.
On a Windows 9x/ME/NT platform, use msconfig to prevent fwenc.exe from running at startup. On Windows 2000/XP, you need to disable the Check Point SecuRemote service in Services.
On your firewall module, add the following line to $FWDIR/conf/ports.conf, which you may have to create if it doesn't exist:
fwd_gettopo = X
Replace X with the value for the port number you wish to use.
You also have to change two other things on your management station. Change the definition for the FW1_topo service to match the new port and edit $FWDIR/lib/services.def, changing the following line:
#define FWD_TOPO_PORT X
Perform a cprestart on the firewall module and reload the policy from the management station.
It is common to want to run SecuRemote and some sort of NAT program on the same system, like SyGate, WinRoute, or Windows Internet Connection Sharing. This would theoretically allow your client to act as sort of a site-to-site VPN for machines behind the client. I have not seen or heard of any NAT solution that works with the NG version of SecureClient, particularly in Office Mode.
Standard proxy servers appear to work okay. For instance, I've used two different proxies from http://www.analogx.com as well as Squid (NT version available at http://www.serassio.it/SquidNT.htm), DeleGate (http://www.delegate.org), and Stone (http://www.gcd.org/sengoku/stone/).
Although there is nothing to prevent you from using a proxy server on a SecuRemote client, this configuration could potentially create a hole through which a hacker could access your internal network using a "trusted source" (i.e., the SecuRemote client).
A hardware solution to this problem would be to use a SofaWare-based platform as your home gateway. This can act like a SecuRemote client and allow all of your home machines to access the corporate network.
Some people have successfully made this work, but this is generally not recommended or supported.
SecureClient NG FP3 and above contain a command-line interface (CLI). The scc binary in C:\Program Files\CheckPoint\SecuRemote\bin allows you to set authentication credentials, connect or disconnect from a site, check status, and more. When you switch into command-line mode with the command scc setmode cli, SecureClient will restart in a command-line mode. The SecureClient "envelope" will still be in the system tray and will still blink when talking to the encryption domain, but you will not be able to access any menus from the envelope. Table 12.1 documents the commands available from the CLI.
The Linux version of SecuRemote uses these commands to control the client. As of this writing, no GUI is present for the Linux version of SecuRemote.
The only thing missing from the command-line mode is the ability to add or update site information. It also currently does not support automatic site updates. Other than these limitations, command-line mode works well enough.
On one of my systems, I have SecureClient set up with a batch job that I periodically run to refresh my VPN connection. The system is accessible via the Windows 2000 Telnet server, so I rarely need to see the screen on this particular platform. This script breaks the VPN connection, sets my credentials to the provided password (actually a SecurID passcode), connects to the site using the established VPN profile, checks to see that it actually did connect with an ipconfig just to make sure I got assigned, and finally erases the credentials. Erasing the credentials is necessary in my case because when the VPN requires reauthentication, my previously entered credentials will be used. Those credentials will be wrong since it's a SecurID passcode (it changes every 60 seconds) and it will eventually "lock" my SecurID card for too many failed attempts! Here's the code I use for the batch job:
scc disconnect scc up dwelch %1% scc connect "VPN Profile" scc status ipconfig scc ep
Technically, one-time password schemes are not supported when authenticating via SecuRemote's CLI. However, this scheme allows my one-time password to work well enough.
scc connect profilename scc c profilename
Establishes a connection to the specified profile. If the name has spaces in it, put the name in quotes (e.g., "Nokia Access Point"). Credentials should be specified prior to executing this command.
scc connectnowait profilename scc cn profilename
Establishes a connection asynchronously (i.e., the command prompt returns immediately versus waiting until authentication succeeds or fails). Credentials should be specified prior to executing this command.
scc disconnect scc d
Disconnects the currently active session.
scc erasecreds scc ep
Tells SecureClient to "forget" your supplied authentication requirements.
scc status scc s
Displays the current connection status.
scc userpass userid password scc up userid password
Sets the login credentials to the specified userid and password.
scc passcert password file scc pc password file
Tells SecureClient to use the certificate file specified by file (full path). The password is used to unlock the certificate.
Stops and restarts the SecureClient service.
scc setmode [cli|trans|con]
Sets the mode of the client to either Transparent mode (trans), Connect Mode (con), or enable cli mode (cli). To disable cli mode, stop SecureClient and change connect_api_support to false in C:\Program Files\CheckPoint\SecuRemote\database\userc.C.
scc setpolicy [on|off] scc sp [on|off]
Tells SecureClient to enable or disable the default policy. If on or off is not specified, the status of the policy will be shown.
Starts the SecureClient service.
Stops the SecureClient service.
scc suppressdialogs [on|off] scc sd [on|off]
Indicates whether to prevent pop-ups from Secure Client that ask for authentication. Useful in a totally command-line-driven setup.
scc version scc ver
Shows the version of SecureClient.