Register for Semperis' Hybrid Identity Protection (HIP) Conference - June 30 - July 1 Register for Semperis' Hybrid Identity Protection (HIP) Conference - June 30 - July 1
Microsoft Azure

How to Architect an Azure Firewall with a VPN Gateway

In this post, I will show you how to architect an Azure Firewall deployment where a centralized firewall will inspect traffic that is flowing across a VPN connection before it reaches the Azure virtual network(s) or returns to on-premises.

Design Concept

The premise of this design is a simple and, probably, a familiar one: anything outside of the “virtual data center” that you deploy in Azure virtual networks will not be trusted – and that includes the networks in your office that will be connected via a VPN (or ExpressRoute) connection.

In summary, the design will feature a hub virtual network that hosts shared services. In this case, the shared services will be:

  • The Azure Firewall.
  • A VPN Gateway with a connection to the on-premises network.

All traffic coming from the office, over the VPN connection, will be routed through the Azure Firewall before it can be forwarded to applications, which are hosted in spoke virtual networks. Data from the applications to the office network(s) will route via the Azure Firewall, and then to the gateway which will tunnel the traffic across the VPN connection.

Routing traffic across a VPN connection through the Azure Firewall [Image Credit: Aidan Finn]
Routing traffic across a VPN connection through the Azure Firewall [Image Credit: Aidan Finn]

Hub Virtual Network

This is a relatively simple virtual network with two subnets:

  • AzureFirewallSubnet: This is required to host the Azure Firewall. The firewall has a single public IP address, which you should note for the “destination address” in NAT rules, and a single internal IP address, which you should note for creating route tables in the other subnets.
  • GatewaySubnet: This subnet will host the VPN gateway.

A route table will be created and associated with the GatewaySubnet subnet. A route to the address space(s) being used by the application virtual networks will route all traffic via the internal IP address of the Azure Firewall. Let’s say that you will use the following addresses:

  • 10.0.0.0/8 for all of the address spaces in your Azure virtual networks that are peered with this hub virtual network.
  • 10.0.1.4 for the internal IP address of the Azure Firewall.

The user-defined route that you will create will be as follows:

  • All traffic to 10.0.0.0/8
  • Next hop type of virtual application
  • Virtual appliance address of 10.0.1.4.

Note that the local network definition that you use for the VPN connection will create system-managed routes for returning traffic back across the VPN tunnel to the office.

VNet Peering

Each application or service is deployed into a dedicated virtual network with one or more subnets. Remember that each subnet has its own route table that, by default, contains only system-managed routes.

VNet peering will be used to share the resources of the hub virtual network with the spoke VNets that contain the applications. There is always a pair of configurations between peered virtual networks. In this case:

  • Hub -> Spoke: Enable Allow Gateway Transit
  • Spoke -> Hub: Enable Forwarded Traffic and Use Remote Gateways

Note that Use Remote Gateways can only be enabled in the spoke VNets once the hub gateway is complexly deployed and in a running state. Attempting to configure this setting while the gateway is in a creating state will fail because the route cannot be propagated to the gateway.

Application Virtual Network(s)

By default, each subnet in those VNets will attempt to use an automatically propagated system route: send all traffic to on-premises via the gateway across the peered connections. However, we want to take control of this routing and force traffic from the spokes to pass through the Azure Firewall before reaching the gateway.

To accomplish this, you will create and associate a route table resource for each spoke subnet that must communicate with on-premises networks. If 192.168.1.0/24 was the address space of the on-premises network(s) and 10.0.1.4 was the IP address of the Azure Firewall, the route in these tables would be:

  • All traffic to 192.168.1.0/24
  • Next hop type of virtual application
  • Virtual appliance address of 10.0.1.4.

Azure Firewall

Now the Azure Firewall is in control of everything flowing between on-premises and your applications running in Azure virtual networks. You can create Network Rule Collections to allow or deny (everything is denied by default) traffic flows as required.

On-premises is now considered external to and untrusted by your “virtual data center” in Azure – and that means you’ve created a form of isolation between malware on your user device networks and the valuable services and data in The Cloud.

Related Topics:

BECOME A PETRI MEMBER:

Don't have a login but want to join the conversation? Sign up for a Petri Account

Register
Comments (3)

3 responses to “How to Architect an Azure Firewall with a VPN Gateway”

  1. ThomasCel

    I am still wondering would it be okay if I use an outsourced VPN service with Azure? I am wondering precisely about NordVPN Teams as I saw they save "seamless logins" with Azure AD? 

  2. catmir

    Hello,

    I'm seeking some ways to create an Azure VPN connection that will get me the same results as the 3rd party solutions out ther NordVPN, Perimeter81, meaning that all the traffic will be secured and routed through Azure also these solutions will give you a private Gateway so everyone connecting will get the same Gateway IP, is this possible?

  3. akhasfarooq

    Hi,


    Great atricle, exactly what I was looking for.


    I have a question about the exact order of placement of the Azure Firewall and VPN Gateway and the Public IP Address assignment.


    In your picture you have a Public IP address assigned to the Azure Firewall and another to the VPN Gateway. Do you place the firewall first and then the VPN Gateway sitting behind the firewall? Is the Public IP address assigned only to the Azure firewall? How does this exactly work.


    Many Thanks


    Akhas

Leave a Reply

Aidan Finn, Microsoft Most Valuable Professional (MVP), has been working in IT since 1996. He has worked as a consultant and administrator for the likes of Innofactor Norway, Amdahl DMR, Fujitsu, Barclays and Hypo Real Estate Bank International where he dealt with large and complex IT infrastructures and MicroWarehouse Ltd. where he worked with Microsoft partners in the small/medium business space.

Register for the Hybrid Identity Protection (HIP) Europe Conference!

Hybrid Identity Protection (HIP) Europe 2021 - Virtual Conference

Mobile workforces, cloud applications, and digitalization are changing every aspect of the modern enterprise. And with radical transformation come new business risks. Hybrid Identity Protection (HIP) is the premier educational forum for identity-centric practitioners. At the inaugural HIP Europe, join your local IAM experts and Microsoft MVPs to learn all the latest from the Hybrid Identity world.