23.6 Example of a more complex Kerio VPN configuration
Prev | Chapter 23 Kerio VPN | Next

## 23.6 Example of a more complex Kerio VPN configuration

In this chapter, an example of a more complex VPN configuration is provided where redundant routes arise between interconnected private networks (i.e. multiple routes exist between two networks that can be used for transfer of packets).

The only difference of Kerio VPN configuration between this type and VPN with no redundant routes (see chapter 23.5 Example of Kerio VPN configuration: company with a filial office) is setting of routing between endpoints of individual tunnels. In such a case, it is necessary to set routing between individual endpoints of VPN tunnels by hand. Automatic route exchange is inconvenient since Kerio VPN uses no routing protocol and the route exchange is based on comparison of routing tables at individual endpoints of the VPN tunnel (see also chapter 23.4 Exchange of routing information). If the automatic exchange is applied, the routing will not be ideal!

For better reference, the configuration is here described by an example of a company with a headquarters and two filial offices with their local private network interconnected by VPN tunnels (so called triangle pattern). This example can be then adapted and applied to any number of interconnected private networks.

The example focuses configuration of VPN tunnels and correct setting of routing between individual private networks (it does not include access restrictions). Access restrictions options within VPN are described by the example in chapter 23.5 Example of Kerio VPN configuration: company with a filial office.

### Specification

The network follows the pattern shown in figure 23.30 Example of a VPN configuration — a company with two filials.

Figure 23.30. Example of a VPN configuration — a company with two filials

The server (default gateway) uses the fixed IP address `63.55.21.12` (DNS name is `gw-newyork.company.com`). The server of one filial uses the IP address `115.95.27.55` (DNS name `gw-london.company.com`), the other filial's server uses a dynamic IP address assigned by the ISP.

The headquarters uses the DNS domain `company.com`, filials use subdomains `santaclara.company.com` and `newyork.company.com`. Configuration of individual local networks and the IP addresses used are shown in the figure.

### Common method

The following actions must be taken in all local networks (i.e. in the main office and both filials):

1. WinRoute in version `6.1.0` or higher must be installed at the default gateway. Older versions do not allow setting of routing for VPN tunnels. Therefore, they cannot be used for this VPN configuration (see figure 23.30 Example of a VPN configuration — a company with two filials).

   Note: For each installation of WinRoute, a separate license for corresponding number of users is required! For details see chapter 4 Product Registration and Licensing.

2. Configure and test connection of the local network to the Internet. Hosts in the local network must use the WinRoute host's IP address as the default gateway and as the primary DNS server.

   If it is a new (clean) WinRoute installation, it is possible to use the traffic rule wizard (refer to chapter 7.1 Network Rules Wizard).

   For detailed description of basic configuration of WinRoute and of the local network, refer to the Kerio WinRoute Firewall — Step By Step document.

3. In configuration of the DNS module, set DNS forwarding rules for domains of the other filials. This enables to access hosts in the remote networks by using their DNS names (otherwise, it is necessary to specify remote hosts by IP addresses).

   To provide correct forwarding of DNS requests from a WinRoute host, it is necessary to use an IP address of a network device belonging to the host as the primary DNS server. As a secondary DNS server, a server where DNS requests addressed to other domains will be forwarded must be specified (typically the ISP's DNS server).

   Note: For proper functionality of DNS, the DNS database must include records for hosts in a corresponding local network. To achieve this, save DNS names and IP addresses of local hosts into the `hosts` file (if they use IP addresses) or enable cooperation of the DNS module with the DHCP server (in case that IP addresses are assigned dynamically to these hosts). For details, see chapter 8.1 DNS module.

4. In the Interfaces section, allow the VPN server and set its SSL certificate if necessary. Note the fingerprint of the server's certificate for later use (it will be required for configuration of the VPN tunnels in the other filials).

   Check whether the automatically selected VPN subnet does not collide with any local subnet in any filial and select another free subnet if necessary.

   Note: With respect to the complexity of this VPN configuration, it is recommended to reserve three free subnets in advance that can later be assigned to individual VPN servers.

5. Define the VPN tunnel to one of the remote networks. The passive endpoint of the tunnel must be created at a server with fixed public IP address. Only active endpoints of VPN tunnels can be created at servers with dynamic IP address.

   Set routing (define custom routes) for the tunnel. Select the Use custom routes only option and specify all subnets of the remote network in the custom routes list.

   If the remote endpoint of the tunnel has already been defined, check whether the tunnel was created. If not, refer to the Error log, check fingerprints of the certificates and also availability of the remote server.

6. Follow the same method to define a tunnel and set routing to the other remote network.

7. Allow traffic between the local and the remote networks. To allow any traffic, just add the created VPN tunnels to the Source and Destination items in the Local traffic rule. Access restrictions options within VPN are described by the example in chapter 23.5 Example of Kerio VPN configuration: company with a filial office.

8. Test reachability of remote hosts in both remote networks. To perform the test, use the `ping` and `tracert` system commands. Test availability of remote hosts both through IP addresses and DNS names.

   If a remote host is tested through IP address and it does not respond, check configuration of the traffic rules or/and find out whether the subnets do not collide (i.e. whether the same subnet is not used at both ends of the tunnel).

   If an IP address is tested successfully and an error is reported (Unknown host) when a corresponding DNS name is tested, then check configuration of the DNS.

The following sections provide detailed description of the Kerio VPN configuration both for the headquarter and the filial offices.

### Headquarters configuration

1. Install WinRoute (version `6.1.0` or higher) at the default gateway of the headquarters network.

2. Use Network Rules Wizard (see chapter 7.1 Network Rules Wizard) to configure the basic traffic policy in WinRoute. To keep the example as simple as possible, it is supposed that the access from the local network to the Internet is not restricted, i.e. that access to all services is allowed in step 4.

   Figure 23.31. Headquarters — no restrictions are applied to accessing the Internet from the LAN

   In step 5, select Create rules for Kerio VPN server. Status of the Create rules for Kerio Clientless SSL-VPN option is irrelevant (this example does not include Clientless SSL-VPN interface's issues).

   Figure 23.32. Headquarter — creating default traffic rules for Kerio VPN

   This step will create rules for connection of the VPN server as well as for communication of VPN clients with the local network (through the firewall).

   Figure 23.33. Headquarter — default traffic rules for Kerio VPN

3. Customize DNS configuration as follows:

   - In the WinRoute's DNS module configuration, enable DNS forwarder (forwarding of DNS requests to other servers).

   - Enable the Use custom forwarding option and define rules for names in the `filial1.company.com` and `filial2.company.com` domains. To specify the forwarding DNS server, always use the IP address of the WinRoute host's inbound interface connected to the local network at the remote side of the tunnel.

     Figure 23.34. Headquarter — DNS forwarding settings

   - Set the IP address of this interface (`10.1.1.1`) as a primary DNS server for the WinRoute host's interface connected to the LAN 1 local network. It is not necessary to set DNS at the interface connected to LAN 2.

     Figure 23.35. Headquarter — TCP/IP configuration at a firewall's interface connected to the local network

   - Set the IP address `10.1.1.1` as a primary DNS server also for the other hosts.

4. Enable the VPN server and configure its SSL certificate (create a self-signed certificate if no certificate provided by a certification authority is available).

   Note: A free subnet which has been selected is now specified automatically in the VPN network and Mask entries. Check whether this subnet does not collide with any other subnet in the headquarters or in the filials. If it does, specify a free subnet.

   Figure 23.36. Headquarters — VPN server configuration

   For a detailed description on the VPN server configuration, refer to chapter 23.1 VPN Server Configuration.

5. Create a passive endpoint of the VPN tunnel connected to the London filial. Use the fingerprint of the VPN server of the London filial office as a specification of the fingerprint of the remote SSL certificate.

   Figure 23.37. Headquarter — definition of VPN tunnel for the London filial

   On the Advanced tab, select the Use custom routes only option and set routes to the subnets at the remote endpoint of the tunnel (i.e. in the London filial).

   Figure 23.38. The headquarters — routing configuration for the tunnel connected to the London filial

   ### Warning

   In case that the VPN configuration described here is applied (see figure 23.30 Example of a VPN configuration — a company with two filials), it is unrecommended to use automatically provided routes! In case of an automatic exchange of routes, the routing within the VPN is not be ideal (for example, any traffic between the headquarters and the Paris filial office is routed via the London filial whereas the tunnel between the headquarters and the Paris office stays waste.

6. Use the same method to create a passive endpoint for the tunnel connected to the Paris filial.

   Figure 23.39. The headquarters — definition of VPN tunnel for the Paris filial

   On the Advanced tab, select the Use custom routes only option and set routes to the subnets at the remote endpoint of the tunnel (i.e. in the Paris filial).

   Figure 23.40. The headquarters — routing configuration for the tunnel connected to the Paris filial

7. Add the new VPN tunnels into the Local Traffic rule.

   Figure 23.41. Headquarter — final traffic rules

### Configuration of the London filial

1. Install WinRoute (version `6.1.0` or higher) at the default gateway of the filial's network.

2. Use Network Rules Wizard (see chapter 7.1 Network Rules Wizard) to configure the basic traffic policy in WinRoute. To keep the example as simple as possible, it is supposed that the access from the local network to the Internet is not restricted, i.e. that access to all services is allowed in step 4.

   In step 5 of the wizard, select the Create rules for Kerio VPN server option (setting of the Create rules for Kerio Clientless SSL-VPN option is not regarded here).

   Figure 23.42. The London filial — no restrictions are applied to accessing the Internet from the LAN

   Figure 23.43. The London filial office — creating default traffic rules for Kerio VPN

   This step will create rules for connection of the VPN server as well as for communication of VPN clients with the local network (through the firewall).

   Figure 23.44. The London filial office — default traffic rules for Kerio VPN

3. Customize DNS configuration as follows:

   - In the WinRoute's DNS module configuration, enable DNS forwarder (forwarding of DNS requests to other servers).

   - Enable the Use custom forwarding option and define rules for names in the `company.com` and `filial2.company.com` domains. To specify the forwarding DNS server, always use the IP address of the WinRoute host's inbound interface connected to the local network at the remote side of the tunnel.

     Figure 23.45. The London filial office — DNS forwarding settings

   - Set the IP address of this interface (`172.16.1.1`) as a primary DNS server for the WinRoute host's interface connected to the LAN 1 local network. It is not necessary to set DNS at the interface connected to LAN 2.

   - Set the IP address `172.16.1.1` as a primary DNS server also for the other hosts.

4. Enable the VPN server and configure its SSL certificate (create a self-signed certificate if no certificate provided by a certification authority is available).

   Note: A free subnet which has been selected is now specified automatically in the VPN network and Mask entries. Check whether this subnet does not collide with any other subnet in the headquarters or in the filials. If it does, specify a free subnet.

   Figure 23.46. The London filial office — VPN server configuration

   For a detailed description on the VPN server configuration, refer to chapter 23.1 VPN Server Configuration.

5. Create an active endpoint of the VPN tunnel which will connect to the headquarters server (`newyork.company.com`). Use the fingerprint of the VPN server of the headquarters as a specification of the fingerprint of the remote SSL certificate.

   Figure 23.47. The London filial office — definition of VPN tunnel for the headquarters

   On the Advanced tab, select the Use custom routes only option and set routes to headquarters' local networks.

   Figure 23.48. The London filial — routing configuration for the tunnel connected to the headquarters

   At this point, connection should be established (i.e. the tunnel should be created). If connected successfully, the Connected status will be reported in the Adapter info column for both ends of the tunnel. If the connection cannot be established, we recommend you to check the configuration of the traffic rules and test availability of the remote server — in our example, the `ping gw-newyork.company.com` command can be used at the London branch office server.

   ``

6. Create a passive endpoint of the VPN tunnel connected to the Paris filial. Use the fingerprint of the VPN server of the Paris filial office as a specification of the fingerprint of the remote SSL certificate.

   Figure 23.49. The London filial office — definition of VPN tunnel for the Paris filial office

   On the Advanced tab, select the Use custom routes only option and set routes to Paris' local networks.

   Figure 23.50. The London filial — routing configuration for the tunnel connected to the Paris branch office

7. Add the new VPN tunnels into the Local Traffic rule. It is also possible to remove the Dial-In interface and the VPN clients group from this rule (supposing that all VPN clients connect to the headquarters' server).

   Figure 23.51. The London filial office — final traffic rules

### Configuration of the Paris filial

1. Install WinRoute (version `6.1.0` or higher) at the default gateway of the filial's network.

2. Use Network Rules Wizard (see chapter 7.1 Network Rules Wizard) to configure the basic traffic policy in WinRoute. To keep the example as simple as possible, it is supposed that the access from the local network to the Internet is not restricted, i.e. that access to all services is allowed in step 4.

   Figure 23.52. The Paris filial — no restrictions are applied to accessing the Internet from the LAN

   In this case, it would be meaningless to create rules for the Kerio VPN server and/or the Kerio Clientless SSL-VPN, since the server uses a dynamic public IP address). Therefore, leave these options disabled in step 5.

   Figure 23.53. The Paris filial — default rules for Kerio VPN will not be created

3. Customize DNS configuration as follows:

   - In the WinRoute's DNS module configuration, enable DNS forwarder (forwarding of DNS requests to other servers).

   - Enable the Use custom forwarding option and define rules for names in the `company.com` and `filial1.company.com` domains. Specify the server for DNS forwarding by the IP address of the remote firewall host's interface (i.e. interface connected to the local network at the other end of the tunnel).

     Figure 23.54. The Paris filial office — DNS forwarding settings

   - Set the IP address of this interface (`172.16.1.1`) as a primary DNS server for the WinRoute host's interface connected to the LAN 1 local network. It is not necessary to set DNS at the interface connected to LAN 2.

   - Set the IP address `172.16.1.1` as a primary DNS server also for the other hosts.

4. Enable the VPN server and configure its SSL certificate (create a self-signed certificate if no certificate provided by a certification authority is available).

   Note: A free subnet which has been selected is now specified automatically in the VPN network and Mask entries. Check whether this subnet does not collide with any other subnet in the headquarters or in the filials. If it does, specify a free subnet.

   Figure 23.55. The Paris filial office — VPN server configuration

   For a detailed description on the VPN server configuration, refer to chapter 23.1 VPN Server Configuration.

5. Create an active endpoint of the VPN tunnel which will connect to the headquarters server (`newyork.company.com`). Use the fingerprint of the VPN server of the headquarters as a specification of the fingerprint of the remote SSL certificate.

   Figure 23.56. The Paris filial office — definition of VPN tunnel for the headquarters

   On the Advanced tab, select the Use custom routes only option and set routes to headquarters' local networks.

   Figure 23.57. The Paris filial — routing configuration for the tunnel connected to the headquarters

   At this point, connection should be established (i.e. the tunnel should be created). If connected successfully, the Connected status will be reported in the Adapter info column for both ends of the tunnel. If the connection cannot be established, we recommend you to check the configuration of the traffic rules and test availability of the remote server — in our example, the `ping gw-sanfrancisco.company.com` command can be used at the Paris branch office server.

   ``

6. Create an active endpoint of the tunnel connected to London (server `gw-london.company.com`). Use the fingerprint of the VPN server of the London filial office as a specification of the fingerprint of the remote SSL certificate.

   Figure 23.58. The Paris filial office — definition of VPN tunnel for the London filial office

   On the Advanced tab, select the Use custom routes only option and set routes to London's local networks.

   Figure 23.59. The Paris filial — routing configuration for the tunnel connected to the London branch office

   Like in the previous step, check whether the tunnel has been established successfully, and check reachability of remote private networks (i.e. of local networks in the London filial).

7. Add the new VPN tunnels into the Local Traffic rule. It is also possible to remove the Dial-In interface and the VPN clients group from this rule (VPN clients are not allowed to connect to this branch office).

   Figure 23.60. The Paris filial office — final traffic rules

### VPN test

The VPN configuration has been completed by now. At this point, it is recommended to test reachability of the remote hosts in the other remote networks (at remote endpoints of individual tunnels).

For example, the `ping` or/and `tracert` operating system commands can be used for this testing.

Prev | Up | Next
23.5 Example of Kerio VPN configuration: company with a filial office | Contents | Chapter 24 Kerio Clientless SSL-VPN (Windows)