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…

 

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. “Forced Tunneling” : The first step towards integration is “forced tunneling”. 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). 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.
  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.

Continue reading “Azure Networking : Blueprint patterns for enterprises”

Advertisements

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…

Drawing1

Continue reading “Azure & Cross-Host Container Networking using Rancher”

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”…
2015-09-03 10_30_29-Networks - Microsoft Azure

Next up is to enter the local ip range your client devices will receive upon connection!
2015-09-03 10_47_38-Administrator_ Command Prompt

Client Connector
Now press save and upon success, you will find the download links of the VPN connector on the dashboard page.
2015-09-03 10_28_03-Networks - Microsoft Azure
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

2015-09-03 10_30_53-Networks - Microsoft Azure

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.
    2015-09-03 10_35_07-Windows Software Development Kit for Windows 8.1
  • I installed the vpn software. What now? – The install runs and a terminal windows flashes. 2015-09-03 10_40_57-RD-APOC-VDC02Now 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… 2015-09-03 10_42_00-Connect to a Workplace Next is to connect to the VPN … 2015-09-03 10_42_23-RD-APOC-VDC02 and validate the functionality! 2015-09-03 10_42_49-Network and Sharing Center

I hope this helped you on your journey in Azure!