Petri Newsletter Sign-up
Tech Tuesday

Subscribe to Tech Tuesday, the latest insights from Petri.com for IT Pros.

    See All Petri Newsletters

    How to Architect an Azure Firewall with a VPN Gateway

    Posted on by Aidan Finn in Microsoft Azure

    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.

    BECOME A PETRI MEMBER:

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

    Register