What the proxy?!? How to use a proxy with the typical Azure tools…

Introduction

Proxy servers are a very common thing in a lot of enterprises. They are used so that people cannot directly access the internet, and additional management capabilities to the flow (logging, authentication, …). Now that sounds very dandy, though what about those non-browser-based tools? How can we ensure that tools like Azure CLI, Azure Powershell & AzCopy work with our “beloved” enterprise proxy? That’ll be the topic for today!

Test Setup

What will we be doing today? I’ve setup a proxy server in my own lab… Basically deployed a Squid proxy by means of a container.

Next up, I’m going to use the three earlier mentioned tools on both Linux (WSL) & Windows, and see what needs to be done to get things working. In the following screenshots you’ll typically see a “split screen”, where left is a “tcpdump” on the box running the proxy server and right will be the commands on the box running the tools. If you see a lot of mumbo jumbo (network packets) on the left, that’ll mean that the proxy server was being used. Ready?!? Cool, let’s go!

Continue reading “What the proxy?!? How to use a proxy with the typical Azure tools…”

Hardening your Azure Storage Account by using Service Endpoints

Introduction

Earlier this week I received a two folded question ; “Does a service endpoint go over internet? As when I block the storage account tags with a NSG, my connection towards the storage account stops.” Let’s look at the following illustration ;

 

The first thing to mention here is that the storage account (at this time) always listens to a public IP address. The funky thing is, that in Azure, you’ll have a capability called “Service Endpoint“, which I already covered briefly in the past. For argument’s sake, I’ve made a distinction in the above illustration between the “Azure Backbone” and the “Azure SDN”. A more correct representation might have been to have said “internal” & “external” Azure Backbone in terms of the IP address space used. So see the “Azure Backbone” in the above drawing as the public IP address space. Here all public addresses reside. Where the “Azure SDN” is the one that covers the internal flows. Also be aware that an Azure VNET can only have address spaces as described by RFC1918. So why did I depict it like this? To indicate that there are different flows;

  • Connections from outside of Azure (“internet”)
  • Connections from within the Microsoft backbone (“Azure Backbone”)
  • Connections by leveraging a service endpoint

So how does the service endpoint work?

So to answer the question stated above ;

  • Q: Does a service endpoint go over “the internet”?
  • A : Define “internet”…
    • If you mean that it uses a public ip address instead of an internal one? Then yes.
    • If you mean that it leaves the Microsoft backbone? Then no.
    • If you mean that the service is accessible from the internet? Unless you open up the firewall, it won’t (by default, when having a service endpoint configured).

 

  • Q: When I block the storage tag in my network security group (“NSG”), then the traffic stops. How come?
  • A: The NSG is active on NIC level. The storage account, even when using a service endpoint, will still use the public IP. As this public IP is listed in the ranges that are configured in the service tag, you’ll be effectively blocking the service. This might be your objective… Though if you do this to “lock down the internet flow”, then you won’t achieve the requested you wanted. You should leverage the firewall functionality from the service for which the service endpoint was used.

 

Deep Dive

As always, let’s do a deep dive to experience this flow! So I did set up the above drawing in my personal lab ;

Continue reading “Hardening your Azure Storage Account by using Service Endpoints”

Trying out the Azure Firewall in a Hub & Spoke deployment model

Introduction

A few weeks ago the Azure Firewall went into public preview. Today’s post will be around taking it for a spin in a hub & spoke deployment.

 

Architecture

First off, what will the architecture of our deployment look like?

  • A central hub, where we’ll deploy the Azure Firewall. This will consist of the address space 172.16.0.0/12.
  • Two spokes, each with their own address space (10.[1/2].0.0/16) where a UDR will send all traffic to the Azure Firewall (172.16.254.4).
  • In each VNET, we’ll deploy a “SUBNET000” in which we’ll setup a vm to do our basic connectivity testing.
  • Each spoke is connected with a bidirectional VNET peering with the spokes. Both spokes can only talk to each other over the HUB.
  • The Azure firewall will be configured to allow traffic within the 10.0.0.0/8 range.

 

Continue reading “Trying out the Azure Firewall in a Hub & Spoke deployment model”

Taking a look at Azure Service Endpoints

Introduction

The concept of Service Endpoints has been around for a while now. Though for today’s post I would like to guide you through the typical process. Here we’ll take a glance of how they work and so that you know what to expect.

 

Scenario

For this post we’ll be connecting the Azure PostgreSQL Service to a VNET by leveraging a Service Endpoint. Afterwards we’ll make a connection from a VM within that VNET, and see what route is being taken!

Continue reading “Taking a look at Azure Service Endpoints”

Azure API Management : What about Multi-Region & VNET Integration?

Introduction

Yesterday I received a question whether the combination of Multi-Region & VNET Integration is supported for Azure API Management. My gut feeling told me yes… Though it seems our documentation wasn’t 100% clear on the matter. So I did a quick test to see if it was possible.

Continue reading “Azure API Management : What about Multi-Region & VNET Integration?”

Understanding the budget impact of Azure Networking on your architecture

Introduction

Today’s post will be about “demystifying” the possible network costs you might incur when using Azure services. Once you understand the basics behind the billing model, you’ll soon find that you can tweak these to your advantage!

 

Cost Drivers

When looking towards the costs, there are several pricing pages you should visit to know the cost drivers of your architecture…

Though I can feel you… It’s not always easy to understand when what is triggered.

 

Updates (!)

  • 23/08 – Updated HL overview to v2.0 to include costs due to zone architecture
  • 23/08 – Source files for the drawing can be found here.

 

High Level Overview

Underneath you can find an overview of the possible cost drivers. We’ll go into depth on the individual flows in this post.

Continue reading “Understanding the budget impact of Azure Networking on your architecture”

Azure : Is it possible to do a cross subscription network peering?

Introduction

Today I received a question if it was possible to do a cross subscription peering… with one big catch; that it was between the subscription of a service provider and their customer(s). So let’s see what is possible?

 

Update : Oct 2018

At Ignite 2018 it was announced that peering will also be able to work cross tenants.

 

Public Preview Announcement

When we take a look at the announcement, we see the following statement ;

Note that you can peer virtual networks that exist in two different subscriptions as long as a privileged user of both subscriptions authorizes the peering and the subscriptions are associated with the same Active Directory tenant.

Now the from this we can already see that it is possible to doe cross subscription peering. As a requirement, we need a user that is authorized on both subscriptions AND that the subscriptions are associated with the same AAD tenant.

The latter caused a bit of confusion on the requestor part, where the statement was made if a B2B invite would solve this issue. The answer to this is “no”. The B2B invite lies on the authorized user part, and is not related to the tenant of the subscription!

 

Let’s try it out?!?

Continue reading “Azure : Is it possible to do a cross subscription network peering?”