Zone Aware Azure VPN Gateway : Deployment options

Introduction

Today a quick post on Zone Aware VPN Gateways… When you currently create a VPN gateway, you’ll see the following screen ;

There are two important options to note here ;

– Availability Zone

– Active / Active

Azure Networking : Blueprint patterns for enterprises

Introduction

When moving to the cloud, one cannot imagine this without some kind of network integration. Taking a look at “Infrastructure-as-a-Service”, there are several common patterns that are utilized by enterprises. Today we’ll discuss these patterns…

 

Update – June 2018

Despite that this post isn’t even a year old, I’ll be updating it with the new guidance that come from the introduction of the standard LB. Here we advise to use a single legged deployment.

 

Typical Network Maturity Models

Embarking on a cloud journey? You’ll typically go through the following patterns depending on your “maturity level” in working with the cloud ;

1. “Island” : The first approach is typically “the island”. The VMs reside in a VNET that is not connected/integrated with any other networks, except for (maybe) the internet.
2. “Hybrid Connection” : The first step towards integration is creating a hybrid connection. Here you want to access “On Premises” resources, though the mass of the resources on Azure do not justify the investment into a “Network Virtual Appliance” (AKA Firewall). Two flavours typically arise here;
   1. “Forced Tunneling” : Here you set up a “UDR” (User Defined Route, AKA Static Route), where you force all traffic to go back to the “On Premises” network.
   2. “Azure = Internet Zone” : Here you assume that the Azure zone is does what it needs to do to protect its resources Though you’ll protect your “On Prem” zone by considering the Azure VNET as being “the bad internet”.
3. “Single VNET with DMZ” : One step beyond “forced tunneling”, is moving towards the typical DMZ-alike pattern, where you setup a HA-pair of “Network Virtual Appliances” and segregate network zones.
4. “Hub & Spoke”-model : Growing even further, you’ll have multiple subscriptions. Setting up “NVAs” on all of those can be quite expensive. In terms of governance, this also a nice model, where you can consolidate all network integration into a segregated subscription/vnet.

The advantage of these patterns is that you can evolve into another pattern without breaking anything in terms of design.

Azure : Understanding VPN Connections in ARM

Introduction

Setting up VPN connections is a common practice to provide secure/private connectivity between your OnPremise & your Azure VNETs.  Or even between Azure VNETs actually… Though I’ve had various questions regarding the usage of keys ; “Do I have one key for the entire environment or can I use different ones?”

Azure : ExpressRoute Connection Methods

Introduction

In the past I’ve already explained a bit on ExpressRoute… This is a topic on which I’ve had a vast amount of discussions in the past.

Thomas was a worthy sparring partner and truly had a big share in those discussions. Recently he pinged me to say that the naming has shifted. So we’ll be covering that today.

Azure & Cross-Host Container Networking using Rancher

Introduction

Today we’ll try to understand a bit more about the Rancher cross-host networking capabilities.

Networking

Rancher supports cross-host container communication by implementing a simple and secure overlay network using IPsec tunneling. To leverage this capability, a container launched through Rancher must select “Managed” for its network mode or if launched through Docker, provide an extra label “–label io.rancher.container.network=true”. Most of Rancher’s network features, such as load balancer or DNS service, require the container to be in the managed network.

Under Rancher’s network, a container will be assigned both a Docker bridge IP (172.17.0.0/16) and a Rancher managed IP (10.42.0.0/16) on the default docker0 bridge. Containers within the same environment are then routable and reachable via the managed network.

Note:The Rancher managed IP address will be not present in Docker meta-data and as such will not appear in the result of a Docker “inspect.” This sometimes causes incompatibilities with certain tools that require a Docker bridge IP. We are already working with the Docker community to make sure a future version of Docker can handle overlay networks more cleanly.

Source : http://docs.rancher.com/rancher/concepts/#networking

So in short… You can create a virtual network spanned accross all hosts using Rancher. At the time of writing, this is still based upon an IPsec VPN implementation underneath, where RancherLabs is looking to implement the “new” overlay networking of the native Docker. Be aware that Weave is also pretty known, and used, within the community. Though at this point I want to keep it as simple as possible…

High Level Setup

Anyhow, let’s look at our labo for the day…

Azure : Deploying Point-to-site VPN

Introduction
This post will provide you with a high level outline how to set up a point-to-site VPN with an Azure virtual network. If you run into issues during the setup, browse to the last part of this post, as it contains some “gotchas” that we encountered in the past.

Point-to-Site VPN Setup
Browse to your virtual network, then “configure” and tick the “Configure point-to-site connectivity”…

Next up is to enter the local ip range your client devices will receive upon connection!

Client Connector
Now press save and upon success, you will find the download links of the VPN connector on the dashboard page.

Before you ask… there are NO non-windows agents available for download.

Authentication Configuration
In regards to the authentication, this is solely done via certificates. So I advise you to follow this guide…

The guide will get you through the process of creating a root certificate and generating client certificates by using this root certificate. Along with the VPN software, you’ll be providing your users/partners/… an export of the client certificate. In turn, they will need to import this into their workstation.

The bumps on the road…
What are the issues you’ll run into?

• Makecert? I don’t have this… – Download the SDK and install the “Windows Software Development Kit. Afterwards you’ll find “makecert” in %Programfiles%\Windows Kits\8.1\bin\x86|x64.
  
• I installed the vpn software. What now? – The install runs and a terminal windows flashes. Now you are in the dark… Not nice of Microsoft to be honest! Browse to “Control Panel”, “Network & Internet”, “Network & Sharing Center” and then “Connect”. Now you will see your VPN connection. If you have no connect button, go to “Set up a new connection or network”, select “Connect to a workplace” and select your VPN adapter… Next is to connect to the VPN … and validate the functionality!

I hope this helped you on your journey in Azure!