IPsec Server

Introduction

About this Document

The AXS Guard IPsec How To serves as a reference and practical source for technical personnel and / or system administrators. In this guide we explain the various concepts of the IPsec framework, e.g. IKE, ESP, Security Associations (SA), the Diffie-Hellman key exchange and how to configure them on the AXS Guard appliance.

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.

IPsec Security Concepts

Overview

In the first part of this section, we explain some common Internet security problems. In the second part, we focus on the tools needed to overcome Internet security problems and how these tools can be combined to lead to a strong network security strategy.

Topics covered in this section include:

• Tools to solve Internet security problems: Encryption, Authentication and Integrity.

• Symmetric and Asymmetric Encryption.

• Encryption algorithms, such as DES, 3DES, RSA and AES.

• Shared Key generation: the Diffie-Hellman Key Exchange.

• Authentication hashing functions: MD5 and SHA1-1.

• Message Authentication Codes: MAC and HMAC.

• Key Management: Manual, PKI, Certificate Authorities. RSA, X.509.

Internet Security Issues

Password sniffing IP spoofing Replay attack Session hijacking Denial of service DoS

TCP/IP networks are plagued with security problems because they have been designed to work in a friendly environment, with physically secure connections. Nowadays, many security weaknesses of TCP/IP become manifest and can easily be exploited. In general, IP communications are exposed to several types of attack:

• Password Sniffing: A technique used by intruders to eavesdrop on a communication line to capture passwords transmitted in plaintext (unencrypted). Once a valid password has been captured, the intruder can use it to pose as a legitimate user.

• IP Spoofing: A technique used by intruders to fake their IP address and pose as a trusted host when address-based authentication is used. If successful, the intruder can execute operating system commands remotely, compromising the target’s system and network security.

• Replay Attack: A replay attack is a network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. The attack is carried out by an intruder who intercepts the data and retransmits it, possibly as part of a masquerade attack by IP packet substitution.

• Session Hijacking: A technique by which an intruder takes over a connection after the original source has been authenticated. This is also known as a "man-in-the-middle” attack.

• Denial-of-Service: A technique used by attackers to flood a host with packets so that it no longer can provide the intended services.

As the Internet evolved from an academic and a research network into a commercial network, the secrecy and integrity of data transmitted over the Internet have become a point of concern. Encryption and Authentication techniques constitute the tools to address this concern.

Countering Internet Security Issues

Several tools are available to overcome the Internet security problems Each tool has a specific function, as shown in the table below. Please note that a same tool can fulfill different functions, e.g. verify data integrity and check the identity of the sender. The classification is not always clear-cut.

Function	Description
Ensure Confidentiality	The guarantee that only the authorized parties can read the data and that unauthorized parties cannot.
Verifying Data Integrity	The guarantee that, upon receipt of a datagram from the network, the receiver is able to determine if the data was changed in transit.
Checking Identity	The guarantee that, upon receipt of a datagram from the network, the receiver is able to determine if the stated sender of the datagram is, in fact, the sender.

Encryption

Encryption is the process of transforming data (referred to as plaintext) using an algorithm (also called cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key. The result of the process is encrypted information (referred to as ciphertext). In many contexts, the word encryption implicitly refers to the reverse process, decryption (e.g. “software for encryption” can typically also perform decryption), to make the encrypted information readable again.

The aim of encryption is to provide confidentiality, i.e to ensure that only the authorized parties can read the data, as shown in the image below.

Integrity Checks

Integrity checks provide protection against unauthorized alteration or destruction of information. They verify if information has remained unaltered from the point it was produced by a source, during transmission, storage, and receipt by the destination.

Authentication

Authentication is the process of ensuring that the sending host of a datagram is who it claims to be. With authentication, fraud and forgery is excluded. This can be compared to an ID or passport.

Example: Passports

Passports can only be issued by specific authorities, are issued for a limited time, can be revoked if necessary, have a serial number and are tamper-proof.

Encryption Concepts and Algorithms

Encryption Methods and Algorithms define:

• The supported key sizes.

• The number of keys used to encrypt and decrypt data.

• The way the key(s) is/are generated, managed and distributed (exchanged).

There are two types of encryption: Symmetric and Asymmetric Encryption. Analogically, two principal classes of encryption algorithms can be identified: symmetric algorithms and asymmetric algorithms.

Encryption algorithms are mathematical formulas used by encryption systems to encrypt and decrypt data with keys.

This manual only provides basic information about encryption algorithms. For more advanced and specific information on the listed encryption algorithms, consult the appropriate external (online) resources.

Encryption Keys

In cryptography, an Encryption Key is a piece of information (a parameter) that determines the functional output of a cryptographic algorithm or cipher (explained further in this chapter). Without a key, the algorithm would have no result. In encryption, a key specifies how plaintext is converted into ciphertext, or vice versa during decryption. Keys are also used in other cryptographic algorithms, such as Message Authentication Codes. The longer a key is, the stronger it is.

Block Ciphers

A block cipher is a type of symmetric-key encryption algorithm that transforms a fixed-length block of plaintext (unencrypted text) data into a block of ciphertext (encrypted text) data of the same length (see below). This transformation takes place under the action of a user-provided secret key. Decryption is performed by applying the reverse transformation to the ciphertext block using the same secret key. The fixed length is called the block size, and for many block ciphers, the block size is 64 bits or 128 bits.

Symmetric Encryption Concept

Symmetric encryption uses a single, unique key shared by all involved parties to secure (encrypt and decrypt) data. While faster than Public Key Encryption, it has some disadvantages.

Symmetric encryption requires all parties to share a single secret key, which is hard to choose, distribute and store without error and / or loss. Any person in possession of the unique secret key can read the data encrypted with it. Therefore, it is hard to make sure that messages encrypted with symmetric encryption came from the correct person and were not altered on the way. As a result, current security systems mostly use asymmetric encryption to distribute keys securely. Once the keys are distributed, symmetric encryption takes over.

Symmetric encryption is sometimes also referred to as single-key and / or private-key encryption. Private-key encryption should not be confused with the ‘private key’ used in Public Key Encryption.

Some common examples of symmetric encryption algorithms are the Advanced Encryption Standard (AES), the Data Encryption Standard (DES) and Blowfish.

Key Tables

Most symmetric algorithms create a Key Table from the original key. This is also known as the key setup or initialization. It’s actually the key table that is used to encrypt the data. The original key is mathematically tied to the Key Table so, as long as you have the original key, the Key Table can be created. The original key is the model or mold for all the other keys in the Key Table.

Assume that the original key is ABCDEFG

The associated Key table may look like this:

GFEABCDGFE
CDCDABFGEE
AABBGCFFDE

Symmetric Encryption Algorithms

DES

DES is a symmetric algorithm stands for Digital Encryption Standard and was created in 1975 with some assistance from the National Security Agency (NSA). In 1981, DES became an accepted standard and was widely used. DES is a block cipher that uses a 56-bit key to create the key table (explained on page 18). Then it goes through the process of combining a key from the key table with the block of plaintext. After the key and the plaintext have been combined, DES goes through 16 more changes (called rounds) to thoroughly mix up the ciphertext. To decrypt the data, DES just goes through all the changes in reverse order.

Given that a 56-bit key has about 72 quadrillion (72.000.000.000.000.000) different combinations of numbers, most people felt that DES would be secure for a very long time. What people failed to consider was that computers got faster and cheaper and that it wouldn’t cost very much to create a computer specifically to break DES. In 1999, DES was broken in less than 24 hours on a specially built computer.

3DES

As its name implies, Triple DES does something three times more than DES. 3DES is a symmetric algorithm which uses three keys on each block of plaintext. Instead of using one 56-bit key from the key table, 3DES encrypts the plaintext with the first key, encrypts the resulting ciphertext with another 56-bit key, and finally encrypts that ciphertext again with another 56-bit key. 3DES also supports longer keys to make it more secure. The most commonly longer key lengths (at present) are 112 bits and 168 bits.

To crack this algorithm one would need to figure out three separate keys. Besides that, the ciphertext can only be decrypted when all three keys are used in the correct order. Even if one key is guessed, there is no way to know it is correct until it is combined with the other two keys. The number of permutations is incredibly high.

AES

AES stands for Advanced Encryption Standard. It is the first algorithm that was created through organized competition. The contest was announced by NIST (National Institute of Standards and Technology) in 1997 in an attempt to find a good algorithm that would become the next government standard. In 1998, the list of competing algorithms had been whittled down to 15 candidates.

In 2000, after 2 years of heavy testing, NIST announced it had a winner — an algebraic algorithm called Rijndael (after Vincent Rijmen and Joan Daemen, pronounced “rine-doll”). It had survived all the tests, and people generally liked the way it worked. The government has called it the Advanced Encryption Standard (AES). AES specifies three approved key lengths: 128-bits, 192-bits and 256-bits.

The NSA (National Security Agency) has approved 128-bit AES for use up to the SECRET level and 192-bit AES for use up to TOP SECRET level.

Blowfish

Blowfish is a symmetric encryption algorithm that can be used as a replacement for DES. It takes a variable length key, from 32 bits to 448 bits, making it ideal for both domestic and professional use. Blowfish was designed in 1993 by Bruce Schneier as a fast, free alternative to existing encryption algorithms. Since then it has been analyzed considerably, and it is gaining acceptance as a strong encryption algorithm. Blowfish is unpatented and license-free, and is available free for all uses.

Twofish

Twofish is a symmetric encryption algorithm with key sizes up to 256 bits. It was one of the five finalists of the Advanced Encryption Standard (AES) contest, but was not selected for standardization. Twofish is related to the Blowfish algorithm. The Twofish algorithm has not been patented. As a result, the Twofish algorithm is free for anyone to use without any restrictions whatsoever. Twofish has seen less widespread usage than Blowfish, which has been available for a longer period of time.

Serpent

Serpent is a symmetric encryption algorithm which was a finalist in the Advanced Encryption Standard (AES) contest, where it came second. Serpent was designed by Ross Anderson, Eli Biham, and Lars Knudsen. Like other AES submissions, Serpent supports a key size of 128, 192 or 256 bits. The Serpent algorithm has not been patented and can be freely used by anyone.

CAST-128

CAST-128 is a symmetric encryption algorithm supporting key sizes between 40 to 128 bits. Although Entrust holds a patent on the CAST design procedure, CAST-128 is available worldwide on a royalty-free basis for commercial and non-commercial uses.

Asymmetric Encryption Concept

Asymmetric encryption is an encryption system in which two different keys (key pair) are used by each party for encryption and decryption. The key pair for each party is unique. Even though the two keys of a pair are mathematically related, they cannot be derived from one another. Data encrypted using one key can only be decrypted using the other key of the pair. The two keys are typically referred to as public and private keys.

The image below explains the stages of a message exchange using asymmetric encryption. Although the process is only illustrated from one point of view (Bob), it is in fact bidirectional.

1. Bob creates a unique key pair which consist of a public and a private key.

2. Bob publishes this key, so that anyone can access it. The private key must remain in Bob’s possession at all times and be kept secret!

3. Since Alice has access to Bob’s public key, she can encrypt messages with it.

4. Once the message is encrypted, she sends it to Bob. The message cannot be read in transit, since it is encrypted.

5. Bob receives the encrypted message. Only Bob can read (decrypt) the message, since he is the only one who has the matching private key.

Asymmetric encryption is very slow compared to symmetric encryption, because it requires a lot of processing power. Therefore, symmetric encryption – which is faster - is typically used to encrypt large chunks of data, while asymmetric encryption is used for securing very small data objects, such as a secret key for symmetric encryption or a hash. Hashes are used for Authentication and to check the Integrity of data.

Asymmetric encryption is also referred to as Public Key Encryption. Some common examples of asymmetric encryption algorithms are RSA, DSA and ECC. The most popular and known asymmetric key algorithm is RSA.

Asymmetric Encryption Algorithms

RSA

RSA is the best known asymmetric algorithm, due in part to the very large corporation that stands behind it — RSA Data Security. RSA comes from the last names of its inventors, Ron Rivest, Adi Shamir, and Leonard Adleman, who created the algorithm in 1978.

To date, it is the only asymmetric algorithm in widespread general use that is used for private/public key generation and encryption. Many programs use a combination of asymmetric algorithms and symmetric algorithms to protect data, because symmetric encryption requires all parties to share a single secret key, which is hard to choose, distribute and store without error and / or loss.

RSA uses the product of very large prime numbers to create each of the keys (private & public). It relies on the Integer Factorization Problem, which consists of:

• The ease of multiplying two huge prime numbers and obtain a huge product.

• The extreme difficulty of breaking down the huge product into factors.

Using this kind of keys to encrypt large amounts of data is impractical due to the required processing power and time.

More often than not, an encryption program that uses RSA encrypts the data with a symmetric algorithm such as DES, 3DES, AES, etc. The symmetric key created by the symmetric algorithm, e.g. 3DES is encrypted with the recipient’s public key. When the recipient gets the message, he/she uses his/her private key to decrypt the 3DES key, and when the 3DES key is decrypted, the bulk of the message can be decrypted.

DSA

The Digital Signature Algorithm (DSA) is a United States Federal Government standard for digital signatures. The Digital Signature Standard, created by the National Institute of Standards and Technology (NIST), specifies DSA as the algorithm for digital signatures and SHA-1 for hashing. DSA is for signatures only and is strictly not an encryption algorithm, although some authors describe encryption mechanisms (ElGamel encryption and RSA encryption) based on DSA.

DSA is a public key algorithm; the secret key operates on the message hash generated by SHA-1; to verify a signature, one recomputes the hash of the message, uses the public key to decrypt the signature and then compare the results. The key size is variable from 512 to 1024 bits which is adequate for current computing capabilities.

ECC

Elliptical Curve Cryptography (ECC) is a very different form of asymmetric encryption, which is based on the algebraic structure of elliptic curves. It is not used often and tends to be used to encrypt large amounts of data. This is because ECC computes very quickly, and doesn’t tie up a lot of processing time compared to RSA.

The Diffie-Hellman Key Exchange

Diffie-Hellman is a Key Exchange algorithm (illustrated below), commonly known as DH. It is named after two of its inventors. DH is defined per RFC 2631.

DH is not an encryption algorithm. Its purpose is to:

• Negotiate a shared secret over an insecure channel (the Internet) between two parties that have no prior knowledge of each other. The shared secret is transmitted between the parties by using an Asymmetric Encryption Algorithm, e.g. RSA.

• Use the negotiated shared secret to encrypt subsequent communications between the two parties by means of a Symmetric Encryption Algorithm.

Below we explain the Diffie-Hellman Key Exchange based on the illustration above:

• Alice and Bob agree to use a prime number (p = 23) and a base (g = 5). The values of p and g don’t need to be kept secret.

• Alice then chooses a secret number (X_A = 6).

• Bob also chooses a secret number (X_B = 15).

• Alice computes Y_A and Bob computes Y_B:

  1. Y_A = 5⁶ mod 23 = 8

  2. Y_B=5¹⁵ mod 23 = 19

  3. Y_A and Y_B are exchanged.

Alice and Bob can calculate the secret key as such:

• K_AB = g ^{XA XB} mod p

• = Y_A ^XB mod p = 815 mod 23 = 2 (Which Bob can compute)

• = Y_B ^XA mod p = 196 mod 23 = 2 (Which Alice can compute)

The key (2) may then be used with a Symmetric Encryption Algorithm to secure the communications between Alice an Bob.

Network Traffic Integrity Checks

The purpose of Integrity Checks is to verify whether received data is tamper-free. In other words, to make sure the data wasn’t altered en route. Integrity is checked by adding hashes (MAC and HMAC) to data. The hashes are calculated by hash algorithms, such as MD5 and SHA1.

This guide only provides basic information about hash algorithms. For more advanced and specific information about the mentioned hash algorithms, consult the appropriate external (online) resources.

Introduction to Hashes

A hash is an alphanumeric “fingerprint” of data, comparable to checksums and CRCs. Hashes are optimized to detect deliberate alterations in data. A hash algorithm calculates a hash which is added to the sender’s data. When the data arrives, the receiver uses the same hash algorithm to check the data’s integrity. If the data has not been changed en route, the algorithm on the receiver’s side produces the same hash as the sender. If the result is different, then the data has been changed in transit.

MAC

MAC stands for Message Authentication Code and is a type of hash. A MAC, in contrast to an HMAC, does not contain information about a secret key being used to secure communications between parties (see the diagram on page 27). This means that a MAC is susceptible to man-in-the-middle attacks and can be modified en route.

HMAC

Data that has been hashed with a MAC can be changed en route. This means that an attacker can intercept the data, modify it and create a new hash before it reaches its destination. The HMAC (Hashed Message Authentication Code) provides a solution to this problem.

An HMAC is a secured MAC. It contains information about a secret key. You can use any symmetric algorithm to create a key, encrypt your message (data) and then use SHA1 or MD5 to create the hash. Because the hash includes information about the secret key, an attacker who hijacks the message (data) has to know exactly which key has been used. If an attacker intercepts the data, modifies it, and then creates a hash, there is no way it will come out correctly. The secret key is needed to make a correct replication.

HMACs are also referred to as Keyed Hashes and are defined per RFC 2104.

Hash Functions

A Hash Algorithm is a mathematical method to calculate hashes or “fingerprints”, e.g. MD5 and SHA1. The algorithms listed in the table below can produce MACs as well as HMACs.

Hash Algorithm	Properties
MD5	MD5 stands for Message Digest 5. It is a a Hash Algorithm, which takes a message of arbitrary length as input and produces a 128-bit "fingerprint" as output.
SHA1	SHA1 stands for Secure Hash Algorithm 1. It is a Hash Algorithm, which takes a message of any length smaller than 264 bits as input and produces a 160-bit “fingerprint” as output.
SHA2 256	SHA2 256 takes a message of any length smaller than 264 bits as input and produces a 256-bit “fingerprint” as output.
SHA2 512	SHA2 512 takes a message of any length smaller than 2128 bits as input and produces a 512-bit “fingerprint” as output.

Authenticating Network Traffic

The purpose of Authentication is to guarantee that, the sender of a datagram is, in fact, the sender and not a rogue party.

To authenticate datagrams, Hashing is used. Hashing is a mathematical method to verify and authenticate data. The result of Hashing are Hashes, which are sometimes also referred to as Message Digests.

Following is an overview of Hashing methods which are explained further in this section:

• Hashing with Public / Private Keys (RSA): Authentication is achieved by adding encrypted Hashes to the outgoing messages of the sender. These Hashes are decrypted by the receiver, achieving Mutual Authentication.

• Hashing with PSK: A Pre-Shared Key is an authentication mechanism that uses a password/key exchange. The password or key is only known by the parties allowed to participate in the communication.

• PKI: Public Key Infrastructure is a system of digital certificates (e.g. X.509), certification authorities (CA), and other registration authorities that verify and authenticate the validity of each party involved in the communication.

The Role of Public and Private Keys

Besides ensuring the integrity of data, hashes are also used to verify the identity of the sender. In other words, the sender is authenticated via a hash. Hashes are small and don’t require a lot of processing power. The mechanism is illustrated in the image below.

1. Bob generates a Key Pair and provides Alice with his Public Key.

2. Alice generates a Key Pair and provides Bob with her Public Key.

3. Rather than encrypting the whole message, Bob only encrypts the hash added to the message with his Private Key. The result of this encryption is encrypted again, but with Alice’s Public Key. Only Alice can decrypt this, since she has the matching Private Key.

4. Alice decrypts the message with her Private Key. The result is Bob’s encrypted hash. The hash can be read by Alice with Bob’s Public Key.

Mutual Authentication

• Alice is sure Bob is the author of the message since his Private Key was used to encrypt the hash and the hash can only be decrypted with Bob’s Public Key.

• In turn, if Alice sends a message to Bob using the same method, Bob is sure Alice is the author of the message, since her Private Key was used to encrypt the hash and the hash can only be decrypted with Alice’s Public Key.

As such, Mutual Authentication is achieved.

Hashing with a PSK

A Pre-Shared Key or PSK is a key which is shared and only known by two parties. Its provides Mutual Authentication and is required before a secure communication channel can be established between the parties, as illustrated below. The characteristics of this secret or key are determined by the system which uses it; some system designs require a particular format, e.g. a password like abc123. or a hexadecimal string like 65E4 E556 2286 EEE1.

Hashing using a PKI

PKI stands for Public Key Infrastructure. This networked infrastructure is built to safely create, organize, store, distribute, and maintain Public Keys and provides user identity inspection and assurance.

The keys used in the PKI are created by a Certificate Authority (CA). The concepts and use of the AXS Guard CA are explained in detail in the PKI How To.

AXS Guard IPsec Concepts and Features

Overview

In this chapter, we explain the concepts underpinning IPsec and how it overcomes Internet security problems by using the techniques as explained in IPsec Security Concepts.

Topics covered in this section include:

• A definition of IPsec.

• IPsec Security Features, such as Confidentiality, Integrity and Authentication.

• IPsec Components and Protocols, such as SA, IKE, AH and ESP.

• IPsec implementation modes: Transport Mode and Tunnel Mode.

• IPsec Phases and Parameters: Phase 1 and Phase 2.

• Advanced IPsec options, such as Extended Authentication, Dead Peer Detection and Aggressive Mode, NAT-Traversal and Firewall issues.

• E-tunnels: an easy method to create secure Star Networks using the GRE Protocol.

• Road Warriors: IPsec VPN clients.

Introduction to IPsec

IPsec is an Internet Engineering Task Force (IETF) standard suite of protocols (framework) providing data Confidentiality, Integrity, and Authentication while the data is transferred between communication points across IP networks. It is an open standard which provides data security at the IP datagram level and is defined per RFC 4301.

An IP datagram or packet (see below) is a data bundle that is organized for transmission across an IP network. It includes a header and payload (the data in the packet). IPsec emerged as a viable network security standard because enterprises wanted to securely transmit data over the Internet.

IPsec provides a framework to:

• Encrypt data packets with a given Encryption Algorithm (e.g. DES, 3DES and AES).

• Protect and authenticate data packets with a given Hash Algorithm (e.g. MD5 and SHA1).

Security Features

IPsec is the most secure method commercially available for connecting network sites. IPsec provides the following security features when transferring packets across networks:

• Confidentiality: Conceals the message content through encryption.

• Integrity: Ensures that the contents of the packet did not change in transit.

• Authentication: Verifies that the received packet is actually from the claimed sender.

Tunnel and Transport Mode

IPsec can be used in two modes: Tunnel Mode or Transport Mode. The modes are illustrated and explained below.

Transport Mode

In Transport Mode, the original IP header of the packet is used. The payload (data) can be encrypted and authenticated. This mode requires less processing, but has the disadvantage that mutable fields within the original IP header are not protected, i.e. tamper-proof. Another disadvantage is that you cannot use private IP addresses. Transport Mode should not be used by gateways.

Tunnel Mode

In Tunnel Mode, the original IP header is replaced with a tunnel header. The payload (data) can be encrypted and authenticated. This mode requires more processing, but protects the mutable fields within the original IP header (tamper-proof).

Another advantage of Tunnel Mode is that private IP addresses may be used for the inner IP header. Tunnel mode indicates that the traffic is tunneled to a gateway, which decrypts / authenticates the data, extracts it from the tunnel and passes it on to its final destination.

Important

AXS Guard only supports IPsec in Tunnel Mode. This has to be taken into consideration when connecting other IPsec appliances or clients to AXS Guard.

Components of the IPsec Framework

IPsec contains the following components, which are explained in the following subsections:

• Security Associations (SA): An SA is a channel and logical connection which provides a secure data connection between network devices.

• Internet Key Exchange (IKE): Provides key management and Security Association (SA) management.

• Authentication Header (AH): Provides Authentication and Integrity.

• Encapsulating Security Payload (ESP): Provides Confidentiality, Authentication, and Integrity.

Security Associations (SA)

A Security Association or SA (defined per defined per RFC 2401) is a bundle of algorithms and parameters needed to encrypt and authenticate a communication stream. Security services are afforded to an SA by the use of AH or ESP.

IKE SAs are bidirectional, while AH and ESP SAs are unidirectional. To secure typical, bidirectional communication between two hosts using AH and / or ESP, two SA’s (one in each direction) are required, as illustrated below.

An SA defines:

• The Encryption Algorithms to be used.

• The Hashing Algorithms to be used for Integrity.

• The Diffie-Hellman Group.

• Other advanced parameters, e.g. Perfect Forward Secrecy.

IPsec uses the Security Parameter Index (SPI) to link a data flow to the correct SA. The SPI is a unique identification tag added to the header for tunneling the IP traffic. This unique tag helps the kernel discern between traffic streams where different encryption rules and / or algorithms may be in use and is based on:

• An SPI number.

• A destination IP address.

• Network Restrictions, i.e. allowed networks and protocol IDs.

Internet Key Exchange (IKE)

IPsec uses the Internet Key Exchange (IKE) framework – defined per RFC 2409 – to facilitate and automate the SA setup and the exchange of keys used for encryption, authentication and integrity. The purpose of IKE is to negotiate and provide authenticated keying material for Security Associations in a protected manner.

IKE is a dynamic negotiation and exchange of:

• Security Parameters, e.g. the key strength and key lifetime.

• Authentication Keys, e.g. RSA keys, a PSK or X.509 certificate.

• Symmetrical Keys for encryption.

IKE Versions

There are a number of differences between IKEv1 and IKEv2, not the least of which is the reduced bandwidth requirements of IKEv2. Freeing up bandwidth is always a good thing as the extra bandwidth can be used for the transmission of data.

Another difference between IKEv1 and IKEv2 is the inclusion of EAP authentication in the latter. IKEv1 does not support EAP and can only choose between a pre-shared key and certificate authentication which IKEv2 also supports. EAP is essential in connecting with existing enterprise authentication systems.

Another difference between IKEv1 and IKEv2 is the incorporation of NAT-Traversal in the latter. NAT-Traversal is necessary when a router along the route performs Network Address Translation. This is when a router captures the packets sent and modifies the destination address on the packets. This is typical when multiple users are using the same Internet connection thus giving them the same IP address. This is not a problem with ordinary activities like browsing but can be a significant problem when IPsec is needed. That is why IKEv2 has a significant advantage over IKEv1

Lastly, IKEv2 has been improved so that it is able to detect whether the tunnel is still alive or not. This is commonly referred to as a “liveness” check. If the liveness check fails, caused by the tunnel breaking down, IKEv2 is then able to re-establish the connection automatically.

Key Lifetime

Keys ensure that only the sender and the receiver of a message can access it. IPsec requires that keys be re-created or refreshed frequently. IKE manages the process of refreshing keys; however, an administrator can control the key strength and the refresh frequency. Refreshing keys on a regular basis ensures data confidentiality between sender and receiver and prevents Replay Attacks and Session Hijacking.

IKE Protocols

A variety of IKE protocols exist and are briefly explained in the table below. In-depth details about the listed protocols are outside the scope of this How To. For more details about these protocols, consult the available online resources (RFCs).

Protocol	Description
ISAKMP	The Internet Security Association and Key Management Protocol (ISAKMP) defines procedures and packet formats to establish, negotiate, modify and delete Security Associations. ISAKMP defines payloads for exchanging key generation and authentication data (Peer Authentication). ISAKMP uses UDP port 500.
SKEME	The Secure Key Exchange Mechanism (SKEME) is a protocol which provides anonymity and quick key refreshment. SKEME uses Public Encryption for Authentication.
Oakley	The Oakley Key Determination Protocol is a key-agreement protocol allowing authenticated parties to exchange keying material across an insecure connection using the Diffie-Hellman algorithm.

IKE Proposals

An IKE proposal is a suggestion of how to protect data (Encryption and Hash Algorithms to be used). The VPN gateway initiating an IPsec connection, the initiator, sends a list of proposals, suggesting different methods of how to protect the connection, as illustrated below.

The connection being negotiated can be either an IPsec connection protecting the data flow through the VPN (AH and / or ESP), or it can be an IKE connection, protecting the IKE negotiation itself. The responding VPN gateway, upon receiving this proposal-list, chooses the most suitable proposal according to its own security policy, and responds by specifying which one of the proposal it has chosen. If no acceptable proposal can be found, it responds by saying that no proposal could be accepted, and possibly provides a reason why.

Authentication Header (AH)

The Authentication Header (AH) protocol is used to provide Integrity and Authentication to IP packets. It uses a Hash Function to produce a MAC or HMAC from the data in the IP packet. The MAC is transmitted with the packet, allowing the remote gateway to verify the integrity of the original IP packet, hereby making sure the data is tamper-proof (protection against Replay Attacks). AH has IP protocol number 51. AH only authenticates packets and does not encrypt them. Apart from the IP packet data, AH also authenticates parts of the IP header. In Transport Mode, the AH protocol inserts an AH header after the original IP header, and in Tunnel Mode, the AH header is inserted after the outer header, but before the original, inner, IP header (illustrated below).

Important

AXS Guard does not support AH, because it does not provide encryption. This has to be taken into consideration when connecting other IPsec appliances or clients to the AXS Guard. Only ESP is supported.

Encapsulating Security Payload (ESP)

The Encapsulating Security Payload (ESP) protocol is provides integrity, authentication and encryption to IP packets. ESP has IP protocol number 50. The format of the ESP packet is more complicated than the AH packet.

Actually there is not only an ESP header, but also an ESP trailer and ESP authentication data (see image below). The payload or data is located (encapsulated) between the header and the trailer, hence the name of the protocol.

• In Transport Mode, an ESP header is inserted right after the original IP header, as illustrated below. The ESP trailer and the optional authentication data are appended to the payload or data. ESP in Transport Mode provides neither authentication nor encryption for the IP header. This is a disadvantage, since false packets might be delivered for ESP processing.

• In Tunnel Mode, a new IP packet is constructed with a new IP header (see below). The original IP packet becomes the payload (data) for the new ESP packet. All data after the ESP header is encrypted and authenticated, hereby protecting the original IP header from eavesdroppers.

Important

AXS Guard only supports ESP in Tunnel Mode. This has to be taken into consideration when connecting other IPsec appliances or clients to the AXS Guard appliance.

IPsec Phases and Session Parameters

The process of negotiating session parameters consists of a number of phases and modes, which are explained in the following subsections. Following is a brief description of the IPsec phases (also illustrated below).

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

Both the IKE and the IPsec connections have limited lifetimes. These lifetimes prevent a connection from being used too long, providing more security. The longer a same key is used, the more insecure it becomes.

Phase 1: IKE Security Negotiation

When two IPsec endpoints negotiate security parameters, they exchange IKE Policies (Phase1, illustrated below). IKE Policies consist of the following parameters which must be coordinated (match) on both endpoints:

• IKE Encryption Algorithm: AES / DES / 3DES.

• IKE Authentication Algorithm: MD5 / SHA1.

• IKE Authentication Key: RSA / PSK / X.509 (explained further).

• Diffie-Hellman Group: 1 / 2 / 5 / 14 / 15 / 16 / 17 / 18.

• IKE Tunnel Lifetime: Lifetime in minutes, e.g. 60.

IKE Parameters which must be mirrored

IKE Policies consist of the following parameters which must be crossed on both endpoints:

• Remote IP Type:

  • Any: Allows any IP address (useful for Road-Warriors).

  • Specific: Specify the Remote Public IP. The Remote IP address must be static.

• Remote IP: The Public IP address of the remote SA.

The steps below explain the setup of Phase 1, as illustrated above.

1. The two parties negotiate the encryption and authentication algorithms to use in the IKE SAs, e.g. 3DES and SHA1. This is the IKE Proposal.

2. A shared Master Key is generated by the Diffie-Hellman Public key algorithm within the IKE for the two parties. The Master Key is also used in the Phase 2 to derive IPsec keys for the SAs.

3. The two parties authenticate each other using a predetermined mechanism. This process is also known as Peer Authentication and prevents rogue devices to establish tunnels in your network. Three methods are supported:

   • Authentication via RSA keys.

   • Authentication via a Pre-Shared Key.

   • Authentication via Digital Certificates (Only applies to Road Warriors, using PKI).

IKE Negotiation Modes

The IKE negotiation has two modes of operation: Main Mode and Aggressive Mode, as defined per RFC 2409.

• Main: Main Mode uses 6 messages to negotiate the IKE (3 exchanges of 2 messages, illustrated above):

  • IPsec Parameters (encryption and authentication algorithms)

  • Diffie-Hellman Public Key Exchange (Diffie-Hellman Groups)

  • ISAKMP Session Authentication (RSA key, preshared keys, X.509)

• Aggressive: Aggressive Mode will pass more information in fewer packets (3 messages), with the benefit of slightly faster connection establishment, at the cost of transmitting the identities of the security gateways in plaintext, which is less secure.

Phase 2: IPsec Security Negotiation

Only when Phase 1 is successfully completed, the Phase 2 negotiation (also called Quick Mode) is started. The Phase 2 setup is as follows:

1. The two parties verify which encryption and authentication algorithms are agreed upon in the IPsec SAs, e.g. 3DES and SHA1. If a difference exists on either SA, the Phase 2 fails. The Master Key, negotiated via Diffie-Hellman in Phase 1, is used to derive the IPsec keys for the SAs. Once the SA keys are created and exchanged, the IPsec SAs are ready to protect user data between the two VPN gateways.

2. The Security Policies are exchanged. The Security Policies contain the Local and Remote parameters, determine which network traffic is allowed and identify the tunnels (if more than one tunnel definition is present).

3. Optionally, Perfect Forward Secrecy, which is explained further, is enabled.

The parameters for the IPsec connection are negotiated via the IKE SAs. The following 7 parameters must match on both endpoints:

IPsec Parameters

• IPsec Encryption Algorithm: AES / DES / 3DES / Blowfish / Twofish / Serpent / CAST.

• IPsec Authentication Algorithm: MD5 / SHA1.

• IPsec Protocol: ESP / AH.

• IPsec Mode: Tunnel Mode / Transport Mode.

• IPsec Tunnel Lifetime: Lifetime in minutes, e.g. 480.

• Local Parameters (see below): Local Identifier Type / Local Identifier / Local Network / Allowed Protocols and Ports.

• Remote Parameters (see below): Remote IP Type / Remote IP / Remote Identifier Type / Road-Warrior Definition / Remote Network / Allowed Protocols and Ports.

Reminder

AXS Guard does not support AH and Transport Mode.

The Local and Remote Parameters determine which networks may communicate via the IPsec tunnel, the identifiers of the IPsec SAs and the type of allowed traffic (protocols and port numbers). Details are provided below.

Local Access and Identification Parameters

Name	Description
Local Network	The local LAN IP address and subnet, e.g. 192.168.1.0/24
Traffic Selector	Specify the protocol and/or port which is allowed to traverse the IPsec tunnel. Use the following format without spaces: protocol number/port number or protocolname/portname, e.g. 6/25 or tcp/smtp. If left blank, no protocol / port restrictions apply.

Local identification parameters

• Local Identifier Type:

  • Local endpoint IP: IP address used or identification with the remote SA.

  • Other: Local Identifier. A string to uniquely identify the local SA, e.g. tunnel_X.

• Local Virtual Endpoint IP: The local Virtual IP address to be used for the E-tunnel, e.g. 192.168.254.10

Info

If the Local Identifier Type is an X.509 certificate, you can only select the certificate. X.509 is meant to be used with Road Warriors.

Remote Access and Identification Parameters

Name	Description
Remote Network	Only to be used when connecting two VPN appliances. The remote LAN IP address and subnet. Use the CIDR notation, e.g. 172.16.77.0/24
Allowed IP Range	Only to be used with Road-Warriors. Enter the allowed IP range using the CIDR notation. If you wish to allow any client, enter 0.0.0.0/0
Traffic Selector	Specify the protocols and/or ports which are allowed to traverse the IPsec tunnel. Use the following format without spaces: protocol number/port number or protocolname/portname, e.g. 6/25 or tcp/smtp. If left blank, no protocol / port restrictions apply.

Remote identification parameters

• Remote Identifier Type

  • Remote Endpoint IP: The IP address by which the remote SA is identified (Public IP address).

  • Other: Remote Identifier. Enter the unique string by which the remote SA is identified, e.g. tunnel_Y.

• Road-Warrior Definition

  • Unchecked: Uncheck this option if the Tunnel Definition is not used by Road-Warriors, but in a network to network setup.

  • Checked: Check this option is the Tunnel Definition is to be used by Road-Warriors and enter the Remote Network within settings.

Important

If the Remote Identifier Type is an X.509 certificate, you can only select the certificate. X.509 is meant to be used with Road Warriors.

Do not use the endpoint IP as a connection identifier on an appliance of which the Internet interface(s) is/are NATted. 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 NATted, 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 its IPsec server log. The Local and Remote Parameters must be mirrored exactly for the IPsec connection to succeed (as illustrated below). The slightest misconfiguration will prevent the IPsec tunnel from coming up.

Perfect Forward Secrecy (PFS)

The Re-key, or key re-generation is a process where new key material is created to protect IP traffic. The main cause of re-keying in IPsec is the expiration of the Phase 1 or the Phase 2 SA. The time when the SA expires is determined by the lifetime of the SA.

If Perfect Forward Secrecy (PFS) is specified in the IPsec Security Policy, a new Diffie-Hellman exchange is performed with each Quick Mode (Phase 2) providing keying material with greater entropy (key material life) and which is therefore more resistant to cryptographic attacks. Each Diffie-Hellman exchange requires large calculations, thereby increasing CPU use and inducing a certain performance cost. With today’s hardware specifications, PFS by far outweighs the (negligible) performance cost. Able therefore highly recommends the use of PFS.

Important

Both sides of the VPN must be able to support PFS in order for PFS to work. When PFS is enabled, the two gateways must generate a new set of phase 1 keys for every negotiation of a new phase 2 SA.

Additional IPsec Options

Dead Peer Detection

Dear Peer Detection (DPD) is a method to detect a dead Internet Key Exchange (IKE) peer by sending periodic control messages to it. DPD is also used to perform an IKE peer Failover. Failover is the capability to automatically switch over to a redundant or standby system (slave), after the failure or abnormal termination of the main system (master). If you have two Internet lines (Redundancy), you can easily create such a system on AXS Guard. Failover occurs transparently, without human intervention.

Maximum Transmission Unit

The Maximum Transmission Unit (MTU) is the largest number of bytes which can be carried by a Program Data Unit (PDU). A PDU is information that is delivered as a unit between peers in a network and that may contain control information, address information or data. The MTU setting should only be adjusted if fragmentation issues occur between IPsec SAs. More information about MTU settings is available in the AXS Guard System Administration How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool.

Compression

IPsec uses the IP payload compression protocol (IPComp) to reduce the size of IP datagrams. IPComp is defined per RFC 3173. This protocol increases the overall communication performance between a pair of communicating hosts / gateways by compressing the payload of an IP packet. In the case of IPsec, the payload is everything following the outer IP header.

Extended Authentication (XAUTH)

This section only applies to Road Warriors, i.e. IPsec clients, explained in the AXS Guard IPsec XAUTH How To, which can be accessed via the Documentation button in the Administrator Tool.

Extended Authentication or XAUTH provides an additional level of authentication by allowing the IPsec gateway to request extended authentication from remote users (Road-Warriors), thus forcing remote users to respond with their credentials before being allowed access to the VPN.

XAUTH functions by first forming an IKE Phase 1 SA using conventional IKE and then extends the IKE exchange to include additional user authentication exchanges.

The advantage of XAUTH, is that only a single IPsec Tunnel needs to be configured on the AXS Guard for multiple clients. You don’t need to create a separate Tunnel Definitions for each Road Warrior.

AXS Guard allows the implementation of various Authentication Policies for IPsec, such as DIGIPASS Authentication and RADIUS back-end Authentication. These are explained in greater detail in the AXS Guard Authentication How To, which is available by clicking on the permanently available Documentation button in the Administrator Tool.

IPsec and Firewalls

Internet Firewall Settings

Many UTM appliances have built-in firewalls. Virtual Private Networks (VPN) like IPsec cannot function properly if firewall settings block all incoming traffic. You should check the relavant documentation of your appliance to allow specific protocols, ports and addresses. The AXS Guard automatically adds the necessary Firewall Rules for the Internet interface(s) when the IPsec feature is enabled. The protocols and ports to be allowed are listed below.

• IKE / UDP Port 500: Used by IKE.

• AH / IP Protocol ID 51: Used with AH. Only ESP is supported by AXS Guard.

• ESP / IP Protocol ID 50: Used by ESP traffic.

• UDP / Port 4500: Necessary to allow NAT Traversal.

LAN Firewall Settings

Firewall settings are automatically applied when an IPsec Tunnel is created. However, there is an important distinction between “classic” IPsec tunnels and E-tunnels. The difference between both tunnel types is illustrated below.

Classic IPsec Tunnels

Firewall Rules are automatically added to the stat-vpn policy for the subnets specified in the Tunnel Definition. Based on the illustration below, the automatically added Firewall Rules would be:

• AXS Guard #1 62.58.227.146

  • ipsec_tunnel_r1: On any ACCEPT 192.168.10.0/24 > 192.168.20.0/24

  • ipsec_tunnel_r2: On any ACCEPT 192.168.20.0/24 > 192.168.10.0/24

• AXS Guard #2 195.07.6.86

  • ipsec_tunnel_r1: On any ACCEPT 192.168.20.0/24 > 192.168.10.0/24

  • ipsec_tunnel_r2: On any ACCEPT 192.168.10.0/24 > 192.168.20.0/24

Important

Firewall Rules are added automatically for the specified networks when a tunnel is created. If you modify your local or remote network settings, the associated firewall rules will be automatically adjusted to match your new configuration.

E-tunnels

Firewall Rules are automatically added for the E-tunnel devices to the stat-etunnel Firewall Policy. An E-tunnel device is a virtual network interface that can be addressed by software (e.g. routing software), but which does not physically exist.

Firewall Rules are automatically added based on the tunnel definition and the Virtual IP addresses:

• AXS Guard #1 62.58.227.146

  • etunnel_X: On any ACCEPT 10.10.10.2/32 > 10.10.10.1/32

• AXS Guard #2 195.07.6.86

  • etunnel_X: On any ACCEPT 10.10.10.1/32 > 10.10.10.2/32

When adding routing entries to connect the subnets (based on the illustration above), the Firewall Rules listed below are added automatically to the stat-vpn policy and the AXS Guard Administrator Tool generates an Actication Warning.

Important

• Firewall Rules for specific subnets are only added if the adequate routing entries are made , as opposed to “classic” IP Tunnels. The Firewall Rules should be adjusted according to your needs. They are not automatically updated if subnets or routes are removed or modified.

• Firewall Rules for any network alias added to a secure device, e.g. eth0 are not added automatically. They must be entered manually (see the section about E-tunnels with Aliases and the Troubleshooting section for detailed information).

E-tunnel Subnet Firewall Rules

• AXS Guard #1 62.58.227.146

  • axs2_r1: On any ACCEPT 192.168.10.0/24 > 192.168.20.0/24

  • axs2_r2: On any ACCEPT 192.168.20.0/24 > 192.168.10.0/24

• AXS Guard #2 195.07.6.86

  • axs1_r1: On any ACCEPT 192.168.20.0/24 > 192.168.10.0/24

  • axs1_r2: On any ACCEPT 192.168.10.0/24 > 192.168.20.0/24

E-tunnels with Aliases

When adding routing entries to connect the subnets (based on the illustration below), the Firewall Rules listed above are added automatically to the stat-vpn policy and the AXS Guard Administrator Tool generates a warning, such as the one shown above. Firewall Rules to allow traffic originating from any network alias added to a secure device, e.g. eth0 are not added automatically. They should be entered manually, as explained in the following example.

Adding a route for the destination network 192.168.20.0/24 on AXS Guard #1 via an E-tunnel automatically adds the the following Firewall Rules:

• r1 On any ACCEPT 192.168.10.0/24 > 192.168.20.0/24

• r2 On any ACCEPT 192.168.20.0/24 > 192.168.10.0/24

This means that network traffic originating from 172.16.202.0/24 cannot be sent to 192.198.20.0/24, since the associated Firewall Rules are not created. The Firewall Rules must be entered manually (see Configuration Examples, which explain the procedure to add and verify routes). Based on the illustration above, the following Firewall Rules must be added on AXS Guard #1.

• r1 On any ACCEPT 172.16.202.254/24 > 192.168.20.0/24

• r2 On any ACCEPT 192.168.20.0/24 > 172.16.202.254/24

On AXS Guard #2, add the necessary routing entries towards 192.168.10.0/24 and 172.16.202.0/24.

NAT-Traversal and PAT

NAT Traversal NAT PAT Port Address Translation Network Address Translation

Network Address Translation (NAT) involves changes in packet headers. NAT is explained in the AXS Guard System Administration How To, available via the Documentation button in the Administrator Tool.

Port Address Translation (PAT), is an extension to NAT which allows multiple devices on a local area network (LAN) to be mapped to a single public IP address. The goal of PAT is to conserve IP addresses. Port Address Translation is also called porting, port overloading, port-level multiplexed NAT and single address NAT.

Any attempt to perform a NAT / PAT operation on IPsec packets creates issues, because IPsec authenticates all packets in Tunnel Mode. This means that packets must remain unaltered for the sake of data integrity.

If you need to translate TCP or UDP communications from hosts on a private network to hosts on a public network and vice versa, you must use NAT Traversal. If enabled, NAT Traversal inserts a UDP header with destination port 4500 right before the ESP header. The inserted UDP header can be translated (modified), while keeping the original IP header intact (illustrated below). This way, the packet can reach its final destination intact.

Important

Do not use the endpoint IP as a connection identifier on an appliance of which the Internet interface(s) is/are NATted. 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 NATted, 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 its IPsec server log.

For additional details about NAT Traversal, see RFC 3715.

Important

Forcing NAT-Traversal may be necessary even when the peers are not NAT’d, e.g. when a router is not forwarding the ESP packets.

E-tunnels

Definition

Standard IPsec tunnels restrict traffic between the subnets specified in the SAs, which also means that separate SAs have to be created per subnet. This requires a lot of configuration, especially in complex setups. E-tunnels are special IPsec tunnels which overcome the subnet constraint inherent to standard IPsec tunnels. E-tunnels use Virtual Endpoint IP addresses (illustrated below) in combination with the GRE protocol (defined per RFC 2784) and have multiple advantages, which we explain further.

E-tunnel packets are constructed as follows:

Advantages

E-tunnels require less configuration.

E-tunnels enable system administrators to easily create secure Hub-to-Spoke or Star Networks. Rather than creating and maintaining separate IPsec Tunnel Definitions to connect separate secure LANs, you only need to create a single Tunnel Definition on each endpoint to obtain the same result (compare the examples below).

With standard IPsec, you need to set up 3 IPsec Tunnel Definitions to connect all 4 networks, i.e. 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24 and 192.168.4.0/24.

You can obtain the same result with only 1 E-tunnel on each IPsec endpoint and and by adding static routes on AXS Guard A and B:

E-tunnels allow easy routing between local subnets.

As mentioned earlier, E-tunnels are special IPsec tunnels which overcome the subnet constraint inherent to standard IPsec tunnels and facilitate the configuration of secure Star Networks. To connect different subnets via E-tunnels, administrators only need to add the appropriate static route entries on all endpoints.

Based on the figure above, the routing entries would be as follows:

E-tunnel Routing AXS GUARD A

Destination Network	Network Device
192.168.1.0/24	Secure LAN
192.168.2.0/24	E-tunnel
192.168.3.0/24	E-tunnel
192.168.4.0/24	E-tunnel

E-tunnel Routing AXS GUARD B

Destination Network	Network Device
192.168.1.0/24	E-Tunnel
192.168.2.0/24	Secure LAN
192.168.3.0/24	Secure LAN
192.168.4.0/24	Secure LAN

VPN Failover

E-tunnels are highly recommended if you have 2 (or more) separate Internet lines connected to an AXS Guard in a remote network. To use the VPN Failover system, administrators need to create separate tunnel definitions (1 for each tunnel, including the failover), to add an extra route, assign the adequate priority and enable Dead Peer Detection on the local and the remote AXS Guard.

If the main Internet line of the remote AXS Guard fails, the E-tunnel traffic is routed via the alternate Internet line according to the added route. Based on the image below, you would have 2 tunnel definitions on AXS Guard A and 2 tunnel definitions on AXS Guard B. Remember to use unique Virtual IP addresses for each tunnel definition.

NAT Traversal and Connection Identifiers

If the local identifier of the NATted side of the connection is an endpoint IP, then the receiving end’s remote identifier may not be configured as an endpoint IP.

In other words, the NATed IP will be used to authenticate the NATted host with the receiving end, which only sees the external IP of the NATted side. Since IPsec requires both ends of the connection to be exact matches, the receiving end will refuse the NATted host’s proposal (IP mismatch).

We therefore highly recommended the use of custom identifiers when configuring e-tunnels combined with NAT traversal.

Road Warriors

The IPsec protocol can be used to set up an AXS Guard VPN server for roaming clients on the Internet. This is commonly called a "Road Warrior" configuration, because the VPN client is typically a laptop that is connected to the Internet via a public access point, e.g. in an airport. Road Warriors can be forced to provide credentials when connecting to the AXS Guard IPsec server. This is known as extended authentication.

An example of a Road Warrior setup is provided in the IPsec XAUTH How To and the L2TP How To, available via the Documentation button in the AXS Guard Administrator Tool.

PKI Configuration

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 Configuration

Overview

Topics covered in this section include:

• How to enable the IPsec feature on your appliance.

• General server settings, such as X.509 options and interfaces to bind IPsec.

• Creating your own IKE and ESP profiles.

• How to create and configure IPsec tunnels.

Info

To change or update your AXS Guard configuration, you must log in with administrator privileges as explained in the AXS Guard System Administration How To, which can be accessed by clicking on the permanently available Documentation link in the Administrator Tool.

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.

   

Info

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.

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.

   

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.

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.

IKE and ESP Profiles

In this section, we explain how to configure IKE (Phase 1) and ESP (Phase 2) profiles on the AXS Guard. IKE and ESP profiles both determine:

• The encryption algorithms to be used.

• The authentication algorithms to be used.

• The Diffie-Hellman Group to be used.

To change or update your AXS Guard configuration, you must log in with administrator privileges as explained in the AXS Guard System Administration How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool.

Predefined IKE Profiles

For convenience, predefined IKE profiles are available on the AXS Guard so that you don’t have to configure your own. Predefined IKE profiles cannot be modified or edited. However, you can create a new definition based on a predefined IKE profile by clicking on Edit as new. To access the predefined IKE profiles:

1. Navigate to VPN > IPsec > IKE Profiles.

2. Click on an IKE profile name to view its configuration.

   

Creating IKE Profiles

1. Navigate to VPN > IPsec > IKE Profiles.

2. Click on Add New.

3. Enter the IKE settings as explained in the table below.

4. Click on Save.

   

Option	Description
Name	Enter a name for your IKE profile. This name will appear in the IKE profile drop-down menu when you configure an IPsec tunnel.
Description	Enter a description for the new IKE profile. Even though this is an optional field, we recommend using a sensible name to facilitate the configuration of your IPsec tunnels. The description will also appear in the IKE profile drop-down menu when you configure or edit a tunnel.
Encryption Algorithm	Select the desired encryption algorithm in the drop-down menu. Note that the selected encryption algorithm must match the one of the other endpoint to successfully establish a tunnel.
Hash Algorithm	Select the desired hash algorithm in the drop-down menu. Note that the selected algorithm must match the one of the other endpoint to successfully establish a tunnel.
DH Group	Select the appropriate Diffie-Hellman Group in the drop-down menu. Note that the selected group must match the group of the other endpoint in order to successfully establish a tunnel.

Info

You can create a new IKE profile based on a predefined IKE profile by clicking on Edit as new.

Predefined ESP Profiles

Predefined ESP profiles are available on the AXS Guard, so you don’t have to configure your own. Predefined ESP profiles cannot be modified or edited. However, you can create a new ESP profile based on a predefined ESP profile by clicking on Edit as new. To access the predefined ESP profiles:

1. Navigate to VPN > IPsec > ESP Profiles.

2. Click on an ESP profile name to view its configuration settings.

   

Creating ESP Profiles

1. Navigate to VPN > IPsec > ESP Profiles.

2. Click on Add New.

3. Enter the settings as explained in the table below.

4. Click on Save.

   

Option	Description
Name	Enter a name for your ESP profile. This name will appear in the ESP profile drop-down menu when you configure an IPsec tunnel.
Description	Enter a description for the new ESP profile. Even though this is an optional field, we recommend using a sensible name to facilitate the configuration of your IPsec tunnels. The description will also appear in the ESP profile drop-down menu when you configure or edit a tunnel.
Encryption Algorithm	Select the desired encryption algorithm in the drop-down menu. Note that the selected encryption algorithm must match the one of the other endpoint to successfully establish a tunnel.
Encryption Key Size	Select the desired key size for the encryption algorithm. The number of available key sizes depends on the selected encryption algorithm.
Authentication Algorithm	Select the desired hash algorithm in the drop-down menu. Note that the selected algorithm must match the one of the other endpoint to successfully establish a tunnel.
Perfect Forward Secrecy	Check to enable Perfect Forward Secrecy (PFS). If PFS is enabled, a new Diffie-Hellman exchange is performed with each Quick Mode (Phase 2) negotiation, providing keying material with a greater entropy, meaning it is more resistant to cryptographic attacks. Note that both sides of the VPN must be able to support PFS in order for PFS to work.
DH Group	Select the appropriate Diffie-Hellman Group in the drop-down menu. Note that the selected group must match the group of the other endpoint in order to successfully establish a tunnel.

Info

You can create a new ESP profile based on a predefined ESP profile by clicking on Edit as new.

IPsec Tunnels

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.

   

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

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.
Automatic Firewall	When enabled, the AXS Guard appliance will automatically create, update and delete firewall rules for the tunnel. If you wish to create your own firewall rules, disable this option.

Phase 1 - Main Mode (IKE)

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)

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.

Configuration Examples

Overview

In this section we provide some hands-on examples of IPsec tunnels.

To change or update your AXS Guard configuration, you must log in with administrator privileges as explained in the AXS Guard System Administration How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool.

Important

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

E-tunnel with RSA Authentication

Overview

In this section we explain how to set up an E-tunnel with RSA Authentication between two AXS Guard appliances, based on the setup illustrated below. We start by configuring AXS Guard#1, followed by AXS Guard#2 (from left to right).

The most important considerations are:

• To match the Phase 1 and Phase 2 encryption and authentication parameters on both IPsec endpoints.

• To correctly mirror the local and remote Phase 2 parameters on both AXS Guard appliances.

Tunnel Setup

1. Log in to the local AXS Guard.

2. Navigate to VPN > IPsec > Tunnels.

3. Click on Add new.

4. Enter a name and description for the new tunnel.

5. Check the "E-tunnel" option.

6. Enter the phase 1 settings as shown in the screenshot below:

   

7. Enter the phase 2 settings as shown in the screenshot below:

   

8. Click on Save. An activation notice will be displayed.

9. Repeat the same steps on the remote AXS Guard appliance.

Important

The virtual endpoint IPs must be unique in their respective networks.

Routing

In this section, we explain how to add the necessary routing to each of the AXS Guard secure subnets. The appropriate routing entries must be added on each AXS Guard appliance:

AXS GUARD #1

1. Log on to AXS Guard#1.

2. Go to Network > Routing.

3. Click on Add new.

4. Add a route towards the AXS Guard#2 subnet as shown below.

5. Click on Save.

   

AXS GUARD #1

1. Log on to AXS Guard#2.

2. Go to Network > Routing.

3. Click on Add new.

4. Add a route towards the AXS Guard#1 subnet as shown below.

5. Click on Save

   

Checking the Tunnel Status

1. Log on to the first AXS Guard appliance.

2. Navigate to VPN > IPsec > Status.

3. Restart the E-tunnel (if necessary) by clicking on Restart.

   

Checking the Firewall Configuration

In this section, we explain how to verify the automatically added Firewall Rules of the AXS Guard E-tunnel definitions.

Important

• Firewall Rules are automatically added when E-tunnel routing entries are created. However, they must be adjusted manually if the routing entries are modified.

• The Firewall Rules are not automatically/dynamically updated if routes are removed or modified to allow more flexibility in the customization. This way, administrators can tailor firewalling in accordance with their company security policy without affecting the existing routing configuration.

1. Log on to AXS Guard#1.

2. Navigate to Firewall > Policies > Static

3. Click on the stat-vpn policy.

   

4. Repeat steps 1 to 3 for AXS Guard#2.

E-tunnel with RSA Authentication and NAT-Traversal

Tunnel Setup

Check the Force NAT-T option in the phase 1 options.

E-tunnel with PSK Authentication

Overview

In this section, we explain how to set up an E-tunnel with PSK Authentication between two AXS Guard appliances. We start by configuring AXS Guard#1, followed by AXS Guard#2 (from left to right). The most important considerations are:

• To match the Phase 1 and Phase 2 encryption and authentication parameters on both IPsec endpoints.

• To properly mirror the local and remote Phase 2 parameters on both AXS Guard appliances.

Tunnel Setup

1. Log in to the first AXS Guard appliance.

2. Navigate to VPN > IPsec > Tunnels.

3. Select the tunnel created in the previous section and select "Edit as new".

4. Change the name and description.

5. Change the Host Authentication method to PSK as shown in the screenshot below:

   

6. Log in to the second AXS Guard appliance and repeat the same steps.

Routing

In this section, we explain how to add the necessary routing to each of the AXS Guard secure subnets. The appropriate routing entries must be added on each AXS Guard appliance:

AXS GUARD #1

1. Log on to AXS Guard#1.

2. Go to Network > Routing.

3. Click on Add new.

4. Add a route towards the AXS Guard#2 subnet as shown below.

5. Click on Save.

   

AXS GUARD #1

1. Log on to AXS Guard#2.

2. Go to Network > Routing.

3. Click on Add new.

4. Add a route towards the AXS Guard#1 subnet as shown below.

5. Click on Save

   

Checking the Tunnel Status

1. Log on to the first AXS Guard appliance.

2. Navigate to VPN > IPsec > Status.

3. Restart the E-tunnel (if necessary) by clicking on Restart.

   

Checking the Firewall Configuration

In this section, we explain how to verify the automatically added Firewall Rules of the AXS Guard E-tunnel definitions.

Important

• Firewall Rules are automatically added when E-tunnel routing entries are created. However, they must be adjusted manually if the routing entries are modified.

• The Firewall Rules are not automatically/dynamically updated if routes are removed or modified to allow more flexibility in the customization. This way, administrators can tailor firewalling in accordance with their company security policy without affecting the existing routing configuration.

1. Log on to AXS Guard#1.

2. Navigate to Firewall > Policies > Static

3. Click on the stat-vpn policy.

   

4. Repeat steps 1 to 3 for AXS Guard#2.

Building a Star Network with E-tunnels

Overview

In this section, we explain how to create a Star Network connecting three AXS Guard appliances via E-tunnels with PSK Authentication. The setup is illustrated below.

The most important considerations are:

• The central AXS Guard (hub) has to be connected to all other AXS Guard appliances with an E-tunnel.

• You must add the appropriate routing entries on all AXS Guard appliances for the subnets.

• The needed Firewall Rules are generated automatically and should be adapted according to the users' needs. You should always check the Static Firewall Policy of the central AXS Guard (hub).

• To avoid mistakes, only use 1 virtual IP address per AXS Guard. This virtual IP address can be used by multiple E-tunnels (if you are not using a failover setup).

• Enable Dead Peer Detection if you connect to a site equipped with an AXS Guard failover system.

Tunnel Setup

AXS GUARD #1

Use the same setup for AXS GUARD#1 as explained in E-tunnel with PSK Authentication.

AXS GUARD #2 Use the same setup for AXS GUARD#2 as explained in E-tunnel with PSK Authentication. Add an additional Tunnel Definition to connect AXS GUARD#2 with AXS GUARD#3:

1. Log on to the second AXS Guard.

2. Navigate to VPN > IPsec > Tunnels.

3. Click on the existing Tunnel.

4. Click on Edit as New.

5. Use the same phase 1 settings as shown in the example below:

   

6. Update the phase 2 parameters as shown in the example below.

   

AXS GUARD #3

1. Log on to AXS Guard#3.

2. Navigate to VPN > IPsec > Tunnels.

3. Click on Add new.

4. Follow the same steps as you did for AXS Guard#1 and AXS Guard#2, but modify the following:

   • The remote endpoint IP

   

   • The Local parameters

   • The Remote parameters

   

Routing

The appropriate routing entries must be added on all AXS Guard appliances.

AXS GUARD #1

1. Log on to AXS Guard#1.

2. Navigate to Network > Routing.

3. Click on Add new.

4. Enter the routing settings towards the AXS Guard#2 subnet as shown in the example below and save your configuration.

5. Enter the routing settings towards the AXS Guard#3 subnet and save your configuration.

   

AXS GUARD #2

1. Log on to AXS Guard#2.

2. Navigate to Network > Routing.

3. Click on Add new.

4. Enter the routing settings towards the AXS Guard#1 subnet and save your configuration.

5. Enter the routing settings towards the AXS Guard#3 subnet and save your configuration.

AXS GUARD #3

1. Log on to AXS Guard#3.

2. Navigate to Network > Routing.

3. Click on Add new.

4. Enter the routing settings towards the AXS Guard#2 subnet and save your configuration.

5. Enter the routing settings towards the AXS Guard#1 subnet and save your configuration.

Checking the Tunnel Status

In this section, we explain how to check the status of your E-tunnels, once the configuration is complete. If all settings are correct, the tunnel is started immediately.

1. Log on to the first AXS Guard appliance.

2. Navigate to VPN > IPsec > Status.

3. Restart the E-tunnel (if necessary) by clicking on Restart.

   

Checking the Firewall Configuration

In this section, we explain how to add Firewall Rules on the AXS Guard E-tunnel hub (appliance #2 in the illustration) to enable communications between the AXS Guard#1 and AXS Guard#3 subnet. Inportant considerations are:

• The necessary Firewall Rules must be added manually on the central AXS Guard (acting as a hub) to allow network traffic between all network leaves.

• Firewall Rules that allow network traffic between the leaves and the hub are added automatically.

Important

• Firewall Rules are automatically added when E-tunnel routing entries are created. However, they must be adjusted manually if the routing entries are modified.

• The Firewall Rules are not automatically/dynamically updated if routes are removed or modified to allow more flexibility in the customization. This way, administrators can tailor firewalling in accordance with their company security policy without affecting the existing routing configuration.

AXS Guard #2

Create Firewall Rules from and to the AXS Guard#1 and AXS Guard#3 subnets:

1. Log on to AXS Guard#2.

2. Navigate to Firewall > Rules > Through.

3. Search for the Firewall Rules which were automatically created for both Tunnel Definitions, i.e. enter tunnel in the search filter.

   

4. Open one of the Firewall Rules.

5. Click on Edit as New.

6. Create a new Firewall Rule to allow network traffic from AXS Guard#1 to AXS Guard#3 and save.

7. Create a new Firewall Rule to allow network traffic from AXS Guard#3 to AXS Guard#1 and save.

Add the created Firewall Rules to the Static Firewall Policy stat-vpn:

1. Navigate to Firewall > Policies > Static.

2. Click on stat-vpn.

3. Add the created Firewall Rules to the stat-vpn Policy and update your configuration.

   

You can also use a larger subnet on the central AXS Guard (hub), e.g. On any ACCEPT 192.168.0.0/16 > 192.168.0.0/16, for convenience. This can be useful if you intend to add any tunneled networks / subnets in the future.

The use and configuration of the AXS Guard Firewall is explained in the AXS Guard Firewall How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool.

E-tunnel with Failover

Overview

In this section, we explain how to create an E-tunnel VPN Failover setup. This setup is only possible if you are connecting an AXS Guard to another AXS Guard with two (or more) Internet lines. The example in this section is based on the illustration below.

Tunnel Setup

1. Create an E-tunnel towards the main public IP address of the AXS Guard appliance with multiple Internet lines (AXS Guard B).

2. Enable Dead Peer Detection.

3. Create another E-tunnel towards the secondary public IP address of the AXS Guard with multiple Internet lines (AXS Guard B).

4. Enable Dead Peer Detection.

   

Important

• Use a unique Virtual IP address for each tunnel definition.

• Use a unique identifier for each tunnel definition.

• Dead Peer Detection must be enabled for the failover to function.

AXS GUARD B

1. Create an E-tunnel towards the public IP address of AXS Guard A.

2. Enable Dead Peer Detection.

3. Specify the Interface to bind IPsec.

4. Create a second E-tunnel towards the public IP address of AXS Guard A.

5. Enable Dead Peer Detection.

6. Specify the Interface to bind IPsec (Internet Line 2).

Important

• Use a unique Virtual IP address for each tunnel definition.

• Use a unique identifier for each tunnel definition.

• Dead Peer Detection must be enabled for the failover to function.

Routing

AXS Guard A

Add the required routes.

• For the E-tunnel towards the main public IP address of AXS Guard B, use priority 0.

• For the E-tunnel towards the secondary public IP address of AXS Guard B, use priority 1.

AXS Guard B (with multiple Internet lines)

Add the necessary routing entry.

• For the 1st E-tunnel to AXS Guard A, use priority 0.

• For the 2nd E-tunnel to AXS Guard A, use priority 1.

Info

0 is the highest priority.

Checking the Tunnel Status

Follow the same steps as explained in Checking the Tunnel Status.

Checking the Firewall Configuration

In this section, we explain how to verify the automatically added Firewall Rules of the AXS Guard E-tunnel definitions.

Important

• Firewall Rules are automatically added when E-tunnel routing entries are created. However, they must be adjusted manually if the routing entries are modified.

• The Firewall Rules are not automatically/dynamically updated if routes are removed or modified to allow more flexibility in the customization. This way, administrators can tailor firewalling in accordance with their company security policy without affecting the existing routing configuration.

1. Log on to AXS Guard#1.

2. Navigate to Firewall > Policies > Static

3. Click on the stat-vpn policy.

   

4. Repeat steps 1 to 3 for AXS Guard#2.

Connecting with a Third-Party VPN Solution

Overview

In this section, we explain how to set up an IPsec tunnel between a third-party VPN appliance and the AXS Guard. The most important considerations are:

• To only use features (encryption and authentication algorithms) which are supported by both IPsec endpoints. AH and Transport Mode are not supported on the AXS Guard.

• To match the Phase 1 and Phase 2 encryption and authentication parameters on both IPsec endpoints.

• To properly mirror the local and remote Phase 2 parameters on both IPsec endpoints.

Tunnel Setup

1. Navigate to VPN > IPsec > Tunnels.

2. Click on Add new.

3. Enter a name for the Tunnel Definition, e.g. my_tunnel.

4. Enable the tunnel.

5. Enter a description for the tunnel (optional).

6. Select the interface to bind IPsec, e.g. eth1 (this option is only applicable if your appliance has Internet Redundancy).

7. Select the desired Authentication parameters.

8. Enter the Phase 1 and Phase 2 settings. Remember that the local parameters on the AXS Guard must be entered as the remote parameters on the third-party appliance and vice versa.

9. Save your configuration.

10. Once the 3^rd Party appliance is configured, check the IPsec Tunnel status .

On the 3rd-party appliance*

1. Log on to the third-party device.

2. Enter the same Phase 1 and Phase 2 settings on the third-party device. Make sure to correctly mirror the local and remote Phase 2 parameters. The local parameters on the AXS Guard are the remote parameters on the third-party device and vice versa.

3. Ensure to add the correct routing entries and firewall rights.

4. Save your configuration.

Important

• AH and Transport Mode are not supported by the AXS Guard appliance.

• The slightest error in a Tunnel Definition (on either side) will prevent the IPsec tunnel from coming up. Verify your tunnel configuration carefully.

Checking the Tunnel Status

1. Log on to the first AXS Guard appliance.

2. Navigate to VPN > IPsec > Status.

3. Restart the E-tunnel (if necessary) by clicking on Restart.

   

Checking the Firewall Configuration

Important

Firewall Rules are automatically added for the specified networks when a tunnel is created. However, you must adjust the Firewall Rules accordingly if you modify the tunnel’s network settings. The Firewall Rules are not automatically/dynamically updated if tunnel subnets or routes are removed or modified after the initial tunnel setup.

To verify VPN Firewall Rules on the AXS Guard appliance:

1. Log on to AXS Guard.

2. Navigate to Firewall > Policies > Static

3. Click on the stat-vpn policy.

Also verify the firewall configuration of the 3^rd-party appliance. Consult its documentation if necessary.

Accessing the IPsec Status and Logs

Overview

In this section, we explain how to:

• Access the AXS Guard IPsec VPN status (Phase 1 and Phase 2).

• Access the AXS Guard IPsec VPN logs.

To view the AXS Guard IPsec status and logs, you must log in with administrator privileges as explained in the AXS Guard System Administration How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool.

IPsec Status

To check the status of an IPsec / E-tunnel:

1. Navigate to VPN > Status > IPsec.

2. Click on a tunnel ID to view its Phase 1 and Phase 2 status.

   

IPsec Status Colors	Description
Green	The IPsec tunnel is up.
Red	Mistakes have been made in the IPsec configuration or the remote connection has been lost.
Orange	This status indicates that either: A SA is missing for Phase 2. Since the lifetime of Phase 1 is shorter than the lifetime of Phase 2, Phase 1 is more frequently renegotiated. If an error occurs during this renegotiation, the tunnel is still e-routed, while Phase 1 is down. Two Tunnel Definitions are using the same destination IP.
Grey	The IPsec / E-tunnel definition is error-free, but the tunnel is not enabled.

Info

• Using the IPsec status facilitates troubleshooting, as it indicates which Phase is failing.

• Click the tunnel log link to view the associated logs.

IPsec Logs

In the IPsec logs you will find:

• Details about Phase 1.

• Details about Phase 2.

• Details about XAUTH.

• The duration of a connection.

• Information about dead peers.

To view the logs:

1. Navigate to VPN > Logs > IPsec.

2. Click on the desired log date in the list.

3. Use a search filter to facilitate your search for particular log entries.

   

Troubleshooting

I cannot access the AXS GUARD IPsec menu.

1. Log on to the AXS Guard Administrator Tool as explained in the AXS Guard System Administration How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool.

2. Navigate to System > Feature Activation and select VPN.

3. Verify if the Do you use VPN IPsec? option is enabled.

My IPsec / E-tunnel is up and running, but I cannot access certain servers in the remote LAN.

1. Verify the routing on every IPsec endpoint. Routes for aliases should always be entered manually (see further).

2. Verify the Firewall settings on every IPsec endpoint.

3. Ensure that the servers you are trying to reach point to the correct gateway, so that server replies can be routed correctly and don’t get lost. Consult the documentation of your server(s) if necessary.

I cannot establish an IPsec tunnel between the AXS GUARD and a third-party device.

1. Only use encryption and authentication algorithms which are supported by both IPsec endpoints.

2. Verify the Phase 1 and Phase 2 parameters on each IPsec endpoint. They should match.

3. Make sure the Phase 2 local and remote parameters are crossed on both IPsec endpoints.

4. Verify the routing on every IPsec endpoint.

5. Verify the Firewall settings on every IPsec endpoint.

6. Check the advanced IPsec settings, e.g. the MTU, on every IPsec endpoint.

7. Verify if the third-party device accepts ESP packets. Forcing NAT-Traversal is sometimes necessary even when the peers are not NAT-ted (e.g. when a router is not forwarding the ESP packets).

I cannot reach a certain LAN segment in an E-tunnel Star Network.

1. Verify the routing entries on the concerned AXS Guard appliances. Routes for aliases should always be entered manually.

2. Verify the Firewall settings on the concerned AXS Guard appliances.

3. Make sure the central AXS Guard (hub) Firewall allows traffic between all subnets.

Failover does not work

1. Navigate to VPN > IPsec > Tunnels.

2. Click on the appropriate E-tunnel name.

3. On the bottom of the screen, expand the Advanced IPsec Options.

4. Expand Dead Peer Detection and ensure it is enabled.

How do I specify multiple allowed protocols and ports for a tunnel?

• It is possible to limit IPsec traffic to certain protocols and ports. It is not possible to enter a list of allowed protocols and ports. You can only add a single protocol / port combination to each tunnel definition.

• A workaround is to replicate the tunnel definition (Edit as new) and add the desired allowed protocol / port combination. Save the replicated tunnel definition under a new name. Repeat the procedure as many times as needed.

Routing via etunnel: Firewall Rules are not automatically added for aliases.

When adding a route via an e-tunnel, Firewall Rules for the subnets are added automatically. However, routes for any alias on a secure device should always be added manually.

Example:

Configuration of eth0: 172.16.32.203/24 with alias 172.16.202.254/24

Adding a route for the destination network 172.16.200.0/24 via an E-tunnel automatically adds the the following Firewall Rules:

• r1 On any ACCEPT 172.16.32.0/24 > 172.16.200.0/24

• r2 On any ACCEPT 172.16.200.0/24 > 172.16.32.0/24

This means that network traffic originating from 172.16.202.0/24 cannot be sent to 172.16.200.0/24. The Firewall Rules should be entered manually.

More information about routing is available in the AXS Guard System Administration How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool.

Issues with NAT-Traversal

Important

Do not use the endpoint IP as a connection identifier on an appliance of which the Internet interface(s) is/are NATted. 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 NATted, 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 its IPsec server log.

In the following log, you can see that the identifier is 10.132.23.135 (NATted IP), while the actual IP of the initiating appliance is 10.132.23.136. Since there is a mismatch, the responder refuses to authenticate the initiator.

0:48:43 pluto[30792] "psk_to136" #4: Main mode peer ID is ID_IPV4_ADDR: '10.132.23.135'
10:48:43 pluto[30792] "psk_to136" #4: no suitable connection for peer '10.132.23.135'
10:48:43 pluto[30792] "psk_to136" #4: sending encrypted notification INVALID_ID_INFORMATION to 10.132.23.136:500
10:48:50 pluto[30792] "psk_to136" #3: discarding duplicate packet; already STATE_MAIN_I3
10:48:50 pluto[30792] "psk_to136" #3: ignoring informational payload, type INVALID_ID_INFORMATION msgid=00000000
10:48:50 pluto[30792] "psk_to136" #3: received and ignored informational message
10:48:53 pluto[30792] "psk_to136" #4: Main mode peer ID is ID_IPV4_ADDR: '10.132.23.135'
10:48:53 pluto[30792] "psk_to136" #4: no suitable connection for peer '10.132.23.135'
10:48:53 pluto[30792] "psk_to136" #4: sending encrypted notification INVALID_ID_INFORMATION to 10.132.23.136:500
10:49:13 pluto[30792] "psk_to136" #4: Main mode peer ID is ID_IPV4_ADDR: '10.132.23.135'
10:49:13 pluto[30792] "psk_to136" #4: no suitable connection for peer '10.132.23.135'
10:49:13 pluto[30792] "psk_to136" #4: sending encrypted notification INVALID_ID_INFORMATION to 10.132.23.136:500
10:49:30 pluto[30792] "psk_to136" #3: max number of retransmissions (2) reached STATE_MAIN_I3.  Possible authentication failure: no acceptable response to our first encrypted message
10:49:30 pluto[30792] "psk_to136" #3: starting keying attempt 2 of an unlimited number
10:49:30 pluto[30792] "psk_to136" #5: initiating Main Mode to replace #3

I’m getting the following message: "A problem occurred while fetching the public RSA key. Please contact support."

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.

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