Introduction

The main objective of this document is to describe the IPSec VPN Connectivity that KODE Labs should implement for enabling secure data transmission between KODE OS Cloud Environment and Client’s network using VPN tunnels. 

IPSec Site-to-Site VPN 

A site-to-site IPSec VPN tunnel encrypts traffic at one end and sends it to the other site over the public Internet where it is decrypted and routed on to its destination. Site-to-Site IPsec VPNs are ideal in the following situations:

• When multiple buildings are interconnected on the same network, it is more suitable to create an IPsec VPN tunnel to the main server of the network to view and connect to the gateways and supervisors from a single location.

• When a building has a router that supports IPSec VPN tunnels and has an architecture made up of BMS gateways primarily, an IPSec VPN tunnel connected to the router is a suitable option.

VPN (Site-to-Site IPSec Tunnel) as Solution

An IPSec VPN tunnel is the most common method for connecting on-site systems to the KODE OS Cloud Environment. We recommend that each Site-to-Site IPSec VPN tunnel established is paired with a secondary IPSec VPN tunnel for redundancy purposes.  This will ensure that connectivity is maintained over 99.99% of the time between the Client’s site and the KODE OS Cloud Environment. Figure 1 below demonstrates how a Site-to-Site IPSec VPN establishes connectivity between the KODE OS Cloud Environment and a Client’s building network. 

                                                            Figure 1. Site-to-Site IPsec VPN architecture

Note that Local IP addresses provided in Figure 1 are illustrative. The exact network range of the KODE OS Cloud Environment will be provided in later phases, per the submission of the IPsec VPN Request Form. 

IPSec VPN Workflow Process

Because two tunnels should take place for each building, the following schema diagram illustrates the process and considerations for establishing IPSec VPN tunnels. * Please note that the IP addresses used in the diagram below are just examples. Each client will be assigned another specific IP range. *

IPSec VPN Dependencies

Before creating an IPSec VPN tunnel, several dependencies must be pre-defined between the KODE OS Firewall and the Client’s Firewall. The following attributes should be communicated and exchanged:

• Public IPs of KODE OS Gateways or Domains 

• Public IPs of the Client’s Firewall

• Firewall Type Model 

• Network Range that should be Network Address Translated (NAT’d)

• Remote Network for traffic workflow

• Encryption Algorithms

Public IPs or Domains

It is important to predefine that client’s firewall should be on top of infrastructure, or at least meet all three of the following requirements:

• It must have a public IP address, 

• It must have a domain (hostname mapped to firewall IP)

• It must have the ability to reach hosts inside the local network (Niagara Server, Jace or any other IoT Device that is expected to be connected to the KODE OS).

Two models of WAN peering will be possible so the client will only need to define the way of Peer IP (WAN) Interface (using gateway IP or hostname domain). Both solutions are acceptable. 

Firewall Model Definition

The following are the criterias that a firewall must meet to generate a valid IPSec VPN tunnel:

1. Client’s router has Public IP (WAN Interface Active) [High Importance]

2. Supports IPSec VPN Tunnel [High Importance]

3. Supports NAT over IPSec [High Importance]

4. Support IKEv2 (This is due to security issues and we insist using IKEv2 everywhere)

5. Support Encrypted Algorithms (AES 256GCM or AES256 SHA256) Would be preferable

6. Support DH Group 14 (2048 bit)

The KODE OS Cloud Environment is flexible in the ways that it can connect with a Client’s network.  Depending on the client’s firewall/router type, the most important criterias that should be considered from the above list are criteria #1, #2 and #3. Without these three criteria there is no other way for continuing the creation of tunnels. 

Firewall Rules

The Client side should ensure that communication between KODE OS Firewall and Client Firewall is reachable. Therefore, the following ports will need to be enabled on the client side:

-UDP Ports: 4500, 500

-Protocol: ESP

It is also important to allow communication within the tunnel. We suggest allowing all ports and creating a rule that would be:

Source: Any *, Destination: Any *, Destination Ports: Any *, Interface: IPSec VPN tunnel

Selecting which tunnel would be preferable, since it would avoid allowing for all existing tunnels.

This rule should be applied only on IPsec tunnels and will ensure that communication within the tunnel is open and no port is blocked. This behavior should be enforced to be applied at client side as well.

Furthermore, to ensure clear communication between KODE OS Cloud Environment and Client’s network or IoT device (Jace), both sides need to make sure to allow local device’s port. For example, if a JACE’s API operates on port 5633, this port must be allowed in the IPSec VPN tunnel and should be allowed locally. Lastly, any defender / antivirus tools on the network should be verified to not be blocking the device’s ports.

NAT over IPSec Tunnel

When the number of tunnels increases and the possibility of duplicate IP ranges within a network occurs, we strongly recommend using NAT over IPsec tunnels which would be the best option for avoiding conflicts or mitigation between the same network ranges.

During the initial connectivity phase, the following information is sent to each Client that establishes a IPSec VPN Connection:

-Dedicate a Network IP Range (e.g. 100.80.37.0/24) 

-Remote Network (e.g. 100.64.0.1/32 for primary tunnel and  100.64.0.2/32 for secondary tunnel)

Network Range will be defined for each client, such as 100.80.37.0/24, 100.80.38.0/24, while the Remote Network (100.64.0.1) is static and will be used for all clients.

Authentication and Authorization

KODE OS firewall will use a Pre-Shared key for tunnel authentication. The keys should be generated for every tunnel and the proposed standard should be at least 15 characters and combination of characters, letters and numbers.

Regarding the authorization, KODE OS will take the lead as “Initiator” on tunnel configuration and Client should be “responder”. This would give authorization to the client to keep the tunnel up.

Proposals (Encryption Algorithms)

The selection of Proposals (Encryption Algorithms) should be predefined in Appendix A - IPSec VPN Request From and filled out by the client before tunnel configuration. According to security standards, we recommend using one of the following encryption algorithms in Phase 1 and Phase 2:

• AES 256 GCM or

• AES 256 SHA256 key 256 bit length

Using AES256GCM is preferable because it consumes less resources (CPU/RAM) for encryption/decryption of traffic. AES256 SHA256 is most commonly used and most routers/firewalls support that. However, not all routers/firewalls support this algorithm.  So there is flexibility for selecting proposals based on the IPSec VPN Request Form requirements received from clients.