IPsec

IPsec is capable of connecting to a tunnel over IPv4 or IPv6 phase 1 peer addresses, but with IKEv1 the tunnel can only contain the same type of traffic inside the tunnel phase 2 definition that is used to pass the traffic outside the tunnel. This means that although either IPv4 or IPv6 may be carried inside of the tunnel, to use IPv6 traffic inside the tunnel, then the tunnel must be connected betweenIPv6 peer IPs, not IPv4. In other words, theinner and outer address family must match, they cannot be mixed.

As with most other shortcomings of IKEv1, this has been addressed in IKEv2. Tunnels using IKEv2 may carry both types of traffic no matter which protocol is used to establish the outer tunnel. With IKEv2, mobile clients may also use both IPv4 and IPv6, provided the client supports it.

Choosing configuration options

IPsec offers numerous configuration options, affecting the performance and security of IPsec connections. Realistically, for low to moderate bandwidth usage it matters little whichoptions are chosen here as long as DES is notused, and a strong pre-shared key is definedunless the traffic being protected is so valuable that an adversary with many millions of dollars worth of processing poweris willing todevote it to breaking the IPsec encryption. Even in that case, there is likely an easier and much cheaper way to break into the networkand achieve the same end result (social engineering, for one). Performance is the most important factor for most, and in cases when that is a concern, more care is needed when crafting a configuration.

Phase 1 Settings

The settings here control the phase 1 negotiation portion of the tunnel, as described previously.

Enable/Disable Tunnel

The Disabled checkbox controls whether or notthis tunnel (and its associated phase 2 entries) are active and used.

Key Exchange Version

The Key Exchange Version selector controls whether the tunnel will use IKE version 1 (V1) or IKE version 2 (V2). IKEv2 is a newer version of IKE that is desirable in many ways.The differences are discussed in IKE. In mostcases, IKEv1 will be used unless both sides properly support IKEv2.

Internet Protocol

The Internet Protocol selector sets the protocol for the outside of the tunnel. That is, the protocol that will be used between the outside peer addresses. For most, this will be IPv4 , but if both ends are capable of IPv6, that may be used instead. Whichever protocol is chosen here will be used to validate the Remote Gateway andthe associated identifiers.

Note

A tunnel using IKEv1 can only carry the same protocol traffic in Phase 2 as wasused for Phase 1. For example, IPv4 peer addresses restrict Phase 2 to IPv4 networks only.A tunnel using IKEv2 can carry both IPv4 andIPv6 traffic at the same time in Phase 2 no matter which protocol was used for Phase 1.

Interface Selection

In many cases, the Interface option for an IPsec tunnel will be WAN, since the tunnels are connecting to remote sites. However, there are plenty of exceptions, the most commonof which are outlined in the remainder of this section.

CARP Environments

CARP type virtual IP addresses are also available in the Interface drop-down menu for use in High Availability environments (High Availability). In these environments, An appropriate CARP address must be chosen for the WAN where the IPsec tunnel will terminate. By usingthe CARP IP address, it ensures that the IPsec tunnel will be handled by the High Availability cluster member currently in MASTER state, so even if the primary firewall is down, the tunnel will connect to whichever cluster member has taken over the MASTER role.

IP Alias VIP

If multiple IP addresses are available on an interface using IP Alias type VIPs, they willalso be available in this list.To use one of those IP addresses for the VPN instead, select it here.

Multi-WAN Environments

When using Multi-WAN (Multiple WAN Connections), pick the appropriate Interface choice forthe WAN-type interface to which the tunnel will connect. If the connection will enter via WAN, pick WAN. If the tunnel will use a different WAN, choose whichever OPT WAN interface is needed. A static route will automatically be added to ensure that the traffic to the Remote Gateway routesthrough the appropriate WAN.

A gateway group may also be chosen from this list. A gateway group to be used with IPsec must only have one gateway per tier. When using a gateway group, if the first gateway goes down, the tunnel will move to the next available WAN in the group. When the first WAN comes back up, the tunnel will be rebuilt there again. If the far side router is one that doesnot support multiple peer addresses, such asanother DEfenseBolt unit, this must be combined with a DynDNS host set using the same gateway group for failover. The DynDNS host will update the IP address as seen by the far side, so that the remote router will know to accept traffic from the newly activated WAN.

Wireless Internal Protection

When configuring IPsec to add encryption to awireless network, as described in Additional protection with VPN, choose the OPT interfacewhich corresponds tothe wireless card. When using an external wireless access point, pick the interface which is connected to the wireless access point.

Remote Gateway

The Remote Gateway is the IPsec peer for thisphase 1. This is the router on the other sideof the tunnel to which IPsec will negotiate this phase 1. This may be set to an IP addressor a fully qualified domain name. When set touse a name, the entry is periodically resolved byDNS and updated when a change is detected.

Description

The Description for the phase 1 is some text to use for identifying this phase 1. It’s not used in the IPsec settings, it’s only for reference.

Authentication Method

An IPsec phase 1 can be authenticated using apre-shared key (PSK) or RSA certificates, theAuthentication Method selector chooses which of these methods will be used for authenticating the remote peer. Fields appropriate to the chosen method will be displayed on the phase 1 configuration screen.

Mutual PSK

When using Mutual PSK , the peer is validatedusing a defined string. The longer the betterbut since it is simple a string, there is apossibility that it can be guessed. For thisreason a long/complex key is more secure when using PSK mode.

Mutual RSA

In Mutual RSA mode, select a CA and certificate used to verify the peer. During the phase 1 exchange, each peer sends its certificate to the other peer and then validates it against their shared CA. The CA and certificate must be created for the tunnel before attemptingto setup the phase 1.

Mutual PSK+Xauth

Used with mobile IPsec and IKEv1, this selection enables xauth username and password verification along with a shared (or “group”) pre-shared key.

Mutual RSA+Xauth

Used with mobile IPsec and IKEv1, this selection enables xauth username and password verification along with RSA certificate authentication using certificates on both the client and server.

Hybrid RSA+Xauth

Used with mobile IPsec and IKEv1, this selection enables xauth username and password verification along with a certificate only on the server side. It is not quite as secure as Mutual RSA+Xauth , but it is easier on the clients.

EAP-TLS

Used with mobile IPsec and IKEv2, RSA EAP-TLSverifies that certificates on the client andserver are from the same shared CA, similar toMutual RSA. The client and server certificates require special handling:

• The server certificate must have the firewall’s name as it exists in DNS listed in its Common Name, and again as a Subject Alternative Name (SAN). The firewall’s IP address must also be listed in a SAN.
• The identifier in Phase 1 must also be set to match the firewall’s hostname as listed inthe Common Name of the certificate.
• The client certificate must have the user’sname listed as the common name and then again as a SAN.

The CA and server certificates must be generated before attempting to configure EAP-TLS. The CA and user certificate must be imported into the client.

EAP-RADIUS

Used with mobile IPsec and IKEv2, this selection performs CA verification along with username and password authentication via RADIUS. ARADIUS server must be selected on the Mobile Clients tab. Though user certificates are notnecessary, EAP-RADIUS still requires that a CA and server certificate be present using thesame attributes mentioned under EAP-TLS. The CA must be imported to the client, but no user certificate.

EAP-MSCHAPv2

Used with mobile IPsec and IKEv2, EAP-MSCHAPv2 works identically to EAP-RADIUS except the usernames and passwords are defined on the Pre-Shared Key tab under VPN > IPsec with the Secret type set to EAP. It also requires a CA and server certificate with the same requirements listed previously. The CA must be imported to the client, but no user certificate.

Negotiation Mode

For IKEv1, two Negotiation Mode choices are supported: main , aggressive. This selection is not present when using IKEv2.

Main Mode

Main is the most secure mode, though it also requires more packets between the peers to accomplish a successful negotiation. It is also much more strict in its validation.

Aggressive Mode

My dentifier / Peer Identifier

Here, choose the identifier used to send to the remote peer, and also for verifying the identity of the remote peer. The following identifier types can be chosen for the My Identifier and Peer Identifier selectors. If needed, a text box will appear to enter a value to be used for the identifier.

My IP Address / Peer IP address

This choice is a macro that will automatically use the IP address on the interface, or theselected VIP, as the identifier. For peers, this is the IP address from which the packets were received, which should be the Remote Gateway.

IP Address

The IP Address option allows a different IP address to be used as the identifier. One potential use for this would be if the firewall is behind a router performing NAT. The real external IP address could be used in this field

Distinguished Name

A Distinguished Name is another term for a fully qualified domain name, such as host.example.com. Enter a value in that format into thebox.

User Distinguished Name

A User Distinguished Name is an e-mail address, such as vpn@example.com, rather than an FQDN.

ASN.1 Distinguished Name

If using Mutual RSA authentication, this can be the subject of the certificate being used,or a similar string.

KeyID Tag

An arbitrary string to use as the identifier.

Dynamic DNS

A hostname to resolve and use as the identifier. This is mostly useful if the firewall is behind NAT and has no direct knowledge of itsexternal IP address aside from a dynamic DNS hostname. This is not relevant or available for a Peer Identifier as the hostname may be used directly in the Remote Gateway field and use Peer IP Address for the identifier.

Any

In cases when the remote identifier is unknown or cannot be matched, the Peer Identifier may be set to Any. This is more common on certain types of mobile configurations, but it is a much less secure choice than matching the identifier properly.

Pre-Shared Key (If using Mutual PSK)

This field is used to enter the PSK for phase1 authentication. As mentioned previously, make this a long/complex key. If this PSK has been provided by the peer, enter it here. If anew PSK must be generated, we recommend usinga password generation tool set to a length ofat least 15, but it can be much longer.

Phase 1 Encryption algorithms

There are many options for encryption algorithms on both phase 1 and phase 2.

The current options are all considered cryptographically secure. Which to choose depends on the device to which the tunnel will connectand the hardware available in this firewall. Generally speaking, AES is the most desirablecipher and the longest key length (256 bits) is best. When connecting to third party devices, 3DES (also called “Triple DES”) is a common choice as it may be the only option the other end supports. More information about ciphers and acceleration is available in Phase 2 Encryption algorithms.

Phase 1 Hash algorithms

Hash algorithms are used with IPsec to verifythe authenticity of packet data. MD5, SHA1, SHA256, SHA384, SHA512, and AES-XCBC are the available hash algorithms on phase 1 and phase2. All are considered cryptographically secure, though SHA1 (Secure Hash Algorithm, Revision 1) and its variants are considered the stronger than MD5. SHA1 does require more CPU cycles than MD5, and the larger values of SHA in turn require even greater CPU power. These hash algorithms may also be referred to with HMAC (Hash Message Authentication Code) in the name in some contexts, but that usage varies depending on the hardware or software in use.

Note

The implementation of SHA256-512 is RFC 4868 compliant on the FreeBSD version used by DefenseBolt. RFC 4868 compliance breaks compatibility with stacks that implemented draft-ietf-ipsec-ciph-sha-256-00, including FreeBSD 8.1 and earlier. Before using SHA256, 384, or 512, check with the other side to ensure they are also RFC 4868 compliant implementations or they will not work. The relevant FreeBSD commit message when this happened explains in a little more detail.

DH key group

All of the DH (Diffie-Hellman, named after its authors) key group options are considered cryptographically secure, though the higher numbers are slightly more secure at the cost ofincreased CPU usage.

Lifetimes

The lifetime specifies how often the connection must be rekeyed, specified in seconds. 28800 seconds on phase 1 is a common configuration and is appropriate for most scenarios.

My Certificate (If using Mutual RSA)

This option only appears if using an RSA-based Authentication Mode. The list is populated using the certificates present in the firewall’s configuration. Certificates can be imported and managed under System > Cert Manager on the Certificates tab. Choose the certificate to use for this IPsec phase 1 from the list. The CA for this certificate must match the one chosen in the My Certificate Authorityselector.