On a recent project, a client had a requirement for all Public IP addresses to be part of a Pubic IP Address Prefix. This ensured they could both re-use and predict their IPs. Greatly simplifying Governance requirements and white-listing with partners.
However, once the Prefix was active, I went to create a Virtual Network Gateway to test some connectivity options. Being a simple test, I was using the Portal for deployment. I realised that the parameter defaults prevent you from using a Prefix IP as they are on the Standard SKU by default. If you’re creating a single VNG that is not linked to an Availability Zone, the Portal looks for a Basic SKU and you receive this error:
Now a quick fix was to simply select one the AZ SKUs, but I didn’t want that. Thankfully, Cloud Shell was my answer. Out of curiosity, I then tried the same process, but via Powershell. Using the exact same resources and parameters.
And…success! My guess is the flag that prevents you from using a Standard SKU Public IP address for a VpnGw1 SKU VNG is a parameter limitation rather than a technical one. The VNG works exactly as expected.
Hopefully this can save you some time if you find yourself in the same situation!
Bonus tip! When working in Cloud Shell, if there is a parameter you are unfamiliar with and not sure what it expects as input, type out the parameter and hit tab, it will list all allowed inputs:
About a year ago, Microsoft introduced the first release of Azure Firewall. Since then, and since its general release the service has grown and the features have matured.
To begin, let’s understand what Azure Firewall is? At its core it’s a managed, network security service that protects your Azure Virtual Network resources. It functions as a stateful firewall-as-a-service and offers built-in high availability and scalability. This means you can centrally control, enforce and log all of your network traffic. It fully integrates with Azure Monitor too which means all of the usual logging and analytical goodness.
If the above sounds like something you’d like to use, or at least try, in your Azure environment, read on! To start, let’s break out what can be configured within Azure Firewall and which features could be useful for you.
When deploying an Azure Firewall, you need a couple of things in advance. It needs a dedicated subnet, specifically named “AzureFirewallSubnet” and the minimum size it can be is a /26. It also needs at least one Static Public IP. The Public IP must be on the Standard tier. My recommendation here is to look at creating a Public IP Prefix in advance of creating your Azure Firewall. That way, if you need to delete it and redeploy, you can continue to use the same Public IP again and again. If you want to use multiple Public IPs, it supports up to 100.
So, let’s look at what Azure Firewall (AFW) can do for you on your Virtual Network and then consider some deployment options.
Using your single, or multiple Public IP addresses, AFW allows both source and destination NATing. Meaning it can support multiple inbound ports, such as HTTPS over 443 to different resources. Outbound SNAT helps greatly with services that require white-listing. If you are using multiple Public IPs, AFW randomly picks one for SNAT, so ensure you include all of them in your white-listing requirements.
AFW uses a Microsoft service called Threat Intelligence filtering. This allows Azure Firewall to alert and deny traffic to and from known malicious IPs and domains. You can turn this setting off, set it to just alert or to both alert and deny. All of the actions are logged.
Finally, for filtering, AFW can use both Network Traffic and Application FQDN rules. This means that you can limit traffic to only those explicitly listed within the rule collections. For example, an application rule that only allows traffic to the FQDN – www.wedoazure.ie
A visual representation of the above features is below:
Now that you understand AFW, let’s look at how to configure to your needs. Normally I would go into the deployment aspect, but it is excellently documented already and relatively easy to follow. However, there are some aspects of the configuration that warrant further detail.
Once deployed, you must create a Custom Route Table to force traffic to your AFW. In the tutorial, it shows you how to create a route for Internet traffic (0.0.0.0/0), however you may want the AFW to be your central control point for your vnet traffic too. Don’t forget, traffic between subnets is not filtered by default. Routing all traffic for each subnet to AFW could allow you to manage which subnet can route where centrally. For example, if we have three subnets, Web, App and DB. A single route table applied to each subnet can tunnel all traffic to AFW. On the AFW you can then allow Web to the Internet and the App subnet. The App subnet can access Web and DB but not Internet and finally the DB subnet can only access the App subnet. This would all be achieved with a single Network Rule collection.
Similarly you can allow/block specific FQDNs with an Application Rule collection. In the tutorial, a single FQDN is allowed. This means that all others are blocked as that is the default behaviour. This might not be practical for your environment and the good news is, you can implement the reverse. With the right priority order, you can allow all traffic except for blocked FQDNs.
Finally, and in some cases most importantly, let’s look at price. You are charged in two ways for AFW. There is a price per-hour-per-instance. That means if you deploy and don’t use it for anything, you will pay approx. €770 per-month (PAYG Calculator). On top of that, you will pay for both data inbound and outbound that is filtered by AFW. You’re charged the same price either direction and that’s approx. €14 per-Tb-per-month. Depending on your environment and/or requirements this price could be OK or too steep. My main advice is to ensure you understand it before deploying!
As always, if there are any questions please get in touch!
One of the most popular methods of connecting to Azure privately is via VPN. This can be a relatively simple process and is well documented by both Microsoft and 3rd party blogs. However, if you encounter problems, it can be difficult to get the data you need to troubleshoot efficiently. Especially if you don’t have access to both Azure and the local connection appliance.
In this post, I’m going to show you how to troubleshoot a Virtual Network Gateway and its VPN connection. As part of this, there are some required specifics:
If the above lines up with your environment, then let’s get started! (If not, get in touch and I might be able to help)
Troubleshoot a Virtual Network Gateway
Login to the Azure Portal, then click the search bar at the top, type “Network Watcher” and click on it to open your resource.
In the Network Watcher blade, under ‘Network Diagnostic Tools” select ‘VPN Diagnostics’.
You’ll have to choose a Storage Account and a Container within to run the tests. If you don’t have one, you can create one from Network Watcher. The Storage Account doesn’t have to be in the same location as your VNG.
Click the checkbox for the VNG you want to troubleshoot, then click ‘Start Troubleshooting’
Once complete, you will see your ‘Troubleshooting Status’, you can see that for mine above it is shown as ‘Unhealthy’. To get more details, there is a Details pane just below with a ‘Status’ blade giving you more information about the problem and an ‘Action’ blade which gives suggestions on how to resolve the issue.
In this instance, the VNG as a resource is healthy, but the Connection it’s facilitating is not, so we need to dig further.
Troubleshooting a Virtual Network Gateway Connection (VPN)
In the same location we ran troubleshooting for the VNG, we will repeat the steps and select the Connection instead of the VNG this time. Select your Storage Account etc. as before and then click the Connection to troubleshoot. Then click ‘Start Troubleshooting’
Once complete, you will again see a ‘Troubleshooting Status’ and can get more information from the ‘Details’ pane.
As you can see from the above, I have a very simple fix to make, as my pre-shared keys do not match.
Hopefully this helps you out when trying to figure out why those VPN tunnels aren’t working.
As always, if you have any questions, get in touch!
Application Gatway v2 brings several welcome additions to the service since it’s initial v1 release. For those who have spent time configuring an Application Gateway, you’ll be glad to hear that udpate/modification times have been drastically reduced. Better performance and the addition of functionality are some of the other main reasons to use v2 over v1. The entire list can be found here.
Recently, I had to secure an Application Service with an Application Gateway v2 on the WAF (web application firewall) tier. This is something I have done several times with v1 without any significant issue. In this instance the Application Service runs on a custom domain as does the Application Gateway. Requirements were to run SSL end to end and have WAF run in prevention mode.
If you’ve ever done this before, you know there are some basics to be completed within your Application Service. For this post and my requirement, they were map a custom domain, runs HTTPS only and prep rules to allow connections only from your Application Gateway. How to do all of that can be found at the following links:
Once your Application Service is ready to go, you move on to configuring your Application Gateway. This is a relatively simple process and can even be completed within the Portal. There is a published guide here. However, once it was configured, I noticed that certain redirect functionality aspects of the application were returning the default host name of the Application Service. This can also happen if you use Azure AD authentication. With WAF in prevention mode, this returns a 403 as a default rule picks up the change in address.
The reason for this is how both Application Gateway and Application Service handle their host headers. To fix this issue, there are two changes you can make, one of which that is only possible on Application Gateway v2.
The v2 only fix is to rewrite the location in the host header using rewrite rules. Rewrite rules are new functionality only included in v2. A guide on what you need to do exactly is here. Make sure the text is exactly as in the guide or it will not work.
The second option, and the one that is more common is to change how your Custom Probe and HTTP settings are configured. The reason for this is that the default guide does not take into account the use of a custom domain on your Application Service. For both settings, modify and remove the ” PickHostNameFromBackendAddress” setting. Now, the Application Gateway will forward the same hostname and redirection will happen on the same too. Full guide here.
As always, if there are any questions on the above, get in touch!
Microsoft released an introduction video to Azure Bastion a couple of days ago and today a new post has gone live giving us all the details of Azure Bastion in its preview state.
First up, what is a Bastion? Often referred to as a jumpbox, jumphost or bastion host, it’s a server which provides access to a private network from an external network, most commonly the Internet. As it’s exposed to potential attack, bastion hosts must be designed to minimize risk of penetration. As this connectivity function is so widely used, bastions are quite common in the majority of environments. The alternative is to increase your perimeter exposure by allowing public access to your private resources directly. Little tip from me, please don’t do this!
However, management and administration of these hosts can be a complex and time consuming task. Thankfully, Microsoft have introduced a new PaaS based service – Azure Bastion. Which allows managed, seamless access to VMs in your private network via RDP and SSH over SSL.
Azure Bastion is provisioned directly into a virtual network, which allows bastion host and integrated connectivity to all virtual machines within that vnet using RDP/SSH directly from and through your browser via the Azure Portal.
Microsoft list the following as key features available right now as part of the preview:
RDP and SSH from the Azure portal: Initiate RDP and SSH sessions directly in the Azure portal with a single-click seamless experience.
Remote session over SSL and firewall traversal for RDP/SSH: HTML5 based web clients are automatically streamed to your local device providing the RDP/SSH session over SSL on port 443. This allows easy and securely traversal of corporate firewalls.
No public IP required on Azure Virtual Machines: Azure Bastion opens the RDP/SSH connection to your Azure virtual machine using a private IP, limiting exposure of your infrastructure to the public Internet.
Simplified secure rules management: Simple one-time configuration of Network Security Groups (NSGs) to allow RDP/SSH from only Azure Bastion.
Increased protection against port scanning: The limited exposure of virtual machines to the public Internet will help protect against threats, such as external port scanning.
Hardening in one place to protect against zero-day exploits: Azure Bastion is a managed service maintained by Microsoft. It’s continuously hardened by automatically patching and keeping up to date against known vulnerabilities.
And they list the following as on the roadmap for future release:
The future brings Azure Active Directory integration, adding seamless single-sign-on capabilities using Azure Active Directory identities and Azure Multi-Factor Authentication, and effectively extending two-factor authentication to your RDP/SSH connections. We are also looking to add support for native RDP/SSH clients so that you can use your favorite client applications to securely connect to your Azure Virtual Machines using Azure Bastion, while at the same time enhance the auditing experience for RDP sessions with full session video recording.
There are a couple of things to note as the service is in preview. As always, be wary deploying for production, there is no SLA yet.
The preview is limited to the following Azure public regions:
South Central US
You have to register the resource provider manually to make use of the preview, instructions on how to do that here.
To use the Azure Bastion service, you need the following roles:
Reader role on the virtual machine
Reader role on the NIC with private IP of the virtual machine
Reader role on the Azure Bastion resource
Once you’re OK with all of the above, you can simply click connect on any of your VM resources and a new Bastion tab is available. From here you can launch your session to the VM right in the browser, which is pretty slick as it provides copy and paste and full screen functionality already.
One item I noticed from the FAQ is that you may need to use the preview link to access the resource deployment blade from the portal – https://aka.ms/BastionHost
Also of note, pricing! On the FAQ it states you will be billed partially. Not 100% sure what that means, so watch those usage rates. The pricing page is live however so check it out in advance here.