Virtual private networks (VPNs) have been around for a long time, and with time, they have increased in popularity. If you haven’t configured remote VPN access on your Check Point NGX R65 FireWall-1/VPN-1 yet, this chapter will take you through the different methods and configuration options. Several different methods currently exist; however, SecuRemote, SecureClient, and SSL Network Extender (SNX) are the most popular.
SecuRemote is a client-side application that allows authenticated users to enter the network to work as though they were directly connected at the office. SecuRemote offers split tunneling by default, so when a user is connected to the LAN, he can also connect to the Internet through his Internet service provider (ISP). SecuRemote comes free of charge with the purchase of a FireWall-1/VPN-1 license.
SecureClient offers the same functions as SecuRemote, but adds more flexibility and configuration options. With SecureClient, you can install a client-side desktop security policy that will protect the remote client while connected on the VPN. This desktop security policy will ensure that when a user is connected to the NGX R65 FireWall-1, the client will be protected from any possible hackers on the Internet. SecureClient can also prohibit Internet access from users’ ISPs and have them route all traffic through the corporate firewall according to customizable desktop security rules. When the client disconnects from the VPN, Internet activity is returned to normal and the user can route traffic through his ISP.
SNX allows remote VPN users to connect without a client installed on their PC, as was the requirement for SecuRemote and SecureClient. SNX is Check Point’s clientless VPN solution which works on Windows and most flavors of Linux. The popularity of a clientless solution is rampant and is often a common choice for users connecting from shared computers where they cannot install applications with administrator privileges.
SecuRemote is a Check Point IPSec client-side application that permits you to connect to your network in a secure manner once you’ve been authenticated. The supported encrypted levels range from the Data Encryption Standard (DES) to AES-256 (the higher encryption algorithm is recommended). However, it is more CPU intensive, thus creating a heavier load on the gateway and client. SecuRemote will permit split tunneling while connected to the corporate firewall and will not secure the client PC from any external unauthorized access attempts.
The first step in using SecuRemote is to decide where you want to allow your remote VPN users to connect. This may be a network(s) or a single host that your gateway protects. Check Point uses a VPN encryption domain for VPN site-to-site and remote user access. Each VPN method can have a different VPN domain, which is strongly recommended. The definition of a VPN domain is essential for ensuring that the client is aware of the networks to which it can connect. When a user connects to the gateway and is authenticated, the gateway will send to the remote user the VPN domain information through the Secure Sockets Layer (SSL) protocol. The VPN domain information is stored on the client PC in a file named userc.C. When a remote client tries to reach inside the protected network of the gateway, the SecuRemote routing daemon will verify against this file before the PC’s network interface card (NIC) to see whether it is the destined network. If the destined network resides behind a known site or gateway, it will ask for authentication.
To enable your firewall to start using SecuRemote, you must ensure that your firewall is VPN-enabled (see Figure 6.1).
Once you have VPN-enabled your firewall, you must make your gateway a member of a VPN remote community. A community is a set of global properties that can be shared among several gateways. Select Your gateway object | VPN | Add | Add This Gateway To Community | RemoteAccess, as shown in Figure 6.2.
The VPN domain is essential to the inner workings of your remote access configuration. Without the VPN domain, the end-user will never know which network(s) or host(s) is behind the gateway. By default, Check Point enables the VPN domain using the Internet Protocol (IP) addresses behind the gateway based on the topology information. This means that if the gateway has only one internal interface with an IP address of 10.1.1.1 and a subnet of 255.255.255.0, remote users will be allowed to connect to all 10.1.1.x addresses. The VPN domain in Figure 6.2 would comprise all 255 possible addresses.
Tools & Traps...: VPN Domains
You must ensure that you define the VPN domain manually for your remote users. Don’t let the system automatically create it for you. Create a simple group and place all network(s) or host(s) within this group. Then, define the group in the Specify VPN domain field for the remote access community (see Figure 6.3). By default, the VPN domain for the remote access community inherits the same values from the site-to-site VPN; create two different groups if needed, one for each.
The remote access community must be configured and should now include your gateway object. The other two options required for the remote access community are the user groups and a general description of the remote access community. Assuming your users are already defined and are part of a user group, you must now create a rule within the security policy that will permit the connection. The rule base must specify the source as being a group of user(s) toward a destination which must be part of your VPN domain and part of the remote access community. The services permitted for the remote users should be defined; however, any service may be used temporarily for testing purposes. The remaining options within the security rule are optional, and once completed, you must install them on the gateway. Figure 6.4 shows an example rule permitting a user within the Mobile-VPN-user group to reach the Internal-net-group with any services. We will use the rule example in Figure 6.4 throughout this chapter.
Once you have installed the security policy, the end-user must install the SecuRemote software and follow a few steps to establish communication with the gateway. You can find the latest version of SecuRemote at www.checkpoint.com/downloads; SecuRemote and SecureClient are part of the same package and differ only by an option during the installation process (see Figure 6.5).
Toward the end of the SecuRemote/SecureClient installation, the computer requires a reboot. If the installation was successful, you should see an icon in the taskbar that resembles a yellow key. To start the client connection, you can double-click the icon in the taskbar and follow the initial setup instructions. The first step in configuring the SecuRemote client is to define a site (see Figure 6.6). A site is the IP address of the corporate gateway. You can decide to record the routable IP address of your gateway in your domain name system (DNS) record to allow easier site configuration for your clients. Your clients would then have to input only the DNS name instead of an IP address, which clients often forget. Examples of DNS settings include vpn.abc.com; remote.ab.com, and gatekeeper.abc.com. However, a drawback to obvious name conventions is that they may allow hackers to pinpoint the entry point into your VPN network. Something subtler such as syngress.abc.com may be suitable.
After you create the VPN site, you will be asked what type of authentication method you are using, and then you will be asked for your username and password. If you authenticate properly, the gateway will send the VPN domain topology through SSL to your client PC. Remember to look at this file, for it is the core of Check Point’s client VPN solution. Once the site is created, you will be able to reach the internal VPN domain which will be encrypted from your client PC to the gateway. Once the packet reaches the gateway, it will be decrypted and sent in the clear toward the VPN domain destination. The return packet will arrive in clear text until it reaches the internal interface of the firewall, where it will be encrypted and then sent back to the client.
Sometimes remote users have the same internal network IP scheme that you are using within the VPN domain, which may cause problems with the gateway. Home networks will often be configured with a network IP range of 192.168.1.0–192.168.1.255. You can resolve this configuration by enabling the use of IP Pool NAT for remote VPN connections. You enable IP Pool NAT through Global Properties | NAT – Network Address Translation|Enable IP Pool NAT. Once you have enabled IP Pool NAT, you will have the configuration options on your gateway object under NAT | IP Pool NAT. Figure 6.7 shows the various options available for IP Pool NAT.
Prior to enabling the use of IP Pool NAT, you must create a network object with a subnet that is different from any other subnets you may encounter. Then you must select the newly created network object to identify which IPs the gateway will lease to its remote clients, and possibly even gateway-to-gateway connections should you encounter the same problem. When identifying the connections in SmartView Tracker, the source IP of the remote user should now be one from the IP Pool NAT network.
As noted earlier, SecureClient includes all the features of SecuRemote, plus some additional features and flexibility. To activate some of the SecureClient features, you must activate the SecureClient Policy Server on the gateway object. Once you have activated the SecureClient Policy Server, you must add a policy package to the current security policy if you want to use the Desktop Policy if it wasn’t already there. You can do this by selecting File | Add Policy Type to Package | Desktop Policy through the SmartDashboard. At this point, a Desktop tab will appear within the SmartDashboard. Not everyone uses the full extent of SecureClient with the Desktop policy often being left out.
SecureClient also enables users to assign an IP address to remote users statically by username, by the internal Dynamic Host Configuration Protocol (DHCP) server, or via Office Mode, similar to IP Pool NAT in SecuRemote. An optional parameter for Office Mode is to assign internal DNS and Windows Internet Name Service (WINS) servers, which comes in very handy for network shares and domains.
With SecureClient, split tunneling is now optional. Remote users no longer have to use their own ISP for Internet browsing. Furthermore, you can force remote users to route all traffic through the VPN and use the corporate policies and security measures to protect the end-user while connected. Four conditions must apply to route all traffic through the gateway: Office Mode must be used, Hide NAT must be done on the Office IP Pool Range allocated, the Allow SecureClient to route traffic through this gateway option must be enabled, and a security rule must be enabled to allow the source Office Mode range to leave the corporate firewall. The process of routing all traffic through the gateway is called Hub Mode, and you can enable it on the gateway object itself by selecting Remote Access | Hub Mode Configuration | Allow SecureClient to route traffic through this gateway. Figure 6.8 shows where to activate the feature.
Desktop policies, which resemble the familiar look of security policies, are easy to create. You can configure them through the Dashboard on the Desktop tab. The Desktop tab has two sections: Inbound and Outbound. Inbound refers to all traffic destined to the remote user PC, and outbound refers to anything leaving the client PC. Figure 6.9 shows a desktop policy with three inbound rules and four outbound rules.
Desktop security policies allow granular control to all SecureClient users who are connecting. Logging mechanisms are built-in on the client so that any desktop policy that is accepting or dropping traffic is logged and easily audited. On the client side, right-click on the SecureClient icon and select Tools | Launch SecureClient Log Viewer.
Office Mode enables the remote VPN user to receive an IP address designated by the Check Point gateway, internal DHCP server, or RADIUS server. Office Mode options are located on the gateway object under Remote Access | Office Mode. You can enable Office Mode for all users or for a single group of users. By default, the IP lease duration is 15 minutes; however, you can increase this number to a more reasonable one over time.
It is possible to assign static Office Mode IPs to users. However, this requires that you modify the ipassignment.conf file located on the gateway at $FWDIR/conf. Always back up your files prior to modification in case you make a mistake and you have to roll back the configuration. Here is an example of how to assign the user syngress an IP address of 192.168.137.40:
Corporate-gw addr 192.168.137.40 syngress
The first item, Corporate-gw, is the gateway name as it appears in the Dashboard. Instead of using this, you can use the gateway IP address or an asterisk (*).
The second item, addr, is the descriptor; this can also be range or net. In the preceding example, we wanted to assign a static IP to a specific user, so we used addr.
The third item is the IP address that will be assigned to the user. The last item is the username to which we are reserving the IP address. Note that using the ipassignment. conf file isn’t very user-friendly and you must modify it manually every time you want to add a reservation as well as a policy install.
Advantages to using Office Mode are the ability to receive a routable IP address from your LAN, and the fact that you may receive internal DNS and WINS servers. Browsing the network neighborhood also becomes a lot easier, as all the names are resolved automatically from the client’s perspective. This advantage may also bring some disadvantages, because it will add a load to the VPN. If you plan to roll out a large number of SecureClient users, try to benchmark the load this may bring to your firewall. You may want to add a faster machine or add software accelerators.
Another advantage of using Office Mode is that it allows you to route the Office Mode range internally. From within the LAN, you can reach an Office Mode Secure Client user. This is practical when using soft phones or whenever your administrators want to debug remote VPN users.
Visitor Mode allows remote SecureClient users to connect to the gateway over SSL on port 443. Often when a remote user is traveling and trying to connect through a hotel, many ports are blocked and only a select few are open. Transmission Control Protocol (TCP) port 443 is almost always open, as it is a commonly used port for secure Web browsing. Visitor Mode for remote SecureClient access must be enabled directly on the gateway object, as shown in Figure 6.10.
Visitor Mode configuration allows you to select on which interface it will listen for incoming connections. If you have several external interfaces, you may want to select only one, or you may want to select all interfaces, which is the default. Once you have enabled Visitor Mode, the client will have to decide whether to connect using Visitor Mode or via the default IPSec mode by using connection profiles.
With SecureClient, you can use connection profiles to give your users even more flexibility by allowing them to choose which type of profile to use. Several connection profile combinations are available, including Visitor Mode, Hub Mode, Policy Server, Multiple Entry Points (MEPs), and Backup Gateways. You can create a connection profile by selecting Manage | Remote Access | Connection Profiles through the Dashboard. Figure 6.11 shows the initial configuration option for a connection profile that will be configured to use Visitor Mode.
We will discuss the remaining options in Figure 6.11 later in this chapter. For now, note that it is important to enter a client-side description that all users will understand when they are selecting profiles. Using a difficult name will generate support calls, so give an obvious profile name to your remote users. The advanced options for connection profiles are Support Office Mode, Connectivity enhancements (NAT traversal tunneling or Visitor Mode), and Hub Mode configuration (route all traffic through gateway), as shown in Figure 6.12.
When the user will be creating a site and connecting to the corporate gateway, it will receive new topology information through SSL and will now be able to select which profile it can use. Figure 6.13 shows a SecureClient that has successfully created a site and has received the options to select from two different connection profiles.
If you want to create several different profiles for users, ensure that you have educated your remote users on the different types of profiles available.
Installing client-side applications to grant remote users VPN access may be a troublesome task for many organizations. Most of the PC population is still Windows-based, and therefore, Check Point has to support the built-in VPN client from Microsoft, which complies with the Layer 2 Tunneling Protocol (L2TP). You can configure L2TP support directly on the gateway object under Remote Access. On the general Remote Access page of the gateway object, you must enable support for L2TP, and it’s only applicable when Office Mode is active. Once enabled, you have two authentication method options: MD5-Challenge and Smart Card (certificates). When you have activated the support for L2TP, don’t forget to install the security policy. Security policies must always be installed for changes to take effect.
SNX (SSL Network Extender) is a VPN solution that doesn’t require a client to be installed on the remote user computer. The idea behind this is to allow remote users to use their Web browser, such as Internet Explorer, to make an HTTPS connection directly to the firewall. Once they make the HTTPS connection to the firewall, a pop-up box will appear and they are prompted to enter their credentials.
SNX is supported on various operating systems and browsers. Some operating systems such as Ubuntu are not officially listed as a supported OS; nevertheless, you can use Ubuntu, and we will discuss later how to activate SNX with this OS. The operating system prerequisite for clients using SNX is one of the following: Windows 2000, XP, Vista, Linux RHEL 3.0, Linux Suse 9 or later, Red Hat Linux 7.3, or Mac OS X Tiger. Although SNX does not officially support many flavors of Linux, an advanced end-user can configure such support. Remote clients must have the ability to use ActiveX or a Java applet because SNX will download either one for connectivity. Check Point officially supports Internet Explorer, Firefox, and Safari. You should verify with Check Point for any updated browser and operating system support.
You activate SNX directly on the Check Point gateway object under Remote Access | SSL Clients. Once there, you have to enable SSL Network Extender; however, keep in mind that Visitor Mode must be enabled prior to this activation. Once SSL Network Extender is activated and the proper rules are in place, the client is ready to open an HTTPS session directly on the corporate-gw interface. Remember that you can activate all interfaces through Visitor Mode, or you can select just the external interface. Figure 6.14 shows the pop-up box from Internet Explorer once the remote client has made the HTTPS connection toward the gateway.
Notice that Figure 6.14 is in French; Check Point supports multiple languages for any remote offices that you may have. In addition to French, SNX also comes bundled with the following languages: Brazilian Portuguese, English, German, Hebrew, Italian, Japanese, simplified Chinese, Spanish, and traditional Chinese. The languages are defined in /opt/CPsuite-R65/fw1/conf/extender/language/chkp. Switching to French from the default language of English requires the following manual change to the index.html file located on the gateway under the /opt/CPsuite-R65/fw1/conf/extender directory:
function set_initial_cookie()
{
try {
if(getCookie("language") == null)
setCookie("language","french");
if(getCookie("skin") == null)
setCookie("skin","skin1");
} catch (e) {}
}Once the user has successfully authenticated to the gateway, the SNX Connection Details window will appear and will look similar to Figure 6.15 (depending on your operating system). Notice that the Office Mode IP is displayed and that this user has a reserved IP address which was defined in the ipassignment.conf file.
You can find other options for SNX in the Global properties by selecting Policy | Global Properties | Remote Access | SSL Network Extender. From here, you can select User Authentication method, Supported encryption methods, Client upgrade upon connection, Client uninstall upon disconnection, and (ICS) Integrity Clientless Security. Changing the default values and supporting higher encryption methods is recommended. By default, the Client upgrade upon connection option is set to ask the user; it is recommended that you set this to Always Upgrade. With this option, the client is not bothered by possible errors when connecting.
There are plenty of advantages to using a clientless VPN solution, including SNX; however, be advised that there are some disadvantages as well. With SNX you cannot use connection profiles, Hub Mode, or desktop policies, as you can with SecureClient. SNX will also create a heavier load for traffic; in addition, you can expect to see a longer delay.
The demand to have a backup entry point for remote VPN access has risen over time and is possible with NGX R65. Backup gateways can be used to access internal corporate information if the primary gateway is not available. The backup gateway should be on a different ISP and managed by the same SmartCenter Server (SCS) for better backup plans. The backup gateway should have its own VPN domain defined, as there shouldn’t be an overlap between the two gateways; otherwise, you will not be able to install the security policy.
You must enable the backup gateway feature through Global Properties | VPN | Advanced. Once enabled, the backup gateway should be represented in each VPN community in which the primary gateway is currently being used. On the primary gateway object under the VPN, a new feature will appear. At the bottom will be an option to select Use Backup Gateways. Once this feature has been selected, you may select the backup gateway from the pull-down menu. Asymmetric routing may become an issue when using backup gateways, so IP Pool NAT must be defined on each gateway participating in the VPN. If you are configuring backup gateways for SecureClient users, you should use Office Mode for ease and simplicity.
Multiple Entry Point (MEP) VPNs are an addition to the backup gateway configuration. However, clients will now be using a probing method to select through which gateway it will be connecting. With a backup gateway, there is always a primary and a backup. MEP enhances VPN clients to determine by which entry point they will choose to come in. SecureClient can use three different mechanisms to determine with which gateway it will choose to end its encryption: first to respond, Primary-Backup, or Load Distribution.
The mechanism that responds first must have at least two gateways, and these gateways should be configured to have the same VPN domains. If all participating members have the same VPN domain, SecureClient will use the first-to-respond method to determine with which one it will encrypt.
Primary-Backup requires the configuration of a connection profile. The connection profile will consist of a primary gateway and, at the lower part of the connection profile setting, a backup gateway. Figure 6.16 shows a primary gateway object, Corporate-gw, with syngress defined as the backup.
MEP Load Distribution will dynamically set remote clients to randomly select the active gateway to set up the VPN. To activate Load Distribution, select Global Properties | Remote Access | VPN – Basic | enable the Load Distribution option.
As described earlier in this chapter, whenever a remote client connects to the gateway to start a VPN session, the client receives the VPN domain topology information and many other values which are stored on the client in the userc.C file. By default, this file is in clear text; however, when compiling a VPN client package with the Packaging tool, you have the option to encrypt the file. We could fill an entire chapter discussing this one file, but instead, we’ll take a quick look at the most common options we’ve seen from our experience:
manual_slan_control. With this option a SecureClient user can disable the desktop security policy. By default, this option is set to true; however, you may decide you don’t want your remote SecureClient users to be able to disable the desktop security policy. Changing the value from true to false will remove that possibility, so the client PC will always have the desktop policy enabled.
disconnect_when_in_enc_domain. This useful value will disable the client whenever it detects that it is within the same VPN domain as was received from the gateway when it created the site. This way, when clients bring their laptops to the internal LAN, they won’t have to mess around with the VPN client.
enable_kill. If you want to prevent the user from being able to stop the client, setting this will do the trick.
NGX R65 has several different options that allow remote connectivity for your users or partners. SecuRemote is the standard client which Check Point has been offering from day one. It allows you to connect to your network and do basically anything you want while you are connected. Split tunneling with SecuRemote is permitted and the client doesn’t have any protection. SecureClient is based on SecuRemote, but adds a few more bells and whistles. Some of its strongest points include the ability to receive and protect the client by receiving a desktop policy which is user-defined on the gateway, and the ability to use Office Mode as well as internal corporate WINS and DNS servers, making network shares readily available. The most recent addition to NGX R65 is the clientless solution offered by SNX. SNX alleviates the burden of having to install and debug remote clients of possible issues; however, doing so decreases the security of your corporate network and end client.
 | SecuRemote offers remote users the ability to connect to the internal corporate network in a secure way using AES-256 as the highest level of encryption. |
| It is possible to allow SecuRemote users the ability to query an internal DNS server by defining a SecuRemote DNS within the Dashboard. You can add several different domains for the client to query. |
| Split tunneling is the default when using SecuRemote. No additional security mechanisms are in place to protect the client when connecting. |
| You can use SecureClient to download a desktop policy from the Policy Server which is configured through the Dashboard. The desktop policy rules are divided into two sections: inbound toward the client and outbound from the client. |
| You can configure SecureClient to route all traffic through the corporate network when connected. This means the client will be using the corporate ISP when browsing on the Internet and all security mechanisms in place will be protecting the client. |
| You must take anti-spoofing into consideration when activating Office Mode. You must define the Office Mode range on the gateway’s interface. |
| SSL Network Extender (SNX) is a clientless VPN solution that is often used when installing client software becomes cumbersome. |
| You can use SNX on several different operating systems and browsers. However, many people find Internet Explorer to be the easiest to use. |
| SNX supports the same authentication mechanisms in place for your security gateway. |