The course is part of these learning pathsSee 2 more
Introduction to Azure Virtual Networking (ARM)
Cloud based virtual networks are software based, and they provide a standard way to organize and isolate Virtual Machines running in the cloud. A virtual network controls addressing, DNS settings, security policies, and routing tables.
Virtual Networks which are commonly referred to as “v-nets”, are isolated from one another. Due to the isolation you can create networks for development, testing, and production that use the same address blocks.
To allow even further isolation, v-nets support subnets, which allow you to segment the network. Subnets will allow you to break out VMs by their purpose, which is common with tiered architectures. For example, if you have an application broken out into front-end and back-end tiers, then you might want to create two subnets, one for the front-end VMs, and another for the back-end tier.
If you're familiar with traditionally networking componets then you're going to feel right at home working with v-nets. So, if you're looking to learn more, then start in on the first lesson!
Azure Virtual Networking (ARM)
|Lecture||What you'll learn|
|Intro||What will be covered in this course|
|Overview||The componets of virtual networks|
|Creating a v-net||Creating a virtual network part 1|
|Completing the v-net||Creating a virtual network part 2|
|Application Gateway||The application load balancer|
|User defined routes||Using route tables|
|Traffic Manager||DNS based load balancing|
|Hybrid networking||VPNs and express route|
|Final thoughts||Wrapping up the course|
Welcome back! In this lesson we’ll cover the Azure application load balancer, named Application Gateway.
Previously we talked about the Azure Load Balancer, so you might be wondering how this is different. And that’s a great question.
The Azure Load Balancer is a Layer 4 load balancer. Which basically means it’s a networking load balancer. It’s distributes TCP or UDP packets without any consideration to any higher level protocols, such as FTP, HTTP, SMTP, etc.
Application Gateway is considered a layer 7 load balancer, which means it’s an application load balancer. In particular it’s used for web based applications since it speaks HTTP.
Using a layer 7 based load balancer has some perks that layer 4 doesn’t offer. Such as options for traffic routing and a web application firewall.
The Application is a dedicated virtual appliance that is managed by Microsoft. Because it’s a virtual appliance it’s basically a managed set of Azure VMs preloaded with software to filter and route all of the requests.
Let’s take a look at the features before getting our hands dirty.
You get round robin based load balancing.
There’s SSL termination, which terminates the SSL connection on the virtual appliance, and then forwards the requests on unencrypted. If you’re running your web servers in the same v-net this could be viable option. It saves the processing power of web servers, because they don’t need to handle the encryption and decryption.
Application Gateway also supports end-to-end SSL by terminating at the virtual appliance like I mentioned a moment ago, however it then re-encrypts the traffic before sending it to the servers.
Because this is happening at layer 7, the HTTP requests can be directed based on the URL. URL based routing allows you to direct requests to different back-ends. This sort of thing tends to work well when you want to be able to scale the different back-end pools independently.
Application Gateway also supports cookie based sticky sessions, which will help while transitioning from stateful to stateless applications. It supports health monitoring, and web sockets, and it also has a web application firewall.
The firewall is offered as a separate SKU, to distinguish it from the original appliance without the firewall.
The web application firewall, which is also call a WAF allows you to filter out known attack patterns without the need to handle in the application’s code. That doesn’t mean you shouldn’t consider security best practices for your code, however it does serve as a second line of defense.
The WAF is configured by default with the firewall rules from ModSecurity, which includes rules for the OWASP top ten. If you’re not familiar with OWASP, I recommend checking it out.
The rules include filters for:
The end result is that requests that match known malicious signatures can be either detected or prevented. In detection mode you can report on what’s happening, where prevention mode will block anything considered to be malicious by returning a 403 HTTP status code.
Application Gateway is useful enough as a web application load balancer, however the inclusion of the WAF makes this a great way to manage HTTP based apps.
In the previous lessons we set up a vnet with an application server, and web server using nginx as a reverse proxy. We’ll what if we could omit the the front-end subnet all together? Application Gateway is a reverse proxy, and it allows us to cut out the nginx tier from our solution. So let’s see what it might look like to replace all of this, the public load balancer, the front-end subnet, and front-end VM, with Application Gateway.
Before we can create an application gateway we need to create a new empty subnet for it. So let’s do that. I’ll drill into the vnet, and select subnets, and click add.
The only setting required for this is the name, the rest of the options are fine with the defaults, so let’s create this.
Okay now it’s time to create the application gateway, so let’s click new, and networking, and application gateway.
We’ll start out with the name, let’s call this application gateway.
There are two tiers to choose from, the Standard and the web application firewall. I’m going to select the firewall option.
In order to meet the SLA, there has to be at least 2 instances, so let’s set it to two. Also, you can see there are two options for the SKU size, which are medium and large. Let’s leave it set to medium.
Next we need to set the resource group. Okay, that’s everything on this blade, so let’s move on to the next.
First we need to select the vnet, and subnet to deploy this to, so I’ll select the ca vnet.
And then by default, it’s going to select the only empty subnet available on this vnet.
Since Application Gateway is going to be the new public entry point for this solution, it needs a public IP address.
So, let’s created a new IP address, and let’s name it application-gateway-ip.
There are some additional settings here for the protocol and port, which are fine for this solution. We could optionally disable the firewall component, which I won’t do here.
And the we have the option to set the firewall mode. This is what I mentioned before, where you can use detection or prevention mode. I want to show you what prevention looks like, since detection is only going to log issues.
Alright, let’s move on to the next blade to review the settings, and create this resource. Since we’re happy with the settings, let’s click okay.
Okay, this is going to take a while. If you’re following along, don’t be surprised if you have time to have an entire meal while this does its thing.
So, I’ve jumped ahead to once this is complete, and now we can edit the configuration.
There are two things we need to do, we need to tell Application Gateway which port our web app runs on, and we need to add the back-end load balancer’s IP address to the backend pool.
Since both need to happen before this is working, there’s no particular order this needs to happen in. So let’s set the port to 5000.
To do that click on the HTTP Settings and edit the existing, default option. We need to change the port to 5000, and save this. Changing settings takes a while to updates, so again, it’s time to jump forward.
Okay, that took a couple minutes, though, now we’re here on the back-end pools blade and we need to add the internal load balancer’s IP address to the pool. So let’s click on the default pool.
I’m going to paste this in, and save this. And then I’ll jump forward.
Okay, it took a couple minutes, however we’re back and ready to test this out. So, on the overview tab, let’s browse to the public IP address.
Notice we get this scary looking 403 error. You might be thinking that something was configured incorrectly, however this is actually what we should be seeing.
When you use prevention mode for the firewall, it returns a 403 for anything that it considers to be potentially malicious.
The reason that it’s considering this request to be potentially malicious is because it’s using the IP address, and not a URL. So, let’s try this again with the Azure supplied DNS name.
On the overview tab, if I copy this and open it in the browser, you can see that it displays the message from the back-end web app. Which means all of this works.
We’re not going to delve into all of the things the WAF will protect you from, however, check this out, if I was to add some SQL to a URL parameter, the WAF will flag it as malicious and return a 403. The same would apply for other issues that are deemed malicious.
So, let’s see what we’ve actually accomplished. Previously we had a vnet with two subnets, and we had to configure the front-end web servers for ourselves. Now, we’ve replaced the public load balancer, the front-end subnet and the front-end VM. And in its place we have Application Gateway in its own subnet.
By using application gateway, we’re able to cut out a significant amount of management from our solution, because it’s managed by Microsoft.
Application gateway is great option when you’re hosting web applications, especially due to the firewall.
Alright, that’s going to wrap up this lesson, in the next lesson we’ll talk about another component of virtual networks, called user defined routes. So, if you’re ready to keep learning, then let’s get started in the next lesson!
- Azure Virtual Networking Course
- Azure Virtual Networking Overview
- Creating a V - Net part 1
- Creating a V - Net part 2
- Application Gateway
- User defined routes
- Traffic manager
- Hybrid Networking VPN
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.