Skip to content

IPsec XAUTH

Introduction

About this Document

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. Able 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.

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 in as a full administrator or a user with lower access privileges.

As software development and documentation are ongoing processes, the screenshots shown in this guide may slightly deviate from the current user interface.

XAUTH Concepts

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.

Road Warrior Concept

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.

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:

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.

image

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.

DHCP for IPsec Clients

The Dynamic Host Configuration Protocol (DHCP) is an application protocol that enables your appliance to dynamically assign IP addresses to computers and other devices in its network. DHCP simplifies network administration because software automatically keeps track of IP addresses so that administrators don’t have to. Many Internet Service Providers (ISPs) use DHCP to assign IP addresses to their clients.

You can configure the IPsec server to allow static client IP addresses only or to dynamically assign IP addresses to IPsec clients. In the latter case, DHCP requests are forwarded to the specified DHCP server in the secure LAN.

Forwarding DHCP Requests of IPsec Clients

IPsec Server Configuration

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.

Feature Activation

  1. Log on to the AXS Guard as explained in the System Administration guide.

  2. Go to System > Feature Activation > VPN

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

    IPsec Feature Activation

Important

As soon as you enable the IPsec feature, the AXS Guard will start to generate the RSA keys required for authentication. This process may take a while, especially on virtual appliances. Please be patient.

Server and Client Certificates

If you are planning 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 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 AXS Guard CA

  • How to generate certificates

  • How to import, export and revoke certificates

  • How to configure automatic notifications.

IPsec Server Settings

Appliances without Internet Redundancy

  1. Navigate to VPN > IPsec > Server.

  2. Enter the settings as explained in the tables below.

  3. Click on Update.

    IPsec Server Settings

Option Description

X.509 Authentication

Enable this option if you intend to configure IPsec tunnels for L2TP and other IPsec clients. The X.509 certificate is used by the IPsec server to identify itself to IPsec clients, a.k.a. road warriors. Go to PKI > Certificates to import or create certificates for the IPsec server and its clients.

Server Certificate

Select the appropriate server certificate. Go to PKI > Certificates for an overview of available certificates or to create or import a new server certificate.
Option Description

IPsec Client IP Configuration

Select whether or not IPsec clients should obtain an IP address from a DHCP server in your network.

DHCP Server IP

This field is only visible if you selected to use DHCP for IPsec clients. Enter the IP address of a DHCP server in your secure LAN.

Appliances with Internet Redundancy

If Internet Redundancy is enabled on your appliance, i.e. if your appliance has two or more Internet devices, you can select which Interface(s) handle(s) IPsec connections.

IPsec General Settings with Internet Redundancy

Option Description

Select Network Interfaces

This option is only available if Internet redundancy is enabled on your system. Check to specify the network interfaces that should handle IPsec traffic.

Interfaces to bind IPsec

This field only appears if your enabled the previous option. Select the network interfaces to be used by the IPsec server. You can only select Internet interfaces; DMZ interfaces cannot be selected.

Creating a new Tunnel

  1. Navigate to VPN > IPsec > Tunnels

  2. Click on Add New.

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

    IPsec Tunnel Overview

Mind the difference between:

  • RSA Authentication (Only applies to site-to-site tunnels)

  • PSK Authentication (Applies to site-to-site tunnels, IPsec road warriors and L2TP clients)

  • X.509 Authentication (Only applies to IPsec road warriors and L2TP clients)

Tunnel Type and Interfaces

IPsec Tunnel Type

Option

Description

Name

Enter a name to reference the IPsec tunnel, using lower cases without spaces. Names of e-tunnels should not exceed 13 characters. The tunnel name will appear in the tunnel overview.

Enabled

Enables the IPsec tunnel. Uncheck to disable.

Description

Descriptions are optional, but useful if you have a lot of tunnels to manage. Even though this is an optional field, we recommend using a sensible name to facilitate the configuration and management of your IPsec tunnels. The description will also appear in the tunnel overview.

Interface

This option is only available if Internet Redundancy is enabled on your appliance, i.e. for appliances with two or more Internet devices. Select the interface that should handle traffic for your IPsec tunnel. Note that only Interfaces which have been selected under IPsec > Server are offered as an option. Selecting the default option means that the first Internet device will be used.

E-tunnel

Select this option to create hub-and-spoke tunnels between AXS GUARD appliances. E-tunnels allow you to easily connect remote networks by adding static routes to each tunnel endpoint. E-tunnels use GRE (defined per RFC 2784) over IPsec. An IP address must be assigned to each virtual endpoint (GRE device) of the e-tunnel.

With e-tunnels, one AXS GUARD appliance acts as the central site router, to which all the other sites connect through IPsec. By adding static routes, all sites are able to reach the main network behind the central router and each other’s networks via the tunnel to the central AXS GUARD appliance. Go to Network > Routing to connect networks via e-tunnels.

E-tunnels can also provide redundancy. Failure of a main tunnel is automatically detected by the IPsec framework which automatically switches to a secondary tunnel, if available. 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.

Phase 1 - Main Mode (IKE)

Phase 1 - Main Mode

Option

Description

IKE Profile

Select the IKE profile to be used with by your tunnel. Only profiles created under IPsec > IKE Profiles are available for selection. The options of the selected profile must match those of the other endpoint.

IKE Version

Select the appropriate IKE version. The selected version must match that of the other endpoint.

Lifetime

This option specifies how long the keying channel of a connection (ISAKMP SA) should last before being renegotiated. Values can range from 19 minutes as a minimum, up to 480 minutes as a maximum. The default value is 60 minutes and can differ on both endpoints.

Option

Description

Host Authentication

A key or certificate is used by the IPsec server to prove its identity to hosts and to allow these hosts to verify its identity. Select the appropriate option for your IPsec tunnel:

  • Public RSA Key

  • PSK (Pre-shared Key)

  • X.509 Certificate (L2TP and IPsec clients only)

Public RSA Key

Select to use IPsec authentication by means of public RSA keys. Both sides of the tunnel have their public/private RSA key infrastructure installed. The endpoints exchange their public keys, which enables them to encrypt and decrypt messages. There are some extra constraints with this type of authentication; a Base64-encoded key of a least 2192 bits is required. The keys should be generated in the same way on both endpoints.

The local public RSA key will automatically appear on screen if you select this option. Copy and paste this key to the remote endpoint. Be careful not to add extra spaces or characters during this process.

RSA Key Size

This field is only visible if you selected Public RSA Key authentication and a value lower than 2192 bits has been configured in previous versions of the software. 2192 bits is the supported minimum. Select the strength of the RSA key pair to be used on this end of the tunnel. 4096 bits is the system default and recommended key size. Caution: When selecting a higher key size, you must copy the updated public key to the remote endpoint, otherwise the connection will fail. Lowering the key size is not possible.

PSK

Select to use IPsec authentication by means of a pre-shared key (PSK). This is a unique key that is known by both endpoints and consists of a string of characters.

When using PSK with Aggressive Mode, the authentication hash is transmitted as a response to the initial packet of the host that wants to establish an IPsec tunnel. The hash (pre-shared key) is not encrypted. If attackers can capture these session packets, they can run an attack to recover the PSK. The attack only affects aggressive mode because main mode encrypts the hash. Be aware that there are security tools that make these attacks simple to execute, e.g. ikescan.

Pre-shared Key

This field only appears if you selected PSK authentication. Enter your pre-shared key into this field. From a security perspective, it is highly recommended to use a strong, complex shared secret combined with Perfect Forward Secrecy (PFS). Complex secrets are less susceptible to brute-force attacks, while PFS ensures that the same data encryption key will not be regenerated (increased entropy). Note that the string must be identical on both sides of the IPsec tunnel and must be kept secret at all times. If you suspect that a key has been compromised, it must be changed immediately. Click on the "A" after the input field to display the input as you type.

Best Practices for PSKs

  • Generate a different PSK for each VPN tunnel.

  • Use a password generator for the creation of your PSKs.

  • Generate long PSKs with at least 30 characters to resist brute-force attacks.

  • Send the PSK to your peer via a secure channel, such as an encrypted e-mail.

X.509 Certificate

A prerequisite for this type of authentication to work, is to configure the PKI infrastructure of the AXS GUARD appliance. The CA must be initialized, a server certificate must be imported or created and installed under IPsec > Server. Server, L2TP and IPsec client certificates can be created under PKI > Certificates and distributed among peers.

L2TP is a typical Road Warrior setup which uses this kind of authentication; the AXS GUARD appliance listens for incoming connections from clients which have been issued a valid client certificate. The certificate is used to setup the encrypted IPsec tunnel. The L2TP protocol is used to authenticate the client a second time by means of a username and password, such as a one-time password generated by a DIGIPASS token.

Current Certificate

This read-only field only appears if you selected X.509 host authentication and displays information about the selected X.509 certificate.

Aggressive Mode

Check to use Aggressive Mode instead of Main Mode. Aggressive Mode is less secure and vulnerable to Denial of Service (DoS) attacks. It is also vulnerable to brute-force attacks with software such as ikecrack. Its use should be avoided, especially with XAUTH and PSK. Aggressive Mode is limited to only one proposal; there is no room for negotiation.

Force NAT-T

In some cases, for example when ESP packets are filtered or when a broken IPsec peer fails to recognize NAT, it can be useful to force RFC 3948 encapsulation. This option forces the NAT detection code to lie and tell the remote peer that RFC-3948 encapsulation (ESP in UDP port 4500 packets) is required.

Enable XAUTH

Extended authentication or XAUTH provides an additional level of authentication (in addition to the host authentication) in that the IPsec endpoint requests user credentials before any data transfer can take place. It is an extension of the IPsec phase1 authentication provided by IKE. Enable this option if you wish to enforce two-factor authentication for IPsec clients by means of DIGIPASS tokens. Go to Authentication > Services to configure the XAUTH authentication policy.

DPD

Check to enable dead peer detection, which continuously tests whether the tunnel is still up.

Delay

If DPD is enabled, you can specify the interval between tests. The system default interval is 30 seconds.

Timeout

If DPD is enabled, you can specify the maximum amount of time to wait for peer responses before they are considered dead. The system default value is 120 seconds.

Option

Description

Remote IP Type

You can either specify the IP address of the remote endpoint, allow any remote IP address or specify a hostname.

Remote Endpoint IP

Enter the public IP address of the remote endpoint.

Remote Endpoint Hostname

Enter the public hostname of the remote endpoint, e.g. ipsecremote.example.com.

Public RSA Key

This field is only visible if you selected Public RSA Key authentication. Copy and paste the public RSA key of the remote endpoint into this field. Only Base64-encoded keys are accepted.

Phase 2 - Quick Mode (ESP)

Phase 2 - Quick Mode

Option

Description

ESP Profile

Select the ESP profile to be used by your tunnel. It includes both a hash and an encryption algorithm which are used to encrypt all data going through the IPsec tunnel. Only profiles created under IPsec > ESP Profiles are available for selection. The options of the selected profile must match those of the other endpoint.

Lifetime

This value specifies how long a particular instance of a connection (a set of encryption/authentication keys for user packets, otherwise referred to as IPsec SA) should last, from successful negotiation to expiry. Values can range from 5 minutes as a minimum, up to 1440 minutes as a maximum. The default value is 480 minutes. This value can differ on both sides of the connection.

Option

Description

Local Identifier Type

Choose a method for the local side to identify itself to the remote side of the connection, either by means of the local endpoint IP or by means of a custom identifier. The latter is a string to uniquely identify the local endpoint tunnel. This identifier must be configured on the remote endpoint as the remote identifier.

Local Network

Enter a secure LAN IP address of your AXS GUARD appliance, e.g. 192.0.2.0/24.

Local Identifier

This field only appears if you have selected to use a custom identifier or if you enabled the e-tunnel option. Enter a domain name or e-mail address as the local identifier. This identifier must be configured on the remote endpoint as the remote identifier.

Do not use the endpoint IP as an identifier on an appliance of which the Internet interface(s) is/are NAT’d. The responding appliance checks if the connection identifier matches the source IP address of the appliance that initiates the connection. If the initiating appliance is NAT’d, the responder will see the translated IP address, which is of course different from the actual source IP. As a result, the responder will refuse the connection and an authentication failure will appear in the IPsec logs.

Local Virtual Endpoint IP

This field only appears if you selected the e-tunnel option. Enter an IP address for the virtual endpoint (GRE device) used on this end of the connection. Note that this IP must be in the same private range as the IP assigned to the virtual endpoint on the remote side of the connection. Make sure the IPs are not used elsewhere in your network to avoid routing issues.

Traffic Selector

Specify the network traffic to be allowed. If nothing is specified, there will be no traffic restrictions.

The general form is protocol/port. This is most commonly used to limit the connection to L2TP traffic only by specifying a value of 17/1701 for UDP (protocol 17 and port 1701). The notation 17 can be used to allow all UDP traffic and is needed for L2TP connections with older Windows XP machines before Service Pack 2. See the predefined L2TP tunnel for an example.

The protocol can be an IANA protocol number, e.g. 6 or a name, e.g. tcp. Ports can be defined as a number, e.g. 25 or as a name, e.g. smtp. Enter a protocol number or name without a port to allow any port; traffic will only be restricted to the selected protocol. Entering 0 (zero) in this field or leaving this field empty means that any traffic is allowed. The local traffic selector must match the remote traffic selector of the remote endpoint.

MTU

Set the Maximum Transfer Unit (MTU) for the route(s) to the remote endpoint and/or subnets. This is sometimes required when the overhead of the IPsec encapsulation would cause the packet the become too big for a router on the path. Since IPsec cannot trust any unauthenticated ICMP messages, PATH MTU discovery does not work. Acceptable values are positive numbers. There is no default.

Enable Compression

Enables IPsec data compression (RFC 3173) if checked. If enabled, the overall communication performance between a pair of communicating hosts/gateways ("nodes") will be increased by compressing the datagrams.

Option

Description

Remote Identifier Type

Choose how the remote side should identify itself. This can be achieved by means of a remote endpoint IP or a custom identifier. The latter is a string to uniquely identify the remote endpoint tunnel. This identifier must be configured on the local endpoint as the remote identifier and vice versa.

Remote Identifier

Enter a domain name or e-mail address as the remote identifier. This identifier must be configured on the local endpoint as the remote identifier and vice versa.

Do not use the endpoint IP as an identifier on an appliance of which the Internet interface(s) is/are NAT’d. The responding appliance checks if the connection identifier matches the source IP address of the appliance that initiates the connection. If the initiating appliance is NAT’d, the responder will see the translated IP address, which is of course different from the actual source IP. As a result, the responder will refuse the connection and an authentication failure will appear in the IPsec logs.

Remote Virtual Endpoint IP

This field only appears if you enabled the e-tunnel option. Enter the IP address assigned to the virtual endpoint (GRE device) on the remote side of the connection. Note that the local and remote IPs must be in the same private range. Make sure the IPs are not used elsewhere in your network to avoid routing issues.

Road Warrior Tunnel

Check to configure the tunnel as a Road Warrior server. A typical setup involves clients with different dynamic public IPs, which potentially all have different internal networks.

Remote Network

Enter a secure LAN IP address of the remote endpoint, e.g. 192.0.2.0/24 and click on the add button. Multiple networks can be added.

Allowed IP Range

This field only appears if the Road Warrior Tunnel option is enabled and applies to L2TP and other IPsec client setups, where several clients may have different virtual IPs or are being NAT’d.

More specifically, the outer IP address of a client is usually dynamically assigned by the ISP. The inner IP address is either configured statically on the client or is assigned dynamically using DHCP over IPsec. Since most clients are not connected to a specific local subnet, only the virtual IP (statically or dynamically assigned) is shared over the tunnel. You can use this field to configure a wide range of virtual IPs with only a single tunnel definition, in order to service multiple Road Warrior clients effectively and to reduce your system administration workload. Use the CIDR notation to specify a network range, e.g. 192.0.2.0/24. Entering 0.0.0.0/0 means that any IP is allowed.

Traffic Selector

Specify the network traffic to be allowed. If nothing is specified, there will be no traffic restrictions.

The general form is protocol/port. This is most commonly used to limit the connection to L2TP traffic only by specifying a value of 17/1701 for UDP (protocol 17 and port 1701). The notation 17 can be used to allow all UDP traffic and is needed for L2TP connections with older Windows XP machines before Service Pack 2. See the predefined L2TP tunnel for an example.

The protocol can be an IANA protocol number, e.g. 6 or a name, e.g. tcp. Ports can be defined as a number, e.g. 25 or as a name, e.g. smtp. Enter a protocol number or name without a port to allow any port; traffic will only be restricted to the selected protocol. Entering 0 (zero) in this field or leaving this field empty means that any traffic is allowed. The remote traffic selector must match the local traffic selector of the remote endpoint.

XAUTH Authentication Policy

  1. Log on to the AXS Guard appliance.

  2. Navigate to Authentication > Services.

  3. Click on IPsec XAUTH.

  4. Select the Authentication Policy for IPsec road warriors.

  5. Update your configuration.

    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.

Configuration Example

IPsec Client with X.509 Authentication and PFS

Overview

The IPsec client software used in this guide is available on the Internet and is merely used for example purposes. Able 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 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).

Server-Side Configuration

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.

  • This client software configuration example 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.

About X.509 Certificates

To deploy IPsec Road Warriors with X.509 authentication, you must configure the AXS Guard PKI to issue the appropriate certificates. The concepts and use of the AXS Guard PKI are explained in the PKI How To, which can be downloaded by 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 issue self-signed certificates

  • How to import, export and revoke certificates

  • How to configure automated notifications

IPsec X.509 Settings

  1. Log on to the AXS Guard appliance.

  2. Go to PKI > Certificates and create or import a server certificate.

  3. Navigate to VPN > IPsec > Server.

  4. Configure the settings as shown below and update your configuration.

    IPsec Server Settings

Creating an ESP profile with PFS Support

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

  1. Navigate to VPN > IPsec > ESP Profiles.

  2. Click on Add New.

  3. Enter the settings as shown below.

  4. Save the ESP profile.

    ESP profile with PFS

Info

You can easily create a new ESP profile by selecting a predefined ESP profile and clicking on Edit as New.

Phase 1 Settings

  1. Navigate to VPN > IPsec > Tunnels.

  2. Click on Add New.

  3. Enter the settings as shown below. Make sure to use the same IKE version as supported by the client.

    IPsec Phase 1 Settings

Phase 2 Settings

IPsec Phase 2 Settings

User Authentication Settings

Use the same settings as explained in User Authentication Settings.

For details about authentication, see the AXS Guard Authentication How To, which is accessible via the Documentation button in the Administrator Tool.

Assigning Authentication Tokens

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).

To assign a token:

  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.

    DIGIPASS Assignment

Client-Side Configuration

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

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

  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.

Configuration

  1. Click on Start.

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

  3. Click on The GreenBow IPsec VPN Client. A screen as shown below appears.

    image

To add an IPsec connection:

  1. Click on the Root icon as shown below.

  2. Right click and select New Phase 1.

    image

Phase 1 configuration:

  1. Enter a name for the new connection.

  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).

    image

Import the Client Certificate:

  1. Click on the Certificates Import button.

  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.

  5. Click once on the Certificate file.

  6. Click on Open.

  7. Enter the same Password (passphrase) that was used to export the client certificate.

  8. Click on OK.

    image

Phase 1 Advanced Settings:

  1. Click on the P1 Advanced button.

  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.

  11. Click on Save & Apply.

    image

Create a new Phase 2:

  1. Go to the main screen and select the created Phase 1 Definition.

  2. Right-click on the Phase 1 Definition.

  3. Click on Add Phase 2 as shown below.

    image

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 appliance, e.g. 192.168.11.0.

  4. Enter the subnet mask of the AXS Guard LAN, 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.

    image

Phase 2 Advanced Settings:

  1. Click on the P2 Advanced button.

  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.

  6. Click on Save & Apply.

    image

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

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

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.

    image

  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.

    image

  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.

image

  • 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.

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.

Important

  • 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 (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.

  3. If the problem persists, consult the GreenBow online Documentation.

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 token.

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

    image

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

Restart the tunnel:

  1. In the Greenbow menu, select Tools

  2. Then "Reset IKE"

  3. Restart the tunnel

Support

If you encounter a problem

If you encounter a problem with AXS Guard, follow the steps below:

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

  2. Check the knowledge base on this site for information about special configurations.

  3. If no solution is available in any of the above sources, contact your AXS Guard vendor.

Contact Information

(+32) 15-504-400
support@axsguard.com