Add Policy

This screen helps you in creating IPsec Policies.

Add Policy

The following information are required to create an IPsec Policy.

● Policy Name: A unique name to identify the policy.

● Allow Re-keying: whether a connection should be renegotiated when it is about to expire; acceptable values are yes (the default) and no. The two ends need not agree, but while a value of no prevents renegotiation, it does not prevent responding to renegotiation requested from the other end, so no will be largely ineffective unless both ends agree on it.

● Pass Data in Compressed Format: whether compression of content is desired on the connection (link-level compression does not work on encrypted data, so to be effective, compression must be done before encryption); acceptable values are yes and no (the default). The two ends need not agree. A value of no is absolute: IPsec will neither propose nor accept compression. A value of yes causes IPsec to propose both compressed and uncompressed, and prefer compressed.

● PFS: If Perfect Forward secrecy is enabled the system uses single-use unique keys for key exchange. If Perfect Forward Secrecy is disabled, there would be a single secret key from which all the symmetric keys are derived. Note: PFS enhances the IPsec security but at the cost of more CPU processing and utilisation.

● Encryption Algorithm : Encryption Algorithm and Hashing Algorithm pair. Encryption Algorithm specifies the algorithm for encrypting the IPsec Tunnel and Hashing algorithm specifies the algorithm used to check the authenticity of IPsec Tunnel.

Supported Encryption Algorithms are:

● 3DES (168 bit)

● AES (128, 192, 256 bits)

● TwoFish (128 bit)

● BlowFish (128 bit)

● Serpent (128bit)

Supported Hashing Algorithm are:

● MD5 (128 bit)

● SHA1 (160 bit)

● DH Group: The Diffie-Hellman key exchange group. The Diffie-Hellman exchange allows an insecure channel to become secure. All participants in a Diffie-Hellman exchange must first agree on a group that defines the encryption strength.

Supported Diffie-Hellman Groups are:

● DH Group 1 : MODP768

● DH Group 2 : MODP1024

● DH Group 5 : MODP1536

● DH Group 14: MODP2048

● DH Group 15: MODP3072

● DH Group 16: MODP4096

● keylife : how long a particular instance of a connection (a set of encryption/authentication keys for user packets) should last, from successful negotiation to expiry; acceptable values are seconds. Normally, the connection is renegotiated (via the keying channel) before it expires. The two ends need not exactly agree on keylife, although if they do not, there will be some clutter of superseded connections on the end which thinks the lifetime is longer.

● rekeymargin : how long before connection expiry or keying-channel expiry should attempts to negotiate a replacement begin; acceptable values as for keylife are seconds. Relevant only locally, other end need not agree on it.

● Randomize Re-Keying Margin By: maximum percentage by which rekeymargin should be randomly increased to randomize rekeying intervals (important for hosts with many connections); acceptable values are an integer, which may exceed 100. The value of rekeymargin, after this random increase, must not exceed keylife. The value 0% will suppress time randomization. Relevant only locally, other end need not agree on it.

● Enable Dead Peer Detection: This option is used for automatically terminating a connection if the remote VPN gateway or client is unreachable. For connections with static endpoints, the tunnel will be re-negotiated automatically. Connections with dynamic endpoints always enable this option. The IPsec peers automatically determine whether the remote side supports Dead Peer Detection or not, and will fall back to normal mode if necessary.

On this screen you can set advanced properties of the IPsec Module, This should only be used by experienced users.

Settings of phase 2 is similar to that of phase 1, the only difference being PFS Group which are again Diffie-Hellman Phase 2 key exchange groups.