Azure : What the BGP is going on there?

Introduction

Something I had on my to-do for a while now was to post a proof-of-concept to you guys/gals about what BGP on Azure can entail… Now some of you might go; “BGP? What the hell is that?!?”. Check out the following “CBT Micro Nugget” as it is a nice high level description of what BGP is.

 

So why should you care? BGP can offer you a way to deal with advanced routing paths. This in turn can deliver resiliency to your business.

 

Proof-of-Concept Design

For today, we’ll be building the following setup ; kvaes-azure-networking-bgp-resiliency

This will consist of the following components ;

  • Four virtual networks ; VNET001, VNET002, VNET003 & VNET004
  • Each VNET will have its own VPN Gateway. We’ll enable BGP on the VPN Gateway and give it its own (unique for, and private to, our deployment) ASN & peering address. The VPN Gateway will be set to “RouteBased”-routing and we’ll use a “Standard” SKU.
  • Each VPN Gateway will have two connections towards the “previous” and “next” gateway. The keys per connection pair will be set to the same key and we’ll also enable BGP on the connection.
  • We’ll deploy two systems into this PoC setup
    • System001 will reside in VNET001
    • System004 will reside in VNET004

 

To test our setup, we’ll execute the following scenario ;

  • Connect from system001 to system004 whilst our ring is complete =>the green path will be followed
  • Connect from system001 to system004 whilst having deleted the connections between VPNGW001 & VPNGW004 => the yellow path will be followed

Continue reading “Azure : What the BGP is going on there?”

Azure : A poor man’s SSL termination (by leveraging Cloudflare)

Introduction

A few weeks back I posted some posts about the Azure Application Gateway. Here I must say I ran into some issues in combination with Rancher. So I was forced to look for alternatives…

One of my requirements was to have a “zero-touch deployment”-capability. Meaning that I did not want to deploy a system where I had to manually change things to get it working.

 

High Level Blueprint

So how would a “poor man’s ssl termination on Azure” look? Basically I’m using Cloudflare as my DNS provider which then provides capabilities like CDN, various SSL options (like SSL Termination = Flexible SSL), WAF, etc. We can start with the free plan, where we can do a redirect to https and do SSL termination.

kvaes-azure-cloudflare-poorman-ssl-termination

In addition, we’ll deploy an NSG (network security = basic azure firewall rule) that is configured to only allow the IP ranges from Cloudflare. This way we speak https on the outside world, and we have to accept that the traffic between Cloudflare and our hosts is unencrypted…

 

Continue reading “Azure : A poor man’s SSL termination (by leveraging Cloudflare)”

Azure : What does the Direct Server Return option do for a Load Balancer?

Introduction

When setting up a load balancing rule in Azure, you’ll be given the opportunity to enable/disable “Direct Server Return”.

2016-08-18 16_06_29-Add load balancing rule - Microsoft Azure

 

So what does it do?

Apart from disabling the “backend port” input field, what does it do? Clicking on the “?” gives us a start…

2016-08-18 16_06_00-Add load balancing rule - Microsoft Azure

Basically, DSR (Direct Server Return) will disable any NAT involved. So the targetted VM should be aware of the loadbalancer IP, or the network flow will break.

So it’s usefull to use as a cluster IP address (for example, when using a cluster IP), though do NOT use it for typical load balancing scenario’s where the nodes aren’t aware of the cluster address.

 

Azure : VNet Peering

Introduction

We’ve talked about setting up VPN connections between VNets in the past… At the end of July, VNet peering entered “preview”. This one allows you to connect two VNets within the same region without the need for a gateway.

 

How does this look?

So let’s look at an example with several VNets ; Two in west europe and one in north europe.

2016-08-16 09_19_01-Choose virtual network - Microsoft Azure

If we select on VNet (from West Europe), we’ll notice another option called “Peerings”.

2016-08-16 09_19_17-Choose virtual network - Microsoft Azure

Press “Add” here, and you’ll be able to link another VNet in the same region.

2016-08-16 09_19_26-Choose virtual network - Microsoft Azure

Issue : Exposing ports with Windows Containers on TP5

A brief post today, so assist people who are probably going to “enjoy” the same networking issue. When coming from docker on linux and working with docker on windows, the first thing you’ll probably run into is the port exposing…

I built a MSSQL 2016 container with the default port (1433) exposed.

PS C:\Users\kvaes> docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
efc7a981f6b9 kvaessql2016 “cmd /S /C ‘powershel” 6 minutes go Up 6 minutes 1433/tcp

Though I was unable to connect from the container host to this port…

PS C:\Users\kvaes> Test-NetConnection -Port 1433 -ComputerName Localhost
WARNING: TCP connect to Localhost:1433 failed

ComputerName : Localhost
RemoteAddress : ::1
RemotePort : 1433
InterfaceAlias : Loopback Pseudo-Interface 1
SourceAddress : ::1
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms
TcpTestSucceeded : False

Now let’s try that directly from the container…

PS C:\Users\kvaes> docker exec -ti efc7a981f6b9 powershell Test-NetConnection -Port 1433 -ComputerName Localhost

ComputerName : Localhost
RemoteAddress : ::1
RemotePort : 1433
InterfaceAlias : Loopback Pseudo-Interface 2
SourceAddress : ::1
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms
TcpTestSucceeded : True

This had me totally flabbergasted! After searching for a solution, I ran into the following github issue ; https://github.com/Microsoft/Virtualization-Documentation/issues/253 

Which pointed me to the following statement ;

This is a known limitation in our Windows NAT implementation (WinNAT) that you cannot access the external port in a static port mapping directly from the container (NAT) host.

The following github issue showed a workaround ; https://github.com/docker/docker/issues/15740

So let’s check the IP of our container…

PS C:\Users\kvaes> docker exec -ti efc7a981f6b9 ipconfig

Windows IP Configuration

Ethernet adapter vEthernet (Temp Nic Name):

Connection-specific DNS Suffix . : 404nupum1doencwb55jgqiwlph.ax.internal.cloudapp.net
Link-local IPv6 Address . . . . . : fe80::3077:b4b4:3a8c:5d83%31
IPv4 Address. . . . . . . . . . . : 172.27.75.141
Subnet Mask . . . . . . . . . . . : 255.240.0.0
Default Gateway . . . . . . . . . : 172.16.0.1

And then setup a proxy to reroute the traffic ;

PS C:\Users\kvaes> netsh interface portproxy add v4tov4 listenaddress=127.0.0.1 listenport=1433 connectaddress=172.27.75
.141 connectport=1433

What does the test from our container host say now?

PS C:\Users\kvaes> Test-NetConnection -Port 1433 -ComputerName Localhost

ComputerName : Localhost
RemoteAddress : ::1
RemotePort : 1433
InterfaceAlias : Loopback Pseudo-Interface 1
SourceAddress : ::1
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms
TcpTestSucceeded : True

And now it works! In all honesty, I find this a serious flaw in the Windows implementation and truly annoying to anyone making the shift from containers in the Linux ecosystem to the Windows ecosystem.