No ratings

Configuring a VPN Connection in K2 Cloud

Configuring a VPN Connection in K2 Cloud

Use this article for configuring a site-to-site VPN gateway to connect your K2 Cloud instance to another network. Typically this is your on-premises network but it could be another cloud-based service. A VPN connection between K2 Cloud and another network allows you to use data stored in the other network in your K2 Cloud solutions. The supported line of business systems that you can connect to include:

  • Microsoft SQL Server 2014, 2016, and 2017
  • Microsoft Dynamics CRM 2013, 2015, and 2016
  • Microsoft Exchange 2013 and 2016
  • Oracle 11g (releases 1 & 2) and 12c 
  • REST web services
  • WCF web services
  • SOAP web services
  • OData web services

For the latest compatibility information, see Product Compatibility, Integration and Support.



Creating a VPN connection requires an additional K2 subscription. Please contact your K2 Sales representative for details and pricing.

VPN Gateway Prerequisites and Configuration

Configuring a VPN from K2 Cloud to another network requires specific hardware, software, and configuration.


You must have a VPN device that is configured and installed in your on-premises environment. K2 Cloud can integrate with either of the following VPN solutions:

Recommended VPN Configuration

K2 Cloud only supports RouteBased VPN configurations due to its performance advantages. Testing has proven that K2 Cloud users see up to a 50% speed improvement when compared to other VPN configurations.

Required Network Details

When connecting from K2 Cloud to another network using VPN, you must provide the following information:

  • A pre-shared encryption key
  • A static public IP address
  • Local network address space

Information about the need for these details before you can work with the K2 Cloud Operations team to create a VPN gateway is detailed below. Create a new support ticket when you're ready.

Pre-Shared Encryption Key

To set up the K2 Cloud VPN gateway, both endpoints (peers) of the VPN tunnel must be authenticated. After authentication, the peers negotiate the encryption mechanism and algorithms to secure the communication.

The Internet Key Exchange (IKE) process is used to authenticate the VPN peers, and IPSec Security Associations (SAs) are defined at each end of the tunnel to secure the VPN communication. IKE uses pre-shared keys (PSKs) and the Diffie Hellman keys to set up the SAs for the IPSec tunnel. The SAs specify the parameters required for the secure transmission of data, including the Security Parameter Index (SPI), security protocol, cryptographic keys, and the destination IP address. These ensure secure encryption, data authentication, data integrity, and endpoint authentication of the VPN tunnel. You are responsible for providing the necessary pre-shared keys to the K2 Cloud Operations team prior to establishing the VPN connection to your on-premises environment.

Static Public IP Address

The K2 Cloud VPN gateway connection requires that you VPN device, located on-premises, has a public facing, static IP address. You cannot Network Address Translation (NAT) or IP masquerading for this IP address.

You are responsible for supplying this IP address to the K2 Cloud Operations team.


Avoiding Local Network Address Space Conflicts

You are asked to provide a local network address space during the K2 Cloud VPN gateway configuration. This ensures that the K2 Cloud tenant address space does not conflict with or overlap your on-premises local network address space.

Using Static LOB IP Addresses

Your K2 Cloud tenant uses a Microsoft Azure-based Domain Name Server (DNS) to resolve public names to IP addresses. K2 Cloud will not prioritize your on-premises DNS server over the Azure-based resolution, which means you should use IP addresses and not DNS names to configure your SmartObject service instances. This also means that each of your on-premises data sources should be assigned a static IP address.

Authentication Recommendation

K2 Cloud uses Microsoft Azure Active Directory (AAD) to authenticate users. Since many on-premises data sources do not support AAD, you should plan on integration with your on-premises systems using static credentials. This means that all access to data from K2 Cloud to your on-premises LOB systems is based on a single identity, and when you make changes to the identity or its credentials, you must also update the service instance that connects to that LOB system. For more information about authentication in K2 Cloud see Authentication Modes in the K2 Cloud User Guide.

K2 Cloud Availability Impact

If your on-premises data to which K2 Cloud connects is unavailable, the K2 Cloud Service Availability policy becomes exempt, meaning that K2 is not responsible for service interruptions caused by on-premises data that cannot be accessed using the VPN connection established for this purpose.

Labels: (1)
Version history
Last update:
‎02-12-2021 04:53 AM
Updated by: