Policies
On the IPsec > Policies tab you can customize parameters for IPsec Internet Protocol Security connections and unite them into a policy. An IPsec policy defines IKE (Internet Key Exchange) and IPsec proposal parameters of an IPsec connection. Note that each IPsec connection needs an IPsec policy.
Note – Sophos UTM only supports the main mode in IKE phase 1. The aggressive mode is not supported.
To create an IPsec policy, proceed as follows:
-
On the Policy tab, click New IPsec Policy.
The Add IPsec Policy dialog box opens.
-
Specify the following settings:
Name: Enter a descriptive name for this policy.
IKE encryption algorithm: The encryption algorithm specifies the algorithm used for encrypting the IKE messages. Supported algorithms are:
- DES (56 bit)
- 3DES (168 bit)
- AES 128 (128 bit)
- AES 192 (192 bit)
- AES 256 (256 bit)
- Blowfish (128 bit)
- Twofish (128 bit)
- Serpent (128 bit)
Security Note – We strongly recommend to use AES and SHA2 256 to reduce potential vulnerability.
IKE authentication algorithm: The authentication algorithm specifies the algorithm used for integrity checking of the IKE messages. Supported algorithms are:
- MD5 (128 bit)
- SHA1 (160 bit)
- SHA2 256 (256 bit)
- SHA2 384 (384 bit)
- SHA2 512 (512 bit)
IKE SA lifetime: This value specifies the timeframe in seconds for which the IKE SA (security association) is valid and when the next rekeying should take place. Valid values are between 60 sec and 28800 sec (8 hrs). The default value is 7800 seconds.
IKE DH group: When negotiating a connection, the communicating parties also settle the actual keys used to encrypt the data. In order to generate a session key, IKE uses the Diffie-Hellman (DH) algorithm, which utilizes random data. The random data generation is based on pool bits. The IKE group basically tells the number of pool bits. The more pool bits, the larger the random numbers. The larger the numbers, the harder it is to crack the Diffie-Hellman algorithm. As a consequence, more pool bits mean more security but also the consumption of more CPU resources. Currently, the following Diffie-Hellman groups are supported:
- Group 1: MODP 768
- Group 2: MODP 1024
- Group 5: MODP 1536
- Group 14: MODP 2048
- Group 15: MODP 3072
- Group 16: MODP 4096
Security Note – Group 1 (MODP 768) is considered weak and only supported for interoperability reasons. We strongly recommend against using it, as it represents a potential vulnerability.
IPsec encryption algorithm: The same encryption algorithms as for IKE. Additionally there are the following entries:
- No encryption (null)
- AES 128 CTR (128 bit)
- AES 192 CTR (192 bit)
- AES 256 CTR (256 bit)
- AES 128 GCM (96 bit)
- AES 192 GCM (96 bit)
- AES 256 GCM (96 bit)
- AES 128 GCM (128 bit)
- AES 192 GCM (128 bit)
- AES 256 GCM (128 bit)
Security Note – We strongly recommend against using no encryption or DES, as this represents a potential vulnerability.
IPsec authentication algorithm: The same authentication algorithms as for IKE. Additionally there are the following algorithms:
- SHA2 256 (96 bit)
- SHA2 384 (96 bit)
- SHA2 512 (96 bit)
Those are available for compliance with tunnel endpoints not adhering to RFC 4868, for example UTM (i.e., ASG) versions older than V8, and therefore do not support truncated checksums longer than 96 bit.
IPsec SA lifetime: This value specifies the timeframe in seconds for which the IPsec SA is valid and when the next rekeying should take place. Valid values are between 60 sec and 86400 sec (1 day). The default value is 3600 seconds.
IPsec PFS group:Perfect Forward Secrecy (PFS) refers to the notion that if a session key is compromised, it will permit access only to data of this specific session. In order for PFS to exist, the key used to protect the IPsec SA must not be derived from random keying material used to get the keys for the IKE SA. Therefore, PFS initiates a second Diffie-Hellman key exchange proposing the selected DH group for the IPsec connection to get a new randomly generated key. Supported Diffie-Hellman groups are the same as for IKE.
Enabling PFS is considered to be more secure, but it takes also more time for the exchange. It is not recommended to use PFS on slow hardware.
Note – PFS is not fully interoperable with all vendors. If you notice problems during the negotiation, you might consider disabling PFS.
Strict policy: If an IPsec gateway makes a proposition with respect to an encryption algorithm and to the strength, it might happen that the gateway of the receiver accepts this proposition, even though the IPsec policy does not correspond to it. If you select this option and the remote endpoint does not agree on using exactly the parameters you specified, the IPsec connection will not be established. Suppose the IPsec policy of your Sophos UTM requires AES-256 encryption, whereas, for example, a road warrior with SSH Sentinel wants to connect with AES-128; with the strict policy option enabled, the connection would be rejected.
Note – The compression setting will not be enforced via Strict policy.
Compression: This option specifies whether IP packets should be compressed by means of the IP Payload Compression Protocol (IPComp) prior to encryption. IPComp reduces the size of IP packets by compressing them to increase the overall communication performance between a pair of communicating hosts or gateways. Compression is turned off by default.
Comment (optional): Add a description or other information.
-
Click Save.
To either edit or delete a policy, click the corresponding buttons.