23.5 Example of Kerio VPN configuration: company with a filial office
Prev | Chapter 23 Kerio VPN | Next

## 23.5 Example of Kerio VPN configuration: company with a filial office

This chapter provides a detailed exemplary description on how to create an encrypted tunnel connecting two private networks using the Kerio VPN.

This example can be easily customized. The method described can be used in cases where no redundant routes arise by creating VPN tunnels (i.e. multiple routes between individual private networks). Configuration of VPN with redundant routes (typically in case of a company with two or more filials) is described in chapter 23.6 Example of a more complex Kerio VPN configuration.

Note: This example describes a more complicated pattern of VPN with access restrictions for individual local networks and VPN clients. An example of basic VPN configuration is provided in the Kerio WinRoute Firewall — Step By Step Configuration document.

### Specification

Supposing a company has its headquarters in New York and a branch office in London. We intend to interconnect local networks of the headquarters by a VPN tunnel using the Kerio VPN. VPN clients will be allowed to connect to the headquarters network.

The server (default gateway) of the headquarters uses the public IP address `63.55.21.12` (DNS name is `newyork.company.com`), the server of the branch office uses a dynamic IP address assigned by DHCP.

The local network of the headquarters consists of two subnets, `LAN 1` and `LAN 2`. The headquarters uses the `company.com` DNS domain.

The network of the branch office consists of one subnet only (`LAN`). The branch office `filial.company.com`.

Figure 23.13 Example — interconnection of the headquarter and a filial office by VPN tunnel (connection of VPN clients is possible) provides a scheme of the entire system, including IP addresses and the VPN tunnels that will be built.

Figure 23.13. Example — interconnection of the headquarter and a filial office by VPN tunnel (connection of VPN clients is possible)

Suppose that both networks are already deployed and set according to the figure and that the Internet connection is available.

Traffic between the network of the headquarters, the network of the branch office and VPN clients will be restricted according to the following rules:

1. VPN clients can connect to the `LAN 1` and to the network of the branch office.

2. Connection to VPN clients is disabled for all networks.

3. Only the `LAN 1` network is available from the branch office. In addition to this, only the WWW, FTP and Microsoft SQL services are available.

4. No restrictions are applied for connections from the headquarters to the branch office network.

5. `LAN 2` is not available to the branch office network nor to VPN clients.

### Common method

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

1. It is necessary that WinRoute in version `6.0.0` or higher (older versions do not include Kerio VPN) is installed at the default gateway.

   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 the domain in the remote network. This enables to access hosts in the remote network 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 remote endpoint of the VPN tunnel).

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

5. Define the VPN tunnel to the remote network. The passive endpoint of the tunnel must be created at a server with fixed public IP address (i.e. at the headquarter's server). Only active endpoints of VPN tunnels can be created at servers with dynamic IP address.

   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. In traffic rules, allow traffic between the local network, remote network and VPN clients and set desirable access restrictions. In this network configuration, all desirable restrictions can be set at the headquarter's server. Therefore, only traffic between the local network and the VPN tunnel will be enabled at the filial's server.

7. Test reachability of remote hosts from each local network. 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.0.0` or later) at the headquarter's default gateway (“server”).

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.14. 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.15. 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.16. Headquarter — default traffic rules for Kerio VPN

   When the VPN tunnel is created, customize these rules according to the restriction requirements (see item 6).

   Note: To keep the example as simple and transparent as possible, only traffic rules relevant for the Kerio VPN configuration are mentioned.

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 `filial.company.com` domain. 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.17. 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 server at the interface connected to LAN 2 — DNS configuration is applied globally to the entire operating system.

     Figure 23.18. 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.

   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. 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.

   Figure 23.19. 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 end of the VPN tunnel (the server of the branch office uses a dynamic IP address). Specify the remote endpoint's fingerprint by the fingerprint of the certificate of the branch office VPN server.

   Figure 23.20. Headquarter — definition of VPN tunnel for a filial office

6. Customize traffic rules according to the restriction requirements.

   Figure 23.21. Headquarter — final traffic rules

   - In the Local Traffic rule, remove all items except those belonging to the local network of the company headquarters, i.e. except the firewall and `LAN 1` and `LAN 2`.

   - Define (add) the VPN clients rule which will allow VPN clients to connect to `LAN 1` and to the network of the branch office (via the VPN tunnel).

   - Create the Branch office rule which will allow connections to services in `LAN 1`.

   - Add the Company headquarters rule allowing connections from both headquarters subnets to the branch office network..

   Rules defined this way meet all the restriction requirements. Traffic which will not match any of these rules will be blocked by the default rule (see chapter 7.3 Definition of Custom Traffic Rules).

### Configuration of a filial office

1. Install WinRoute (version `6.0.0` or later) at the default gateway of the branch office (“server”).

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.22. 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.23. A filial — it is not necessary to create rules for the Kerio VPN server

   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.24. Filial office — default traffic rules for Kerio VPN

   When the VPN tunnel is created, customize these rules according to the restriction requirements (Step 6).

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 `filial.company.com` domain. 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.25. Filial office — DNS forwarding settings

   - Set the IP address of this interface (`192.168.1.1`) as a primary DNS server for the WinRoute host's interface connected to the local network.

     Figure 23.26. Filial office — TCP/IP configuration at a firewall's interface connected to the local network

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

   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. 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.

   Figure 23.27. 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.28. Filial office — definition of VPN tunnel for 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 newyork.company.com` command can be used at the branch office server.

   ``

   Note: If a collision of VPN network and the remote network is detected upon creation of the VPN tunnel, select an appropriate free subnet and specify its parameters at the VPN server (see Step 4).

   For detailed information on how to create VPN tunnels, see chapter 23.3 Interconnection of two private networks via the Internet (VPN tunnel).

6. Add the new VPN tunnel 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 the branch office).

   Figure 23.29. Filial office — final traffic rules

   Note: It is not necessary to perform any other customization of traffic rules. The required restrictions should be already set in the traffic policy at the server of the headquarters.

### VPN test

Configuration of the VPN tunnel has been completed by now. At this point, it is recommended to test availability of the remote hosts from each end of the tunnel (from both local networks).

For example, the `ping` or/and `tracert` operating system commands can be used for this testing. It is recommended to 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.

Prev | Up | Next
23.4 Exchange of routing information | Contents | 23.6 Example of a more complex Kerio VPN configuration