Frequently Asked Questions

This section answers some frequently asked questions about SecuRemote.

12.1 Can I Use SecuRemote if My Client Is Subject to NAT?

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

12.2 Can Multiple SecureClient Users behind the Same NAT Device Access the Same Firewall?

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

12.3 How Do I Initiate an Encrypted Session to a SecuRemote Client?

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):

dport=5555,<dst,0>in userc_rules

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.

12.4 What if My SecuRemote Client Must Pass through a FireWall-1 Gateway?

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.

12.5 How Can I Use SecuRemote When I Am behind a Proxy?

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.

12.6 How Do I Disable SecuRemote at Startup?

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.

12.7 How Do I Tell FireWall-1 to Use a Different Port for SecureClient Topology Requests?

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.

12.8 Can I Share an Internet Connection and Use SecuRemote?

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

WARNING!

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.

12.9 Can I Install SecureClient on the Same Machine with a VPN Client from Another Vendor?

Some people have successfully made this work, but this is generally not recommended or supported.

12.10 Can SecureClient be Controlled via the Command Line?

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.

NOTE!

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

NOTE!

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

scc connectnowait profilename
scc cn profilename

scc disconnect
scc d

scc erasecreds
scc ep

scc status
scc s

scc userpass userid password
scc up userid password

scc passcert password file
scc pc password file

scc setpolicy [on|off]
scc sp [on|off]

scc suppressdialogs [on|off]
scc sd [on|off]

scc version
scc ver