Skip to content

IPsec policies

With IPsec policies, you can specify the phase 1 and phase 2 IKE (Internet Key Exchange) parameters for establishing IPsec and L2TP tunnels between two firewalls.

You can assign IPsec policies to IPsec and L2TP connections. The default policies support some common scenarios. You can also configure custom policies.

  • To specify the phase 1 and phase 2 security parameters, go to VPN > IPsec policies.
  • To duplicate an IPsec policy, click Duplicate Button for duplicating a policy.
  • To specify the peer IP address or DNS name and the peer authentication method, go to VPN > IPsec connections and L2TP (remote access).

You can create IPsec tunnels between two Sophos Firewall devices or between a Sophos Firewall and a third-party firewall.

Restriction

With FIPS turned on, certain encryption restrictions apply to ensure a certain encryption strength. For details, see VPN encryption restrictions with FIPS.

IKE and SAs

Internet Key Exchange: IKE helps you set up a Security Association (SA) for shared, secure IPsec communication. IKE enables both firewalls to generate the same symmetric key privately. The firewalls use the symmetric key to encrypt and decrypt IP packets.

You can specify IKEv1 and IKEv2 protocols for key exchange. Aggressive mode isn't available for IKEv2.

Security Association: The firewalls establish an SA based on the IKE negotiation with each other and maintain a list of SAs until the corresponding tunnels remain connected. SAs contain the source and destination IP addresses, encryption and authentication algorithms, key life, and the SPI.

Security Parameter Index: SPI is a unique local identifier each firewall generates. The SPI refers to each SA, identifying the tunnel to which a packet belongs.

Phase 1 parameters

IKE SA: The firewall initiating the tunnel sends its phase 1 parameters, and the peers negotiate the parameters they'll use. These parameters include the encryption algorithm, hash (data authentication) algorithm, key length, DH group, peer authentication method, and key life.

In main mode, IKE SAs use six messages and encrypted authentication. In aggressive mode, they use three messages and unencrypted authentication.

When the peers come to an agreement, each has a common IKE SA policy for setting up the phase 1 tunnel and a Security Parameter Index (SPI), the unique identifier for each tunnel. The peers then perform a Diffie-Hellman (DH) key exchange and locally generate the shared secret key.

Peer authentication: The peers then authenticate each other using the authentication type you've specified in IPsec connections.

The local and remote interfaces or gateways you've specified authenticate each other using one of the following options based on the connection type:

  • IPsec connections: Preshared key, digital certificate, or RSA key.

    Additionally, you can use local and remote IDs, such as DNS name, IP address, or email address, for the peers to authenticate each other if you use preshared or RSA keys. If you use digital certificates, you can use DER ASN1 DN (x.509) for the local and remote IDs.

  • L2TP (remote access): Preshared key or digital certificate. IKEv2 isn't available for L2TP tunnels.

You can specify the tunnel's local and remote peers, peer authentication mechanism, and additional authentication parameters, such as local and remote IDs, on IPsec connections and L2TP (remote access).

The phase 1 negotiation is complete with the peers authenticating each other, and the firewalls establish a two-way phase 1 tunnel between the peers. The firewalls use the phase 1 tunnel to negotiate the phase 2 parameters. If phase 1 negotiations fail, the firewalls can't negotiate phase 2 parameters.

Phase 2 parameters

Sophos Firewall uses ESP (Encapsulating Security Payload) protocol in tunnel mode, offering data integrity and data origin authentication, and anti-replay service.

IPsec SAs: The firewalls use the phase 1 tunnel to negotiate phase 2 SAs, including the encryption algorithm, authentication algorithm, key life, and optionally, DH key exchange with Perfect Forward Secrecy (PFS). When the peers agree on these parameters, they establish an IPsec SA, identifying it with a local SPI, the unique identifier.

Perfect Forward Secrecy: You can use PFS to generate new shared secret keys for the phase 2 tunnels.

Traffic selectors: If the traffic selectors, that is, the subnets or hosts (example: servers), match on both firewalls, the firewalls establish a tunnel between each subnet pair (or host pair). Phase 2 SAs encrypt and authenticate the data traffic between the corresponding hosts and subnets.

Since phase 2 SAs and tunnels are established between each subnet and host pair, their number is a multiple of the local and remote subnets (or hosts) you specify. See the following example:

Local subnets: Subnet L1 and subnet L2

Remote subnets: Subnet R3 and subnet R4

In this example, the firewalls establish the following four phase 2 tunnels:

  • L1 to R3
  • L1 to R4
  • L2 to R3
  • L2 to R4

Incoming packets are then decapsulated and decrypted. After the matching firewall rule applies the security policies, traffic is sent to the destination. Outgoing packets are encapsulated and encrypted after applying the matching firewall rule.

XAuth: Additionally, you can specify user and group authentication using XAuth (Extended Authentication) if you configure the VPN in client-server mode. You can configure the firewall in the central location in server mode. XAuth uses your current authentication mechanism, such as AD, RADIUS, or LDAP, to authenticate users after the phase 1 exchange. You then configure the remote firewall in client mode with a username and password to authenticate with the firewall that's in server mode.

You can select the traffic selectors and XAuth settings on IPsec connections and L2TP (remote access).

Encryption, authentication, shared secret, and key life

Encryption: You can use encryption algorithms, such as AES. These are symmetric keys, encrypting and decrypting packet data.

Authentication: You can use authentication algorithms, such as SHA2 to authenticate data, that is, ensure its integrity. Sophos Firewall uses HMAC (Hash-based Message Authentication Code), using the authentication algorithm to compute a hash value based on the packets and the shared secret key. It sends the hash value with the packets. The remote firewall recalculates the hash value from the message and its shared secret key to confirm that the hash values are identical.

You can select a combination of up to three encryption and authentication algorithms to make sure you have a common set. Sophos Firewall uses the most secure combination to negotiate with the remote firewall.

Diffie-Hellman: DH key exchange enables the firewalls to securely exchange the symmetric key over an insecure channel, such as the internet. Each firewall generates a public-private key pair and shares the public key with the remote firewall over the insecure channel. Each firewall then privately computes a common shared secret based on the local private key and the remote firewall's public key. The private keys and the shared secret key aren't exchanged. The firewalls use the shared secret key to derive the symmetric key independently.

Perfect Forward Secrecy: PFS derives the phase 2 keys independent from the phase 1 keys. When you specify PFS, the firewalls generate a new key for each phase 2 tunnel with a new DH key exchange for each. Alternatively, you can use the phase 1 DH groups to generate a new key or choose not to use a new DH key exchange for phase 2. If you don't select a DH group, the firewalls use the phase 1 secret key for phase 2 exchanges. PFS is the most secure, generating an independent shared key with a different DH group from the phase 1 group for each phase 2 tunnel.

Tip

Hardware acceleration, which accelerates and compresses cryptographic workloads, is available for IPsec VPN connections on XG 125 Rev.3, XG 135 Rev.3, and XG 750 appliance models. It's turned on by default. To turn it off, go to the command-line console.

Key life: You can allow the firewalls to start the negotiation process automatically before the current shared secret key expires. Either of the firewalls can start the renegotiation. If you turn off rekeying on the local firewall, it can still respond to a rekeying request from the remote firewall. If you turn it off on both, the connection uses the same key during its lifetime.

The key life and rekey settings you specify in phase 1 are also used for phase 2 rekeying. Depending on PFS, the negotiation uses the regenerated phase 1 key or generates a new key for phase 2.

You can specify the maximum number of retries if a key exchange doesn't succeed. Alternatively, you can choose not to have any retries.

Tip

Sophos Firewall supports only time-based rekeying. To configure an IPsec connection between Sophos Firewall and a third-party firewall, select time-based rekeying on the third-party firewall.

More resources

Back to top