Remote Access VPN Overview

Overview

Whenever users access the organization from remote locations, it is essential that the usual requirements of secure connectivity be met but also the special demands of remote clients, for example:

• The IP of a remote access client might be unknown.
• The remote access client might be connected to a corporate LAN during the working day and connected to a hotel LAN during the evening, perhaps hidden behind some kind of NATing device.
• The remote client might need to connect to the corporate LAN via a wireless access point.
• Typically, when a remote client user is out of the office, they are not protected by the current security policy; the remote access client is both exposed to Internet threats, and can provide a way into the corporate network if an attack goes through the client.

To resolve these issues, a security framework is needed that ensures remote access to the network is properly secured.

Check Point Remote Access VPN solutions let you create a VPN tunnel between a remote user and your internal network. The VPN tunnel guarantees:

• Authenticity, by using standard authentication methods
• Privacy, by encrypting data
• Integrity, by using industry-standard integrity assurance methods

Check Point Remote Access Clients extend VPN functionality to remote users, enabling users to securely communicate sensitive information to networks and servers over the VPN tunnel, using LAN, wireless LAN and various dial-up (including broadband) connections. Users are managed either in the internal database of the Security Gateway or via an external LDAP server.

After a user is authenticated, a transparent secured connection is established.

SecureClient Remote Access Solution

Enhancing SecuRemote with SecureClient Extensions

SecureClient is a remote access client that includes and extends SecuRemote by adding a number of features:

• Security features
• Connectivity features
• Management features

Security Features

• A Desktop Security Policy. See: Desktop Security.
• Logging and Alerts
• Secure Configuration Verification (SCV); (see: Secure Configuration Verification)

Connectivity Features

• Office mode addresses. See Office Mode.
• Visitor mode. See Resolving Connectivity Issues.
• Hub mode. See Hub Mode(VPN Routing for Remote Clients).

Management Features

• Automatic software distribution.
• Advanced packaging and distribution options (see: Packaging SecureClient.)
• Diagnostic tools

Establishing a Connection Between a Remote User and a Security Gateway

To allow the user to access a network resource protected by a Security Gateway, a VPN tunnel establishment process is initiated. An IKE (Internet Key Exchange) negotiation takes place between the peers.

During IKE negotiation, the peers' identities are authenticated. The Security Gateway verifies the user's identity and the client verifies that of the Security Gateway. The authentication can be performed using several methods, including digital certificates issued by the Internal Certificate Authority (ICA). It is also possible to authenticate using third-party PKI solutions, pre-shared secrets or third party authentication methods (for example, SecurID, RADIUS etc.).

After the IKE negotiation ends successfully, a secure connection (a VPN tunnel) is established between the client and the Security Gateway. All connections between the client and the Security Gateway's VPN domain (the LAN behind the Security Gateway) are encrypted inside this VPN tunnel, using the IPSec standard. Except for when the user is asked to authenticate in some manner, the VPN establishment process is transparent.

In the figure, the remote user initiates a connection to Security Gateway 1. User management is not performed via the VPN database, but an LDAP server belonging to VPN Site 2. Authentication takes place during the IKE negotiation. Security Gateway 1 verifies that the user exists by querying the LDAP server behind Security Gateway 2. Once the user's existence is verified, the Security Gateway then authenticates the user, for example by validating the user's certificate. Once IKE is successfully completed, a tunnel is created; the remote client connects to Host 1.

If the client is behind the Security Gateway (for example, if the user is accessing the corporate LAN from a company office), connections from the client to destinations that are also behind the LAN Security Gateway are not encrypted.

Remote Access Community

A Check Point Remote Access community enables you to quickly configure a VPN between a group of remote users and one or more Security Gateways. A Remote Access community is a virtual entity that defines secure communications between Security Gateways and remote users. All communications between the remote users and the Security Gateways' VPN domains are secured (authenticated and encrypted) according to the parameters defined for Remote Access communications in SmartDashboard Global Properties.

Identifying Elements of the Network to the Remote Client

Client needs to know the elements of the organization's internal network before it can handle encrypted connections to and from network resources. These elements, known as a topology, are downloaded from any Security Gateway managed by the Security Management server.

A site's topology information includes IP addresses on the network and host addresses in the VPN domains of other Security Gateways controlled by the same Security Management server. If a destination IP is inside the site's topology, the connection is passed in a VPN tunnel.

When the user creates a site, the client automatically contacts the site and downloads topology information and the various configuration properties defined by the administrator for the client. This connection is secured and authenticated using IKE over SSL. The site's topology has a validity timeout after which the client would download an updated topology. The network administrator can also configure an automatic topology update for remote clients. This requires no intervention by the user.

Connection Mode

The remote access clients connect with Security Gateways using Connect mode.

During connect mode, the remote user deliberately initiates a VPN link to a specific Security Gateway. Subsequent connections to any host behind other Security Gateways will transparently initiate additional VPN links as required.

Connect mode offers:

• Office mode, to resolve routing issues between the client and the Security Gateway. See, Office Mode.
• Visitor mode, for when the client needs to tunnel all client to Security Gateway traffic through a regular TCP connection on port 443.
• Routing all traffic through Security Gateway (Hub mode), to achieve higher levels of security and connectivity.
• Auto connect, when an application tries to open a connection to a host behind a Security Gateway, the user is prompted to initiate a VPN link to that Security Gateway. For example, when the e-mail client tries to access the IMAP server behind Security Gateway X, SecureClient prompts the user to initiate a tunnel to that Security Gateway.
• User profiles (Location Profiles). See: User Profiles.

User Profiles

Mobile users are faced with a variety of connectivity issues. During the morning they find themselves connected to the LAN of a partner company; during the evening, behind some kind of NATing device employed by the hotel where they are staying.

Different user profiles are used to overcome changing connectivity conditions. Users create their own profiles, or the network administrator creates a number of profiles for them. If the administrator creates a profile, the profile is downloaded to the client when the user updates the site topology. The user selects which profile to work with from a list. For example, a profile that enables UDP encapsulation in order to cope with some NATing device, or a profile that enables Visitor mode when the remote client must tunnel the VPN connection over port 443. The policy server used to download the Desktop Security Policy is also contained in the profile.

Access Control for Remote Access Community

Typically the administrator needs to define a set of rules that determines access control to and from the network. This is also true for remote access clients belonging to a remote access community. Policy rules must be created in order to control the way remote clients access the internal network via the Security Gateway. (Membership of a community does not give automatic access to the network.)

The Security Gateway's Security Policy Rule Base defines access control; in other words, whether a connection is allowed. Whether a connection is encrypted is determined by the community. If both the source and the destination belong to the community, the connection is encrypted; otherwise, it is not encrypted. For example, consider a rule that allows FTP connections. If a connection matching the rule is between community members, the connection is encrypted. If the connection is not between community members, the connection is not encrypted.

The Security Gateway's Security Policy controls access to resources behind the Security Gateway, protects the Security Gateway and the networks behind it. Since the remote client is not behind the Security Gateway, it is not protected by the Security Gateway's Security Policy. Remote access using SecureClient can be protected by a Desktop Security Policy. See Desktop Security.

Client-Security Gateway Authentication Schemes

Authentication is a key factor in establishing a secure communication channel among Security Gateways and remote clients. Various authentication methods are available, for example:

• Digital certificates
• Pre-shared secrets
• Other authentication methods (made available via Hybrid mode)

Digital Certificates

Digital Certificates are the most recommended and manageable method for authentication. Both parties present certificates as a means of proving their identity. Both parties verify that the peer's certificate is valid (i.e. that it was signed by a known and trusted CA, and that the certificate has not expired or been revoked).

Digital certificates are issued either by Check Point's Internal Certificate Authority or third-party PKI solutions. Check Point's ICA is tightly integrated with VPN and is the easiest way to configure a Remote Access VPN. The ICA can issue certificates both to Security Gateways (automatically) and to remote users (generated or initiated).

Using the ICA, generate a certificate and transfer it to the user "out-of-band." Alternatively, initiate the certificate generation process on Security Management server. The process is completed independently by the user. The administrator can also initiate a certificate generation on the ICA management tool (the only option available if users are defined on an LDAP server).

It is also possible to use third-party Certificate Authorities to create certificates for authentication between Security Gateways and remote users. The supported certificate formats are PKCS#12, CAPI, and Entrust.

Users can also be provided with a hardware token for storing certificates. This option offers the advantage of higher level of security, since the private key resides only on the hardware token.

As part of the certificate validation process during the IKE negotiation, both the client and the Security Gateway check the peer's certificate against the Certificate Revocation List (CRL) published by the CA which issued the certificate. If the client is unable to retrieve a CRL, the Security Gateway retrieves the CRL on the client's behalf and transfers the CRL to the client during the IKE negotiation (the CRL is digitally signed by the CA for security).

Pre-Shared Secret

This authentication method has the advantage of simplicity, but it is less secure than certificates. Both parties agree upon a password before establishing the VPN. The password is exchanged "out-of-band", and reused multiple times. During the authentication process, both the client and Security Gateway verify that the other party knows the agreed-upon password.

Other Authentication Methods Available via Hybrid Mode

Different organizations employing various means of user authentication may wish to utilize these means for remote access. Hybrid mode is an IKE mode that supports an asymmetrical way of authentication to address this requirement. Using Hybrid mode, the user employs one of the methods listed below to authenticate to the Security Gateway. In return, the Security Gateway authenticates itself to the client using strong, certificate-based authentication. Authentication methods which can be used in Hybrid mode are all those supported for normal user authentication in VPN, namely:

• One Time Password — The user is challenged to enter the number displayed on the Security Dynamics SecurID card. There are no scheme-specific parameters for the SecurID authentication scheme. The VPN module acts as an ACE/Agent 5.0. For agent configuration.

  SoftID (a software version of RSA's SecurID) and various other One Time Password cards and USB tokens are also supported.

• Security Gateway ‑ Password — The user is challenged to enter his or her password held on the Security Gateway.
• OS Password — The user is challenged to enter his or her Operating System password.
• RADIUS — The user is challenged for the correct response, as defined by the RADIUS server.
• TACACS — The user is challenged for the correct response, as defined by the TACACS or TACACS+ server.
• SAA. SAA is an OPSEC API extension to Remote Access Clients that enables third party authentication methods, such as biometrics, to be used with Endpoint Security VPN, Check Point Mobile for Windows, and SecuRemote.

Configuring Authentication

On the Security Gateway, you can configure authentication in one of two places:

• In the Gateway Properties window of a gateway in Authentication. In the Authentication page, you can allow access to users who authenticate with a Check Point Password, SecurID, OS Password, RADIUS server, or TACACS server. Authentication using Client Certificates from the Internal Certificate Authority is enabled by default in addition to the selected method.
• Some blades have their own authentication settings. Configure this in the Gateway Properties window of a gateway under <name of the blade> > Authentication. For example, configure the authentication method for IPsec VPN clients in Gateway Properties > IPsec VPN > Authentication. If you select an authentication method for the blade, that is the method that all users must use to authenticate to that blade. You can configure other authentication methods that users must use for different blades on different pages.

  If you do not make a selection on the Authentication page for a specific blade, the Security Gateway takes authentication settings for the blade from the main gateway Authentication page.

How the Gateway Searches for Users

If you configure authentication for a blade from the main Security Gateway Legacy Authentication page, the Security Gateway searches for users in a standard way when they try to authenticate. The gateway searches:

1. The internal users database.
2. If the specified user is not defined in this database, the gateway queries the User Directory (LDAP) servers defined in the Account Unit one at a time, and according to their priority.
3. If the information still cannot be found, the gateway uses the external users template to see if there is a match against the generic profile. This generic profile has the default attributes applied to the specified user.

If you configure an authentication method for a specific blade, the gateway searches for users according to the user groups that are used for authorization in that blade.

For example, in Mobile Access, the gateway looks at the Mobile Access policy to see which user groups are part of the policy. When the gateway tries to authenticate a user, it starts to search for users in the databases related to those user groups.

In IPsec VPN, the gateway looks at the Remote Access VPN Community to see which user groups are included. It starts to search for users in the databases related to those user groups.

A search based on the authentication scheme is faster, with better results. You can have users with the same user name in unrelated groups. The gateway will know which user is relevant for the blade based on the user groups.

Advanced Features

Remote Access VPN supports other advanced features such as:

• Resolving connectivity and routing issues. See: Office Mode, and Resolving Connectivity Issues.
• IP-per-user/group.
• L2TP clients.

Alternatives to SecuRemote/SecureClient

To avoid the overhead of installing and maintaining client software, Check Point also provides the SSL Network Extender, a simple-to-implement thin client installed on the user's machine via a web browser. The browser connects to an SSL enabled web server and downloads the thin client as an ActiveX component. Installation is automatic.

Need for Remote Access VPN

Whenever users access the organization from remote locations, it is essential that the usual requirements of secure connectivity be met but also the special demands of remote clients, for example:

• The IP of a remote access client might be unknown.
• The remote access client might be connected to a corporate LAN during the working day and connected to a hotel LAN during the evening, perhaps hidden behind some kind of NATing device.
• The remote client might need to connect to the corporate LAN via a wireless access point.
• Typically, when a remote client user is out of the office, they are not protected by the current security policy; the remote access client is both exposed to Internet threats, and can provide a way into the corporate network if an attack goes through the client.

To resolve these issues, a security framework is needed that ensures remote access to the network is properly secured.