In Microsoft Azure, routing to the internet works slightly differently than it would on-premises. When you build a machine out of a catalogue, all you can choose is the subnet that it goes into. The networking is handled from the Azure portal, and when you connect onto that VM and browse the internet, you might notice you get a different IP each time / from each VM.
Note: You get a lot more granularity with extra options if you build via PowerShell, however most admins will probably build it from the browser.
Once the VM is built, you can make its IP address static as well as change the DNS servers. This would be the case if you wanted to reference an Azure VM or on-premises domain. Each time the VM is rebooted, it resets its NIC back to DHCP and thus manually editing it will almost certainly cut your access off. Everything networking-wise needs to be done from the Azure platform itself.
To route all of your internet traffic out via a single IP, things get both trickier, and more expensive. The best way so far has been to implement an Azure-based firewall from the likes of Cisco, Palo Alto or Sophos. Even better if you’re already using one of their devices on-premises.
Microsoft released the Azure Firewall (after some time in public preview) in September last year. It is essentially a virtual appliance, managed in the same way as everything else is managed. It’ll get its own private IP address in a new subnet (“AzureFirewallSubnet”) which falls under either a new or existing VNET. You can manually create the subnet, or leave it to be created automatically.
Note: it needs to be in an IP block of /26 or less, although you might use far less than the 59 available IPs. That’s another point – you’re limited to ONE Azure Firewall per VNET.
I’ve manually created it here:
Creating the firewall is as straightforward as can be, too:
Routing everything outbound through the firewall is pretty easy. In your Azure Route Table, create a new route (0.0.0.0/0) with the next hop type set to “virtual appliance”, put its private IP address in and away you go.
By default, everything will be blocked, so you need to create some rules before your VMs will have internet access. This, in my opinion, is great for things like RDS and Citrix in Azure. My only gripe with it is the cost – saying that though, you do get quite a lot of functionality built-in. You pay for ingress and egress traffic, as well as the actual appliance itself. There’s no way to shut it down, so to spin one up you’ll be paying just under £1 per hour – 730 hours a month – it’s not cheap!
Note: The other way to route traffic to the internet is by using an Azure Load Balancer. By creating dummy LB rules – tied to a public IP – which is clunky to say the least, you can force traffic out via a single IP. As always, keep security in mind and don’t give all of your Azure IaaS VMs their own public IPs.
I’ve created a demo VM here, which had a public IP assigned to it with RDP open – you can see my RDP connection won’t work because the Azure Firewall is blocking it:
I removed the VM’s public IP, and created a rule to allow it through the firewall from my IP.
Straight in, and my IP is the public IP of the firewall:
What if you have more than 1 VM you want to RDP to? NAT is a great way to go about it, with port translation. So I can RDP to the single public IP and use a different port for a different VM:
So in summary, I’m a fan. You’ll never get the granularity for outbound web filtering as other paid “premium” solutions, but you get a good solution that’s Azure-native and tied to everything else. For analytics, reporting, and the “holistic package” view, it’s great. Right, I’m off to delete it all so that it doesn’t eat all my credit up.
Here are my rules …
Outbound traffic from Azure VNET / Subnet.
Inbound NAT rule from my IP.
Inbound Firewall rule to allow connections.
Leave a Reply