Phone Lines icon GFI Support Home

Articles in this section

See more

Configuring IPsec VPN Tunnel

Author: Vladyslav Velychko Updated

Overview

Kerio IPsec VPN tunnel allows the administrator to connect users located in separate geographic areas into a single network. Kerio Control allows configuring the IPSec tunnel with 3rd-party remote endpoints, services, or firewalls, such as Cisco, Mikrotik, etc.

Kerio IPsec VPN tunnel offers authentication and encryption to ensure a fast and secure connection.

Note: To connect two or more Kerio Controls via a VPN tunnel, use Kerio VPN. Unlike the Kerio IPsec VPN tunnel, the Kerio VPN tunnel is able to seek routes in remote networks automatically.

Warning: Kerio Control does not support OpenVPN and SOCKS5 protocols for VPN. Additionally, please note that aggressive mode is not supported. You can see further details about the supported features in Establishing IPSec VPN tunnel with another firewall

Prerequisites

  • Enable the VPN Services pre-configured traffic rule on both tunnel endpoints.

    075.png

  • The ID of the remote endpoint. In most of the servers, it is called Local ID.

  • A list of all routes behind the remote endpoint.

  • If you want to use an SSL certificate, prepare the SSL certificate of the remote endpoint, or an authority + ID of the remote SSL certificate. You must import the certificate or the authority to Kerio Control.

 

Solution

 

Configuring Authentication Method

 You can select one of the following methods:

 Pre Shared Key Authentication

 This method is easy to set up. Both endpoints use the same password for authentication:

  1. In the administration interface, go to Interfaces.

  2. Click Add > VPN Tunnel.

    076.png

  3. Type the name of the new tunnel.

  4. Set the tunnel as active and type the hostname of the remote endpoint. At least one endpoint must be set as active. The active endpoint establishes and maintains a connection to the passive endpoint.

  5. Select Type: IPsec.

  6. Select the Preshared key and type the key.

  7. Copy the value of the Local ID field from Kerio Control to the Remote ID of the remote endpoint and vice versa. Predefined Local ID is the hostname of Kerio Control. If you change the Kerio Control hostname, the Local ID is changed too.

    077.png

  8. (Optionally) In Phase 1 and Phase 2 cipher, click Change and configure the ciphers manually. This may be required if you want to connect Kerio Control with the third party firewall. For details, see Configuring IKE ciphers.

  9. On tabs Remote Networks and Local Networks, you must define all remote networks, including subnet for VPN clients and all local networks which are not detected by Kerio Control.

  10. Save the settings.

 SSL Certificate Authentication

 Authentication with an SSL certificate requires a valid SSL certificate on both endpoints.

 When the SSL certificate/Authority is imported, follow these instructions:

  1. In the administration interface, go to Interfaces.

  2. Click Add > VPN Tunnel.

  3. Type the name of the new tunnel.

  4. Set the tunnel as active and type the hostname of the remote endpoint. At least one endpoint must be set as active. The active endpoint establishes and maintains a connection to the passive endpoint.

  5. Select Type: IPsec.

  6. Select Remote certificate:

    • Not in the local store — only the authority was imported to Kerio Control. Copy the remote SSL certificate ID to the Remote ID field and vice versa: import the Kerio Control authority to the remote endpoint and copy the Local ID somewhere in the remote endpoint.

    • Select the remote SSL certificate. Export the certificate from Kerio Control and import it to the remote endpoint.

  7. (Optionally) In Phase 1 and Phase 2 cipher, click Change and configure ciphers manually. This may be required if you want to connect Kerio Control with the third party firewall. For details, see Configuring IKE ciphers.

  8. Save the settings.

Back to Top

 

Configuring Ciphers in Key Exchange (IKE)

NOTE: New in Kerio Control 9.2!

Kerio Control can use several IKE ciphers during the connecting and authorizing process of the IPsec tunnel. In many cases, these ciphers are common between the endpoints, and no custom configuration is necessary.

In other cases, you may need to assign custom ciphers. Therefore, you can configure IKE ciphers in Kerio Control manually:

Configuring Authentication

  1. In the administration interface, go to Interfaces.

  2. Select the IPsec VPN tunnel and click Edit.

  3. In the VPN Tunnel Properties dialog box, click Change on the Authentication tab.

    img18-mod.png

  4. In the VPN Tunnel Ciphers Configuration, select Custom ciphers.

  5. In drop-down menus, change ciphers in the same way as they are set in the other firewall or device.

    079.png

  6. Click OK twice. The interface node will be showing a new VPN connection.

    080.png

  7. Both endpoints should connect successfully, and you can verify it in the Interfaces section. The IPsec tunnel is Up. For more information, refer to IPSec VPN Tunnel Configuration With Another Device.

Configuring Local Networks

Kerio Control IPsec tunnel can detect most of its local networks. To enable automatic detection:

  1. In the administration interface, go to Interfaces.

  2. Select the IPsec VPN tunnel and click Edit.

  3. In the VPN Tunnel Properties dialog box, select Use automatically determined local networks. Automatically determined local networks are:

    • All non-internet interfaces networks with no default route.

    • Static networks.

    • Remote networks of other IPsec tunnels.

    • Manually specified custom remote networks of Kerio VPN tunnels.

    • VPN subnet.

  4. If you define custom routes, select Use custom networks too.

    NOTE: To set up Kerio VPN — IPsec VPN interoperability, also add networks connected via Kerio Control VPN, which are not defined manually in the Kerio VPN tunnel configuration.
  5. Click OK.

    081.png

Networks from the following interfaces are not detected automatically:

  • Interfaces from the Internet Interfaces group
  • Interfaces with a default route
  • Networks dynamically discovered by Kerio VPN

Configuring Remote Networks

IPsec VPN is not able to seek remote routes. You must enter them manually. For more information refer to Connecting Multiple Offices Via Kerio VPN And IPsec Tunnels

Back to Top

 

Configuring VPN Failover

If Kerio Control is being used for load balancing between multiple Internet links, it is possible to use a VPN failover. This ensures that a VPN tunnel is re-established automatically in case the primary link used for VPN tunneling becomes unavailable.

To configure failover:

  1. In the administration interface, go to Interfaces.

  2. Select the IPsec VPN tunnel and click Edit.

    082.png

  3. Input all remote endpoints (by hostname or IP address), separated by semicolons, into the VPN tunnel properties.

NOTE: When attempting to establish the tunnel, Kerio Control cycles through the list of the endpoints in the same order that they are listed in the VPN Tunnel Properties.

Back to Top

 

Confirmation

IPsec Tunnel is successfully established between two firewalls. IPsec Debug logs are showing a similar output:

[30/Oct/2019 13:48:10] {charon} charon: 05[IKE] initiating Main Mode IKE_SA tunnel_2_1_1_1[42] to 192.168.2.146
[30/Oct/2019 13:48:10] {charon} charon: 05[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536
[30/Oct/2019 13:48:10] {charon} charon: 05[ENC] generating ID_PROT request 0 [ SA V V V V V ]
[30/Oct/2019 13:48:10] {charon} charon: 05[NET] sending packet: from 192.168.2.113[500] to 192.168.2.146[500] (180 bytes)
[30/Oct/2019 13:48:10] {charon} charon: 14[NET] received packet: from 192.168.2.146[500] to 192.168.2.113[500] (160 bytes)
[30/Oct/2019 13:48:10] {charon} charon: 14[ENC] parsed ID_PROT response 0 [ SA V V V V ]
[30/Oct/2019 13:48:10] {charon} charon: 14[IKE] received XAuth vendor ID
[30/Oct/2019 13:48:10] {charon} charon: 14[IKE] received DPD vendor ID
[30/Oct/2019 13:48:10] {charon} charon: 14[IKE] received FRAGMENTATION vendor ID
[30/Oct/2019 13:48:10] {charon} charon: 14[IKE] received NAT-T (RFC 3947) vendor ID
[30/Oct/2019 13:48:10] {charon} charon: 14[CFG] selecting proposal:
[30/Oct/2019 13:48:10] {charon} charon: 14[CFG]   proposal matches
[30/Oct/2019 13:48:10] {charon} charon: 14[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536
[30/Oct/2019 13:48:10] {charon} charon: 14[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536
[30/Oct/2019 13:48:10] {charon} charon: 14[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536
[30/Oct/2019 13:48:10] {charon} charon: 14[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
[30/Oct/2019 13:48:10] {charon} charon: 14[NET] sending packet: from 192.168.2.113[500] to 192.168.2.146[500] (332 bytes)
[30/Oct/2019 13:48:10] {charon} charon: 06[NET] received packet: from 192.168.2.146[500] to 192.168.2.113[500] (332 bytes)
[30/Oct/2019 13:48:10] {charon} charon: 06[ENC] parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
[30/Oct/2019 13:48:10] {charon} charon: 06[ENC] generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
[30/Oct/2019 13:48:10] {charon} charon: 06[NET] sending packet: from 192.168.2.113[500] to 192.168.2.146[500] (108 bytes)
[30/Oct/2019 13:48:10] {charon} charon: 13[NET] received packet: from 192.168.2.146[500] to 192.168.2.113[500] (92 bytes)
[30/Oct/2019 13:48:10] {charon} charon: 13[ENC] parsed ID_PROT response 0 [ ID HASH ]
[30/Oct/2019 13:48:10] {charon} charon: 13[IKE] IKE_SA tunnel_2_1_1_1[42] established between 192.168.2.113[control]...192.168.2.146[control]
[30/Oct/2019 13:48:10] {charon} charon: 13[IKE] scheduling reauthentication in 9973s
[30/Oct/2019 13:48:10] {charon} charon: 13[IKE] maximum IKE_SA lifetime 10513s
[30/Oct/2019 13:48:10] {charon} charon: 13[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1536/NO_EXT_SEQ
[30/Oct/2019 13:48:10] {charon} charon: 13[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1536/NO_EXT_SEQ
[30/Oct/2019 13:48:10] {charon} charon: 13[CFG] proposing traffic selectors for us:
[30/Oct/2019 13:48:10] {charon} charon: 13[CFG]  10.10.11.0/24
[30/Oct/2019 13:48:10] {charon} charon: 13[CFG] proposing traffic selectors for other:
[30/Oct/2019 13:48:10] {charon} charon: 13[CFG]  192.168.100.0/24
[30/Oct/2019 13:48:10] {charon} charon: 13[ENC] generating QUICK_MODE request 2605570284 [ HASH SA No KE ID ID ]
[30/Oct/2019 13:48:10] {charon} charon: 13[NET] sending packet: from 192.168.2.113[500] to 192.168.2.146[500] (396 bytes)
[30/Oct/2019 13:48:10] {charon} charon: 03[NET] received packet: from 192.168.2.146[500] to 192.168.2.113[500] (396 bytes)
[30/Oct/2019 13:48:10] {charon} charon: 03[ENC] parsed QUICK_MODE response 2605570284 [ HASH SA No KE ID ID ]
[30/Oct/2019 13:48:10] {charon} charon: 03[CFG] selecting proposal:
[30/Oct/2019 13:48:10] {charon} charon: 03[CFG]   proposal matches
[30/Oct/2019 13:48:10] {charon} charon: 03[CFG] received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1536/NO_EXT_SEQ
[30/Oct/2019 13:48:10] {charon} charon: 03[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1536/NO_EXT_SEQ
[30/Oct/2019 13:48:10] {charon} charon: 03[CFG] selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1536/NO_EXT_SEQ
[30/Oct/2019 13:48:10] {charon} charon: 03[IKE] CHILD_SA tunnel_2_1_1_1{109} established with SPIs c2532c8a_i cb758146_o and TS 10.10.11.0/24 === 192.168.100.0/24
[30/Oct/2019 13:48:11] {IPsec} reqIdUp: reqId=17, tunnelId=2 (Right subnet: 192.168.100.0/255.255.255.0 via 2)
[30/Oct/2019 13:48:11] {IPsec} Registering new route 192.168.100.0/255.255.255.0 for tunnel VPN to 146
[30/Oct/2019 13:48:11] {IPsec} Touching route 192.168.100.0/255.255.255.0 (via dev: 2)
[30/Oct/2019 13:48:11] {IPsec} Tunnel 2:VPN to 146 is up
[30/Oct/2019 13:48:11] {IPsec} Connection info read from kernel: 192.168.2.113 === 192.168.2.146 (proto 50)
[30/Oct/2019 13:48:11] {IPsec} Register tunnel VPN to 146

 

Back to Top

Was this article helpful?
0 out of 0 found this helpful

Related articles