Azure Point to Site VPN - private access to your cloud environment

You don't really have to worry about connectivity when you have a single in-house data center.  All your proprietary data is on "your" network that you manage. You firewall protects your sensitive information from internet intruders.  The internal network provides routing and name lookup services.

You don't really worry about connectivity when your are consuming publicly available resources on the internet.  Your internal network allows outbound connections to the internet.  Your gateway knows which DNS servers provide name support.

Note: IPV4 network numbers in the diagrams are just examples. They happen to be how my internal and Azure networks are configured.

Azure a Cloud Provider

Cloud providers give you the ability to spin up off-site data centers that are visible and reachable from the internet.  The actual remote data center organization and configuration is somewhat opaque to you since it is managed and controlled by the cloud provider.   The cloud provides internal network connectivity between your virtual hosts.  PaaS services handle internal cloud specific configuration handles in-cloud machine-to-machine connectivity usually through proprietary API.  Public endpoints are usually web services or web sites. 

There is limited management connectivity from the outside. Allowing management access via the public internet increases the number of attack vectors and odds of system intrusion.

Azure users get around the remote nature of the environment by enabling Remote Desktop Protocol access to their windows machines. This lets any machine on the internet RDP into the Azure machines as long as they can provide the right credentials.  This is an obvious security risk.  Azure users add remote Powershell, remote profiling, remote management and non-web accesses by enabling those additional public endpoints.  This increases the number of attack vectors on against the Azure machines.  We want to minimize the number of ports/services that are visible to the internet while providing as much corporate/owner and operational access as possible.

Corporate Azure users get around the remote nature by extending a site-to-site VPN tunnel that joins the cloud and the internal corporate network.  Some companies will not allow this type of network configuration because they are worried about the bi-directional open nature of the connection. Site-to-site has additional issues like the fact that does not help off-site developers and operational folks because only one site-to-site connection is supported. 

Note: that this picture shows an Azure DNS service.  This is used for internal name service for processes that run inside your Azure account.  They could always connect by IP address if azure DNS has not been set up.  Azure DNS is not required for external access. That all happens on cloudnet.app and is supported by the cloudapp.net DNS servers. 

See this document for a description of how to set up Azure point to site VPN networks and connections.

Network Organization as a First Step, VLANs

Azure users must first organize their networks in a way that makes it possible to provide both public access to web sites and services while making it also possible to provide secure non-public access to the management functions.  The default Azure configuration throws all VMs and Cloud Services into a single large network.  

The first step is to create a Virtual LAN (VLAN). VLANs provide a way to organize a network into different segments and is the base level network construct for creating subnets including remote connection tunnels (VPNs).  Pretty much everything you previously created will have to be deleted and recreated sitting on a VLAN instead of your default Azure network. You will want to to subdivide the VLAN namespace into subnets. Normally they are just syntactic sugar because Azure doesn't support firewall or filtering between subnets.  They are important to the point-to-site VPN because Azure VPN will use one of the subnets as the landing zone for VPN connections.

Initial Azure Configuration, Preparing for VPN

Azure VPN requires a VLAN subnet of its own that acts as a type of DMZ network between your on-prem network and the Azure VLAN that you configured.  Systems Administrators use the Azure Management Portal to create the external connectivity subnet. It allows you to pick the number of addresses on the VPN subnet. Each connected VPN client consumes an address on this VPN subnet.  The VPN public gateway takes two addresses also. You should size appropriately for the number point-to-site connections that you expect.

The second piece of the VPN connection is the creation of the actual public IP gateway for the VPN connection subnet.  This is another option on the Azure Management Portal.  Microsoft creates a public IP address and creates internal routing from that address to the VPN subnet. It also creates VPN virtual appliances that sit behind that VPN public IP address.  

The VPN is protected by certificates.  I'm not going to go into details here. You can use Microsoft MSDN  point-to-site vpn configuration page for this information

Azure Point-to-Site Remote Back Channel Connectivity

A VPN connection makes the local machine part of a remote connection using a secure tunnel. Microsoft provides a VPN client side configuration program that is customized to a specific Azure VPN public address and network.  This program is dynamically created in the Azure Management Portal and makes use of built-in Windows 7 / 8 VPN capabilities. 

A point-to-site VPN connection creates an additional network on the local machine that is part of the same network defined in the VPN connection subnet.  Essentially it puts a machine "on the network" in the VPN subnet portion of your VLAN. This mans the local machine has access to all private resources on the VLAN.  The local user can to non-internet-public ports that are unavailable to others outside the Azure cloud.  This is because the local machine is part of the Azure network when connected to the VPN tunnel.

The default Windows VPN configuration does not isolate the local machine to the VPN network. It leaves all the other network connections active.  This means a point-to-site connected machine has access to the internal corporate network, the Azure VLAN and the internet.  Users must keep anti-virus, rootkit, and malware protection software up to date to stop attackers from attacking the Azure or corporate network through the local machine. It is possible to disable all other network connections while attached to a VLAN.  You see this a lot with VPN connections that are restricted due to corporate policies.

Conclusion

<to be written>