A few weeks ago the “HA Ports” (finally) saw the light (in public preview)! I’m truly excited about this one, as it had become a “unicorn” for me over the last years.
Why am I so excited about this one? This unlocks of advanced networking patterns, starting with a truly HA setup for the Network Virtual Appliances (NVAs). In the past, we needed to rely on “workarounds” that would switch the UDR to point to the surviving node. That was great for the time, but let’s be honest… It shouldn’t have been like that.
Another use case is the scenario where an application needs to connect to a certain dynamic port ranges (like with SQL). I’ve seen several deployments annoyed by this requirement, which then forced people to create a lot of rules. This can now be avoided by allowing the entire port range, and just hardening it with a “Network Security Group” or Firewall rule base.
Continue reading “Azure Star / Any Load Balancer or … like we would like to call it “HA Ports””
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 ;
- “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.
- “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;
- “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.
- “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”.
- “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.
- “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”
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.
For today, we’ll be building the following setup ;
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?”
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.
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)”
Ever heard of the azure application gateway? No… I understand. It is (strangely enough) a component that is often overlooked. In essence, what does it do? Look at it as a load balancer on security steroids. The basic form will help you in terms of SSL offloading, where the advanced form will turn it into a WAF.
Continue reading “Azure Application Gateway : Often overlooked…”
When you set up your Application Gateway on Azure, and you’re getting the following message…
Then you know you are in a world of pain in order to debug this. So before we continue, please help to avoid this pain by voting on the user voice! 😉
Continue reading “Azure Application Gateway : Debugging the dreadful “502”-error”
When setting up a load balancing rule in Azure, you’ll be given the opportunity to enable/disable “Direct Server Return”.
So what does it do?
Apart from disabling the “backend port” input field, what does it do? Clicking on the “?” gives us a start…
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.