| Home Prev |  cOS Core 14.00.15 Administration Guide
|
Next |
|---|
This section discusses how to set up and use IPsec tunnels with cOS Core.
Note that a quick start checklist of setup steps for IPsec in typical scenarios can be found in the preceding VPN quickstart section in the following sections:
This section is a general discussion of the operation of IPsec and describes the various components, techniques and algorithms that are used in IPsec based VPNs.
Internet Protocol Security (IPsec) is a set of protocols defined by the Internet Engineering Task Force (IETF) to provide IP security at the network layer. An IPsec based VPN is made up of two parts:
The first part, IKE, is the initial negotiation phase, where the two VPN endpoints agree on which methods will be used to provide security for the underlying IP traffic. Furthermore, IKE is used to manage connections, by defining a set of Security Associations, SAs, for each connection. SAs are unidirectional, so there are usually at least two for each IPsec connection.
The second part is the actual IP data being transferred, using the encryption and authentication methods agreed upon in the IKE negotiation. This can be accomplished in a number of ways; by using IPsec protocols ESP, AH, or a combination of both.
The flow of events can be briefly described as follows:
The following sections will describe each of these stages in detail.
This section describes IKE, the Internet Key Exchange protocol, and the parameters that are used with it.
Encrypting and authenticating data is fairly straightforward, the only things needed are encryption and authentication algorithms, and the keys used with them. The Internet Key Exchange (IKE) protocol, IKE, is used as a method of distributing these "session keys", as well as providing a way for the VPN endpoints to agree on how the data should be protected.
IKE has three main tasks:
IKEv2 Should Be Used Instead of IKEv1
The IKE protocol comes in two versions called IKEv1 and the newer IKEv2. cOS Core provides support for both versions but it is recommended to always use IKEv2, unless IKEv1 is required for compatibility with the remote tunnel peer. IKEv2 provides much faster tunnel setup times and provides features not available with IKEv1, such as better Diffie-Hellman negotiation.This administration guide provides details for setting up IPsec using either IKEv1 or IKEv2. The material in this section is applicable to both IKE versions.
Security Associations (SAs)
IKE keeps track of connections by assigning a set of Security Associations, SAs, to each connection. An SA describes all parameters associated with a particular connection as well as the session keys used to encrypt/decrypt and/or authenticate/verify the transmitted data.An SA is unidirectional and relates to traffic flow in one direction only. For the bidirectional traffic that is usually found in a VPN, there is therefore a need for more than one SA per connection. In most cases, two SAs will be created for each connection, one describing the incoming traffic, and the other describing the outgoing traffic.
IKE Negotiation
The process of negotiating session parameters consists of a number of phases and modes. These are described in detail in the sections below.The flow of events can be summarized as follows:
It is recommended that the lifetimes are equal to or greater than the following values:
For all tunnels, the IPsec lifetime should always be significantly shorter than the IKE lifetime.
cOS Core rekeys IPsec security associations 30 seconds before lifetime expiry in order to have time for any resends. This will mean that when a lifetime is at the minimum of 40 seconds, the IPsec security associations will be rekeyed every 10 seconds. cOS Core will issue warning messages during reconfiguration if the lifetime values are too low.
An IKE algorithm proposal list is a suggestion of how to protect IPsec data flows. The VPN device initiating an IPsec connection will send a list of the algorithms combinations it supports for protecting the connection and it is then up to the device at the other end of the connection to say which proposal is acceptable.Upon receiving the list of supported algorithms, the remote peer will choose the algorithm combination that best matches its own proposal list, and reply by specifying which member of the list it has chosen. If no mutually acceptable proposal can be found, the responder will reply by saying that nothing on the list was acceptable, and possibly also provide a textual explanation for diagnostic purposes.
This negotiation to find a mutually acceptable algorithm combination is done not just to find the best way to protect the IPsec tunnel data but also to find the best way to protect the IKE negotiation itself.
Algorithm proposal lists contain not just the acceptable algorithm combinations for encrypting and authenticating data but also other IKE related parameters. Further details of the IKE negotiation and the other IKE parameters are described next.
IKE Phase-1 - IKE Security Negotiation
An IKE negotiation is performed in two phases. The first phase, phase 1, is used to authenticate the two VPN firewalls or VPN clients to each other, by confirming that the remote device has a matching Pre-Shared Key.However, since we do not want to publish too much of the negotiation in plaintext, we first agree upon a way of protecting the rest of the IKE negotiation. This is done, as described in the previous section, by the initiator sending a proposal-list to the responder. When this has been done, and the responder accepted one of the proposals, we try to authenticate the other end of the VPN to make sure it is who we think it is, as well as proving to the remote device that we are who we claim to be. A technique known as a Diffie Hellman Key Exchange is used to initially agree a shared secret between the two parties in the negotiation and to derive keys for encryption.
Authentication can be accomplished through Pre-Shared Keys, certificates or public key encryption. Pre-Shared Keys is the most common authentication method today. PSK and certificates are supported by the cOS Core VPN module.
IKE Phase-2 - IPsec Security Negotiation
In phase 2, another negotiation is performed, detailing the parameters for the IPsec connection.During phase 2 we will also extract new keying material from the Diffie-Hellman key exchange in phase 1 in order to provide session keys to use in protecting the VPN data flow.
If Perfect Forward Secrecy (PFS) is used, a new Diffie-Hellman exchange is performed for each phase 2 negotiation. While this is slower, it makes sure that no keys are dependent on any other previously used keys; no keys are extracted from the same initial keying material. This is to make sure that, in the unlikely event that some key was compromised, no subsequent keys can be derived.
Once the phase 2 negotiation is finished, the VPN connection is established and ready for traffic to pass through it.
IKEv2 Should Be Used Instead of IKEv1
cOS Core supported both IKEv2 and IKEv1 but IPsec tunnels will default to using IKEv2 and this is the recommended setting. IKEv1 is considered obsolete. IKEv2 provides the following advantages over IKEv1:The possible methods of IKE authentication are the following:
These methods will now be examined further.
Manual Keying
The simplest way of configuring a VPN is by using a method called manual keying. This is a method where IKE is not used at all; the encryption and authentication keys, as well as some other parameters, are directly configured on both sides of the VPN tunnel. This is an outdated authentication method which cOS Core does not support.PSK
Using a Pre-shared Key (PSK) is a method where the endpoints of the VPN share a secret key which can be either a text string or hexadecimal sequence.PSK Advantages
Pre-Shared Keying is useful for its simplicity of setup. Only a single key is needed for one tunnel which is manually shared between the tunnel endpoints.
PSK Disadvantages
One thing that has to be considered when using Pre-Shared Keys is key distribution. How are the Pre-Shared Keys distributed to remote VPN clients and firewalls? This is a major issue, since the security of a PSK system is based on the PSKs being secret. Should one PSK be compromised, the configuration will need to be changed to use a new PSK.
Certificates
Each VPN endpoint has its own certificate, and one or more trusted root certificates.Certificate authentication is based on the following:
Advantages of Certificates
A principal advantage of certificates is flexibility and scalability. For example, a large number of IPsec endpoints can be managed without having the same pre-shared key configured on all of them, which is often the case when using pre-shared keys and roaming clients. If a certificate becomes compromised, it can simply be revoked without reconfiguring every endpoint.
Disadvantages of Certificates
The principal disadvantage of certificates is the added complexity. Certificate based authentication may be used as part of a larger public key infrastructure (PKI), making all VPN clients and firewalls dependent on third parties. In other words, there are more aspects that have to be configured, and there is more that can go wrong.
The IPsec protocols are the protocols used to protect the actual traffic being passed through the VPN. The actual protocols used and the keys used with those protocols are negotiated by IKE.
There are two protocols associated with IPsec, AH and ESP. These are covered in the sections below.
AH (Authentication Header)
AH is a protocol used for authenticating a data stream.AH uses a cryptographic hash function to produce a MAC from the data in the IP packet. This MAC is then transmitted with the packet, allowing the remote endpoint to verify the integrity of the original IP packet, making sure the data has not been tampered with on its way through the Internet. Apart from the IP packet data, AH also authenticates parts of the IP header.
The AH protocol inserts an AH header after the original IP header. In tunnel mode, the AH header is inserted after the outer header, but before the original, inner IP header.
It should be noted that AH is rarely used and cOS Core does not currently support it.
ESP (Encapsulating Security Payload)
The ESP protocol inserts an ESP header after the original IP header, in tunnel mode, the ESP header is inserted after the outer header, but before the original, inner IP header.All data after the ESP header is encrypted and/or authenticated. The difference with AH is that ESP also provides encryption of the IP packet. The authentication phase also differs in that ESP only authenticates the data after the ESP header; thus the outer IP header is left unprotected.
The ESP protocol is used for both encryption and authentication of the IP packet. It can also be used to do either encryption only, or authentication only.
IPsec tunnels in cOS Core are defined by the IPsec Tunnel configuration object and this can be regarded as specifying an IPsec tunnel endpoint. An IPsec Tunnel object should also be regarded by the administrator as a logical cOS Core interface, with the same filtering, traffic shaping and configuration capabilities as Ethernet interfaces. Most importantly, an IPsec Tunnel object can be used as the Source Interface and/or Destination Interface in an IP Policy or other IP rule set entry.
Remote Initiation of Tunnel Establishment
When another Clavister firewall or other IPsec compliant networking product (also known as the remote endpoint) tries to establish an IPsec VPN tunnel to a local Clavister firewall, the list of currently defined IPsec tunnels in the cOS Core configuration is examined. If a matching tunnel definition is found, that tunnel is opened. The associated IKE and IPsec negotiations then take place, resulting in the tunnel becoming established to the remote endpoint.The way cOS Core selects the IPsec Tunnel object to use when the tunnel is initiated by an external device is described in more detail in Section 10.3.9, IPsec Tunnel Selection.
Local Initiation of Tunnel Establishment
Alternatively, a user on a protected local network might try and access a resource which is located at the end of an IPsec tunnel. In this case, cOS Core sees that the route for the IP address of the resource is through a defined IPsec tunnel and establishment of the tunnel is then initiated from the local Clavister firewall.IP Policies Control Decrypted Traffic
Note that an established IPsec tunnel does not automatically mean that all the traffic flowing from the tunnel is trusted. On the contrary, network traffic that has been decrypted will be checked against the IP rule set. When performing this check, the source interface of the traffic will be the associated IPsec tunnel since tunnels are treated like interfaces in cOS Core.In addition, a Route or an Access rule may have to be defined for roaming clients in order for cOS Core to accept specific source IP addresses from the IPsec tunnel.
Returning IPsec Traffic
For network traffic going in the opposite direction, back into an IPsec tunnel, a reverse process takes place. First, the unencrypted traffic is evaluated by the IP rule set. If an IP policy and route matches, cOS Core tries to find an established IPsec tunnel that matches the criteria. If not found, cOS Core will try to establish a new tunnel to the remote endpoint specified by a matching IPsec tunnel definition.No IP Policies Are Needed for the Enclosing IPsec Traffic
With IPsec tunnels, the administrator usually sets up IP policies that allow unencrypted traffic to flow into the tunnel (the tunnel being treated as an interface by cOS Core). However, it is normally not necessary to set up IP policies that explicitly allow the packets that implement the IPsec tunnel itself (in other words, the outer part of the tunnel).IKE and ESP packets are, by default, dealt with by cOS Core's IPsec subsystem without the IP rule sets are not consulted.
If required, this behavior can be changed by disabling the IPsec Before Rules setting (by default, it is enabled). An example of why this might be done is if there are a high number of IPsec connection attempts coming from a particular IP address or group of addresses. Such traffic could degrade the performance of the IPsec subsystem and explicitly dropping such traffic with an IP policy is an effective way of preventing it from reaching the subsystem. In other words, IP policies could be used for complete control over all the traffic related to an IPsec tunnel.
Note, however, that the IPsec Before Rules setting has no effect on Access Rules being applied to traffic when it first enters the firewall. Access rules (discussed in Section 7.1, Access Rules) are always applied before traffic reaches the IPsec subsystem.
The following methods are available with both IKEv1 and IKEv2 for monitoring IPsec tunnel health and reestablishing the tunnel if a problem is detected:Dead Peer Detection
Dead Peer Detection (DPD) is used to monitor IPsec tunnel health. It can optionally be enabled for a tunnel and it is recommended to always have it enabled (the default) unless the external IPsec peer does not support it. With roaming IPsec clients, DPD is the only option for monitoring tunnel health.
DPD monitors the aliveness of the tunnel by looking for traffic coming from the peer at the other end of the tunnel. If no traffic is seen within a certain length of time then cOS Core sends DPD-R-U-THERE messages to the peer to determine if it is still reachable.
If the peer does not respond after sending a series of DPD message messages then the peer is considered dead and the tunnel is closed. The tunnel will be reestablished in the normal way, for example when cOS Core needs to send traffic through the tunnel or if an external IPsec peer initiates tunnel setup.
It should be noted that disabling DPD on a tunnel does not stop cOS Core responding to DPD-R-U-THERE messages from a peer, since the IPsec standard requires a response. However, disabling DPD does mean that cOS Core will not send out its own DPD-R-U-THERE messages.
The only IPsec tunnel property which can be changed for DPD is Interval which specifies the amount of time to wait after the last traffic seen before sending the first DPD message.
![[Note]](images/note.png) |
Note |
|---|---|
|
Both Auto Establish and DPD could be used at the same time. |
Tunnel Monitoring
cOS Core provides tunnel monitoring as an addition to DPD for monitoring the health of an IPsec tunnel. Tunnel monitoring requires that an external host is available that is reachable through the tunnel with ICMP ping messages.
This feature is described further in Section 10.3.17, IPsec Tunnel Monitoring.
Route Failover with IPsec Tunnels
The cOS Core route failover feature can be used with IPsec tunnels. The feature is described generally in Section 4.2.3, Route Failover. The specific considerations needed when route failover is used with IPsec tunnels is discussed in an article in the Clavister Knowledge Base at the following link:Below is a summary of the key properties required with an IPsec Tunnel object. Understanding what these properties do before attempting to configure the tunnel is strongly recommended, since it is important that there is agreement with the remote tunnel peer.
IKE Version
cOS Core supports both IKEv1 and IKEv2 and uses IKEv2 by default. It is recommended to use IKEv2 when possible as IKEv1 is now considered obsolete and is usually only needed for compatibility with older equipment.
This property can be set to a value of Auto which means IKEv2 will be tried first and if that fails then IKEv1 will be tried. This is useful when the IKE support offered by the peer is unknown.
Local and Remote Networks/Hosts
These are the subnets or hosts between which IP traffic will be protected by the VPN. In a LAN-to-LAN connection, these will be the network addresses of the respective LANs.
With IPsec roaming clients, the remote network will most likely be set to all-nets, since the client may connect from any network. The usage of all-nets as the local and/or remote network is discussed further in an article in the Clavister Knowledge Base at the following link:
Local Endpoint
By default, this property of an IPsec tunnel object is the IP address of the Ethernet interface being used for the connection. More specifically, the address is the IP address in the core route for the interface. If there are both IPv4 and IPv6 core routes for the interface then cOS Core can make use of either the IPv4 or IPv6 address as the local endpoint for the IPsec tunnel.
Setting this property means the source address of the tunnel is a specific IP address. If this property is assigned an IP address, the administrator must also manually configure cOS Core to ARP publish the IP address on the sending interface. Doing this is described in Section 3.5.3, ARP Publish.
The Local Endpoint property must be set if local clients behind the firewall are sending traffic through an IPsec tunnel which is established on a different interface. For example, the clients might be on the lan interface but the IPsec tunnel endpoint might be the wan interface. In this case, the Local Endpoint property should be set to the IP address of the wan interface.
A common reason for setting this property is if clients behind a firewall cannot reach an IPsec tunnel endpoint. This usage is discussed further in a Clavister Knowledge Base article at the following link:
Remote Endpoint
The remote endpoint (sometimes also referred to as the remote gateway) is the IP address of the peer at the other end of the IPsec tunnel. It can be specified as a single IP address or IP address range. If the firewall is the tunnel initiator then it should be a single IP address. If tunnels are initiated by connecting roaming clients then the remote endpoint will usually be the IP address range/network to which the clients belong.
The remote endpoint can be specified in any of the following ways: such
As a single IPv4 address or IPv4 range/network.
As a single IPv6 address IPv6 range/network.
As an FQDN Address object. This is the recommended method, providing that DNS lookup is available to resolve an FQDN to an IP address. Creating FQDN address objects is described in Section 3.1.7, FQDN Address Objects.
FQDN objects usually have to be used if the firewall is initiating LAN-to-LAN tunnel setup against multiple IP addresses. When the FQDN resolves to multiple IP addresses, cOS Core will try to initiate tunnel setup against each in turn until it is successful.
Note that the remote endpoint is not used in transport mode.
Incoming Interface Filter
If set, the Incoming Interface filter property of a tunnel determines which interface cOS Core will listen on for incoming IPsec connections (this is sometimes referred to as the Source Interface). This property provides a means to specify that a particular tunnel is used for connections being received on a particular interface as it takes precedence over the normal procedure for selecting a tunnel.
Local ID and Remote ID
The local and remote IDs are values sent by each side of the tunnel during the IKE negotiation and both can be used with either a pre-shared key or certificate based tunnel.
Local ID - this property of an IPsec Tunnel object represents the identity of the local VPN tunnel endpoint and this is the value presented to the remote peer during the IKE negotiation.
The property is set to only a single value but can be left blank when using certificates since the ID will be contained within the host certificate sent. If the certificate sent contains multiple IDs, this property can be set to specify which ID in the certificate to use.
The Enforce Local ID property can be enabled so that when cOS Core is acting as responder, the ID proposed by the initiator must match the Local ID value. The default behavior is to ignore the proposed ID.
Remote ID - This property can be used to specify an ID list object. An ID list object contains one or more IDs. When using certificates, the certificate sent sent by a remote peer must contain an ID which matches one of the IDs in the list in order for the peer to be authenticated. Using the Remote ID property with certificates is explained further in Section 10.3.18, Using ID Lists with Certificates.
cOS Core applies sanity checks on all remote IDs to ensure they are acceptable. Usually malformed IDs have a problem in the DN name. For example, a faulty remote ID name might be the following:
DN=Clavister, OU=One,Two,Three, DC=SE
If specified by the administrator, there will be an error message when the cOS Core configuration is committed. The corrected remote ID form is the following:
DN=Clavister, OU=One\,Two\,Three, DC=SE
Originator IP Address
An IPsec Tunnel object's Originator IP property is a means to set the source IP address that flows inside the tunnel when the originator is cOS Core itself.
This IP will be needed in such cases as when log messages or ICMP ping messages are sent by cOS Core. Also, when NATing an IPsec tunnel's local network to the remote network, the originator IP will be the IP address that will be used as the NAT address. This address may need to be set manually if the automatic choice described below is not suitable.
There are two possible settings for this property:
LocalInterface
This is the default setting. In the Web Interface, this corresponds to enabling the option: Automatically pick the address of a local interface that corresponds to the local net. cOS Core automatically selects the source IP address in the following way:
cOS Core looks at the IP address of all non-IPsec interfaces and uses the first IP address it finds that is within the range of the tunnel's local network.
With an HA cluster, this means the shared and private IP can be different.
If no suitable address is found in the first step, the second IP address from the tunnel's local network is used. This could potentially be an IP address that is already used by a host in the network and if this is the case the IP address will need to be set manually as described in (ii) below.
With an HA cluster, this means the shared and private IP will be the same.
Manual
This option allows the administrator to choose a specific IP. It is possible to set two IPs with this option:
The non-HA IP address. This is the IPv4 address that will be used for non-cluster situations.
The HA IP address. This address will be used in HA clusters as both the shared and private IP. Often, this can be left as localhost for a cluster but should be set if the cluster is sending, for example, logs or ping messages into the tunnel.
Note that if the local network for the tunnel is all-nets then cOS Core will not be able to assign an IP address and a value will have to be assigned manually.
Also note that when this option is used, a core route is automatically added to all routing tables so that the originator IP address is routed on core (also known as a core route). Using this option will also stop cOS Core automatically adding a core route for the tunnel's local network, which can solve problems caused by that addition.
One such core route automatic addition problem could result from the following cOS Core behavior: when defining a local network on an IPsec tunnel that is not part of a local interface (so that a core route already exists), cOS Core will generate a core route in all routing tables except the main routing table. The possible issues caused by automatically created core routes is discussed further in the Clavister Knowledge Base at the following link:
IPsec can be used in one of the two following modes:
Tunnel Mode
Tunnel mode indicates that the traffic will be tunneled to a remote device, which will decrypt/authenticate the data, extract it from its tunnel and pass it on to its final destination. This way, an eavesdropper will only see encrypted traffic going from one of the VPN endpoints to another.
Tunnel mode works by encrypting the entire packet, including the IP header. It is commonly used between two firewalls, with the firewalls acting as proxies for the clients behind them and are not the destination IP for the data.
NAT traversal is supported with tunnel mode.
Transport Mode
In transport mode, only the IPsec data payload is encrypted. The IP header is not encrypted. This is typically used to secure a connection from a VPN client to the firewall, where the firewall is the destination IP. It is often used in conjunction with other tunneling protocols, such as GRE or L2TP, where the packet is first encapsulated by that protocol before being protected by IPsec.
NAT traversal is not supported with transport mode.
This setting will typically be set to Tunnel in most configurations. With IKEv2, only Tunnel should be used.
Main/Aggressive Mode
The IKE negotiation has two modes of operation, main mode and aggressive mode.
The difference between these two is that aggressive mode will pass more information in fewer packets, with the benefit of slightly faster connection establishment, at the cost of transmitting the identities of the endpoints without encryption.
It is recommended to not use aggressive mode in a roaming client scenario as this can increase the vulnerability to amplification attacks.
IKE Encryption
This specifies the encryption algorithms used in the IKE negotiation, and depending on the algorithm, the size of the encryption key used. The IKE encryption algorithms supported by cOS Core are the following:
Of the algorithms listed, only AES and AES-GCM are recommended for active use. Older algorithms are only included to be interoperable with other, older VPN implementations. The use of other than AES algorithms should be avoided whenever possible as they are no longer considered to be sufficiently secure.
IKE Authentication (Integrity)
This specifies the authentication algorithms used in the IKE negotiation phase. The IKE integrity algorithms supported by cOS Core are the following:
![[Caution]](images/caution.png) |
Caution: SHA-1 and MD5 have weaknesses |
|---|---|
|
SHA-1 is considered to have weaknesses and should be used with caution. MD5 is no longer considered to be a secure algorithm and should be avoided if possible. |
IKE DH Group
This specifies the Diffie-Hellman group to use for the IKE exchange. The available DH groups plus recommendations are discussed below in the section titled Supported Diffie-Hellman Groups.
With IKEv1, the same DH group must be used at both ends of the tunnel. IKEv2 provides the ability for tunnel negotiation using overlapping groups.
IKE Lifetime
This is the lifetime of the IKE connection and is specified as a number of seconds.
Whenever the IKE lifetime expires, a new phase-1 exchange will be performed. If no data was transmitted in the last "incarnation" of the IKE connection, no new connection will be made until someone wants to use the VPN connection again. This value should be greater than the IPsec SA lifetime.
Perfect Forward Secrecy (PFS)
This specifies the Diffie-Hellman group to use with PFS. The available DH groups plus recommendations are listed later in Supported Diffie-Hellman Groups.
With Perfect Forward Secrecy disabled, initial keying material is "created" during the key exchange in phase-1 of the IKE negotiation. In phase-2 of the IKE negotiation, encryption and authentication session keys will be extracted from this initial keying material. By using PFS, completely new keying material will always be created with a rekey. Should one key be compromised, no other key can be derived using that information.
IPsec Encryption
The encryption algorithm that will be used on the protected IPsec traffic. The IPsec encryption algorithms supported by cOS Core are the following:
Of the algorithms listed, only AES and AES-GCM is recommended for active use. Older algorithms is only included to be interoperable with other, older VPN implementations. The use of other than AES algorithms should be avoided whenever possible as they are no longer considered to be sufficiently secure.
IPsec Authentication (Integrity)
This specifies the authentication algorithm used on the protected traffic.
This is not used when ESP is used without authentication, although it is not recommended to use ESP without authentication. The IPsec integrity algorithms supported by cOS Core are the following:
|
Caution: SHA1 and MD5 have weaknesses |
|---|---|
|
As stated previously with IKE algorithms, SHA-1 is considered to have weaknesses and should be used with caution. MD5 is no longer considered to be a secure algorithm and should be avoided if possible. |
IPsec Lifetime
This is the lifetime of the IPsec connection following tunnel setup. It is specified in both time (seconds) and data amount (in Kbytes). Whenever either of these values is exceeded, a rekey will be initiated, providing new IPsec encryption and authentication session keys. If the VPN connection has not been used during the last rekey period, the connection will be terminated, and reopened from scratch when the connection is needed again.
Auto Establish
By default, LAN-to-LAN IPsec tunnels are established only at the time that traffic tries to flow through them. By enabling the IPsec tunnel property Auto Establish, LAN-to-LAN tunnels are established without any traffic flowing. This is useful in the following situations:
With LAN-to_LAN tunnels only (IKEv1 or IKEv2). It cannot be used with roaming clients.
With route failover, a tunnel for the alternate route is always established.
After a reconfigure operation is performed on cOS Core, the tunnels are immediately reestablished without waiting for any traffic to flow.
Assuming two IPsec tunnel endpoint A and B, it is recommended that auto establish is enabled on B only when both of the following criteria are true:
A cannot initiate an IKE negotiation to B. The reasons why it cannot be the initiator might be any of the following:
B is behind a NATing device.
A is using DNS to get the IP address of B.
B receives its IP address via DHCP.
The administrator decides that A must be able to initiate UDP/TCP connections through the tunnel without B having sent any packets. For example, there might be a server located behind B which clients located behind A need to reach.
Supported Diffie-Hellman Groups
Diffie-Hellman (DH) is a cryptographic protocol that allows two parties to establish a shared secret key over an insecure communications channel through a series of plain text exchanges. This property specifies one or more DH groups that can be used during the IKE negotiation. A higher group number generally means better security.The DH groups supported by cOS Core are the following:
When more than one DH group is specified for a tunnel, the greatest group number that matches both sides of the tunnel will be chosen.
A few general recommendations when it comes to DH group selections
DH groups between 1 and 15 are not recommended for use due to security concerns.
Using group 17 and 18 should be done with caution as more computing resources will be used for these higher group numbers. This could lead to inefficient key-generation due to high key length, stalling the system, and resulting in unacceptable tunnel setup times on slower hardware platforms.
While having lower key length, DH group 19 and higher employ newer encryption algorithms that enhance speed without compromising on encryption integrity and strength.
Support for Pseudo-random Functions
Note that cOS Core supports the use of Pseudo-random Functions (PRF) according to RFC-4868 but only with SHA-256 and SHA-512. The use of PRFs is also discussed in an article in the Clavister Knowledge Base at the following link:To agree on the IPsec tunnel parameters, a negotiation process is performed. As a result of these negotiations, IKE and IPsec security associations (SAs) are established. A proposal list of supported algorithms is the starting point for the negotiation. Each entry in a proposal list defines parameters that the tunnel endpoint is capable of supporting.
There are two types of proposal lists that can be created in cOS Core for IPsec:
IKE proposal lists
Used for IKE Phase-1 (IKE Security Negotiation). These are created or edited in the Web Interface by going to: Objects > IKE Algorithms
IPsec proposal lists
Used for IKE Phase-2 (IPsec Security Negotiation). These are created or edited in the Web Interface by going to: Objects > IPsec Algorithms
Two proposal lists are already defined in the default cOS Core configuration for each of the above categories. These are named High and Medium and they can be modified if required. The algorithms included with each are the following:
High
Medium
|
Caution: Upgrades do not update the predefined lists |
|---|---|
|
When cOS Core starts for the first time, it creates its default configuration, including the High and Medium proposal lists. Subsequent cOS Core version upgrades will not also upgrade these predefined lists to include the latest default algorithms (since this might mean current IPsec tunnels no longer work). Instead, the administrator must manually edit the High and Medium lists to include any new algorithms. |
Example 10.1. Creating and Using an IPsec Proposal List
This example shows how to create and use an IPsec algorithm proposal list. The 3DES and AES will be proposed as encryption algorithms. The hash functions SHA256 and SHA512 will be proposed for checking if the data packet is altered while being transmitted. Note that this example does not cover how to add the specific IPsec tunnel object. It will also be referred back to in a later example.
Command-Line Interface
First, create a list of IPsec Algorithms:
Device:/> add IPsecAlgorithms esp-l2tptunnel
DES3Enabled=Yes
AESEnabled=Yes
SHA256Enabled=Yes
SHA512Enabled=YesDevice:/> set Interface IPsecTunnel MyIPsecTunnel
IPsecAlgorithms=esp-l2tptunnelInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
First, create a list of IPsec Algorithms:
Then, apply the algorithm proposal list to the IPsec tunnel:
Either a Pre-Shared Key (PSK) or certificates are used to authenticate IPsec tunnels. PSKs are secrets that are shared by the communicating parties before an IPsec tunnel is established. To establish the tunnel, both parties must show that they know the common PSK. PSKs can be constructed like a text password but the more common method is to use a long hexadecimal value.
Random hexadecimal PSKs can be generated automatically through the Web Interface but they can also be generated through the CLI using the command pskgen (this command is described further in the separate CLI Reference Guide).
Beware of Non-ASCII Characters in a PSK on Different Platforms!
If a PSK is specified as a text string and not a hexadecimal value, the different encodings on different platforms can cause a problem with non-ASCII characters. Windows, for example, encodes PSKs containing non ASCII characters into UTF-16, while cOS Core uses UTF-8. Even though they can seem the same at either end of the tunnel, there will be a mismatch and this can sometimes cause problems when setting up a Windows L2TP client that connects to cOS Core.Example 10.2. Creating and Using a PSK
This example shows how to create a Pre-shared Key and apply it to a VPN tunnel. Since regular words and phrases are vulnerable to dictionary attacks, they should not be used as secrets. Here, the pre-shared key is a randomly generated hexadecimal key. Note that this example does not cover how to add the specific IPsec tunnel object.
Command-Line Interface
First create a Pre-shared Key. To generate the key automatically with a 64 bit (the default) key, use:Device:/> pskgen MyPSKDevice:/> pskgen MyPSK -size=512Device:/> add PSK MyPSK Type=HEX PSKHex=<enter the key here>Device:/> set Interface IPsecTunnel MyIPsecTunnel PSK=MyPSKInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
First create a Pre-shared Key:
Then, apply the pre-shared key to the IPsec tunnel:
A VPN can allow geographically distributed Local Area Networks (LANs) to communicate securely over the Internet. In a corporate context this means LANs at geographically separate sites can communicate with a level of security comparable to that existing if they communicated through a dedicated, private link.
Secure communication is achieved through the use of IPsec tunneling, with the tunnel extending from the VPN gateway at one location to the VPN gateway at another location. The Clavister firewall is therefore the implementer of the VPN, while at the same time applying normal security surveillance of traffic passing through the tunnel. This section deals specifically with setting up LAN-to-LAN tunnels created with a pre-shared Key (PSK).
A number of steps are required to set up LAN-to-LAN tunnels with PSK:
Define a Pre-Shared Key (PSK) object.
Define an IPsec Tunnel object.
At minimum, the local network, the remote network and remote endpoint must be specified for the IPsec tunnel, along with the PSK defined in the first step.
Set up IP Policy objects to allow traffic flow in either direction.
A route to the remote network will be added automatically if the Add route statically property (this is called AutoInterfaceNetworkRoute in the CLI) is enabled and this property is always enabled by default for a tunnel.
If a custom route is required, this property should be disabled and the Route to the remote network added in the main routing table (or another table if an alternate is being used).
Set up the peer at the other end of the tunnel in a similar way. The local and remote networks are reversed.
![[Tip]](images/tip.png) |
Tip: The Clavister VPN object can simplify LAN-to-LAN setup |
|---|---|
|
The IPsec LAN-to-LAN setup described here is based on the standard IPsec Tunnel object. cOS Core also provides the Clavister VPN object which simplifies the setup of LAN-to-LAN IPsec between two Clavister firewalls using IKEv2 and either PSK or certificates. This is discussed further in Section 10.3.15.1, LAN to LAN VPN. |
Note that an article in the Clavister Knowledge Base also provides a detailed description of LAN-to-LAN tunel setup with pre-shared keys and can be found at the following link:
https://kb.clavister.com/324736313
Using the Same Network On Both Sides
Sometimes there can be an issue with a conflict between the local networks on either side of an IPsec tunnel. A solution is to use the same network for both sides of the tunnel but where the network only actually exists between the two endpoints. This solution is described further in an article in the Clavister Knowledge Base at the following link:https://kb.clavister.com/324735848
Another, related article that discusses using IPsec to divide the same network between the two sides of a tunnel can be found at the following link:
https://kb.clavister.com/354855796
Example 10.3. PSK Based LAN-to-LAN IPsec Tunnel Setup
This example describes how to configure an IPsec tunnel across the Internet to connect the head office network 172.16.1.0/24 on the lan interface with a branch office network 192.168.11.0/24.
Assume that the branch office firewall Ethernet interface connected to the Internet has the public IP address 203.0.113.1.
It is assumed that the default IKE and IPsec proposal list are used at either end of the tunnel.
Note that the Source Translation property of the IP policy used in this example can be left at the default value of Auto. When the source and destination IP addresses of a connection are both private IP addresses then no translation will be performed when the Auto option is selected. The Auto option is described further in Section 8.5, Automatic Translation.
Command-Line Interface
A. Create a pre-shared key for IPsec authentication:
Device:/> add PSK my_scecret_key Type=ASCII PSKascii=somesecretasciikey
B. Configure the IPsec tunnel:
Device:/> add Interface IPsecTunnel ipsec_hq_to_branch
LocalNetwork=172.16.1.0/24
RemoteNetwork=192.168.11.0/24
RemoteEndpoint=203.0.113.1
PSK=my_secret_key
C. Configure IP policies to allow traffic flow in both directions within the tunnel:
i. Add an IP policy to allow traffic to flow from local to remote network:
Device:/> add IPPolicy Name=hq_to_branch
SourceInterface=lan
SourceNetwork=172.16.1.0/24
DestinationInterface=ipsec_hq_to_branch
DestinationNetwork=192.168.11.0/24
Service=all_services
Action=Allow
ii. Add an IP policy to allow traffic to flow from remote to local network:
Device:/> add IPPolicy Name=branch_to_hq
SourceInterface=ipsec_hq_to_branch
SourceNetwork=192.168.11.0/24
DestinationInterface=lan
DestinationNetwork=172.16.1.0/24
Service=all_services
Action=Allow
D. Add a route that routes the remote network on the tunnel:
This step is not necessary if the route is added automatically (the default). If the AutoInterfaceNetworkRoute tunnel property has been disabled then the route must be added manually, as described below.
Change the context to be the routing table:
Device:/> cc RoutingTable mainAdd the route:
Device:/main> add Route
Interface=ipsec_hq_to_branch
Network=192.168.11.0/24Return to the default CLI context:
Device:/main>ccDevice:/>
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Create a pre-shared key for IPsec authentication:
B. Configure the IPsec tunnel:
C. Configure IP policies to allow traffic flow in both directions within the tunnel:
i. Add an IP policy to allow traffic to flow from local to remote network:
ii. Add an IP policy to allow traffic to flow from remote to local network:
D. Add a route that routes the remote network on the tunnel:
This step is not necessary if the route is added automatically (the default). If the Add route statically tunnel property has been enabled then the route must be added manually, as described below.
Now, configure the branch office firewall in a similar fashion. The local and remote gateway networks are reversed and the head office public IP now becomes the Remote Endpoint value. Note that the same PSK value must be used on both sides. Also, the proposal lists for IKE and IPsec should either be the same or at least have some overlap so cryptographic methods acceptable to both sides can be found during the IKE negotiation to set up the tunnel.
An employee who is on the move and who needs to access a central corporate server from a notebook computer over the Internet from different locations is a typical use case for a roaming client IPsec connection.
There will be a need for secure, authenticated access to the server, but the other issue is that a moving user's IP address is often not known beforehand. To handle unknown IP addresses, cOS Core must dynamically add routes to routing tables as IPsec tunnels are established.
IPsec Roaming Client Encryption and Authentication
When an IPsec tunnel is configured for roaming clients, authentication can be performed using either a pre-shared key (PSK) or using certificates. This is true for both IKEv1 and IKEv2 tunnelsAuthentication of the client is usually done by the client sending a username and password credential combination. For IKEv1 this is handled with XAuth and IKEv2 handles it using EAP. XAuth and EAP will not be discussed in this section but both require that a separate Authentication Rule is set up that triggers when a client connects.
Most of this section applies to both IKEv1 and IKEv2. However, Section 10.3.13, Setup for IKEv2 Roaming Clients gives a detailed description of setting up IPsec with IKEv2 roaming clients using certificates and EAP authentication.
|
Tip: The Roaming VPN object can simplify IKEv2/EAP setup |
|---|---|
|
cOS Core also provides the Roaming VPN object which simplifies IPsec roaming client setup. However this is only for IKEv2 tunnels using certificates with EAP authentication. This is discussed further in Section 10.3.15.2, Roaming VPN. |
Dealing with Unknown IP addresses
If the IP address of the roaming client is not known beforehand then cOS Core needs to create a route in its routing table dynamically as each client connects. In the example below this is the case and the IPsec tunnel is configured to dynamically add routes.If clients are to be allowed to connect from any IP address then the Remote Network needs to be set to all-nets (IP address: 0.0.0.0/0) which will allow all existing IPv4-addresses to connect through the tunnel.
When configuring IPsec tunnels for roaming clients it is usually not necessary to add to or modify the algorithm proposal lists that are preconfigured in cOS Core.
Adding Routes for Roaming Clients Dynamically
Usually, a route in the cOS Core routing table should be added for each client as it connects. This can be done automatically by enabling the IPsec tunnel property Add route dynamically (this property is AddRouteToRemoteNet in the CLI.At the same time the IPsec tunnel property Add route statically (AutoInterfaceNetworkRoute in the CLI) should be disabled since this is used for LAN-to-LAN tunnels and would add a route to the remote network (usually all-nets in this case) if it is left enabled.
Publishing Client IP Addresses with Proxy ARP
It is possible to proxy ARP publish the IP addresses of connecting roaming clients on selected or all Ethernet interfaces by setting the Proxy ARP Interfaces property of the IPsec Tunnel object. This can allow networks on the interfaces specified to communicate with clients.Positioning Of Roaming Client Tunnels in the Tunnel List
When a roaming client tries to open a tunnel to a Clavister firewall, cOS Core will search the list of configured IPsec Tunnel objects and will select the first matching tunnel it finds. As a rule of thumb, it is usually best to make sure that roaming client tunnels are placed after any LAN-to-LAN tunnels in the list. This makes sure that roaming client tunnels are not erroneously selected when a LAN-to-LAN tunnel was intended. A further discussion of this and the tunnel matching process in general can be found in Section 10.3.9, IPsec Tunnel Selection.PSK Based IPsec Tunnels for Roaming Clients
The following example shows how a PSK based tunnel can be set up.Example 10.4. PSK Based IPsec Tunnel for Roaming Clients Setup
This example describes how to configure an IPsec tunnel at the head office firewall for roaming clients that connect to it to gain remote access to the protected network 172.16.1.0/24 which is on the lan interface.
It is assumed that the default cOS Core IKE and IPsec proposal list are used on the firewall and that the clients will use proposal lists that will result in an acceptable match during the IKE negotiation phase of tunnel setup.
Note that the Source Translation property of the IP policy used in this example can be left at the default value of Auto.
When the source and destination IP addresses of a connection are both private IP addresses then no translation will be performed when the Auto option is selected. The Auto option is described further in Section 8.5, Automatic Translation.
Command-Line Interface
A. Create a pre-shared key for IPsec authentication:
Device:/> add PSK my_scecret_key Type=ASCII PSKascii=somesecretasciikey
B. Configure the IPsec tunnel:
Device:/> add Interface IPsecTunnel ipsec_roaming
LocalNetwork=172.16.1.0/24
RemoteNetwork=all-nets
PSK=my_secret_key
AddRouteToRemoteNet=Yes
AutoInterfaceNetworkRoute=No
C. Create an IP policy to allow traffic flow from clients:
Device:/> add IPPolicy Name=roaming_clients_to_hq
SourceInterface=ipsec_roaming
SourceNetwork=all-nets
DestinationInterface=lan
DestinationNetwork=172.16.1.0/24
Service=all_services
Action=Allow
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Create a pre-shared key object for IPsec authentication:
B. Configure the IPsec tunnel object:
C. Create an IP policy to allow traffic flow from clients:
However, if there are other IP addresses being ARP published on the interface and IKE requests are being sent to these addresses, the IPsec tunnel property Local Endpoint is used to specify the IP addresses on which IKE requests will be accepted.
The Local Endpoint property is never used if cOS Core is initiating the IPsec tunnel connection.
The Client's Inner and Outer IPs Should Be Different
With IKEv1, cOS Core requires that a roaming client's inner and outer IP addresses for the tunnel should be different. If they are the same, connections will be dropped by cOS Core and a ruleset_drop_packet log message will be generated containing "rule=Default_Access_Rule".If the IP addresses must be the same, the situation can be corrected by using separate routing tables for the tunnel itself and the traffic the tunnel carries. Alternatively, cOS Core can allocate a unique IP address to clients from an IP pool using Config Mode.
Simplifying Setup with the Roaming VPN Object
This section has discussed setup for roaming clients based on an IPsec Tunnel object. Setup can be simplified by using a Roaming VPN object. This object hides the IPsec tunnel properties not relevant to roaming client connection and also simplifies client authentication by not requiring a separate Authentication Rule object.A full discussion of the Roaming VPN object can be found in Section 10.3.15, Using IPsec Profiles.
Configuring IPsec Roaming Clients
Depending on the type of client used with IPsec, its configuration might require any of the following changes:Specify the URL or IP address of the Clavister firewall so the client can locate the remote tunnel endpoint.
Specify the pre-shared key (PSK) of one is used for authentication. Alternatively, install certificates if those are required for authentication (certificate usage is detailed in the section that follows).
Specify the IKE and IPsec algorithms used so they can agree with the proposal list that cOS Core will use.
Specify if the client will use config mode.
There are a variety of IPsec client software products available from third parties and also a number of IPsec clients that are already built into certain computing platforms. The network administrator should use the client that is best suited to their needs.
The only vendor specific IPsec client which is discussed in this publication are the following:
The Windows IPsec client (Windows 7 and later) in Section 10.3.13, Setup for IKEv2 Roaming Clients.
The Apple iOS™ IPsec client in Section 10.3.14, Setup for iOS Roaming Clients.
This section is a general discussion about using certificates instead of PSKs for IPsec with LAN-to-LAN and IKEv1 roaming clients scenarios. Note that setting up IPsec with IKEv2 roaming clients using certificates and EAP authentication is described separately in Section 10.3.13, Setup for IKEv2 Roaming Clients and is not covered in this section.
Using CA signed certificates is a method of authentication that relies on each tunnel endpoint having the following two certificates:A CA root certificate which will be used to validate the CA signed gateway certificate send by the remote tunnel endpoint. This consists of a single public key file.
A CA signed gateway certificate (also known as a host certificate) which will be used by the endpoint to identify itself. This consists of two files which contain the public and private keys respectively.
It should be noted that the gateway certificate used will be validated by cOS Core so if the root certificate required for this is different from the root certificate mentioned in the previous point then that other root certificate and any associated certificate chain need to uploaded to the firewall.
Uploading certificate files to cOS Core is described in Section 3.9.2, Uploading and Using Certificates. Once they are uploaded, they can then be referenced when defining an IPsec Tunnel object in the cOS Core configuration.
When using CA signed certificates, it is the responsibility of the administrator to acquire the appropriate CA signed certificate from an issuing authority. With some systems, such as Windows Server™ systems, there is built-in access to a CA server. For more information on CA server issued certificates see Section 3.9, Certificates.
For LAN-to-LAN tunnels the best security is provided by certificates signed by an organization's own private CA server since no one outside of an organization should have access to the certificates used. This might also be possible with roaming clients but using a public CA may be the only viable choice if an IPsec connection is to be made available to users outside an organization.
Using Self-signed Certificates
IPsec tunnel authentication in cOS Core can be based on self-signed certificates instead of CA signed certificates. Configuration requires having a pair of different self-signed certificates which are both present on the firewall (or other network device) on either side of the tunnel but have their roles as root and gateway certificate reversed at either side.Suppose the self-signed certificate pair are called cert_A and Cert_B. The certificate cert_A is created on or uploaded to firewall system_A. The certificate cert_B is created on or uploaded to firewall system_B. The following configuration setup is now required:
On system_A, cert_A is the gateway certificate and cert_B is the root certificate for the tunnel. In addition, cert_A must also be installed as a root certificate.
On system_B, the situation is reversed: cert_B is the gateway certificate and cert_A is the root certificate for the tunnel. In addition, cert_B must also be installed as a root certificate.
Note that if cert_A was created on system_A, it should not need to be uploaded and its private key is already available in the key store of system_A. When cert_B is loaded onto system_A, it is stored as a root certificate without a private key file. The situation will be the reverse on system_B.
Using self-signed certificates in a live production environment is not recommended as they defeat the purpose of a public key infrastructure (PKI). Using a pre-shared key (PSK) instead would be simpler to implement and would provide a similar level of security. However, self-signed certificates may be appropriate for some specific use cases.
Using Certificate Chains
Where there is a certificate chain between the root certificate and the gateway certificate for the IPsec tunnel, all the intermediate certificates in the chain must be uploaded and then configured as root certificates for the tunnel.Supported Certificate Types
cOS Core supports Rivest-Shamir-Adleman(RSA) and Elliptic Curve (EC) type certificates. RSA certificates can be created with any combination of key size and signature algorithm, but EC has some restrictions on which combinations can be used for IPsec tunnels. The table below shows which combinations are possible when using EC.| Public Key Type | Key Size | Signature Algorithm |
|---|---|---|
| ECDSA-256 | 256-bit random ECP group | SHA-256 |
| ECDSA-384 | 384-bit random ECP group | SHA-384 |
| ECDSA-521 | 521-bit random ECP group | SHA-512 |
An example of an erroneous combination is the selection of ECDSA-256 together with SHA-512, which would result in an IPsec tunnel malfunction.
Setup Examples
The examples that follow are based on the previous examples of IPsec setup for LAN-to-LAN and roaming client tunnels but these have been modified to use certificates instead of PSKs for authentication.Example 10.5. Certificate Based LAN-to-LAN IPsec Tunnel Setup
This example describes how to configure an IPsec tunnel across the Internet which connects the local network 172.16.1.0/24 on the lan interface of a local Clavister firewall to the network 192.168.11.0/24 behind a remote networking device that supports IPsec. The remote device could be another Clavister firewall.
Assume that the IPsec tunnel end point for the remote device's interface is the public IP address 203.0.113.1.
The default cOS Core IKE and IPsec proposal lists will be used.
Command-Line Interface
A. Upload the required certificate files to cOS Core using SCP
Doing this is described further in Section 3.9.2, Uploading and Using Certificates.
B. Configure the IPsec tunnel:
Device:/> add Interface IPsecTunnel ipsec_local_to_remote_tunnel
LocalNetwork=172.16.1.0/24
RemoteNetwork=192.168.11.0/24
RemoteEndpoint=203.0.113.1
AuthMethod=Certificate
GatewayCertificate=my_host_cert
RootCertificates=my_root_cert
C. Configure IP policies to allow traffic flow in both directions within the tunnel:
i. Add an IP policy to allow traffic to flow from local to remote network:
Device:/> add IPPolicy Name=local_to_remote_traffic
SourceInterface=lan
SourceNetwork=172.16.1.0/24
DestinationInterface=ipsec_local_to_remote_tunnel
DestinationNetwork=192.168.11.0/24
Service=all_services
Action=Allow
ii. Add an IP policy to allow traffic to flow from remote to local network:
Device:/> add IPPolicy Name=remote_to_local_traffic
SourceInterface=ipsec_remote_to_local_tunnel
SourceNetwork=192.168.11.0/24
DestinationInterface=lan
DestinationNetwork=172.16.1.0/24
Service=all_services
Action=Allow
D. Add a route that routes the remote network on the tunnel:
This step is not necessary if the route is added automatically (the default). If the AutoInterfaceNetworkRoute tunnel property has been disabled then the route must be added manually, as described below.
Change the context to be the routing table:
Device:/> cc RoutingTable mainAdd the route:
Device:/main> add Route Interface=ipsec_local_to_remote_tunnel
Network=192.168.11.0/24Return to the default CLI context:
Device:/main>ccDevice:/>
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Upload the required certificates with the following:
B. Configure the IPsec tunnel:
C. Configure IP policies to allow traffic flow in both directions within the tunnel:
i. Add an IP policy to allow traffic to flow from local to remote network:
ii. Add an IP policy to allow traffic to flow from remote to local network:
D. Add a route that routes the remote network on the tunnel:
This step is not necessary if the route is added automatically (the default). If the Add route statically tunnel property has been enabled then the route must be added manually, as described below.
Now, configure the remote network device in a similar fashion. The local and remote networks are reversed and the local public IP now becomes the Remote Endpoint value.
Example 10.6. Certificate Based IPsec Tunnels for Roaming Clients
This example describes how to configure an IPsec tunnel for the head office Clavister firewall so that roaming clients can get remote access. The head office network uses the 203.0.113.0/24 network with the public firewall IP address wan_ip.
Command-Line Interface
A. Upload the required certificate files to cOS Core using SCP
Doing this is described further in Section 3.9.2, Uploading and Using Certificates.
B. Configure the IPsec tunnel:
Device:/> add Interface IPsecTunnel roaming_client_tunnel
LocalNetwork=203.0.113.0/24
RemoteNetwork=all-nets
AuthMethod=Certificate
GatewayCertificate=my_host_cert
RootCertificates=my_root_cert
AddRouteToRemoteNet=Yes
AutoInterfaceNetworkRoute=No
RemoteEndpoint=all-nets
C. Finally, configure IP policies to allow the traffic to flow inside the tunnel.
InControl
With InControl, this is done in a different way to the Web Interface.
Web Interface
A. Upload the required certificates with the following:
B. Configure the IPsec tunnel:
C. Finally, configure IP policies to allow the traffic to flow inside the tunnel.
Check that the correct certificates have been used for the right purposes.
Check that the certificate .cer and .key files have the same filename. For example, my_cert.key and my_cert.cer.
Check that the certificates have not expired. Certificates have a specific lifetime and when this expires they cannot be used and new certificates must be issued.
Check that the cOS Core date and time is set correctly. If the system time and date is wrong then certificates can appear as being expired when, in fact, they are not.
Consider time-zone issues with newly generated certificates. The Clavister firewall's time zone may not be the same as the CA server's time zone and the certificate may not yet be valid in the local zone.
Disable CRL (revocation list) checking to see if CA server access could be the problem. CA Server issues are discussed further in Section 3.9.4, CA Server Access.
When an external network device initiates the setting up of an IPsec tunnel and the firewall acts as the responder, cOS Core must choose which IPsec Tunnel object in the configuration best matches the incoming connection request. This section describes how cOS Core makes this choice. Note that when the firewall is the tunnel initiator, no search is required since the tunnel object to use will be clear.
IPsec Tunnel Object Ordering is Important
When looking for an IPsec Tunnel object match, cOS Core scans the configured tunnel list from top to bottom and stops the search when it finds a match. For this reason, the ordering of tunnels in the list can be important. The following rule of thumb should be followed for correct placement in the tunnel list: tunnels with narrower criteria should be placed higher.When following this rule, LAN-to-LAN tunnels should nearly always be placed before roaming client tunnels because LAN-to-LAN tunnels will usually have much narrower matching criteria than roaming client tunnels. For example, a roaming client tunnel will often have its Remote Network property set to all-nets whereas a LAN-to-LAN tunnel will usually have that property set to a much narrower specific network or range.
The Tunnel Selection Stages
As cOS Core goes through the IP Tunnel object list from first to last, it finds a match using the following three stage process:Stage 1 - IKE SA Setup
The first stage involves trying to set up an IKE SA which is the basis for a secure control channel between the local and remote peer. The configuration properties used are:
Stage 2 - Authentication
In the second stage the peers authenticate themselves to each other. The matching criteria are:
Authentication Method.
Local ID - If specified, this must be acceptable to the remote peer. If not specified, and certificates are used, a local ID specified in the tunnels host certificate must be acceptable to the remote peer.
Remote ID - If specified, the remote peer's ID must match one entry in the ID List assigned to this property. This is explained further in Section 10.3.18, Using ID Lists with Certificates.
Stage 3 - IPsec SA Setup
In the final stage, the IPsec SA is negotiated. This is an addition to stage 2.
After the above three stages have been processed, the tunnel should be established.
IPsec tunnels in cOS Core provide IPv6 support in the following ways:
For tunnel establishment. In other words, the outer part of the tunnel uses IPv6. This section will only cover this aspect of IPv6 usage with IPsec.
Section 3.2, IPv6 Support discusses all the solutions for tunneling IPv6 over IPv4 networks.
The setup for IPv6 traffic flowing inside an IPv4 IPsec tunnel is discussed specifically in a Clavister Knowledge Base article at the following link:
IPv6 Must Be Manually Enabled on Relevant Ethernet Interfaces
By default, IPv6 is disabled on all Ethernet interfaces. For IPv6 to function with IPsec, IPv6 must be enabled on the Ethernet interfaces IPsec will use for connection. Enabling IPv6 on Ethernet interfaces is described in Example 3.12, “Enabling IPv6 on an Ethernet Interface”.IPv6 Usage with IPsec Tunnels
The following is a list of the IPsec components where IPv6 addresses can be used instead of IPv4:The Local Network and Remote Network properties of an IPsec Tunnel object can be IPv6 networks.
The Local Endpoint and Remote Endpoint properties of an IPsec Tunnel object can be IPv6 addresses.
Note that the Local Endpoint and Remote Endpoint could both be IPv6 addresses but the tunnel can still carry IPv4 traffic. In other words, the endpoints could be IPv6 but the local and remote networks could be IPv4.
IKE Config Mode Pool objects can use a pool of IPv6 addresses.
Both CRL and CA lookup can be done using IPv6 addresses.
The FQDN for the Remote Endpoint can resolve to an IPv6 address.
IPsec Tunnel object properties cannot take both IPv4 and IPv6 addresses at the same time. However, some properties might not have a value assigned and will take the default value of <empty>. The Local Endpoint and Remote Endpoint properties are examples of this. The value <empty> means that either IPv4 and IPv6 is acceptable.
The IP address authenticated using XAuth (with IKEv1) or EAP (with IKEv2) can be IPv4 or IPv6. This is discussed further in Section 9.2.6, Authentication Rules.
|
Note: Tunnel monitoring requires an IPv4 address |
|---|---|
|
The IPsec tunnel monitoring features supports an IPv4 address only for the remote host. This feature is described in Section 10.3.17, IPsec Tunnel Monitoring. |
IKE Configuration Mode (Config Mode) is an extension to IKE that allows cOS Core to provide configuration information to remote IPsec clients. It is used to dynamically configure IPsec roaming clients with IP addresses, and to allocate other types of address information. Either IPv4 or IPv6 addresses can be allocated, although IPv6 cannot be used with IP Pool objects, as explained below.
Config Mode Pools
One or more IKE Config Mode Pool objects can be created in cOS Core. No pools are predefined. The way a pool obtains its addresses is determined by setting its IP Pool Type property to one of the following:Pre-defined IP Pool Object
A range of IPv4 addresses to be handed out are taken from a separate IP Pool object in the cOS Core configuration. See Section 5.5, IP Pools for information about configuring these type of objects.
Static IP Pool
Instead of using an IP Pool object, a range of addresses can be specified directly or an Address Book object can be specified. This option must be used for IPv6 addresses.
This option also allows a Netmask property to be entered. It should be noted that with IKv2 tunnels, this netmask value has no meaning and is always set by cOS Core to be 255.255.255.255.
Optional IKE Config Mode Pool Properties
The following IKE Config Mode Pool object properties can also be sent to the client. cOS Core itself does nothing with these values except forward them to the client.Example 10.7. Creating an IKE Config Mode Pool
In this example, the Config Mode Pool object is enabled by associating it with an already configured IP Pool object called ip_pool1.
Command-Line Interface
Device:/> add ConfigModePool
IPPoolType=PreDefined
IPPool=my_ip_poolInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
After defining the config mode pool object, the remaining task is to associate the pool with the IPsec Tunnel.
Enabling Config Mode on an IPsec Tunnel
Changing the value of the Config Mode property of an IPsec Tunnel object enables the ability to hand out IP addresses to connecting roaming clients from a predefined pool of IP addresses.The Config Mode property can take one of the following values:
None
Config mode is disabled. The tunnel's local and remote network property settings decide the protected networks.
This allows cOS Core to act like a roaming client and receive the IP address it will use as its local endpoint inside the tunnel from the remote IPsec peer. Optionally a DNS server address can also be allocated by the remote peer. This option can be used with both IKEv1 and IKEv2 and is described in more depth at the end of this section.
This option means that cOS Core will allocate IP addresses to a connecting peer from a predefined pool of addresses. An associated Config Mode Pool must also be specified which is the source of the addresses.
This option allows the IP address to be assigned to the user based on the method used for user authentication, which is decided by the triggering Authentication Rule. This option can be used with either IKEv1 XAuth authentication or IKEv2 EAP authentication.
If authentication is performed using a Local User Database then the IP handed out will be the value assigned to the Static Client IP Address property of the relevant User object.
If authentication is performed using an external RADIUS server then the server must be configured so that it sends back a Framed-IP-Address message with the allocated IP address when the user is authenticated.
Note that the allocation of IP addresses using this method is not available when using a Roaming VPN object to simplify roaming IPsec client setup.
Example 10.8. Enabling Config Mode on an IPsec Tunnel
Assume that an IKE Config Mode Pool object called my_cfg_pool and an IPsec Tunnel called my_ipsec_tunnel already exists. This example shows how to enable config mode on the tunnel and set the config mode address pool.
Command-Line Interface
Device:/> set Interface IPsecTunnel my_ipsec_tunnel
ConfigMode=Server
IKEConfigModePool=my_cfg_poolInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
IP Validation with Config Mode
cOS Core always checks if the source IP address of each packet inside an IPsec tunnel is the same as the IP address assigned to the IPsec client with IKE config mode. If a mismatch is detected the packet is always dropped and a log message generated with a severity level of Warning. This message includes the two IP addresses as well as the client identity.Optionally, the affected SA can be automatically deleted if validation fails by enabling the advanced setting IPsecDeleteSAOnIPValidationFailure. The default value for this setting is Disabled.
cOS Core as a Config Mode Client
The Client option for cOS Core config mode allows the firewall to act like an IPsec roaming client that connects to a remote IPsec peer and the IP address of the local endpoint inside the tunnel is assigned by the remote peer. The IPsec tunnel can be using either IKEv1 or IKEv2.The specific steps for setting up an IPsec tunnel so that cOS Core acts like a config mode client are the following:
Set the IKE Version property to be IKE1 or IKEv2.
For IKEv1, enable the setting Pass username and password to peer via IKE XAuthPass username and password to peer via IKE XAuth, if the remote gateway requires it.
For IKEv2, set the EAP property to be EAP-MSCHAPv2. Set it to EAP-MD5 only if this is required by the IPsec peer.
Enter a username and password for authentication with the peer.
Set the IPsec tunnel's local and remote network to all-nets.
Set the Config Mode property to be Client.
The Setup per SA property should keep the default value of Network.
Optionally assign address book objects to the IP (the local endpoint inside the tunnel) and DNS (a DNS server address for FQDN resolution) properties of the IPsec Tunnel object. These address book objects will then be assigned the values handed out by the IPsec peer.
This allows cOS Core rules to be set up using these address book objects prior to the remote peer assigning actual IP addresses. A typical use case for this is when traffic is to be NATed with an IP policy into the IPsec tunnel using the value assigned to the IP address object.
cOS Core supports IPsec using both the IKEv1 and IKEv2 protocols. This section describes the specific considerations that are needed when IKEv2 is used. Where possible, it is recommended to use IKEv2 because it is considered more robust. In some situations, such as tunneling L2TP, IKEv1 must be used.
The IKE Version Property
The IKE Version property of an IPsec Tunnel object determines the IKE version used when the tunnel is set up. This property can have one of the following values:IKEv1 - cOS Core will use IKEv1 for tunnel setup.
IKEv2 - cOS Core will use IKEv2 for tunnel setup. This is the default value.
Auto - cOS Core will first attempt to use IKEv2 for tunnel setup and revert back to IKEv1 if unsuccessful.
However EAP and XAuth are not configurable with this option since it is not possible to know which will be used ahead of time. For this reason, Auto cannot be used with roaming clients that require username/password authentication.
The simplified IPsec profile objects LAN to LAN VPN and Roaming VPN use IKEv2 only. These are essentially simplified versions of the full IPsec Tunnel object and are described further in Section 10.3.15, Using IPsec Profiles.
Configuring IKEv2 based IPsec tunnels is almost exactly the same as for IKEv1 but the following differences should be noted:
Authentication with EAP is used with IKEv2 instead of XAuth with IKEv1.
The AES-XCBC authentication algorithm is supported by IKEv2 only. If AES-XCBC is used in a proposal list with IKEv1, it will be skipped. If AES-XCBC is the only algorithm in the proposal list with IKEv1, tunnel setup will fail.
The Encapsulation Mode property of an IKEv2 tunnel can only be Tunnel. This means that IKEv2 cannot be used with L2TP (see Section 10.4.2, L2TP Servers).
EAP Server
The IPsec peer will be authenticated against a RADIUS server or a Local User Database in the cOS Core configuration. The authentication method is determined by the Authentication Source property of an Authentication Rule which triggers on the connecting tunnel attempt. The Authentication agent property of the rule must be set to EAP.
The associated setting Request EAP ID will, by default, be enabled, which means the ID can be different for the IKE and EAP negotiations. If it is disabled then the username of the client will be taken as the EAP ID sent during the IKE negotiation and this will be used for authentication.
EAP-MD5
Authentication is done using EAP-MD5 with the username/password credentials specified by the additional Username and Password properties.
EAP-MSCHAPv2
Authentication is done using EAP-MSCHAPv2 with the username/password credentials specified by the additional Username and Password properties.
Global Advanced Settings for IKEv2
The global settings that are specific to IKEv2 are discussed under the IKEv2 header in Section 10.3.24, IPsec Advanced Settings. These can also be found listed in the separate CLI Reference Guide.This section goes though the steps needed for setting up cOS Core to communicate with roaming clients that will connect to an IPsec Tunnel object. The tunnel will use IKEv2 with EAP authentication and use a RADIUS server as the AAA source.
It should be noted that this section discusses setup using the IPsec Tunnel object and therefore describes creating a separate Authentication Rule object. Tunnel setup for roaming clients can be simplified by using the Roaming VPN object instead which does not require a separate authentication rule and hides many properties not relevant to client connection. Using the Roaming VPN object is discussed further in Section 10.3.15, Using IPsec Profiles.
Note also that IKEv2 Windows roaming client setup using the firewall as the CA server is described in a Clavister Knowledge Base article at the following link:
https://kb.clavister.com/324736172
Another article in the Knowledge Base describes IPsec setup for roaming IKEv2 clients using FreeRADIUS with XCA for certificate generation. It can be found at the following link:
https://kb.clavister.com/324736225
Note that when using certificates with an IKEv2 client it is possible to use the CA certificates already installed in the client so no additional client certificates need to be installed. A Knowledge Base article discusses this further at the following link:
https://kb.clavister.com/324735761
Setup Steps
There are three parts to the setup:Correct installation of certificates in cOS Core and, when necessary, the client.
Correct configuration of cOS Core.
Correct configuration of the RADIUS server used for authentication.
These three parts will be discussed in the separate sections below
Installation of Certificates in the Client and cOS Core
EAP requires authentication using certificates and the requirements for the installed certificates should be as follows:
The client should have the appropriate CA root certificate installed.
With Windows, the certificate must be installed in a specific location. cOS Core only supports a Windows client running Windows 7™ or later. The Windows installation steps are described in detail below and must be to a specific location for IKEv2 to function correctly.
The certificate setup with other client platforms, such as Apple iOS or Android, should be straightforward and will not be described in detail.
The same CA root certificate used by the client should also be installed in cOS Core.
In addition, cOS Core should also have a host certificate (also known as the gateway certificate) installed which is signed by the root CA. This host certificate must have the following properties:
Either the Common Name (CN) or the Subject Alternative Name (SAN) must contain either the IP address of the IPsec tunnels local endpoint (the IP address the client connects to) or an FQDN that resolves to that IP address.
The serverAuth property should be set.
CA Root Certificate Installation for Windows Clients
The following is a description of certificate installation for a Windows 7 client. This will be similar for later Windows versions (earlier versions are not supported).Start the Microsoft Management Console (mmc) and add the Certificates snap-In.
Select the Computer account option.
Open the folder Certificates (Local Computer) > Trusted Root Certification Authorities > Certificates.
Select the Import option to start the Certificate Import Wizard.
Select the CA root certificate file to be imported and install it in the Trusted Root Certification Authorities store.
Note that the certificate file should never be double-clicked. If it is, the content will end up in the Current User instead of the Local Computer section of the Windows registry and it will not be available to the IPsec client.
Configuration of cOS Core
For the cOS Core configuration, the setup steps are as follows:In cOS Core configure a Config Mode Pool object that will provide the IP addresses to the connecting clients.
Add the same CA root certificate to the cOS Core along with a host certificate signed by the root certificate.
Configure an IPsec Tunnel object that will be used for client connection.
Configure a RADIUS Server object in cOS Core that will be used for EAP authentication. It is recommended to use an EAP method of MSCHAPv2.
Configure an Authentication Rule object that will trigger on the connecting clients. The rule should try to match the targeted traffic as closely as possible and should specify the Agent property as EAP.
The details for the above cOS Core configuration steps can be found in the cOS Core setup example found below.
RADIUS Server Setup
The following setup notes apply to a Microsoft Network Policy Server (NPS) and should be adapted if another type of RADIUS server is being used. With an NPS, the following steps should be performed:Under NPS > Policies > Connection Request Policies, add a Connection Request Policy.
The Type of network access server should be set to Unspecified.
The Conditions part of the policy specifies any restrictions.
Under NPS > Policies > Network Policies, add a Network Policy with no restrictions.
Under Constraints, select Authentication methods and then choose an EAP method. All EAP options are supported but EAP-MSCHAP v2 is recommended.
Select the NAS Port Type section of Constraints and disable all options.
Under RADIUS Clients, add the clients that will connect.
Setup for Splitting Tunnel Traffic
Sometimes there is a need to split traffic from clients so that some traffic goes through an IKEv2 IPsec tunnel and some does not. Setting this up with the standard Windows client is discussed in an article in the Clavister Knowledge Base at the following link:https://kb.clavister.com/324735827
|
Tip: The Roaming VPN object can simplify IPsec setup |
|---|---|
|
The example below goes through the complete steps for IPsec tunnel setup for roaming clients by using an IPsec Tunnel object. For IKEv2 tunnels, setup can be simplified by using a Roaming VPN object and doing this is described in Section 10.3.15, Using IPsec Profiles. The Roaming VPN object hides IPsec tunnel properties that are not relevant to IKEv2 IPsec tunnels for roaming clients and also does not require a separate Authentication Rule object for EAP authentication. |
The examples that follow illustrate how cOS Core is configured for connection by IKEv2 roaming clients using first RADIUS and then a local user database as the authentication source.
Example 10.9. IKEv2 EAP Client Setup using RADIUS
This example describes how to configure cOS Core to allow connection of an IKEv2 IPsec tunnel from a roaming client using EAP authentication against a RADIUS server. The default IKE and IPsec proposal lists will be used.
The example assumed that the relevant certificates have been installed correctly in cOS Core and on the client, as described previously. It also assumes that the RADIUS server used for authentication is also correctly configured.
Note that the authentication rule in this example uses all-nets and any as its traffic filtering parameters. In practice, it would be better to narrow these properties.
Command-Line Interface
A. Create a config mode IP pool for client IPs:
Device:/> add ConfigModePool my_cfg_pool
IPPoolType=Static
IPPoolAddress=192.168.189.30-192.168.189.50
IPPoolNetmask=255.255.255.0
DNS=192.168.28.4
B. Configure the IPsec tunnel:
Device:/> add Interface IPsecTunnel my_ikev2_client_tunnel
LocalNetwork=lan_net
RemoteNetwork=all-nets
AuthMethod=Certificate
GatewayCertificate=my_host_cert
RootCertificates=my_root_cert
AddRouteToRemoteNet=Yes
AutoInterfaceNetworkRoute=No
IKEVersion=2
RemoteEndpoint=all-nets
EAP=Yes
RequestEAPID=Yes
ConfigMode=Server
IKEConfigModePool=my_cfg_pool
C. Configure the RADIUS server for authentication:
Device:/> add RadiusServer my_radius_server
IPAddress=203.0.113.20
SharedSecret=MYSHAREDRADIUSSECRETSTRING
D. Configure the authentication rule for the tunnel:
Device:/> add UserAuthRule Name=my_ikev2_auth_rule
AuthSource=RADIUS
Interface=any
OriginatorIP=all-nets
Agent=EAP
RadiusServers=my_radius_server
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Create a config mode IP pool for client IPs:
B. Configure the IPsec tunnel:
C. Configure a RADIUS server for authentication:
D. Configure the authentication rule for the tunnel:
Example 10.10. IKEv2 EAP Client Setup using a Local Database
This example repeats Example 10.9, “IKEv2 EAP Client Setup using RADIUS” above but uses a Local User Database object instead of a RADIUS server for authentication.
It is assumed that a Local User Database object called my_user_db already exists which contains all the credentials for valid EAP users. Note that only the Authentication Rule object from the previous example needs to be changed.
Command-Line Interface
A. Create a config mode IP pool for client IPs:
Device:/> add ConfigModePool my_cfg_pool
IPPoolType=Static
IPPoolAddress=192.168.189.30-192.168.189.50
IPPoolNetmask=255.255.255.0
DNS=192.168.28.4
B. Configure the IPsec tunnel:
Device:/> add Interface IPsecTunnel my_ikev2_client_tunnel
LocalNetwork=lan_net
RemoteNetwork=all-nets
AuthMethod=Certificate
GatewayCertificate=my_host_cert
RootCertificates=my_root_cert
AddRouteToRemoteNet=Yes
AutoInterfaceNetworkRoute=No
IKEVersion=2
RemoteEndpoint=all-nets
EAP=Yes
RequestEAPID=Yes
ConfigMode=Server
IKEConfigModePool=my_cfg_pool
C. Configure the authentication rule for the tunnel:
Device:/> add UserAuthRule Name=my_ikev2_auth_rule
AuthSource=Local
Interface=any
OriginatorIP=all-nets
LocalUserDB=my_user_db
Agent=EAP
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Create a config mode IP pool for client IPs:
B. Configure the IPsec tunnel:
C. Configure the authentication rule for the tunnel:
The standard IPsec client built into Apple iOS™ devices can be used to connect to a Clavister firewall using the standard IPsec tunnels that can be defined in cOS Core.
The IPsec setup steps with iOS are essentially similar to those used with other roaming clients, as described previously in Section 10.3.7, IPsec Roaming Clients. However, a specific list of iOS setup steps is provided in this section for completeness.
Note that setup for iOS clients with IKEv2 and certificates is also discussed in an article in the Clavister Knowledge Base at the following link:
https://kb.clavister.com/324736134
cOS Core Setup Steps for iOS IPsec Connection
The cOS Core setup steps for iOS compatible IPsec tunnels are as follows:Ensure that the relevant CA root certificate for authenticating the certificate sent by the firewall is installed on the iOS device. A simple way to do this is to mail the certificate to the device as an attachment and then open it in the device followed by installation.
Create address book objects for the tunnel. These will consist of:
The network to which the local endpoint and the client addresses belong. For example, 192.168.99.0/24.
The local tunnel endpoint. For example, 192.168.99.1.
A range of addresses to be handed out to connecting clients. For example, 192.168.99.10-192.168.99.250.
Create a Pre-shared Key (PSK) object of type Passphrase (ASCII). This is the shared secret that will be entered into the IPsec client on the iOS device along with username and password.
Create a IKE Config Mode Pool object, select the option Use a Static IP Pool and associate the IP address range defined in the first step.
Populate a local user database with users that have a username and password. This function could also be performed by a RADIUS server.
Define an IPsec tunnel object and make sure the Diffie-hellman group property has 14 (2048-bits) added to it. Note that this group does not also need to be added to the Perfect Forward Secrecy property.
For the tunnel's IKE proposal list, make sure AES (Rijndael) is present for encryption plus SHA512 for integrity. A new proposal list could be created or a predefined proposal list modified.
For the tunnel's IPsec proposal list, make sure AES (Rijndael) is present for encryption plus SHA1 and/or MD5 for integrity. A new proposal list could be created or a predefined proposal list modified.
The IPsec tunnel object's other properties should have the following values:
The IP address to which the clients connect can be defined using the Local Endpoint property. If this is not set then the local endpoint defaults to the IP address of the tunnel's local Ethernet interface.
Place the tunnel last in the list of IPsec tunnels. Also be aware that this tunnel cannot coexist with a PSK tunnel for L2TP/IPsec.
Create a User Authentication Rule with the following properties:
When adding an IPsec tunnel to the cOS Core configuration, there is more than one type of tunnel object that can be created. Instead of using the standard IPsec Tunnel object, there is also the option to simplify tunnel setup for certain use cases by adding an IPsec profile object. These profiles pre-configure certain properties of the base IPsec Tunnel object leaving just a few properties that need to be assigned values by the administrator.
In addition to the base IPsec Tunnel object, the following simplified IPsec profile objects are available:
LAN to LAN VPN
This is a variant of the base IPsec Tunnel. It is intended to quickly provide LAN-to-LAN IPsec connection to a remote peer that is another cOS Core system and has been similarly configured with an equivalent LAN to LAN VPN tunnel.
The remote peer could also be a non-cOS Core device as long as it is configured to support the LAN to LAN VPN object defaults proposal list.
Details of the proposal list used is described further in Section 10.3.15.1, LAN to LAN VPN.
Roaming VPN
This is another variant of the base IPsec Tunnel object. It is intended for quickly configuring tunnel connection for roaming clients.
This object is described further in Section 10.3.15.2, Roaming VPN.
Azure VPN
This is another variant of the base IPsec Tunnel object. It is a LAN-to-LAN IPsec tunnel, intended for quickly configuring VPN connection to a Microsoft Azure™ virtual network.
This object is described further in Section 10.3.15.3, Azure VPN.
The purpose of the LAN to LAN VPN, Roaming VPN and Azure VPN objects is to be a simplification of the base IPsec Tunnel object. They hide properties that are not relevant to simple scenarios and use appropriate default values. Note that these are always based on IKEv2.
The following sections provide detailed descriptions of these tunnel types.
The LAN to LAN VPN object is an IKEv2 based IPsec tunnel type for quickly configuring LAN-to-LAN connection to a remote peer that is another cOS Core system and has been configured with a matching LAN to LAN VPN tunnel.
The following are the only IPsec Tunnel properties that are entered with this profile:
The IPsec tunnel property settings that are used with this tunnel type are the following:
Other IPsec tunnel properties are set to their default values.
A remote IPsec peer that is not running cOS Core could also connect to this type of tunnel provided it was configured to replicate this tunnel type's behavior.
Note that there is nothing specific to Clavister in the tunnel created by a LAN to LAN VPN object. It just simplifies connecting to a peer with a similarly configured tunnel. The peer could be a non-Clavister system with IPsec configured in the appropriate way.
Example 10.11. IPsec Setup with a LAN to LAN VPN Object
This example shows how Example 10.3, “PSK Based LAN-to-LAN IPsec Tunnel Setup” could have its IPsec tunnel configured as a LAN to LAN VPN object.
The remote peer would normally be another Clavister firewall and would be configured in a similar way using a LAN to LAN VPN object. However, it would have a different Remote Endpoint value and with the Local Network and Remote Network values reversed.
Command-Line Interface
Device:/> add Interface LANtoLANVPN ipsec_hq_to_branch
LocalNetwork=172.16.1.0/24
RemoteNetwork=192.168.11.0/24
RemoteEndpoint=203.0.113.1
PSK=my_secret_key
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
This Roaming VPN object is a variant of the base IPsec Tunnel object. It uses IKEv2 with certificate authentication, as well as EAP-MSCHAPv2, and allows simply and quick configuration of tunnel connections for roaming clients.
|
Note: Local clients are not supported by this profile |
|---|---|
|
The Roaming VPN profile assumes that the IPsec tunnel created will send and receive client traffic on the same interface, and this will be the case for external roaming clients connecting via the Internet. However, this will not be true for any local clients behind the firewall on a different interface, so the profile cannot be used. Instead, a standard IPsec Tunnel object must be used and the Local Endpoint property of the tunnel must be set to the IP address of the interface which terminates the tunnel. The Local Endpoint property is discussed further in Section 10.3.3, IPsec Tunnel Properties. |
The following are the only IPsec Tunnel properties that need to be entered with this profile:
An authentication source which can either be selected as RADIUS or Local. The RADIUS option requires that a configured RADIUS Server is also specified. The Local option requires that a Local User Database is used. A hidden Authentication Rule object is automatically created using this setting.
Note that if a RADIUS server is used, the server cannot also assign an IP address to the client. This can only be done with the standard IPsec Tunnel object.
The local network of the tunnel is always set internally to all-nets so IP policies and routes must be configured that determine how to handle the packets sent by the client since the destination IP address could be anything.
The IPsec tunnel property settings that are used with this tunnel type are the following:
Other IPsec tunnel properties are set to their default values.
An Authentication Rule is Automatically Configured
The Roaming VPN object automatically creates the required Authentication Rule object based on the values entered. The authentication rule created is not visible in the Web Interface and cannot be edited. It can only be viewed with the CLI command uarules.Since it is an IKEv2 tunnel, EAP is always used for client authentication against a RADIUS server or a local database. A RADIUS Server object must be configured separately if RADIUS is to be used, as described in the example at the end of this section.
Configuring Multiple Tunnel Objects
It is possible to configure multiple Roaming VPN objects. The Roaming VPN object that is chosen by cOS Core when a client connects will depend on the root certificate(s) in the client. The tunnel used will be the first one in the Roaming VPN object list where there is a match between a root certificate on the client and a root certificate associated with the Roaming VPN object.Note that a client could have more than one root certificate.
Supported Clients
The base VPN client types that are officially supported by this option are the following:Earlier versions for these environments may function correctly. In all cases, the only client setup required is to import the same root certificate that is used by the Roaming VPN object. Apart from this, the clients will function with their default settings and only the username and password should need to be entered.
For a more detailed description of IKEv2 roaming client setup and in particular setting up the Windows client with certificates, see Section 10.3.13, Setup for IKEv2 Roaming Clients.
Example 10.12. IPsec Setup with a Roaming VPN Object
This example shows how Example 10.9, “IKEv2 EAP Client Setup using RADIUS” could have its IPsec tunnel configured more simply using a Roaming VPN object.
Command-Line Interface
A. Configure the RADIUS server for EAP authentication:
Device:/> add RadiusServer my_radius_server
IPAddress=203.0.113.20
SharedSecret=MYSHAREDRADIUSSECRETSTRING
B. Configure the Roaming VPN object:
Device:/> add Interface RoamingVPN my_vpn_client_tunnel
IPPoolAddress=192.168.189.30-192.168.189.50
GatewayCertificate=my_host_cert
RootCertificates=my_root_cert
AuthSource=RADIUS
RadiusServer=my_radius_server
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Configure a RADIUS server for authentication:
B. Configure the Roaming VPN object:
The Azure VPN object is an IKEv2 based IPsec tunnel type for quickly configuring a site-to-site connection from a Clavister firewall to Microsoft Azure™. This allows connection from any computers located locally behind the firewall to any virtual machine or role instance within an Azure virtual network.
The following are only IPsec Tunnel properties that are entered with this profile:
The IPsec tunnel property settings that are used with this tunnel type are the following:
Other IPsec tunnel properties are set to their default values.
Note that there is no cOS Core feature specific to Azure in the tunnel created by an Azure VPN object. It just simplifies configuring the tunnel.
Example 10.13. IPsec Setup with a Azure VPN Object
This example shows how Example 10.3, “PSK Based LAN-to-LAN IPsec Tunnel Setup” could have its IPsec tunnel configured as an Azure VPN object.
Command-Line Interface
Device:/> add Interface AzureVPN ipsec_local_to_azure
RemoteEndpoint=203.0.113.1
LocalNetwork=172.16.1.0/24
RemoteNetwork=192.168.11.0/24
PSK=my_secret_key
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
The Mobility and Multihoming Protocol feature of IKEv2 provides a means for a roaming client to change IP address as it switches from one network to another (for example, from a 4G mobile network to a static WiFi network) so that an existing IPsec tunnel continues functioning without interruption across the new network.
cOS Core automatically supports MOBIKE with IKEv2 tunnels and there are no special settings that need to be enabled. However, cOS Core only allows the roaming client's IP address to change. The MOBIKE RFC-4555 also allows for the IP address of both endpoints to change but cOS Core does not allow its own local IP address to change.
Below is a summary of the features of MOBIKE usage with cOS Core:
With MOBIKE, clients or NATing devices can change the IP and/or port without renegotiating the tunnel.
MOBIKE is always enabled for IKEv2 IPsec tunnels.
MOBIKE is used only if the peer also allows it.
In a roaming client scenario, MOBIKE is only supported when cOS Core does not initiate the tunnel and acts as the responder.
Dead peer detection interval is configurable on each tunnel so it is possible to make sure that the client sends a DPD message before the server.
Overview
An IPsec Tunnel object has some additional properties which, together, provide a feature called tunnel monitoring. This is used for checking the health of a tunnel and reestablishing it should a problem be detected. When tunnel monitoring is enabled, the following happens:A single IPv4 address is specified in setting up the monitor and ICMP ping messages are then sent once per second through the IPsec tunnel to this IP address. This happens during the entire time the tunnel is established.
The source IP of these ICMP messages will be the value set for the Advanced > IP addresses property of the tunnel. If not explicitly set, the originator IP defaults to the local interface IP address.
If a specified number of replies to consecutive ICMP ping messages are not received back, the tunnel is assumed to be no longer operational and the IPsec tunnel will be taken down (both IKE and associated IPsec SA's will be deleted) and cOS Core will attempt to setup a new IPsec tunnel connection.
The tunnel monitor feature has similarities to the host monitoring described in Section 4.2.3, Route Failover and shares the same underlying mechanism.
Setting Up Tunnel Monitoring
The following steps are needed to set up monitoring for an IPsec Tunnel object:Specify a single IPv4 address as the host that should be accessible through the tunnel. The IP address must always be part of the tunnel's remote network so no route needs to be added for it. The host itself should be configured to respond to ICMP ping requests.
Optionally set the number of consecutive replies that are not received before the tunnel is renegotiated. This default to a value of 10 if not specified.
Using Tunnel Monitoring with Other Tunnel Options
The following should be noted about using other options with tunnel monitoring:DPD
Dead peer detection (DPD) should not be disabled because tunnel monitoring is being used (unless the external IPsec peer does not support DPD). DPD can work as a compliment to tunnel monitoring if both are enabled.
Auto Establish
It is recommended to not use the Auto Establish option together with tunnel monitoring.
Device:/> hostmon
Monitor sessions:
Session #1:
Failed Latency ms
Reachable Proto Host Port Interval Sample (act / max) (act / max)
--------- ----- -------------- ---- -------- ------ ----------- -----------
YES ICMP 192.168.1.1 1000 5 0 / 4 20 / 3000
YES ICMP 192.168.3.1 1000 5 0 / 4 10 / 3000Note that from cOS Core version 14.00.06, the output of the hostmon command can also be viewed in the Web Interface by going to: Status > Host Monitor.
Logging
A log event message is generated by cOS Core in the following instances:When a host is determined to be reachable, the following log message is generated:
IPSEC prio=Info id=01803600 rev=1 event=monitored_host_reachable action=none ip=192.168.1.2 tunnel=PSK-NAT
When a host is determined to be unreachable, the following log message is generated:
IPSEC prio=Error id=01803601 rev=1 event=monitored_host_unreachable action=sas_deleted ip=192.168.1.2 tunnel=PSK-NAT
Example 10.14. Enabling IPsec Tunnel Monitoring
This example will enable tunnel monitoring on an existing IPsec Tunnel object called my_ipsec_tunnel1. The host used for monitoring has the IPv4 address 203.0.11.5 and it is acceptable to not get up to 5 replies to the ICMP messages sent.
Command-Line Interface
Device:/> Set Interface IPsecTunnel my_ipsec_tunnel1
TunnelMonitor=Yes
MonitoredIP=203.0.11.5
MaxLoss=5
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
When certificates are used as the authentication method for IPsec tunnels, cOS Core will accept all remote peers that are capable of presenting a CA signed certificate. This can be a potential problem, especially when using roaming clients.
A Typical Scenario
Consider the scenario of traveling employees being given access to the internal corporate networks using IPsec with certificates. The organization administers their own Certificate Authority, and certificates have been issued to the employees. Different groups of employees are likely to have access to different parts of the internal networks. For example, members of the sales force might access servers running the order system, while technical engineers would access technical databases.The Problem
Since the IP addresses of the traveling employees VPN clients cannot be known beforehand, the incoming IPsec connections from clients cannot be differentiated. This means that the firewall is unable to correctly administer access to different parts of the internal networks using only the client's IP address.The ID List Solution
Identification lists (ID lists) provide a solution to this problem. An ID List object in the cOS Core configuration contains one or more ID objects as children. An IPsec Tunnel object can then have its Remote ID property set to an ID list object. For a particular tunnel to be used by a particular client, the following must be true:When the client connects, cOS Core chooses the IPsec Tunnel object to use as follows:
Finally, cOS Core checks the ID against the ID objects in the ID List for the matching tunnel. If a matching ID is not found then the tunnel setup fails and a log message error is generated by cOS Core.
Any malformed IDs will be ignored but will generate a log message warning.
Note that an ID List can be used with either IKEv1 or IKEv2 tunnels but is usually only relevant for tunnels using certificates. PSK tunnels can use ID lists but there is usually no reason to do this because the PSKs at both ends of the tunnel must match.
Specifying IDs
The ID object properties required are determined by the Type property of the object. The Type property can take one of the following values:DistinguishedName
This will be matched with the distinguished name (DN) in the ID sent by the client. It must be the same as the subjectName field in the client's certificate. The following is an example of ID object creation in the CLI with this value:
Device:/my_id_list> add ID my_dn_id
Type=DistinguishedName
CommonName="John Smith"
OrganizationName=example
OrganizationalUnit=Support
Country=Sweden
EmailAddress=john.smith@example.com
For convenience, the parameters of the distinguished name are specified as separate properties. A long string of parameter/value pairs in a particular order do not need to be specified.
DNS
This will be matched with the FQDN in the ID sent by the client. It must be the same as the subjectAltName field in the client's certificate. The following is an example of ID object creation in the CLI with this value:
Device:/my_id_list> add ID my_dns_id
Type=DNS
Hostname=server.example.com
This will match with the email address in the ID sent by the client. It must be the same as the subjectAltName field in the client's certificate. The following is an example of ID object creation in the CLI with this value:
Device:/my_id_list> add ID my_email_id
Type=E-Mail
E-Mail=john.smith@example.com
IP
This will match with the IP address in the ID sent by the client. It must be the same as the subjectAltName field in the client's certificate. The following is an example of ID object creation in the CLI with this value:
Device:/my_id_list> add ID my_ip_id
Type=IP
IP=203.0.113.5
Example 10.15. Using an ID List
This example shows how to create and use an Identification List object with an IPsec tunnel. This list will contain one ID with the type DN (distinguished name) as the primary identifier. Note that this example does not cover how to add the specific IPsec tunnel object.
Command-Line Interface
First create an Identification List:
Device:/> add IDList my_id_listThen, create an ID:
Device:/> cc IDList my_id_list
Device:/my_id_list> add ID my_dn_id
Type=DistinguishedName
CommonName="John Smith"
OrganizationName=Clavister
OrganizationalUnit=Support
Country=Sweden
EmailAddress=john.smith@example.com
Device:/my_id_list> ccFinally, apply the Identification List to the IPsec tunnel:
Device:/> set Interface IPsecTunnel MyIPsecTunnel
AuthMethod=Certificate
RemoteID=my_id_list
RootCertificates=my_root_cert
GatewayCertificate=my_gateway_cert
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
First create an ID List:
Then, add an ID list to this ID list:
Finally, apply the Identification List to the IPsec tunnel:
The Differentiated Services (diffserv) field in a packet can be used by network equipment to prioritize data traffic. The 8 bit diffserv field consists of two parts: a 6 bit Differentiated Services Code Point (DSCP) and a 2 bit Explicit Congestion Notification (ECN). cOS Core IPsec treats these as a whole and does not divide the 8 bit field.
For IPsec, the DiffServ values related to a tunnel can be split into three types:
The DiffServ value of the packets involved in the IKE exchange for tunnel setup.
The DiffServ value of the outer tunnel IPsec packets.
The DiffServ value of the packets being transported inside the tunnel.
The administrator can alter the DiffServ value in the following ways:
For tunnel setup, the DiffServ value of IKE packets can have a specified fixed value.
The DiffServ of the outer tunnel packets can be set to a fixed value or they can have the value copied from the DiffServ field of the packets inside the tunnel.
Setting up the above two options is described next.
Specifying the DiffServ Field for IKE Traffic
By default, all IKE packets sent by cOS Core during tunnel setup have their DiffServ value set to zero. This can be changed to a fixed value for a tunnel by setting the IKEDSField property of the IPsecTunnel object. For example:Device:/> set Interface IPsecTunnel my_tunnel IKEDSField=1Setting the DiffServ Field in the Outer Tunnel
By default, all IPsec outer tunnel packets sent by cOS Core have their DiffServ field value copied from the packets inside the tunnel. The DiffServ field can be set to a fixed value by setting the property IPsecDSField for the IPsecTunnel object. For example:Device:/> set Interface IPsecTunnel my_tunnel IPsecDSField=1Both IKE and IPsec protocols present a problem in the functioning of NAT. Both protocols were not designed to function with NAT and because of this, the technique called NAT traversal has evolved. NAT traversal is an add-on to the IKE and IPsec protocols that allows them to function when being NATed. cOS Core supports the RFC-3947 standard for NAT-Traversal with IKE.
NAT traversal is divided into two parts:
Additions to IKE that lets IPsec peers tell each other that they support NAT traversal, and the specific versions supported. cOS Core supports the RFC-3947 standard for NAT-Traversal with IKE.
Changes to the ESP encapsulation. If NAT traversal is used, ESP is encapsulated in UDP, which allows for more flexible NATing.
Below is a more detailed description of the changes made to the IKE and IPsec protocols.
NAT traversal is only used if both ends have support for it. For this purpose, NAT traversal aware VPNs send out a special "vendor ID" to tell the other end of the tunnel that it understands NAT traversal, and which specific versions of the draft it supports.
Achieving NAT Detection
To achieve NAT detection both IPsec peers send hashes of their own IP addresses along with the source UDP port used in the IKE negotiations. This information is used to see whether the IP address and source port each peer uses is the same as what the other peer sees. If the source address and port have not changed, then the traffic has not been NATed along the way, and NAT traversal is not necessary. If the source address and/or port has changed, then the traffic has been NATed, and NAT traversal is used.Changing Ports
Once the IPsec peers have decided that NAT traversal is necessary, the IKE negotiation is moved away from UDP port 500 to port 4500. This is necessary since certain NAT devices treat UDP packet on port 500 differently from other UDP packets in an effort to work around the NAT problems with IKE. The problem is that this special handling of IKE packets may in fact break the IKE negotiations, which is why the UDP port used by IKE has changed.UDP Encapsulation
Another problem that NAT traversal resolves is that the ESP protocol is an IP protocol. There is no port information as we have in TCP and UDP, which makes it impossible to have more than one NATed client connected to the same remote gateway and at the same time. Because of this, ESP packets are encapsulated in UDP. ESP-UDP traffic is sent on port 4500, the same port as IKE when NAT traversal is used. Once the port has been changed, all following IKE communication is done over port 4500. NAT keep-alive packets are also sent periodically to keep the NAT mapping alive.NAT Traversal Configuration
Most NAT traversal functionality is completely automatic and in the initiating firewall no special configuration is needed. However, for responding firewalls two points should be noted:On responding firewalls, the Remote Endpoint field is used as a filter on the source IP of received IKE packets. This should be set to allow the NATed IP address of the initiator.
When individual pre-shared keys are used with multiple tunnels connecting to one remote firewall which are then NATed out through the same address, it is important to make sure the Local ID property of an IPsec Tunnel object is unique for every tunnel and takes one of the following values:
Auto - The local ID becomes the IP address of the outgoing interface. This is the recommended setting unless the two firewalls have the same external IP address.
IP - An IP address can be manually entered.
DNS - A DNS address can be manually entered.
Email - An email address can be manually entered.
A root certificate usually includes the IP address or hostname of the certificate authority (CA) to contact when certificates or CRLs need to be downloaded to the Clavister firewall. Lightweight Directory Access Protocol (LDAP) is used for these downloads.
However, in some scenarios, this information is missing, or the administrator wishes to use another LDAP server. The LDAP configuration section can then be used to manually specify alternate LDAP servers.
Example 10.16. Setting up an LDAP server
This example shows how to manually setup and specify an LDAP server.
Command-Line Interface
Device:/> add LDAPServer
Host=192.168.101.146
Username=myusername
Password=mypassword
Port=389InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
IPsec can be used to create a layer-3 bridge between two networks on different hosts. A reason for requiring such a bridge is when a central site and a remote site are using the same IP network and the administrator wants to assign a portion of this network to the remote site without the need to make any major changes on either side.
Normally, each site would be assigned a unique IPv4 network address to ensure that devices within each network can communicate with each other without conflicts. However, a central site and a remote site may have been assigned the same IPv4 network addresses because, for example, the sites were set up by different organizations using overlapping IP address ranges, or perhaps because the sites were merged without proper network planning.
This creates problems, since devices on one network may be unable to communicate with devices on the other network due to conflicting IP addresses. This can be solved using a layer-3 bridge.
The steps for creating the bridge is described in an article in the Clavister Knowledge Base at the following link:
Certain hardware platforms can provide cOS Core with hardware based acceleration. These platforms are:
Hardware with AES-NI
cOS Core can take advantage of AES-NI acceleration if it is available and AES encryption is being used. This acceleration is controlled by an advanced setting in cOS Core which is enabled by default.
This is discussed further under the Enable AES-NI setting in Section 10.3.24, IPsec Advanced Settings.
NetWall 6000 Series with QAT Enabled Modules
The Clavister NetWall 6000 Series provides the option to install Ethernet expansion modules with inbuilt QAT. If installed, cOS Core will automatically make use of the QAT function for IPsec traffic transiting the interfaces in the module.
The NetWall 6000 Series capabilities are discussed further in the separate Getting Started Guide for the product.
The following cOS Core advanced settings are global settings that will apply to all IPsec tunnels. They can be found in the Web Interface by going to: Network > Interfaces and VPN > IPsec > Advanced Settings.
General Settings (IKEv1 and IKEv2)
The IPsec DS Field This setting is specified on a per tunnel value. The value specified is copied into the Differentiated Service Field in the outer IP header of ESP packets sent by cOS Core as part of the IPsec tunnel. In other words, no matter what the DS field value of the inner ESP packets being carried by the tunnel, this value will replace it.If no value is specified (the default) then the DSF value of the tunnel's inner packets will be copied into the outer header of the tunnel's outbound ESP packets.
The DS field value is part of the DiffServ architecture and specifies a Quality of Service (QoS) requirement for the traffic as it passes through other devices such as routers. Diffserv is discussed further in Section 11.1, Traffic Shaping.
IPsec Max Rules
This specifies the total number of IP ruleset entries that can be connected to IPsec tunnels. By default, this is initially approximately 4 times the licensed IPsecMaxTunnels and system memory for this is allocated at startup. By reducing the number of rules, memory requirements can be reduced but making this change is not recommended.IPsec Max Rules will always be reset automatically to be approximately 4 times IPsec Max Tunnels if the latter is changed. This linkage is broken once IPsec Max Rules is altered manually so that subsequent changes to IPsec Max Tunnels will not cause an automatic change in IPsec Max Rules.
Default: 4 times the license limit of IPsec Max Tunnels
IPsec Max Tunnels
Specifies the total number of IPsec tunnels allowed. This value is initially taken from the maximum tunnels allowed by the license. The setting is used by cOS Core to allocate memory for IPsec. If it is desirable to have less memory allocated for IPsec then this setting can be reduced. Increasing the setting cannot override the license limit.A warning log message is generated automatically when 90% of this setting's value is reached.
Default: The limit specified by the license
IKE Send Initial Contact
Determines whether or not IKE should send the "Initial Contact" notification message. This message is sent to each remote endpoint when a connection is opened to it and there are no previous IPsec SA using that gateway.Default: Enabled
IKE Send CRLs
Dictates whether or not CRLs (Certificate Revocation Lists) should be sent as part of the IKE exchange. Should typically be set to ENABLE except where the remote peer does not understand CRL payloads.Note that this setting requires a restart to take effect.
Default: Enabled
IPsec Before Rules
Pass IKE and IPsec traffic sent to cOS Core directly to the IPsec engine without consulting the IP rule set.Default: Enabled
IKE CRL Validity Time
A CRL contains a "next update" field that dictates the time and date when a new CRL will be available for download from the CA. The time between CRL updates can be anything from a few hours and upwards, depending on how the CA is configured. Most CA software allow the CA administrator to issue new CRLs at any time, so even if the "next update" field says that a new CRL is available in 12 hours, there may already be a new CRL for download.This setting limits the time a CRL is considered valid. A new CRL is downloaded when IKECRLVailityTime expires or when the "next update" time occurs. Whichever happens first.
Default: 86400 seconds
IKE Max CA Path
When the signature of a user certificate is verified, cOS Core looks at the issuer name field in the user certificate to find the CA certificate the certificate was signed by. The CA certificate may in turn be signed by another CA, which may be signed by another CA, and so on. Each certificate will be verified until one that has been marked as "trusted" is found, or until it is determined that none of the certificates are trusted.If there are more certificates in this path than what this setting specifies, the user certificate will be considered invalid.
Default: 15
IPsec Cert Cache Max Certs
Maximum number of certificates/CRLs that can be held in the internal certificate cache. When the certificate cache is full, entries will be removed according to an LRU (Least Recently Used) algorithm.Default: 1024
General Settings (IKEv2 only)
When enabled, cOS Core will fallback to using XCBC (RFC-3664) if XCBC (RFC-4344) fails during EAP authentication.AES-XCBC-MAC is a method of generating the message authentication code (MAC) used in IKEv2 negotiations. RFC-3664 states that only key lengths of 128 bits are supported for AES-XCBC-MAC. This is a problem with EAP since EAP authentication uses session keys of at least 512 bits. To solve this, using only the first 128 bits of a 512 bits EAP key has become a de-facto standard for RFC-3664.
RFC-4434 supersedes RFC-3664 and specifies a different method of adapting keys longer than 128 bits. Although RFC-4434 should theoretically be backward compatible with RFC-3664, these different methods of adapting the key to 128 bits are not compatible in practice. This advanced setting provides a way to fallback to using the older RFC-3664 method should authentication using RFC-4434 fail.
If the setting is disabled then only the newer method of RFC-4434 is used and if that method fails then authentication will fail. The disadvantage of having this setting enabled is the greater amount of computing time needed to try both the RFC-4434 and RFC-3664 method.
Default: Disabled
The length of time in seconds that an SA will linger after a client initiated delete.Default: 3 seconds
This forces the requirement for cookies and is used for testing purposes only.Default: Disabled
When enabled, use the client requested subnet attributes when allocating IP addresses using config mode.Default: Disabled
When enabled, the IPsec tunnel is deleted if decrypted source IP addresses do not match the remote network.Default: Disabled
If disabled, cOS Core sends the additional attributes Calling-Station-ID and Called-Station-ID in the RADIUS accounting messages it sends as part of EAP authentication.Called-Station-ID is always set by cOS Core to the value of the responder identity sent during the IKEv2 negotiation. If no identity is available then the default value of "1234567891234321" is used.
Default: Disabled
When a NAT device has been detected between the client and the Clavister firewall, IKEv2 negotiation will switch from port 500 to 4500 and all ESP traffic will be encapsulated in UDP packets. Normally this port change is only done when there is a NAT device involved but some clients may prefer port 4500 instead of 500 even when there is no NAT. If this is the case, cOS Core can accept the IKEv2 connection but when the client sends IKE data, it is sent as raw ESP packets and without this setting enabled, cOS Core will drop the packets since they will be expected to be encapsulated in UDP.When enabled, this setting allows the IKE port change even though there is no NAT.
Default: Disabled
This setting enables logging of session keys for each new IPsec SA established. Both the encryption key and authentication keys are logged as hexadecimal strings. Note that having access to these keys makes it possible to decrypt captured packets offline.Default: Disabled
|
Caution: Enable Key Logging for testing only |
|---|---|
|
As encryption keys are highly sensitive pieces of information, this feature should be enabled for debugging purposes only. |
Hardware Acceleration Settings
If the underlying hardware platform supports AES-NI, this setting should be enabled to significantly speed throughput when AES encryption is used. This is relevant to cOS Core running on Clavister hardware products, as well as in virtual environments such as VMware, KVM or Hyper-V.AES acceleration is relevant to the following in cOS Core:
This setting is enabled by default on all platforms. If the setting is changed, cOS Core must be rebooted for the change to take effect.
If IPsec hardware acceleration is available, this will be used instead of AES-NI acceleration. However, IPsec acceleration can be explicitly disabled using the IPsec Hardware Acceleration setting below, forcing AES-NI acceleration to be used.
To check if the underlying platform supports AES-NI, use the CLI command:
Device:/> cpuidIf AES-NI is supported, aes will appear in the Feature flags list in the output from the command. This command can be used when running cOS Core under a hypervisor.
Default: Yes
This determines if any available IPsec hardware acceleration should be used. Normally, this setting should be left at the default value of Coprocessor.The value None should be chosen if cOS Core is to be forced to use AES-NI acceleration, even though Coprocessor acceleration is available.
The available hardware acceleration can be queried using the following CLI command:
Device:/> cryptostat
Default: Coprocessor
Disable Public-Key Hardware Acceleration
This option would only be enabled for troubleshooting and diagnostic purposes. In normal operation, any available acceleration should never be disabled.Default: No
This section deals with how to troubleshoot some common problems that can occur when using IPsec. A key tool for IPsec troubleshooting is the ike CLI command. Some example options of this command that are useful for troubleshooting are:
This command allows IPsec tunnel negotiations to be examined in a live system as they occur. It is very useful for identifying proposal mismatches.
This command sets up the IKE and IPsec SAs for a particular tunnel but is designed to be used only for running tests.
Note that this command option will add new SAs every time it is run without removing previous SAs.
A complete description of these commands with their options can be found in the separate cOS Core CLI Reference Guide.
Note that there is also a Clavister Knowledge Base article which covers IPsec troubleshooting at the following link:
https://kb.clavister.com/324736401
The above article was originally based on IKEv1 IPsec but many of the same troubleshooting methods are also applicable to IKEv2 tunnels. It can be used as a supplement to the information found in this publication.
If encountering problems, the following checks can be made:
Check that all IP addresses have been specified correctly.
Check that all pre-shared keys and usernames/passwords are correctly entered.
Use ICMP Ping to confirm that the tunnel is working. With roaming clients this is best done by Pinging the internal IP address of the local network interface on the Clavister firewall from a client (in LAN-to-LAN setups, pinging could be done in either direction). If cOS Core is to respond to a Ping then the following IP policy must exist in the IP rule set:
| Action | Src Interface | Src Network | Dest Interface | Dest Network | Service |
|---|---|---|---|---|---|
| Allow | vpn_tunnel | all-nets | core | all-nets | ICMP |
Ensure that another IPsec Tunnel definition is not preventing the correct definition being reached. The tunnel list is scanned from top to bottom by cOS Core and a tunnel in a higher position with the Remote Network set to all-nets and the Remote Endpoint set to none could prevent the correct tunnel being reached. A symptom of this is often an Incorrect Pre-shared Key message.
Try and avoid duplication of IP addresses between the remote network being accessed by a client and the internal network to which a roaming client belongs.
If a roaming client becomes temporarily part of a network such as a Wi-Fi network at an airport, the client will get an IP address from the Wi-Fi network's DHCP server. If that IP also belongs to the network behind the firewall accessible through a tunnel, then Windows will still continue to assume that the IP address is to be found on the client's local network. Windows therefore will not correctly route packets bound for the remote network through the tunnel but instead route them to the local network.
The solution to this problem of local/remote IP address duplication is to create a new route in the client's Windows routing table that explicitly routes the IP address to the tunnel.
If roaming client user authentication is not asking the users for their username/password then ensure that the following advanced settings are enabled:
IPsec Before Rules for pure IPsec roaming clients.
L2TP Before Rules for L2TP roaming clients.
PPTP Before Rules for PPTP roaming clients.
These settings should be enabled by default and they ensure that user authentication traffic between cOS Core and the client can bypass the IP rule set. If the appropriate setting is not enabled then an explicit IP policy needs to be added to allow the authentication traffic to pass between roaming clients and cOS Core. This IP policy will have a destination interface of core (which means cOS Core itself).
If the remote endpoint is specified as a URL, make sure that the URL string is preceded by the prefix dns:. If, for example, the tunnel remote endpoint is to be specified as vpn.example.com, this should be specified as dns:vpn.example.com.
Too many IPsec SA negotiations might introduce timing issues. It is possible to use all-nets as the source or destination network to limit the number of negotiations. This topic is discussed further in a Clavister Knowledge Base article at the following link:
The following are some specific symptoms that will be discussed in this section:
A. The tunnel can only be initiated from one side.
B. The tunnel is unable to be set up and the ike -snoop command reports a config mode XAuth problem even though XAuth is not used.
C. The ike_invalid_payload log message with the reason ike_invalid_cookie.
D. Unable to connect to the tunnel endpoint from behind the firewall.
Troubleshooting the above symptoms will now be discussed in detail.
A. The tunnel can only be initiated from one side
This is a common problem and is due to a mismatch of the size in local or remote network and/or the lifetime settings on the proposal list(s).To troubleshoot this it is necessary to examine the settings for the local network, remote network, IKE proposal list and IPsec proposal list on both sides to try to identify a miss-match.
For example, suppose the following IPsec settings are at either end of a tunnel:
Side A
Local Network = 192.168.10.0/24
Remote Network = 10.10.10.0/24
Side B
Local Network = 10.10.10.0/24
Remote Network = 192.168.10.0/16
In this scenario, it can be seen that the defined remote network on Side B is larger than that defined for Side A's local network. This means that Side A can only initiate the tunnel successfully towards Site B as its network is smaller.
When Side B tries to initiate the tunnel, Side A will reject it because the network is bigger than what is defined. The reason it works the other way around is because a smaller network is considered more secure and will be accepted. This principle also applies to the lifetimes in the proposal lists.
B. Unable to set up with config mode and getting a spurious XAuth message
The reason for this message is basically "No proposal chosen". The case where this will appear is when there is something that fails in terms of the network size on either the local network or the remote network. Since cOS Core has determined that it is a type of network size problem, it will try one last attempt to get the correct network by sending a config mode request.By using ike -snoop when both sides initiate the tunnel, it should be simple to compare the network that both sides are sending in phase-2. With that information it should be possible to spot the network problem. It can be the case that it is a network size mismatch or that it does not match at all.
C. The ike_invalid_payload log message with the reason ike_invalid_cookie.
The common reason for getting the log message ike_invalid_payload with the reason ike_invalid_cookie is that cOS Core could not match a received IKE packet against an existing IKE SA. The unmatched IKE packets are therefore dropped.This can arise if the tunnel is down on one side but the other side still considers the tunnel is up and sends IKE packets. The solution is to first make sure the tunnel is brought down on both sides and then investigate why the side sending the IKE packets saw the tunnel as up. It could be that DPD or tunnel monitoring is not being used by the packet sender to detect if the IPsec peer is not alive.
However, there are other reasons why this log message combination might occur but in all cases there will be some problem with the arriving IKE packet that results in the packet being dropped.
D. Unable to connect to the tunnel endpoint from behind the firewall
By default, cOS Core expects that the interface for incoming and outgoing connection will be the same. This behavior can be altered by explicitly setting the IPsec tunnel property Local Endpoint. This issue is discussed further in an article in the Clavister Knowledge Base at the following link:This section will deal with specific error messages that can appear in log event messages with IPsec and what they indicate. The messages discussed are the following
1. Could not find acceptable proposal / no proposal chosen.
2. Incorrect pre-shared key.
3. Ike_invalid_payload, Ike_invalid_cookie.
4. Payload_Malformed.
5. No public key found.
6. ruleset_drop_packet.
7. Tunnels disabled on deployment.
1. Could not find acceptable proposal / no proposal chosen
This is the most common IPsec related error message. It means that depending on which side initiates tunnel setup, the negotiations in either the IKE or the IPSec phase of setup failed since they were unable to find a matching proposal that both sides could agree on.Troubleshooting this error message can be involved since the reasons for this message can be multiple depending on where in the negotiation it occurred.
If the negotiation fails during phase-1 – IKE
The IKE proposal list does not match. Double check that the IKE proposal list matches that of the remote side. A good idea is to use the ike -snoop -verbose CLI command and have initiation of the tunnel by the remote peer. It can then be seen what proposals the remote side is sending and then compare the results with the local IKE proposal list. At least ONE proposal has to match in order for it to pass phase-1. Remember that the lifetimes are also important, as will be mentioned in Problem symptom-1.
If the negotiation fails during phase-2 – IPsec
The IPsec proposal list does not match. Double check that the local IPsec proposal list matches that of the remote peer. The same method described above of using ike -snoop can be used when the remote side initiates the tunnel, comparing it against the local proposal list. What is extra in the IPsec phase is that the networks are negotiated here, so even if the IPsec proposal list seems to match, the problem may be with mismatching networks. The local network(s) on one side need to be the remote network on the other side and vice versa. Remember that multiple networks will generate multiple IPsec SAs, one SA per network (or host if that option is used). The defined network size is also important in that it must be exactly the same size on both sides, as will be mentioned again later in the symptoms section.
There are also some settings on the IPsec tunnel's IKE tab that can be involved in a no-proposal chosen issue. For example, PFS (for IPsec phase) or DH Group (for the IKE phase). Also, the choice of Main or Aggressive mode.
2. Incorrect pre-shared key
A problem with the pre-shared key on either side has caused the tunnel negotiation to fail. This is perhaps the easiest of all the error messages to troubleshoot since it can be only one thing, and that is an incorrect pre-shared key. Double-check that the pre-shared key is of the same type (Passphrase or Hex-key) and correctly added on both sides of the tunnel.Another reason for why cOS Core detects that the pre-shared key is incorrect could be because the wrong tunnel is triggering during tunnel negotiations. IPsec tunnels are processed from the top to the bottom of the cOS Core tunnel list and are initially matched against the remote gateway. An example is if there is a IPsec tunnel for roaming clients that uses all-nets as its remote gateway. This tunnel will trigger before the intended tunnel if it is placed above it in the cOS Core tunnel list.
For example, consider the following IPsec tunnel definitions:
| Name | Local Network | Remote Network | Remote Gateway |
|---|---|---|---|
| VPN-1 | lannet | office1net | office1gw |
| VPN-2 | lannet | office2net | office2gw |
| L2TP | ip_wan | all-nets | all-nets |
| VPN-3 | lannet | office3net | office3gw |
Since the tunnel L2TP in the above table is above the tunnel VPN-3, a match will trigger before VPN-3 because of the all-nets remote gateway (all-nets will match any network). Since these two tunnels use different pre-shared keys, cOS Core will generate an "Incorrect pre-shared key" error message.
The problem is solved if we reorder the list and move VPN-3 above L2TP. The gateway office3gw will be then matched correctly and VPN-3 will be the tunnel selected by cOS Core.
3. Ike_invalid_payload, Ike_invalid_cookie
In this case the IPsec engine in cOS Core receives an IPsec IKE packet but is unable to match it against an existing IKE.If an IPsec tunnel is only established on one side, this can be the resulting error message when traffic arrives from a tunnel that does not exist. An example would be if, for some reason, the tunnel has only gone down on the initiator side but the terminator side still sees it as up. If the terminator then sends packets through the tunnel, the initiator will drop them since no matching tunnel can be found.
Simply remove the tunnel from the side that believes it is still up to solve the immediate problem. An investigation as to why the tunnel only went down from one side is recommended. It could be that DPD is only used on one side. Another possible cause could be that even though it has received a DELETE packet, it has not deleted/removed the tunnel.
This problem is very similar to the Incorrect pre-shared key problem described above. A possible reason is that the PSK is of different types on either side (passphrase or hex key).Verify that the same type is being used on both sides of the IPsec tunnel. If one side is using Hex and the other Passphrase then this is most likely the error message that will be generated.
5. No public key found
This is a very common error message when dealing with tunnels that use certificates for authentication.Troubleshooting this error message can be very difficult as the possible cause of the problem can be quite extensive. Also it is very important to keep in mind that when dealing with certificates there may be a need to combine the ike -snoop output with normal log messages as ike -snoop does not give extensive information about certificates, whereas normal logs can provide important clues as to what the problem could be.
A good suggestion before starting to troubleshoot certificate based tunnels is to first configure it as a PSK tunnel and then verify that it can be successfully established. Then move on to using certificates (unless the type of configuration prevents that).
The possible causes of certificate problems can be the following:
The certificate on either side is not signed by the same CA server.
A certificate's validity time has expired or it has not yet become valid. The latter can occur if the clock is set incorrectly on either the CA server or the Clavister firewall or they are in different time zones.
The Clavister firewall is unable to reach the Certificate Revocation List (CRL) on the CA server in order to verify if the certificate is valid or not. Double-check that the CRL path is valid in the certificate's properties. (Note that usage of the CRL feature can be turned off.)
Also make sure that there is a DNS client configured for cOS Core in order to be able to correctly resolve the path to the CRL on the CA server.
If multiple IPsec tunnels exist which are similar and there is a need to separate them using ID lists, a possible cause can be that none of the ID lists match the certificate properties of the connecting user. Either the user is not authorized or the certificate properties are wrong on the client or the ID list needs to be updated with this user/information.
With L2TP, the client certificate is imported into the wrong certificate store on the Windows client. When the client connects, it is using the wrong certificate.
7. Tunnels disabled on deployment
When IPsec tunnel changes in a configuration are saved, cOS Core may indicate a problem with an activation error message similar to the following:Cfg Warning (S1325) section 'IPSEC': - Disabling IPsec tunnel my-tunnel1This message indicates that the IPsec Tunnel object called my-tunnel1 will not be functional. This can be due to one of the following reasons:
The number of IPsec tunnels allowed by the current license has been exceeded.
The number of tunnels allowed by the cOS Core setting IPsecMaxTunnels has been exceeded.
There is a lack of free system memory which can be allocated to the tunnel.
Disabled IPsec tunnels are also discussed in an article in the Clavister Knowledge Base at the following link:
The ipsec CLI command can be used to show that IPsec tunnels have been established correctly. A typical example of output might be the following:
Device:/> ipsec
--- IPsec SAs:
Displaying one line per SA-bundle
IPsec Tunnel Local Net Remote Net Remote GW
------------ -------------- ------------- -------------
L2TP_IPSec 192.168.1.5 203.0.113.5 203.0.113.5
IPsec_Tun1 192.168.0.0/24 203.0.113.0/24 203.0.113.10
To examine the first IKE negotiation phase of tunnel setup use the ike command:
Device:/> ikeHowever, to get complete details of tunnel setup use:
Device:/> ipsec -show -verbose -usage
![[Warning]](images/warning.png) |
Warning: Be careful using the -num=all option |
|---|---|
|
If there are large numbers of tunnels then avoid using the -num=all option since this will generate correspondingly large amounts of output. For example, with a large number of tunnels avoid using: Another example of what to avoid with many tunnels is: In these circumstances, using the option with a small number, for example -num=10, is recommended. |
VPN Tunnel Negotiation
When setting up IPsec tunnels, problems can arise because the initial IKE negotiation fails when the devices at either end of a VPN tunnel try but fail to agree on which protocols and encryption methods will be used. The ike -snoop console command is a tool that can be used to identify the source of problems by showing the details of IKE negotiations. Using ike -snoop The ike -snoop command can be entered via a CLI console connected via a network connection or directly via the local console.By default, ike -snoop always generates the most verbose level of output so the -verbose option does not have to be specified explicitly. It is possible to reduce the default verbose level by using the -brief option. All the ike -snoop command options can be found in the separate CLI Reference Guide.
Command Options and Specifying an Endpoint
To begin IKE monitoring for all tunnels, the full command is:Device:/> ike -snoopDevice:/> ike -snoop 10.1.1.10Device:/> ike -snoop -offThe -match Option
Another useful command option which provides more negotiation detail is the -match option:Device:/> ike -snoop -matchThe output from ike -snoop can sometimes be troublesome to interpret when seeing it for the first time. Presented below, is some typical ike -snoop -verbose output with explanations (the initial timestamps have been removed). The tunnel negotiation considered is based on pre-shared keys. A negotiation based on certificates is not discussed here but the principles are similar.
The two parties involved in the tunnel negotiation are referred to in this section as the client and server. In this context, the word "client" is used to refer to the device which is the initiator of the negotiation and the server refers to the device which is the responder.In the example below, the server has the private IPv4 address 10.122.128.10. The initiating client has the private IPv4 address 10.122.128.50. Both are using the default ISAKMP port which is UDP port 500.
Step 1. Client Initiates Negotiation and Sends a Supported Algorithm List
The verbose option output initially shows the proposed list of algorithms that the client first sends to the server. This list details the protocols and encryption methods it can support. The purpose of the algorithm list is that the client is trying to find a matching set of protocols/methods supported by the server. The server examines the list and attempts to find a combination of the protocols/methods sent by the client which it can support. This matching process is one of the principal purposes of the IKE exchange.IkeSnoop: core:10.122.128.10:500 <- WAN:10.122.128.50:500
ISAKMP Version : 1.0
Exchange type : Identity Protection (main mode)
Initiator cookie : 0x1bf64e785c4af5bf
Responder cookie : 0x0000000000000000
Flags :
Message ID : 0x00000000
Length : 408 bytes
# payloads : 9
Payloads:
SA (Security Association)
Payload data length : 208 bytes
DOI : 1 (IPsec DOI)
Proposal 1/1
Protocol 1/1
Protocol ID : ISAKMP
SPI Size : 0
Transform 1/5
Transform ID : IKE
Encryption algorithm : Rijndael-cbc (aes)
Key length : 256
Hash algorithm : SHA
Group description : ECP random 384
Authentication method : Pre-Shared Key
Life type : Seconds
Life duration : 28800
Transform 2/5
Transform ID : IKE
Encryption algorithm : Rijndael-cbc (aes)
Key length : 128
Hash algorithm : SHA
Group description : ECP random 256
Authentication method : Pre-Shared Key
Life type : Seconds
Life duration : 28800
Transform 3/5
Transform ID : IKE
Encryption algorithm : Rijndael-cbc (aes)
Key length : 256
Hash algorithm : SHA
Group description : MODP 2048
Authentication method : Pre-Shared Key
Life type : Seconds
Life duration : 28800
Transform 4/5
Transform ID : IKE
Encryption algorithm : 3DES-cbc
Hash algorithm : SHA
Group description : MODP 2048
Authentication method : Pre-Shared Key
Life type : Seconds
Life duration : 28800
Transform 5/5
Transform ID : IKE
Encryption algorithm : 3DES-cbc
Hash algorithm : SHA
Group description : MODP 1024
Authentication method : Pre-Shared Key
Life type : Seconds
Life duration : 28800
VID (Vendor ID)
Payload data length : 20 bytes
Vendor ID : 01 52 8b bb c0 06 96 12 18 49 ab 9a 1c 5b 2a 51 00 00 00
01
Description : (unknown)
VID (Vendor ID)
Payload data length : 20 bytes
Vendor ID : 1e 2b 51 69 05 99 1c 7d 7c 96 fc bf b5 87 e4 61 00 00 00
09
Description : MS NT5 ISAKMPOAKLEY
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : 4a 13 1c 81 07 03 58 45 5c 57 28 f2 0e 95 45 2f
Description : RFC 3947
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : 90 cb 80 91 3e bb 69 6e 08 63 81 b5 ec 42 7b 1f
Description : draft-ietf-ipsec-nat-t-ike-02
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : 40 48 b7 d5 6e bc e8 85 25 e7 de 7f 00 d6 c2 d3
Description : FRAGMENTATION
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : fb 1d e3 cd f3 41 b7 ea 16 b7 e5 be 08 55 f1 20
Description : MS-Negotiation Discovery Capable
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : 26 24 4d 38 ed db 61 b3 17 2a 36 e3 d0 cf b8 19
Description : Vid-Initial-Contact
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : e3 a5 96 6a 76 37 9f e7 07 22 82 31 e5 ce 86 52
Description : IKE CGA version 1
An explanation of some of the values found above
Exchange type: Main mode or aggressive mode (IKEv1.0 only).Step 2. The Server Responds to the Client
A typical response from the server is shown below. This must contain a proposal that is identical to one of the choices from the client list above. If no match was found by the server then a "No proposal chosen" message will be seen, tunnel setup will fail and the ike -snoop command output will stop at this point.IkeSnoop: core:10.122.128.10:500 -> WAN:10.122.128.50:500
ISAKMP Version : 1.0
Exchange type : Identity Protection (main mode)
Initiator cookie : 0x1bf64e785c4af5bf
Responder cookie : 0x6a6f979a3ccb6ea8
Flags :
Message ID : 0x00000000
Length : 268 bytes
# payloads : 10
Payloads:
SA (Security Association)
Payload data length : 56 bytes
DOI : 1 (IPsec DOI)
Proposal 1/1
Protocol 1/1
Protocol ID : ISAKMP
SPI Size : 0
Transform 1/1
Transform ID : IKE
Encryption algorithm : Rijndael-cbc (aes)
Key length : 256
Hash algorithm : SHA
Group description : MODP 2048
Authentication method : Pre-Shared Key
Life type : Seconds
Life duration : 28800
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : f7 58 f2 26 68 75 0f 03 b0 8d f6 eb e1 d0 03 00
Description : SafeNet QuickSec
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : 27 ba b5 dc 01 ea 07 60 ea 4e 31 90 ac 27 c0 d0
Description : draft-stenberg-ipsec-nat-traversal-01
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : 61 05 c4 22 e7 68 47 e4 3f 96 84 80 12 92 ae cd
Description : draft-stenberg-ipsec-nat-traversal-02
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : 44 85 15 2d 18 b6 bb cd 0b e8 a8 46 95 79 dd cc
Description : draft-ietf-ipsec-nat-t-ike-00
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : cd 60 46 43 35 df 21 f8 7c fd b2 fc 68 b6 a4 48
Description : draft-ietf-ipsec-nat-t-ike-02
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : 90 cb 80 91 3e bb 69 6e 08 63 81 b5 ec 42 7b 1f
Description : draft-ietf-ipsec-nat-t-ike-02
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : 7d 94 19 a6 53 10 ca 6f 2c 17 9d 92 15 52 9d 56
Description : draft-ietf-ipsec-nat-t-ike-03
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : 4a 13 1c 81 07 03 58 45 5c 57 28 f2 0e 95 45 2f
Description : RFC 3947
VID (Vendor ID)
Payload data length : 16 bytes
Vendor ID : af ca d7 13 68 a1 f1 c9 6b 86 96 fc 77 57 01 00
Description : draft-ietf-ipsec-dpd-00
Step 3. The Client Begins the Key Exchange
The server has accepted a proposal at this point and the client now begins a key exchange. In addition, NAT detection payloads are sent to detect if NAT is being used.IkeSnoop: core:10.122.128.10:500 <- WAN:10.122.128.50:500
ISAKMP Version : 1.0
Exchange type : Identity Protection (main mode)
Initiator cookie : 0x1bf64e785c4af5bf
Responder cookie : 0x6a6f979a3ccb6ea8
Flags :
Message ID : 0x00000000
Length : 388 bytes
# payloads : 4
Payloads:
KE (Key Exchange)
Payload data length : 256 bytes
NONCE (Nonce)
Payload data length : 48 bytes
NAT-D (NAT Detection)
Payload data length : 20 bytes
Hash (20) : 5520a6f77c04b36a6e4eb639a483ca4512e1ab1b
NAT-D (NAT Detection)
Payload data length : 20 bytes
Hash (20) : 6df6a51158681aca7a07247c902eb05bd135041c
Step 4. The Server Sends Key Exchange Data
The Server now sends key exchange data back to the client.IkeSnoop: core:10.122.128.10:500 -> WAN:10.122.128.50:500
ISAKMP Version : 1.0
Exchange type : Identity Protection (main mode)
Initiator cookie : 0x1bf64e785c4af5bf
Responder cookie : 0x6a6f979a3ccb6ea8
Flags :
Message ID : 0x00000000
Length : 356 bytes
# payloads : 4
Payloads:
KE (Key Exchange)
Payload data length : 256 bytes
NONCE (Nonce)
Payload data length : 16 bytes
NAT-D (NAT Detection)
Payload data length : 20 bytes
Hash (20) : 6df6a51158681aca7a07247c902eb05bd135041c
NAT-D (NAT Detection)
Payload data length : 20 bytes
Hash (20) : 5520a6f77c04b36a6e4eb639a483ca4512e1ab1b
Step 5. The Client Sends Its Identification
The initiator sends the identification which is normally an IP address or the Subject Alternative Name if certificates are used.IkeSnoop: core:10.122.128.10:500 <- WAN:10.122.128.50:500
ISAKMP Version : 1.0
Exchange type : Identity Protection (main mode)
Initiator cookie : 0x1bf64e785c4af5bf
Responder cookie : 0x6a6f979a3ccb6ea8
Flags : E (encryption)
Message ID : 0x00000000
Length : 64 bytes
# payloads : 2
Payloads:
ID (Identification)
Payload data length : 8 bytes
ID : 10.122.128.50
HASH (Hash)
Payload data length : 20 bytes
An explanation of some of the values found above
Flags: E means encryption (it is the only flag used).Step 6. The Server Responds With Its Identification
The server now responds with its own ID.IkeSnoop: core:10.122.128.10:500 -> WAN:10.122.128.50:500
ISAKMP Version : 1.0
Exchange type : Identity Protection (main mode)
Initiator cookie : 0x1bf64e785c4af5bf
Responder cookie : 0x6a6f979a3ccb6ea8
Flags : E (encryption)
Message ID : 0x00000000
Length : 64 bytes
# payloads : 2
Payloads:
ID (Identification)
Payload data length : 8 bytes
ID : 10.122.128.10
HASH (Hash)
Payload data length : 20 bytes
Step 7. The Client Sends a List of Supported IPsec Algorithms
The client now sends a list of supported IPsec algorithms to the server. It will also contain the proposed host/networks that are allowed in the tunnel.IkeSnoop: core:10.122.128.10:500 <- WAN:10.122.128.50:500
ISAKMP Version : 1.0
Exchange type : Quick mode
Initiator cookie : 0x1bf64e785c4af5bf
Responder cookie : 0x6a6f979a3ccb6ea8
Flags : E (encryption)
Message ID : 0x00000001
Length : 460 bytes
# payloads : 5
Payloads:
HASH (Hash)
Payload data length : 20 bytes
SA (Security Association)
Payload data length : 328 bytes
DOI : 1 (IPsec DOI)
Proposal 1/6
Protocol 1/1
Protocol ID : ESP
SPI Size : 4
SPI Value : 0xd0790a86
Transform 1/1
Transform ID : Rijndael (aes)
Encapsulation mode : Transport
Key length : 256
Authentication algorithm : HMAC-SHA-1
SA life type : Seconds
SA life duration : 3600
SA life type : Kilobytes
SA life duration : 250000
Proposal 2/6
Protocol 1/1
Protocol ID : ESP
SPI Size : 4
SPI Value : 0xd0790a86
Transform 1/1
Transform ID : Rijndael (aes)
Encapsulation mode : Transport
Key length : 128
Authentication algorithm : HMAC-SHA-1
SA life type : Seconds
SA life duration : 3600
SA life type : Kilobytes
SA life duration : 250000
Proposal 3/6
Protocol 1/1
Protocol ID : ESP
SPI Size : 4
SPI Value : 0xd0790a86
Transform 1/1
Transform ID : 3DES
Encapsulation mode : Transport
Authentication algorithm : HMAC-SHA-1
SA life type : Seconds
SA life duration : 3600
SA life type : Kilobytes
SA life duration : 250000
Proposal 4/6
Protocol 1/1
Protocol ID : ESP
SPI Size : 4
SPI Value : 0xd0790a86
Transform 1/1
Transform ID : DES
Encapsulation mode : Transport
Authentication algorithm : HMAC-SHA-1
SA life type : Seconds
SA life duration : 3600
SA life type : Kilobytes
SA life duration : 250000
Proposal 5/6
Protocol 1/1
Protocol ID : ESP
SPI Size : 4
SPI Value : 0xd0790a86
Transform 1/1
Transform ID : Null
Encapsulation mode : Transport
Authentication algorithm : HMAC-SHA-1
SA life type : Seconds
SA life duration : 3600
SA life type : Kilobytes
SA life duration : 250000
Proposal 6/6
Protocol 1/1
Protocol ID : AH
SPI Size : 4
SPI Value : 0xd0790a86
Transform 1/1
Transform ID : SHA
Encapsulation mode : Transport
Authentication algorithm : HMAC-SHA-1
SA life type : Seconds
SA life duration : 3600
SA life type : Kilobytes
SA life duration : 250000
NONCE (Nonce)
Payload data length : 48 bytes
ID (Identification)
Payload data length : 8 bytes
ID : 10.122.128.50
ID (Identification)
Payload data length : 8 bytes
ID : 10.122.128.10
An explanation of some of the values found above
Transform ID: Cipher.Here, the first ID is the local network of the tunnel from the client's point of view and the second ID is the remote network. If it contains any netmask it is usually SA per net and otherwise it is SA per host.
Step 8. The Client Sends a List of Supported Algorithms
The server now responds with a matching IPsec proposal from the list sent by the client. As in step 2 above, if no match can be found by the server then a "No proposal chosen" message will be seen, tunnel setup will fail and the ike -snoop command output will stop here.IkeSnoop: core:10.122.128.10:500 -> WAN:10.122.128.50:500
ISAKMP Version : 1.0
Exchange type : Quick mode
Initiator cookie : 0x1bf64e785c4af5bf
Responder cookie : 0x6a6f979a3ccb6ea8
Flags : E (encryption)
Message ID : 0x00000001
Length : 164 bytes
# payloads : 5
Payloads:
HASH (Hash)
Payload data length : 20 bytes
SA (Security Association)
Payload data length : 64 bytes
DOI : 1 (IPsec DOI)
Proposal 1/1
Protocol 1/1
Protocol ID : ESP
SPI Size : 4
SPI Value : 0xcf25abf6
Transform 1/1
Transform ID : Rijndael (aes)
Encapsulation mode : Transport
Key length : 256
Authentication algorithm : HMAC-SHA-1
SA life type : Seconds
SA life duration : 3600
SA life type : Kilobytes
SA life duration : 250000
NONCE (Nonce)
Payload data length : 16 bytes
ID (Identification)
Payload data length : 8 bytes
ID : 10.122.128.50
ID (Identification)
Payload data length : 8 bytes
ID : 10.122.128.10
Step 9. The Client Confirms the Tunnel Setup
This last message is from the client saying that all the client/server exchanges have been successful.IkeSnoop: core:10.122.128.10:500 <- WAN:10.122.128.50:500
ISAKMP Version : 1.0
Exchange type : Quick mode
Initiator cookie : 0x1bf64e785c4af5bf
Responder cookie : 0x6a6f979a3ccb6ea8
Flags : E (encryption)
Message ID : 0x00000001
Length : 52 bytes
# payloads : 1
Payloads:
HASH (Hash)
Payload data length : 20 bytes
The maximum number of IPsec tunnels that can be opened by cOS Core is controlled by the license parameter Max VPN Tunnels and the aggregate throughput allowed through all tunnels is controlled by the license parameter Max VPN Throughput. It is up to the administrator to make sure that cOS Core has the type of license that will suit an installation's requirements. License capabilities can be extended by purchasing a new license with higher limiting values.
If the Max VPN Tunnels value is exceeded, IPsec IKE negotiation will fail during setup of additional tunnels and the following log message will be generated by cOS Core:
maximum_allowed_tunnels_limit_reached
Note that it not just simple IPsec Tunnel objects that can contribute to the aggregate number of IPsec tunnels open, but also objects that are built on an IPsec tunnel such as LAN to LAN VPN and Roaming VPN objects.
Established tunnels will remain unaffected when the Max VPN Throughput value is reached but data rates will be deliberately throttled by cOS Core so the aggregate IPsec throughput remains within the maximum specified by the license.
How the administrator can best adapt IPsec tunnel usage to the limitations of the cOS Core license is discussed further in a Clavister Knowledge Base article which can be found at the following link:
