16.3.1. Procedure – Configuring IPSec connections

1. Navigate to the VPN component of the Zorp host that will be the endpoint of the VPN connection. Select the Connections tab.

   

   Figure 16.4. Configuring IPSec connections

2. Click New and enter a name for the connection.

3. Select the IPSec protocol option.

4. Set the VPN topology and the transport mode in the Scenario section on the General tab.

   • To create a Peer-to-Peer connection, select the Peer to Peer and the Transport options.

   • To create a Peer-to-Network connection, select the Peer to Peer and the Tunnel options.

   • To create a Roadwarrior server, select the Roadwarrior server and the Transport options.

   • To create a Network-to-Network connection, select the Peer to Peer and the Tunnel options.

   Note
   When creating a Network-to-Network connection, the two endpoints of the VPN tunnel do NOT use the VPN to communicate with each other. To encrypt the communication of the endpoints, create a separate Peer-to-Peer connection.

   

   Figure 16.5. Selecting the IPSec scenario

5. Configure the local networking parameters.

   These parameters affect the Zorp endpoint of the VPN connection. Set the following parameters:

   • Local address: Select the IP address that Zorp will use for the VPN connection.

   • Local ID: It is the ID of the Zorp endpoint in the VPN connection. Leave this field blank unless there are difficulties in establishing the connection with the remote VPN application. If the Local ID is set, the Use ID in ipsec.secrets option might also need to be set.

   • Local subnet: It is the subnet behind Zorp that will be accessible using the VPN tunnel. This option is available only for Peer-to-Network and Network-to-Network connections.

   

   Figure 16.6. Configuring local networking parameters

6. Configure the networking parameters of the remote endpoint. Set the following parameters:

   • Remote address: It is the IP address of the remote endpoint. It does not apply for roadwarrior VPNs.

   • Remote ID: It is the ID of the remote endpoint in the VPN connection. Leave this field blank unless there are difficulties in establishing the connection with the remote VPN application. If the Remote ID is set the Use ID in ipsec.secrets option might also need to be set.

   • Remote subnet: It is the subnet behind the remote endpoint that will be accessible using the VPN tunnel. This option is available only for Peer-to-Network and Network-to-Network connections.

     Note
     Network-to-Network connections connect the subnets specified in the Local subnet and Remote subnet parameters. Do not specify the subnet parameter for the peer side of Peer-to-Network connections, leave either the Local subnet or the Remote subnet parameter empty.

   

   Figure 16.7. Configuring remote networking parameters

7. When configuring Peer-to-Peer or Network-to-Network connections, it is crucial that the endpoint operators cooperate. If the Active side option is selected, Zorp opens the VPN connection to the remote endpoint. It is possible to enable the Active side option on both sides, but if the tunnel is unstable, it is recommended to enable it only on one side.

8. Click on the Authentication tab and configure authentication.

   

   Figure 16.8. Configuring authentication

   To use password-based authentication, select the Shared secret option and enter the password in the Secret field.

   Note
   Authentication using a shared secret is not a secure authentication method. Use it only if the remote endpoint does not support certificate-based authentication. Always use long and complicated shared secrets: at least twelve characters containing a mix of alphanumerical and special characters. Remember to change the shared secret regularly.

   To use certificate-based authentication, select the X.509 option and set the following parameters:

   • Local certificate: Select a certificate available on the Zorp host. Zorp will show this certificate to the remote endpoint.

   • If the remote endpoint has a specific certificate, select the Verify certificate option and select the certificate from the Remote certificate field. Zorp will use this certificate to verify the certificate of the remote endpoint.

   • If there are several remote endpoints that can connect to the VPN tunnel, select the Verify trust option and select the trusted Certificate Authority (CA) group containing the CA certificate of the CA that issued the certificates of the remote endpoints from the CA group field. Zorp will use this trusted CA group to verify the certificates of the remote endpoints. (See Section 11.3.7, Trusted CAs for details.)

     Zorp sends the common name of the accepted CAs to the remote endpoint, so the client knows what kind of certificate is required for the authentication. Select a specific CA certificate using the CA hint option if only certificates signed by the selected CA are required to be accepted.

   Note
   See Chapter 11, Key and certificate management in Zorp for details on creating and importing certificates, CAs, and trusted CA groups required for certificate-based authentication.

9. Before setting the action status of the Dead Peer Detection option, it is necessary that the two endpoint operators agree on the preferred settings. If earlier the Active side option was selected for Zorp, it is recommended to select the restart option of Action parameter. This way Zorp attempts to restart the VPN connection if the remote endpoint becomes unavailable.

   If Zorp is on the passive side and earlier the Active side option was not enabled, it is recommended to set the Action parameter of the Dead Peer Detection to hold for Zorp and set this parameter to restart on the remote endpoint.

   Note
   Dead Peer Detection is effective only if enabled on both endpoints of the VPN connection. If Dead Peer Detection is enabled only on one side, and it is disabled on the other side it may lead to unreliable VPN connection. If Dead Peer Detection is not required, it must be disabled at both endpoints.

   

   Figure 16.9. Configuring IPSec options

   The following additional parameters can be configured for Dead Peer Detection:

   • Delay

     This parameter defines the time interval in which informal messages are sent to the peer.

   • Timeout

     This parameter defines the timeout interval after which all connections to a peer are deleted in case of inactivity.

   • Action

     This parameter controls the usage of Dead Peer Detection protocol, where informal messages are periodically sent to check whether the connection toward the IPSec peer is live or not.

     The available values are: clear, restart and none.

     The values clear, hold and restart activate Dead Peer Detection and instruct on the action to be taken in case of timeout.

     If the parameter is set to clear, the connection shall be closed without any further action taken.

     If the parameter is set to hold, matching traffic will be searched for and renegotiation on the connection will be tried.

     If the parameter is set to restart, an immediate attempt will take place for renegotiating the connection.

     If the parameter is set to none, no more Dead Peer Detection messages will be sent to the peer.

10. Set other options if needed. See Section 16.3.2, IPSec options for details.

    Note
    By default, Zorp 3 F5 and later versions use the IKEv2 key exchange protocol. However, earlier versions support only the IKEv1 protocol. Change the Options > Exchange protocol option to IKEv1 when the remote endpoint of the VPN connection is running Zorp 3.4 LTS or earlier.

11. Configure the parameters of the Keying tab, if necessary.

    

    Figure 16.10. Keying tab parameters

    • Encapsulating Security Payload (ESP)

      This list presents the Encapsulating Security Payload (ESP) encryption and authentication algorithms that shall be used for the actual connection.

      If the DH group is also specified, it defines that Diffe-Hellman (DH) exchange shall be included in re-keying or in initial negotiation.

      The ESN parameter defines whether Extended Sequence Number (ESN) support with the peer is enabled or not. The default value is 'no'.

    • Internet Key Exchange (IKE)

      This list presents the Internet Key Exchange (IKE) encryption and authentication algorithms that shall be used for the actual connection.

      If the DH group is also specified, it defines that Diffe-Hellman exchange shall be included in re-keying or in initial negotiation.

      If no Pseudo Random Function (PRF) algorithm is configured, the algorithms defined for integrity are proposed as PRF.