Configuring SecuRemote on FireWall-1

The general steps for configuring FireWall-1 to use SecuRemote are listed below and described in the subsections that follow.

  1. Configure the gateway object for SecuRemote.

  2. Create SecuRemote users.

  3. Define the client encryption rules and Remote Access community rules.

  4. Configure the global properties.

  5. Configure the Desktop Security policy and other relevant options.

  6. Install the security policy.

Configuring the Gateway Object for SecuRemote

Several areas of the FireWall-1 configuration relate to SecuRemote. At this time, I am going to touch on only what is necessary for basic SecuRemote functionality.

Similar to site-to-site encryption, you must configure the firewall object with the appropriate encryption types and encryption domain. If using the simplified VPN setup, you also need to add the gateway object to the Remote Access community. The Remote Access community was created by default. Traditional mode provides a checkbox for the Exportable for SecuRemote/SecureClient option, as shown in Figure 12.1. Exportable for SecuRemote is somewhat of a misnomer because selecting this option actually means that when a SecuRemote client connects to the management console to request topology (i.e., the encryption domain), this firewall's encryption domain will be provided to the SecuRemote client. If this checkbox is not enabled, a SecuRemote client will not be able to download the encryption domain.

Figure 12.1. Traditional mode IKE properties

graphics/12fig01.gif

In Traditional mode, you need only enable the appropriate type of authentication (Pre-Shared Secret or Public Key Signatures options). The actual parameters specific to each user are defined in each user's definition.

Creating Users for Use with SecuRemote

You can employ the same users you created for User Authentication for outbound access to authenticate SecuRemote users for inbound access. For more information on how to create users, see Chapter 8.

The Encryption tab in the user definition is where you can specify which encryption schemes are defined for this particular user (see Figure 12.2). On this tab, you can also specify whether to log or alert when this user logs in via SecuRemote.

Figure 12.2. User Properties, Encryption tab

graphics/12fig02.gif

Figure 12.3 shows the options presented for the authentication of IKE sessions.

Figure 12.3. IKE Phase 2 Properties, Authentication tab

graphics/12fig03.gif

On the Authentication tab, you specify which authentication methods are supported: passwords (authentication based on a pre-shared secret) or public keys (authentication based on certificates). You would select the Password option only if you want to use a fixed password. If you want to use an external authentication server, like SecurID or RADIUS, leave this box unchecked. Ensure that the Hybrid Mode option is enabled in the Global Properties section, Remote Access, VPN Basic frame.

On the Encryption tab, shown in Figure 12.4, you get to choose how this user will have his or her data encrypted in the IPSec session. (IKE parameters are defined on a per-gateway basis.)

Figure 12.4. IKE Phase 2 Properties, Encryption tab

graphics/12fig04.gif

A global property affects what encryption parameters users will have, specifically in the Remote Access, VPN Advanced frame (see Figure 12.5). If the Enforce Encryption Algorithm and Data Integrity option is checked, users on NG FP2 and above will be given these properties regardless of their individual settings. For pre-NG FP2 modules, they will be given whatever individual parameters they have defined.

Figure 12.5. Global Properties, Remote Access, VPN Advanced frame

graphics/12fig05.gif

If you wish to define a certificate for a user, click the user's Certificates tab to display the screen shown in Figure 12.6.

Figure 12.6. User Properties, Certificates tab

graphics/12fig06.gif

There are two ways to issue a certificate for a user: as a certificate file or as a reservation. In the former case, the certificate is generated on the management console and a copy is saved in the specified location on the SmartDashboard/Policy Editor station (click Generate and save). The administrator is then responsible for giving the end user the certificate. For certificates issued as reservations, the certificate is generated but is "reserved" for the end user to download from SecureClient. Clicking on the Initiate button and clicking OK in the warning dialog shows a screen similar to Figure 12.7.

Figure 12.7. User Properties, Certificates tab, pending certificate

graphics/12fig07.gif

The end user then uses the registration key to obtain the certificate using SecureClient. Right-click on the SecureClient envelope in the desktop tray and select Open or Configure. From the Certificates menu, select Check Point Certificates, then Create. A wizard takes you through saving the certificate to a file or smart card, then specifying the gateway IP and registration key. The certificate is then downloaded to the client and marked as usable in the management station.

Defining Client Encryption Rules and Remote Access Community Rules

The rules defined for client encryption are very similar to the rules you created for combining authentication and encryption in Chapter 11 except the action used for the rule is Client Encrypt. These types of rules are used in Traditional mode policies. With a Simplified mode policy, you instead create a rule in terms of the Remote Access community.

The first rule shown in Figure 12.8 permits your SecuRemote clients to fetch the topology from the management console. The FW1_topo service (TCP port 264) is what allows this. If you also are using the Policy Server functionality, FW1_pslogon_NG (TCP port 18231) allows this communication.

Figure 12.8. Traditional rulebase for SecuRemote access

graphics/12fig08.gif

The second rule allows VPN1_IPSEC_encapsulation, IKE, and ESP, which are all the various protocols used for encryption. This is necessary if the Enable FireWall-1 Control Connections property is unchecked.

The third rule actually permits the SecuRemote users to enter your encryption domain. The Client Encrypt action (see Figure 12.9) has properties that look very similar to those used for User Authentication. The only difference between this screen and the User Authentication screen is the checkbox, which for Client Encrypt requires that the desktop configuration options be set correctly on SecureClient. You can set these options in the Global Properties screen, Remote Access, Secure Configuration Verification frame (see the Setting Up Desktop Security section).

Figure 12.9. User Encryption Action Properties for the Client Encrypt action

graphics/12fig09.gif

Figure 12.10 shows a simplified rulebase for remote access.

Figure 12.10. Simplified rulebase for remote access

graphics/12fig10.gif

Configuring Global Properties

A number of items in the Global Properties screen affect client-to-site VPNs. Let's begin with the Remote Access frame, shown in Figure 12.11.

Figure 12.11. Global Properties, Remote Access frame

graphics/12fig11.jpg

The list below outlines the options available in this screen.

Topology Update: The options in this section control how often a client will attempt to update the topology of this site. This does not prevent the client from updating this information on its own. Automatic means that the client will poll at the specified interval to get an update. Upon startup refers to when the client system is initially booted. If the end user cancels the update request (which is possible), the topology will be updated on first connection to the site.

Authentication Timeout: The options in this section control how often a user must supply his or her credentials to remain authenticated to the VPN. If you choose to use the default value, authentication occurs as follows: Certificate users need not reauthenticate until SecuRemote starts because certificate passwords will be cached on the desktop. Static password users (FireWall-1 password and Hybrid IKE) need not reauthenticate until SecuRemote starts if you indicate that caching of static passwords on the client is allowed; otherwise, static password users must reauthenticate as one-time password users.

Enable tunnel refresh: If enabled, this option forces the client to send periodic "hello" packets back to the gateway. This facilitates connections to connected clients from within the encryption domain.

Encrypt DNS traffic: This option tells SecureClient to forward DNS traffic relating to configured domains to the encryption domain, encrypting the communication. In an Office Mode configuration where DNS servers are assigned, all DNS queries will be encrypted and forwarded to the configured DNS server(s).

Use backup Policy Servers on Logon failure: This tells a SecureClient system in Transparent mode to try other policy servers in the specified fashion. More information on Transparent mode is presented in the section on Office Mode configuration later in this chapter.

VPN-1 SecureClient?Desktop Security Policy expiration time: If SecureClient is unable to connect to a policy server after the specified period of time, and the client has a policy loaded, the client will revert to the "default policy," which is all Desktop Security rules that do not relate to a specific group or have Encrypt as an action.

Setting Up Desktop Security

To use the Desktop Security options, you must have the Policy Server component loaded on your firewall module(s) and have the gateway object configured with the Policy Server as being present on the module. A user group that is allowed to access the Policy Server must be specified in the Authentication frame (see Figure 12.12).

Figure 12.12. Defining a user group for the Policy Server

graphics/12fig12.gif

In the General Properties frame, ensure that SecureClient Policy Server is checked, as shown in Figure 12.13.

Figure 12.13. SecureClient Policy Server enabled in the gateway object

graphics/12fig13.gif

In the Global Properties screen, the Remote Access Secure Configuration Verification (SCV) frame has some additional relevant options (see Figure 12.14).

Figure 12.14. Global Properties, Secure Configuration Verification frame

graphics/12fig14.gif

These options are listed below.

Apply Secure Configuration Verifications on Simplified mode Security Policies: All Simplified mode policies with the Remote Access community require all SCV checks to pass.

Upon verification failure: In this section of the frame in NG AI, you can either block any attempt by clients that fail SCV checks or allow them anyway.

Policy is installed on all interfaces: It is possible to "unbind" SecureClient from an interface. In Windows 2000, you can simply uncheck the SecureClient box from a specific interface. In other Windows platforms, you can either disable or remove the bindings. If this check is enabled and SecureClient is not bound to all interfaces, SCV will fail.

Only TCP/IP protocols are used: Since SecureClient works only with TCP/IP, alternate protocols are considered undesirable. If another protocol is bound to an interface and this check is enabled, SCV will fail.

Configuration Violation Notification on client's machine: This section presents options for notifying the administrator (by generating a log) and/or the end user when an SCV violation has occurred.

Once you've defined these property screens, you need to define a Desktop Security policy. If you did not specify this type of policy when you initially created your policy, you can select New from the File menu and simply add Desktop Security to an existing policy, as shown in Figure 12.15.

Figure 12.15. Adding Desktop Security to an existing policy

graphics/12fig15.gif

Now the Desktop Security tab is present in SmartDashboard/Policy Editor. You need to create both inbound (to the client) and outbound (from the client) rules. The rules are similar to the standard security policy rules except for the following differences.

  • Inbound rules always assume a client is the destination and outbound rules always assume a client is the source. You can place restrictions on where that client is, however.

  • You cannot specify a VPN Community.

  • The actions are limited to Accept, Block, and Encrypt.

  • Logging is limited to being either on or off for a specific rule.

Figure 12.16 shows a rulebase that permits encrypted access only to the encryption domain and not to the Internet. To allow the client to access other Internet hosts as well, change Rule 4 so that its action is Accept, as shown in Figure 12.17.

Figure 12.16. Sample Desktop Security policy for allowing encrypted access only

graphics/12fig16.gif

Figure 12.17. Sample Desktop Security policy for allowing outgoing and encrypted access

graphics/12fig17.gif

These are, of course, simplistic examples. If you manage some FireWall-1 4.1 gateways or have end users who still use SecureClient 4.1, the allowed policy must be a simple one. Figure 12.18 shows the Early Versions Compatibility frame (under Remote Access in the Global Properties section) where you can define this policy.

Figure 12.18. Global Properties, Early Versions Compatibility frame

graphics/12fig18.gif

You can choose from the following policies.

Allow All: Enforce no specific policy.

Allow Outgoing and Encrypted: The user can initiate communication to the Internet (unencrypted) or the VPN.

Allow Outgoing Only: The user can initiate a connection to the Internet but not to the VPN.

Allow Encrypted Only: The user can initiate a connection to the VPN but not to the Internet.

The checkbox for enforcing required policy, if selected, means that the user will not be allowed into the network and the SecuRemote client will be configured with a different policy than what is specified in this frame. The client receives an error to this effect when he or she authenticates.

Installing SecureClient

Users must install SecuRemote before they can use it. There are different versions of SecureClient for Windows 9x/ME, Windows NT/2000, and Windows XP because the TCP/IP stacks are very different in these three versions of Windows. Make sure the correct version for your particular operating system is installed. Before running the enclosed setup.exe, read the README file to make sure you are about to install the correct version. You should also ensure that the version you are installing is the same as or later than your FireWall-1 installation (e.g., if your firewall is NG AI, SecureClient should be too).

During installation, you will be asked if you want to install SecuRemote or SecureClient. Installing SecuRemote provides basic VPN functionality only. There is no reason not to include support for the Desktop Security features by also installing SecureClient, even if you do not plan to use it right away.

Another question you will be asked during installation is if you would like to install only on the dial-up adapters or on all adapters. FireWall-1 recognizes only standard Microsoft Dial-up Adapters (or RAS in Windows NT/2000) as dial-up adapters, so if you need to use a special adapter (for AOL, for instance), install on All Adapters. During the installation process, your only choices are all or nothing; that is, you cannot choose to install interfaces only on specific adapters. In Windows 9x/ME, 2000, and XP, you can easily change the interfaces SecuRemote is bound to by modifying the network properties after SecureClient has been installed. Windows NT does not provide a way to change the interfaces to which SecureClient is bound.

What does it mean if SecuRemote is bound to a particular interface? Simply put, if SecuRemote is bound to the interface, it can send encrypted traffic through it. This may have unintended consequences in some circumstances. Generally, binding SecuRemote only to those interfaces you intend to use to communicate with a remote encryption domain is the right thing to do. Binding SecuRemote to an interface does not preclude you from using that interface for nonencrypted traffic. Note that an administrator can change this behavior with the Desktop Security features.

You must reboot in order for SecuRemote to be usable. In some cases, you will not be able to reboot correctly after installing SecuRemote. These problems are discussed in the Troubleshooting section later in this chapter.

Once Windows comes up and you log in, you will see an icon in your taskbar that looks like this: graphics/12inl01.gif. It lets you know that SecuRemote is active. The icon animates when encrypted data is being sent to a remote site. Right-click on this icon and select Open or Configure, depending on which mode the client was installed in. You will see a screen similar to Figure 12.19.

Figure 12.19. VPN-1 SecureClient window

graphics/12fig19.gif

This figure shows a blank configuration with no sites. To add a site, select Create New from the Sites menu or click the New Site icon. Enter the site IP address (which is usually the firewall) and a "nickname" for the site, as shown in Figure 12.20. Click OK.

Figure 12.20. Starting to create a new site

graphics/12fig20.gif

At this point, you will be prompted for authentication. Enter the appropriate username or password or specify a certificate. Figure 12.21 shows the dialog for the username and password.

Figure 12.21. Authenticating with SecureClient

graphics/12fig21.gif

Figure 12.22 shows a fingerprint validation screen that appears the first time you connect. This fingerprint should match what is shown in the ICA (or other certificate authority) certificate when "viewed" in SmartDashboard/Policy Editor. If it does match, accept it by clicking OK.

Figure 12.22. Verifying the certificate fingerprint

graphics/12fig22.gif

After you have authenticated successfully, you will see a dialog similar to Figure 12.23 that says what method was used to authenticate you (in this example, FireWall-1 Password ).

Figure 12.23. Successful SecureClient authentication

graphics/12fig23.gif

Finally, you can click OK in the Create New Site dialog when you see the Last Update field (see Figure 12.24).

Figure 12.24. Creating a new site after the topology download

graphics/12fig24.gif

Now that you've added the site, you can attempt to connect to it. Depending on whether the site requires login to a policy server or uses Office Mode, you might need to change the connection mode in the client. From the SecureClient menu, select Configure Client Mode from the Tools menu. You can choose either Transparent mode or Connect Mode. For a policy server login or Office Mode configuration, you need to configure the client in Connect Mode. If you change modes, you will have to restart the client. Select Stop VPN-1 SecureClient from the File menu to do this.

There are a couple of options you can configure on the client that affect how the VPN connection takes place, such as forcing UDP encapsulation, IKE over TCP, or Visitor Mode. These options are discussed in the Troubleshooting section.

All of this might be confusing to an end user. Fortunately, you can prepackage a custom version of SecureClient with the site definition and appropriate settings. The SecureClient Packaging Tool, discussed later in this chapter, enables you to do this.