IPSec Versus Clientless VPNs for Remote Access

In this Document

Introduction

Secure Remote Access Requirements

Basic Remote Access Requirements

Additional Remote Access Requirements

Remote Access Scenarios

Basic Technology Overview

IPSec VPNs

IPSec VPNs Pros/Cons

Clientless VPNs

10 Clientless VPNs Pros/Cons

11 Remote Access Deployment Considerations
12 IPSec or HTTPs?
13 Check Point Remote Access Solutions
14 Summary

2004 Check Point Software Technologies Ltd.

IPSec Versus Clientless VPN for Remote Access

Introduction
Over the last several years, the trend to utilize the Internet and encryption technologies for remote
access connectivity has grown dramatically as companies either offer such connectivity as a new
service, or use it to replace dial-in facilities for remote access. By leveraging the ubiquity of Internet
connectivity, while using encryption to ensure privacy of the communications, organizations have
been able to realize cost savings and increase reliability while enhancing many aspects of
connectivity to internal computing resources for remote users.
Several technologies have been developed to enable remote access via the Internet. Some
examples include:

Network layer technology, such as a Virtual Private Network (VPN) stack, typically using
IPSec/IKE

Transport layer networking client, such as SOCKS, which utilizes Secure Sockets Layer (SSL)1

Application level services running over SSL, such as HTTP, as included with most
Web browsers

Each of these technologies has the basic capabilities to provide remote access services to end
users, although each may take a different approach. These capabilities include:

The ability to determine that this information needs to be sent across the Internet in encrypted
form

The ability for both the end users computer and some server (or gateway) to securely
negotiate encryption keys, including mutual authentication of each side

The ability to take the application data, encrypt it and send it to the destination server or to
a gateway, which decrypts it and sends it in cleartext to the final destination server

The ability to provide data integrity checks to determine if the data has been tampered with
in transit

Each technology approach grew out of specific remote access requirements, and therefore each
one has the potential to be a solution for an organizations remote access needs. Each should be
reviewed against an organizations unique set of requirements in order to determine the best
solution(s). In addition, a technology does not make a solution a solution takes the technology
and implements in such a way to meet such customer requirements as cost, manageability,
platform support, reliability, serviceability and the like.
The remainder of this document discusses the general applicability of IPSec/IKE versus HTTPSbased secure remote access services, as well as specific applicability of VPN-1 clients (i.e. VPN-1
SecuRemote and VPN-1 SecureClient) versus HTTPS-based approaches.

Secure Remote Access Requirements

Generally, secure remote access provides encryption of data packets from end user computers,
typically laptop or desktop computers but also personal digital assistants (PDAs), casual access via
kiosks, as well as hardware devices (either a PC-attached dongle or a small form-factor hardware
gateway). Into the future, components such as mobile phones and application-specific devices
(e.g. a handheld computer that checks in rented cars) will likely be used as remote access clients.
These connections either terminate at the destination server or at some gateway or proxy that
terminates the encrypted connection.
Unless otherwise called out, when referring to SSL, this document refers not only to Secure Sockets Layer (or SSL),
but to its successor, Transport Layer Security or TLS

2004 Check Point Software Technologies Ltd.

IPSec Versus Clientless VPN for Remote Access

Basic Remote Access Requirements

At a base level, remote access requirements include:

Privacy/Data Integrity

Data privacy and integrity are achieved by the use of both client-side and server-side
encryption mechanisms. Such mechanisms include a protocol for securely exchanging
cryptographic keys (e.g. IKE, SSL), as well as encryption ciphers (e.g. DES, AES, RC4) and
data integrity methods (e.g. MD5, SHA-1). Use of public peer-reviewed techniques provides
higher assurance than the use of proprietary schemes.

Networkability

Remote Access solutions must include support for the use of IP protocols and network
infrastructure. This includes the ability to operate behind various gateway devices like
firewalls, Network Address Translation (NAT) devices and proxies, as well as support dynamic
IP addresses.

User Management

Organizations require the ability to utilize a diverse set of authentication (e.g. X.509 digital
certificates, fixed passwords, two factor schemes like RSA Securitys SecurID) and directory
technologies (e.g. LDAP, RADIUS, Microsoft Active Directory) to store and manage useraccount information.

Access control

Encryption techniques can provide strong data privacy and data integrity, but do not confer
access rights. Just because a user can establish a VPN tunnel regardless of the technology
used does not mean he or she should be able to access all resources. A remote access
solution must allow administrators to limit access to those required and no others.

Additional Remote Access Requirements

Remote access deployments may also have additional requirements both on the server and client
sides. Examples of server/gateway requirements include:

High availability/failover

For many sites, the remote access infrastructure is a critical function that must be continually
available. Remote access solutions must therefore be able to be engineered to meet this
requirement for high availability.

High performance

Although software optimization continues to improve the price/performance of VPN solutions,

in certain situations the use of dedicated hardware devices (i.e. appliances), drop-in cards with
hardware cryptographic acceleration, or clustering (multiple gateway devices co-located and
working together to meet the load) may be needed to achieve desired performance levels.

Routing

Some organizations may also benefit from the ability to route encrypted remote access
packets from a client via a primary gateway to other gateways on its way to its final
destination.

Integration with existing IT infrastructure

An important characteristic of a remote access solution is its ability to leverage, or at least

coexist with, existing user directories and authentication schemes, firewalls and web
infrastructure solutions such as web servers and proxies.

2004 Check Point Software Technologies Ltd.

IPSec Versus Clientless VPN for Remote Access

Multi-technology termination

In some deployments, it may be desirable or even required that a remote access gateway be
able to terminate several types of traffic such as IPSec, SSL, and HTTPS.

End-to-end security

Remote access solution providers have traditionally focused on protecting the data in transit
across untrusted networks, regardless of the underlying technology employed. By definition,
most remote access users are people accessing internal computing resources from outside an
organizations security perimeter; a growing number of organizations are extending the above
security requirements to include technologies to protect the remote access client itself. Such
technologies include desktop firewalls, intrusion detection systems (IDS) and anti-virus, which
protect users at the internal and Web levels of an untrusted network as well as the perimeter.

Remote Access Scenarios

Two scenarios can be used to label the majority of remote access uses:

Intranet access: employees that are telecommuting, on the road in hotels, at customer
sites, etc.

Extranet access: non-employees such as customers, business partners, contractors,

and government regulators

In both scenarios, end users are typically accessing one or more servers at the corporate site.
In the future, the need for peer-to-peer networking applications (e.g. VoIP, Instant Messaging) may
create additional and more challenging requirements, as peers may be outside of the organizations
firewall, VPN, and other IT security infrastructure.

Basic Technology Overview

Two popular technologies for providing remote access include IPSec/IKE VPNs and HTTP over SSL
(also referred to as clientless VPNs.) We take a closer look at these in this section.

IPSec VPNs
IPSec (IP Security) has been a popular technique over the past several years for providing both
remote access, as well as site-to-site (e.g. branch office to headquarters) VPNs. It is a mature
standard that is in production around the world, and has many vendors offering solutions in multiple
modes: client, server, and gateways. For site-to-site VPNs sometimes referred to as gateway-togateway VPNs good interoperability between vendors has been achieved. IPSec/IKE actually
refers to a collection of IETF standards (RFCs 2401 to 241X) that include specifics on key
management protocols (IKE), as well as the encrypted packet formats/protocols (IPSec). IPSec/IKE
supports a wide variety of encryption algorithms (DES, 3DES, AES, RC4) as well as data integrity
mechanisms (MD5, SHA-1). The standard also calls out support for pre-shared secrets and X.509
digital certificates for authenticating VPN peers.
IPSec is a network layer VPN technology, meaning it operates independent of the application(s)
that may use it. IPSec encapsulates the original IP data packet with its own packet, thus hiding all
application protocol information (at least when using Tunnel Mode IPSec). Once an IPSec tunnel is
negotiated via IKE, one-to-many connections of various types (web, email, file transfer, VoIP) can
flow over it, each destined for different servers behind the VPN gateway.

2004 Check Point Software Technologies Ltd.

IPSec Versus Clientless VPN for Remote Access

Typical deployment of IPSec VPNs consists of one or more VPN gateways providing VPN termination
for the servers behind them, and VPN client software that must be installed on each remote access
users computer. The VPN client is configured either manually or automatically depending on the
specific solution to define which packets it should encrypt and with which gateway it should
build the VPN tunnel.2
IPSec/IKE has been adapted for use in remote access VPNs as well, although interoperability is
not as good as with site-to-site VPNs, since many extensions to IPSec have been made to better
support remote access scenarios (e.g. XAUTH, CRACK and Hybrid to enable legacy authentication
support). The biggest drawback is that no standards exist to specify how to define the IPSec
Security Policy Database (i.e. the information that tells the client which gateway to build the VPN
tunnel with).

IPSec VPNs Pros/Cons

Pros:

All IP types and services are supported (e.g. ICMP, VoIP, SQL*Net, Citrix ICA)

Failover without dropping sessions is available from multiple vendors

High performance is available (e.g. 1+ Gbps VPN gateways on the market, thousands of
concurrent remote access users)

Same technology base works in client-to-site, site-to-site, and client-to-client

Supports strong authentication technologies and directory integration

VPN server/gateway is typically co-resident and therefore integrated with firewall

functions for access control, content screening and other security controls

IPSec client solutions are starting to bundle personal firewall, and other security functions
(e.g. configuration assurance, anti-virus, intrusion detection)

Once a key exchange is complete, many connections can utilize the established tunnel

Cons:

Typically requires a client software installation; not all required client operating systems may
be supported

Connectivity can be adversely affected by firewalls between the client and gateway (i.e. if the
firewall policy doesnt allow IKE or IPSec)

Connectivity can be adversely affected by Network Address Translation (i.e. NAT) or Proxy
devices between the client and gateway3

Requires client configuration before the tunnel is established

Interoperability of different vendors IPSec clients to other vendors IPSec servers/gateways

is weak, mainly due to configuration issues

Once a client has a tunnel (effectively a PVC) into an organization, this can be a target
of hackers (i.e. the remote access client can effectively be turned into a router into the
organization, unless mitigated by personal firewalls and/or access controls at the
VPN gateway)

For more information on IPSec /IKE, a good source is the VPN Consortium at http://www.vpnc.org

The NAT issue can be mitigated by various means (e.g. use of Transport Mode IPSec, Check Points OfficeMode)

2004 Check Point Software Technologies Ltd.

IPSec Versus Clientless VPN for Remote Access

Clientless VPNs
Clientless VPNs typically refer to HTTPS-based VPNs, but can also include SSL-enabled
applications such as email clients (e.g. Microsoft Outlook, or Eudora). It is referred to as clientless
because most computers today ship with a bundled Web browser that supports both HTTP as well
as HTTPS (SSL-based HTTP). This is in contrast to IPSec/IKE remote access scenarios where a
vendors IPSec client stack must be installed on each remote access users computer (note:
Microsoft supplies native IPSec/IKE stacks with its Windows 2000 and Windows XP versions).
SSL which is being succeeded by TLS (RFC 2246) operates over TCP. Like IPSec/IKE, it has a
setup phase, which consists of an exchange of messages that utilize both public key and symmetric
key encryption. This exchange will:

Authenticate the server to the client, via digital certificates

Optionally authenticate the client to the server, via certificates or other means

Securely generate session keys which are used to encrypt the data and provide
integrity checks

SSL can make use of various public key (e.g. RSA, DSA), symmetric key (DES, 3DES, RC4), and data
integrity (MD5, SHA-1) algorithms.
For remote access deployments via HTTPS, the termination of the tunnel can be at the actual
destination server itself, or at a gateway (typically, but not always, a system with two or more network
interfaces that decrypts packets from clients and sends them on in cleartext to internal Web servers)
in front of the servers4. This gateway can be a general-purpose computer, such as a Linux or
Microsoft Windows 2000 server, or a purpose-built appliance.
HTTPS is typically invoked via a URL that points to the HTTPS port (TCP/443), for example:
https://www.checkpoint.com/my-https-url.

Clientless VPNs Pros/Cons

Pros:

HTTPS client (e.g. Internet Explorer, Netscape Communicator, Mozilla) is bundled with all
leading operating systems

Popular applications such as mail clients/servers (e.g. Outlook and Eudora) support SSL

HTTPS functionality is also bundled with leading Web servers, as well as available via
dedicated software and hardware suppliers (i.e. Web access appliances)

Operates transparently across NAT and proxy devices

Not typically affected by a firewall sitting between the client and the server

In the initial SSL handshake, session key use (re-use) is supported to minimize key exchanges
for efficiency

Cons:

Only supports TCP services, and often only HTTP or POP3/IMAP/SMTP over SSL

For a good overview of SSL see: http://developer.netscape.com/docs/manuals/security/sslin/contents.htm

2004 Check Point Software Technologies Ltd.

IPSec Versus Clientless VPN for Remote Access

Multiple SSL handshakes may be required for one session

Web server will experience a transactional performance hit due to the additional computation
load of performing the SSL, unless pushed to some HTTPS or SSL gateway

No known vendor implementations supply failover while maintaining the session (i.e. the user
must reload the URL)

Data is secure in transit, but there are no controls on the security of the client system5

Not used for site-to-site VPNs typically, IPSec/IKE is used thus different technologies
must be used for remote access VPN versus site-to-site VPNs

If sessions are not terminated at a firewall, this requires punching a hole through an
organizations firewall(s), which precludes content inspection of the data within the HTTPS
connection by firewalls

Remote Access Deployment Considerations

IPSec or HTTPS?
The best choice of a given technology depends on the requirements and goals for a given remote
access project. Once a technology is decided upon, the next step is to find the best requirements fit
amongst the vendors offering solutions based on that technology. Performance, manageability,
acquisition cost, ease of integration with existing infrastructure, support, and other such criteria are
used to drive the vendor implementation selection.
Using the pros and cons listed above, for both IPSec and HTTP, the following general observations
can be made:

IPSec/IKE is, most likely, the best-fit solution when one or more of the following are the primary
project requirements:
- Organization needs a general infrastructure to support a broad range of network protocols,
not just Web or email access
- Organization has administrative control over the remote access users computer
- Security controls (e.g. personal firewalling, limiting which machines can be used for remote
access) over the remote access users computer are required. For example, administrators
may NOT want users to access sensitive data from public web kiosks, due to the unknown
security state of these types of web access machines.

HTTPS is, most likely, the best-fit solution when one or more of the following are the primary
project requirements:
- All traffic is HTTP or email-based
- Universal information access (i.e. access from any Internet device such as laptops,
home PCs, Internet kiosks) is required
- Users are operating with a firewall between their machines and the destination server(s),
and the firewall is often configured to allow HTTPS but not allow IKE (UDP Port 500)
or IPSec (IP Protocol 51)

NO CACHE Meta Tags can be sent from the server to the client but there is no guarantee it will be honored by the
client

2004 Check Point Software Technologies Ltd.

IPSec Versus Clientless VPN for Remote Access

- Organization does not have control over the remote access users computer configuration
- Installation of software to provide remote access on the users computer is not possible

Check Point Remote Access Solutions

Check Point supports the following technologies6 for implementing secure remote access solutions:

IPSec/IKE
- VPN-1 SecuRemote (Windows 9X, NT, 2000, XP)
- VPN-1 SecureClient (Windows 9X, NT, 2000, XP, PocketPC 2002)
- VPN-1 Client for Macintosh (MacOS 8.x, 9.x)
- Certicom Movian VPN client for PalmOS
- Nokia VPN client

L2TP/Transport IPSec via Microsoft Windows 2000/XP VPN client feature

HTTPS via the FireWall-1 HTTP Security Server

VPN-1 SecuRemote provides basic IPSec/IKE capabilities, including strong, flexible authentication
and easy client-side configuration.
VPN-1 SecureClient, which is a superset of VPN-1 SecuRemote, provides advanced remote access
technologies including: personal firewall with a centrally managed policy, client security assurance,
IP Compression, automatic in-band software updating, and OfficeMode, which assigns a virtual IP
address to the remote access client, which eliminates all known NAT issues (UDP encapsulation also
helps in this regard) and makes users look like they are on the internal LAN.
HTTPS termination support enables VPN-1/FireWall-1, via its HTTP Security Server, to handle
inbound HTTPS connections. In addition to handling the SSL handshake (including mutual
authentication or server-side X.509 authentication and client-side authentication using several
different schemes), the HTTP Security Server, after decrypting inbound HTTPS traffic, can provide
authorization, full stateful inspection and content screening of the decrypted data, prior to
forwarding on to the destination web server.
All Check Point remote access solutions are tied to the Check Points firewall and
management infrastructure, which provides granular access to internal resources,
regardless of VPN technology used.

For more information on Check Point remote access solutions, please see:
http://www.checkpoint.com/products/index.html or consult the VPN-1/FireWall-1 product documentation.

This section assumes VPN-1/FireWall-1 NG Feature Pack 3

2004 Check Point Software Technologies Ltd.

IPSec Versus Clientless VPN for Remote Access

Summary
Organizations have many options to deploy solutions for remote access. Two of the more popular are
IPSec/IKE and HTTPS. Both have broad industry support from a variety of vendors. Each has relative
strengths and weaknesses that should be considered against an organizations specific goals for
remote access.
The use of either IPSec or HTTPS for remote access solutions is not mutually exclusive. Many
organizations have implemented both, utilizing each depending on its suitability for a given project.
For example, many customers use VPN-1 SecuRemote or VPN-1 SecureClient for internal employee
remote access, while utilizing HTTPS for customer purchase transactions or business partner
access.
Check Points goal is to enable termination of many remote access technologies not only
IPSec/IKE and HTTPS, but also L2TP so that security managers can apply the broad array of
VPN-1/FireWall-1 controls (access control, authentication, content screening) to all types of remote
access traffic. This allows users to unify their Perimeter, Internal and Web security management and
administration, while reducing or eliminating the need to punch holes through their Internet firewalls.
In general, IPSEC is heavier from an administrative point of view, but is a more generalized solution,
acting as a comprehensive secure IP communications infrastructure. HTTPS is lighter from an
administrative burden (i.e. no client software to manage), but is more limited in the services it can
support. Thus, HTTPS seems an excellent choice for casual remote access use, whereas IPSec is
oriented towards all-purpose, heavy use remote access.

About Check Point Software Technologies

Check Point Software Technologies is the worldwide leader in securing the Internet. It is the confirmed
market leader of both the worldwide VPN and firewall markets. Check Point provides Intelligent
Security Solutions for Perimeter, Internal and Web Security. Based on INSPECT, the most adaptive
and intelligent inspection technology and, SMART Management, which provides the lowest TCO for
managing a security infrastructure, Check Points solutions are the most reliable and widely deployed
worldwide. Check Point solutions are sold, integrated and serviced by a network of 1,900 certified
partners in 86 countries. For more information, please call us at (800) 429-4391 or (650) 628-2000
or visit us on the Web at http://www.checkpoint.com or at http://www.opsec.com.

CHECK POINT OFFICES

International Headquarters
3A Jabotinsky Street, 24th Floor
Ramat Gan 52520, Israel
Tel: 972-3-753 4555
Fax: 972-3-575 9256
e-mail: info@CheckPoint.com

U.S. Headquarters
800 Bridge Parkway
Redwood City, CA 94065
Tel: 800-429-4391; 650-628-2000
Fax: 650-654-4233
URL: http://www.checkpoint.com

2004 Check Point Software Technologies Ltd. All rights reserved. Check Point, Application Intelligence, Check Point Express, the Check Point
logo, ClusterXL, ConnectControl, FireWall-1, FireWall-1 GX, FireWall-1 SecureServer, FireWall-1 XL, FloodGate-1, INSPECT, INSPECT XL,
InterSpect, IQ Engine, Open Security Extension, OPSEC, Provider-1, Safe@Office, SecureKnowledge, SecurePlatform, SecureXL,
SiteManager-1, SmartCenter, SmartCenter Pro, SmartDashboard, SmartDefense, SmartLSM, SmartMap, SmartUpdate, SmartView,
SmartView Monitor, SmartView Reporter, SmartView Status, SmartViewTracker, UAM, User-to-Address Mapping, UserAuthority, VPN-1,
VPN-1 Accelerator Card, VPN-1 Edge, VPN-1 Pro, VPN-1 SecureClient, VPN-1 SecuRemote, VPN-1 SecureServer, , and VPN-1 VSX are
trademarks or registered trademarks of Check Point Software Technologies Ltd. or its affiliates. All other product names mentioned herein are
trademarks or registered trademarks of their respective owners. The products described in this document are protected by U.S. Patent No.
5,606,668 and 5,835,726 and may be protected by other U.S. Patents, foreign patents, or pending applications.
P/N 000000

2004 Check Point Software Technologies Ltd.