REFERENCE ARCHITECTURE
Download PDF

Barracuda CloudGen Firewall for Azure - HA Cluster

High Availability Cluster in an Availability Set using an Internal Standard Load Balancer

Introduction

To provide high availability in the Azure platform, a VM needs to use a Load Balancer or use the Cloud platform's Rest API cloud integration to adapt the platform on failover. For several years, the Barracuda CloudGen Firewall (FW, also referred to as NGF) uses cloud integration functionality to perform UDR rewriting to redirect traffic when an HA failover happens. This method works well for smaller deployments, but has few drawbacks when using peered VNets or if corporate policy restricts saving AAD authentication keys in 3rd party software configurations.

By leveraging the Azure Standard Load Balancer, these drawbacks can be solved, providing failover capabilities with no integration with the cloud fabric. This also provides shorter failover times (~15 seconds) independent of network complexity, and provides stateful failover.

This template deploys a VNet with 2 FW instances with managed disks, an any-port ILB instance, and 2 empty subnets routed through FW cluster.

Prerequisites

The solution does a check of the template when you use the provided scripts. It does require that Programmatic Deployment is enabled for the Barracuda CloudGen Firewall BYOL or PAYG images. Barracuda recommends use of D, D_v2, F or newer series.

Deployed Resources

The following resources will be created by the template:

  • One Azure vnet with 3 subnets (1 for the FW, additional subnets for a red and green subnet)
  • Two route tables that will route all traffic for external and towards the other internal networks to the Barracuda FW
  • One internal standard Azure Load Balancer as the default gateway for all traffic that needs inspection
  • One external standard Azure Load Balancer containing the deployed virtual machines with a public IP and services for IPSEC and TINA VPN tunnels available
  • Two Barracuda CloudGen FW virtual machines with 1 network interface each and public IP
  • Both FW systems are deployed in an Availability Set

Note: Additional backend subnets and resources are not automatically created by the template. This has to be done manually after template deployment has finished or by adapting the ARM template.

Deployment

Deployment of the ARM template is accomplished via the Azure Portal, Powershell or Azure CLI. The package provides deploy.ps1 and deploy.sh for Powershell or Azure CLI based deployments. This can be performed from the Azure Portal as well as any other system that has either of these scripting infrastructures installed. Alternatively, you can deploy from the Azure Portal using the provided link.

Azure Portal

To deploy via Azure Portal you can use the button below to deploy this reference architecture into your Azure subscription. Once you click on this, the Azure Portal will ask you for your credentials and you are presented with a page to fill in the minimal variables: resource group, location, Admin password and Prefix. Click here to view how to deploy to Azure and click here to view the visualization chart.

Azure CLI

To deploy via Azure Cloud Shell you can connect via the Azure Portal or directly via https://shell.azure.com/.

  • Start up Azure Cloud Shell from the Azure Portal or go directly to https://shell.azure.com
  • Download the latest version of the ARM templates in the persistent clouddrive:

cd ~/clouddrive/ && wget -qO- https://github.com/barracudanetworks/cloud-reference-architectures/archive/master.zip | jar x && cd ~/clouddrive/cloud-refernce-architectures/Quickstart-Azure-CGF-HA/ && ./deploy.sh

  • Answer the questions asked by the script for the following variables: location, prefix and password

Azure Powershell

To deploy via Azure Cloud Shell, you can connect to the Azure Cloud Shell via https://shell.azure.com/.

  • Start up Azure Cloud Shell from the Azure Portal or go directly to https://shell.azure.com
  • Download the latest version of the ARM templates in the persistant clouddrive:

cd ~\clouddrive\; Invoke-WebRequest -Uri "https://github.com/barracudanetworks/cloud-reference-architectures/archive/master.zip" -OutFile "~/clouddrive/master.zip"; jar xf master.zip; cd "~/clouddrive/cloud-reference-architectures-master/Quickstart-Azure-CGF-HA/"; .\deploy.ps1

  • Answer the questions asked by the script for the following variables: location, prefix and password

Next Steps

Administration of the Barracuda CloudGen Firewall appliance is typically done with a Windows-based client application called the Barracuda CloudGen Firewall Admin.

Note: The username to log in to the appliance is root and the password is the one you have set in the Azure portal while deploying the VM. Also, a forward for TCP/807 and TCP-UDP/691 endpoints will be created automatically when you deploy this VM.

Post Deployment Configuration

You need to manually create a firewall App Redirect rule for ILB Probe traffic. The connection will use the port you indicated during template deployment and it will originate from 168.63.129.16, and can be redirected to any service running locally on FW (e.g. 127.0.0.1:450 for firewall authentication service or 127.0.0.1:691 for FW TINA VPN).

Sign in to the FW and navigate to the CONFIGURATION menu. Click on “Configuration Tree” and navigate through the folders:
Virtual Servers > S1 EXPORT > Assigned Services > NGFW > Forwarding Rules

Double-click on “Forwarding Rules” to open the forwarding firewall rules page. Click “Lock” in the upper right corner. You’ll insert a new rule right before the LAN-2-INTERNET rule. Right-click on LAN-2-INTERNET and click New > Rule. A new window opens. Make the following changes:

  • Change “Block” to “App Redirect”
  • Change name from “NewRule” to “AZURE-LB-PROBE-Redirect”
  • Source: Click drop-down and select “”. In the grid immediately below the drop-down, right-click and click Edit… A new window opens.
  • Click the green + under “Include Entries” and in the “IP” field put “168.63.129.16/32” then click “Insert and Close” and click “OK”
  • Service: Click drop-down and select “”. In the grid immediately below the drop-down, right-click and click Edit… A new window opens.
  • Click “New Object” and in the “Port Range” field put “65500” then click “OK” and “OK” again.
  • Destination: Click drop-down and select “Management IP”
  • In the Redirection Local Address field put “127.0.0.1:450”

The rule configuration should look like this:

Click “OK” then click “Send Changes” and “Activate” then “Activate”

For more information on App Redirect rule consult Barracuda Campus: How to Create an App Redirect Access Rule

Create a destination NAT rule to allow external inbound traffic on a specific port to be routed to a host behind the firewall. See How to Create a Destination NAT Rule for more details.

It is also recommended you harden management access by enabling multifactor or key authentication and by restricting access to management interface using Management ACL: How to Change the Root Password and Management ACL

Template Parameters

Parameter Name Description
adminPassword Password for the Firewall Admin tool
prefix Identifying prefix for all VM's being build. e.g WeProd would become WeProd-VM-NGF (Max 19 char, no spaces, [A-Za-z0-9]
vNetAddressSpace Network range of the vnet (e.g. 172.16.136.0/22)
subnetNGF Network range of the subnet containing the CloudGen Firewall (e.g. 172.16.136.0/24)
subnetRed Network range of the red subnet (e.g. 172.16.137.0/24)
subnetGreen Network range of the green subnet (e.g. 172.16.138.0/24)
imageSKU SKU Hourly (PAYG) or BYOL (Bring your own license)
vmSize Size of the VMs to be create
ccManaged Is this instance managed via a CloudGen Firewall Control Center (Yes/No)
ccClusterName The name of the cluster of this instance in the CloudGen Firewall Control Center
ccRangeId The range location of this instance in the CloudGen Firewall Control Center
ccIpAddress IP address of the CloudGen Firewall Control Center
ccSecret Secret to retrieve the configuration from the CloudGen Firewall Control Center
v1.0
Specifications subject to change without notice.
Barracuda Networks and the Barracuda Networks logo are registered trademarks of Barracuda Networks, Inc. in the United States.
All other names are the property of their respective owners.