emnify Cloud Connect integration into Azure Virtual Network Gateway

Connect devices securely to Azure VNet 

emnify provides a secure integration of IoT devices with applications on Azure.  Utilizing a fully redundant VPN connection to the Azure Virtual Network Gateway customers can directly peer with their devices and remotely access them within their private network. 

How the integration looks like

Prerequisites

The setup of the VPN requires 

• • device with an active emnify SIM
  • Azure account with VNet / VM
  • device sends data to application in VNet / VM instance (e.g. Python, Node.js, Java application / MQTT broker) 
  • one public IP address used by the Virtual Network Gateway
    
    

Benefits

• default redundant managed VPN for high-grade service availability  
• remotely access devices from Azure infrastructure via telnet / SSH or other protocols
• no need for private APNs to establish VPN, always static IPs to reach device
• device data does not traverse public internet
• devices and the application infrastructure reside within the same private network
• no carrier grade NAT between device and cloud which allows e.g. to setup SIP services without additional STUN server (Session Traversal over UDP through NAT)
  
  

  Remarks

• The secure connection is associated with a specific VNet - for example when hosting an own MQTT server. Steps for getting started using Azure IoT Hub can be found in our integration guide.
• An Azure environment may or may not be in place by the time the CloudConnect breakout is created. For the purpose of this example we will create all the necessary resources from scratch
• Backend CIDRs shall be allocated only in the private IP address space. Public IP address ranges are not allowed because this would essentially allow a malicious customer to hijack all the traffic to any public site. 

Configuration Steps

The following steps illustrate how to setup the VPN interconnection of the Azure VNet with the emnify infrastructure. 

• In Azure, create a VNet by creating the following resources
  • A Resource Group named cloudconnect
  • A VNet named cc_vnet with the IP address range 10.0.0.0/8 and a default subnet 10.0.0.0/24
  • A public IP address named cc_vnetgw_public_ip which will be associated to the VNet Gateway and for this reason it shall be of type “dynamic”, which means it will be allocated only after the association takes place.
  • A VNet Gateway named cc_vnet_gw. The VNet Gateway shall be a route-based VPN gateway (rather than policy-based) with BGP and active-active support disabled.

A Summary of these resources is visible in the Resource Groups page

• In the emnify platform, navigate to the Integrations page. Scroll down to Secure Connections  panel. Under IPsec click Add:
• The VPN Public IP field shall contain the public IP address of cc_vnetgw_public_ip. The backend CIDRs shall be subranges of the VNet (10.0.0.0/8 in our case) with a prefix length of at most 22 bits. The larger the VNet range is, the smaller the chance to encounter a backend CIDR collision. We may enter a PSK, which is the recommended approach, but we may also leave the PSK empty, in which case CloudConnect will generate a PSK.
  
• When the CloudConnect attachment state updates from Pending to Not Connected, the VNet configuration can be completed.

Complete VPN Azure Configuration

In the Azure console, navigate to the cc_vnet Subnets section. Add one additional subnet for each backend CIDR configured in CloudConnect, which is 10.179.172.0/22 in our case. To prevent errors during the establishment of the CloudConnect integration, a list of unavailable IP addresses is provided in the following report.

In the CloudConnect panel in the emnify portal, extend the VPN Configuration panel. Two VPN terminations on the emnify side under Tunnel 1 and Tunnel 2 are used as two public IP addresses to configure two Local Network Gateways, cc_vpn_gw_1 and cc_vpn_gw_2.

For the Address space of each of the two Local Network Gateways, configure a larger range of IP addresses that cover all the currently allocated devices / endpoint address spaces as well as future endpoint address space allocations. We will use 100.64.0.0/10 in this example.

Note: To get the IP address ranges that your devices use - check the Portal under Integrations -> IP Address Space Management. If you want to use all potential IP ranges that EMnify uses, these are: 10.192.0.0/12, 100.64.0.0/10, 10.112.0.0/12, 10.176.0.0/12

Navigate to Connections in the Azure console. The Connections must be of type “Site-to-site (IPsec)”, use the IKEv2 protocol and have BGP disabled. The PSKs can be copied from the CloudConnect UI using the copy icon. If the PSK was generated by CloudConnect, Tunnel 1 and Tunnel 2 will have distinct PSKs that need to be copied accordingly into the Azure Connection configuration.

After it is established, the breakout status in the emnify CloudConnect panel changes to active and Tunnel 1 and Tunnel 2 change from down to up.

It is then visible in the Azure console that the tunnels have a status of 'Connected':

To activate traffic on the VPN, a ticket should be opened towards emnify support to request activation of the CloudConnect integration.

Azure Routing and Security Groups Setup

On the Azure console, the traffic must be routed towards the endpoints via the VPN and to allow traffic from the endpoints into cc_as_subnet.
Create a Route Table cc_rt in the cloudconnect Resource Group to route the traffic towards the endpoints via the VNet Gateway.

In Azure there cannot be more than one VNet Gateway per VNet and therefore the VNet Gateway does not need to be named explicitly, instead, the route table entry only specifies the type of the next hop as Virtual Network Gateway. We use again the larger 100.64.0.0/10 range in order to avoid having to update the route table each time we allocate a new endpoint address space.

We also need to make sure cc_rt is associated with cc_as_subnet, the subnet where the Application Servers will be configured.

Similar to the Route Table, the Security Group shall be associated with cc_as_subnet.

We can now configure virtual machines in the 10.179.172.0/22 subnet, which will perform Application Server functionality. When emnify resolves the firewall setup ticket, end-to-end connectivity is then possible.