To safeguard against hardware and software failures in the Azure cloud, use a high availability (HA) setup. Most advanced networking features, such as static internal IP addresses or a reserved IP address for the Cloud Service, can only be deployed via Azure PowerShell. You can either enter the commands directly into the Azure PowerShell or combine the commandlets to a custom deployment script.
Both Barracuda NextGen Firewall F-Series VMs must be deployed in the same Azure Availability Set, so that the VMs run in different fault domains in the Azure datacenter. Both NextGen Firewalls are connected to the same Azure virtual network and use static internal IP addresses (DIPs). An Azure load-balanced endpoint (level 4 load balancer) can be used to offer TCP- and UDP-based services on the VIP.
Connecting to Services and Managing the HA cluster in the Azure cloud:
- Accessing Services in Azure/ on the NextGen Firewall F-Series – Create a Load-balanced Endpoint for each service accessed on or behind the Barracuda NextGen Firewall F-Series in Azure.
- Management Access – If you are not using a Barracuda NextGen Control Center to manage your NextGen Firewall F-Series use the following solution to be able to access both VMs with NG Admin:
- Create an Endpoint on port TCP/807 to manage the primary NextGen Firewall F-Series.
- Configure a Client-to-Site VPN. You can now reach the static internal IP address of the secondary NextGen Firewall F-Series through the Client-to-Site VPN.
Before you begin
Install the latest Windows PowerShell for Azure. (http://azure.microsoft.com/en-us/downloads/)
Step 1. Create an Azure Virtual Network
You must use a Regional VNET to deploy the Barracuda NextGen Firewall F-Series. Older VNets using Affinity Groups do not support the necessary Azure networking features. Configuration information of the VNet is stored in an XML file and then deployed in the Azure cloud via PowerShell commandlet. The following is an example vmnet.xml with 2 subnet:
<NetworkConfiguration xmlns="http://schemas.microsoft.com/ServiceHosting/2011/07/NetworkConfiguration"> <VirtualNetworkConfiguration> <VirtualNetworkSites> <VirtualNetworkSite name="NEVNET" Location="North Europe"> <AddressSpace> <AddressPrefix>10.0.0.0/16</AddressPrefix> </AddressSpace> <Subnets> <Subnet name="Frontend"> <AddressPrefix>10.0.30.0/24</AddressPrefix> </Subnet> <Subnets> <Subnet name="Backend"> <AddressPrefix>10.0.31.0/24</AddressPrefix> </Subnet> </Subnets> </VirtualNetworkSite> </VirtualNetworkSites> </VirtualNetworkConfiguration> </NetworkConfiguration>
- Open the Azure PowerShell.
If VNets already exist, export the existing Virtual Networks to an XML file.
Get-AzureVNetConfig -ExportToFile c:\azure\vmnet.xml
- Edit the vnet.xml file and enter the configuration for your VIRTUALNETWORKSITE. Use the example file above as a guideline. If you are using multiple network interfaces, create one subnet per network interface.
Upload the VNet configuration file:
Set-AzureVNetConfig -ConfigurationPath c:\azure\modified_vmnet.xml
The virtual network is now listed in VIRTUAL NETWORKS in the web UI, via PowerShell:
Get-AzureVNetSite -VNetName "YOUR VNET NAME"
Step 2. (optional) Use a reserved IP for the Azure cloud service
To avoid the difficulty of a changing public IP address when redeploying your Cloud Service, you can reserve a public IP address and assign it to your cloud service on deployment. This IP address persists even when the cloud service is deleted.
Create a Reserved IP address (RIP).
New-AzureReservedIP -ReservedIPName "RIP NAME" -Label "NextGen Firewall F-Series IP" -Location "YOUR LOCATION"
Enter the name of the Reserved IP address in the example deployment script below to always use the same public IP address for your Cloud Service.
Step 3. Create a storage account
Create a Storage Account and set it as the default storage account.
New-AzureStorageAccount -StorageAccountName "STORAGEACCOUNT NAME" -Location "YOUR LOCATION"
Use the storage account as the default storage account for this Azure subscription.
Set-AzureSubscription -SubscriptionName "YOUR AZURE SUBSCRIPTION NAME" -CurrentStorageAccountName "STORAGEACCOUNT NAME"
Verify that you are using the correct storage account:
Get-AzureSubscription
Step 4. Deploy two Barracuda NextGen Firewall F-Series VMs
Deploy the primary and secondary Barracuda NextGen Firewalls using PowerShell. You can change the example deployment script below to fit your needs and deploy both Barracuda NextGen Firewalls at the same time. Deploy the two NextGen Firewalls as to use:
- Static internal IP addresses in the Frontend subnet
- Assign both to the same Availability Set.
- Install and activate the license on the primary NextGen Firewall F-Series. The secondary NextGen Firewall F-Series receives the license through the HA-sync when the HA cluster is paired. For more information, see How to Activate and License a Stand-alone Hardware NextGen F-Series or Control Center Appliance.
Step 5. Create additional load balanced endpoints
The example script above creates a Load Balanced Endpoint for a TINA VPN using tcp by default. When creating Endpoints used for services that are not hosted on the Barracuda NextGen Firewall F-Series, you must configure the probe port and protocol to probe a service running on the NextGen Firewall F-Series to allow the load balancer to detect an HA failover. For example, when configuring a load balanced Endpoint for a web server behind the NextGen Firewall F-Series, configure the probe port and protocol to monitor the VPN service running on port 691 instead.
To add an additional Load Balanced Endpoint after the Barracuda NextGen Firewalls have been deployed, enter:
Get-AzureVM -ServiceName YOUR_CLOUD_SERVICE -Name YOUR_PRIMARY_BARRACUDA_NG_FIREWALL| Add-AzureEndpoint -Protocol tcp -LocalPort 443 -PublicPort 443 -Name "HA1HTTPS" -LBSetName "LBNAME" -DefaultProbe | Update-AzureVM
Get-AzureVM -ServiceName YOUR_CLOUD_SERVICE -Name YOUR_SECONDARY_BARRACUDA_NG_FIREWALL | Add-AzureEndpoint -Protocol tcp -LocalPort 443 -PublicPort 443 -Name "HA2HTTPS" -LBSetName "LBNAME" -DefaultProbe | Update-AzureVM
Step 6. Change the firewall network configuration to use the static internal IP addresses
Change the network configuration of the primary and secondary Barracuda NextGen Firewall F-Series to use a static network interface that you previously configured during deployment of the virtual machines.
Step 6.1 Reconfigure the network interface
Change the network interface type from dynamic to static.
- Log into the primary Barracuda NextGen Firewall F-Series.
- Go to CONFIGURATION > Configuration Tree > Box > Network.
- In the left menu, click on xDSL/DHCP/ISDN.
- Click Lock.
- Delete the DHCP01 entry in the DHCP Links list.
- Select No from the DHCP Enabled drop-down list
- Click Send Changes.
- In the left menu, click on IP Configuration.
- In the Management IP and Network section in the Interface Name line, disable the Other checkbox.
- Select eth0 from the Interface Name list.
- Enter the static internal IP address used in the deployment script in Step 4 as the Management IP (MIP). E.g.,
10.0.30.20
Step 6.3 Create the default route
Add the default route.
- In the left menu, click on Routing.
- Click + in the Routes table and configure the following settings:
- Target Network Address – Enter
0.0.0.0/0
- Route Type – Select gateway.
- Gateway – Enter the first IP address of the subnet the Barracuda NextGen Firewalls reside in. E.g.,
10.0.30.1
if the IP addresses of the Barracuda NextGen Firewalls are 10.0.30.20 and 10.0.30.21 - Trust Level – Select Unclassified.
- Target Network Address – Enter
- Click OK.
- Click Send Changes and Activate.
Step 6.4 Add and configure the second network interface
You must configure the second NIC on each NextGen Firewall F-Series. The second interface can be configured to be static of dynamic. If you are using a static network interface you must use the IP address you assigned to the second NIC of the VM during deployment. Add the second IP address to the Additional Local IPs as it can only be used as a box layer IP address. This address will not be switched over to the secondary NextGen Firewall F-Series during a failover.
- In the left menu, click on Interfaces.
- Click Lock.
- Double click on the netsvc entry in the Network Interface Cards list. The Network Interface Cards window opens.
- Set Number of Interfaces to 2.
- Click OK.
- Click Send Changes.
- In the left menu, click on IP Configuration.
- In the Additional Local IPs section, click + to add a IP Address Configuration. The IP Address Configuration window opens.
- Enter a Name.
- Click OK.
- Enter the following settings for the IP Address Configuration:
- Interface Name – Select eth1.
- IP Address – Enter the IP address you assigned to this interface during deployment.
- Associated Netmask – Select the netmask for this subnet.
- Responds to Ping – Select Yes.
- Trust Level – Select Trusted.
- Click OK.
- Click Send Changes.
Step 6.5. Activate the network changes
Activate the changes to the network configuration.
- Go to CONTROL > Box.
- In the Network section of the left menu, click on Activate new network configuration.
Click Force.
Step 6.6 Switch the NextGen Admin endpoint to the secondary NextGen Firewall
To access the secondary NextGen Firewall F-Series you can either configure a Client-to-Site VPN on the primary NextGen Firewall F-Series to access the MIP of the secondary NextGen Firewall F-Series, or switch the MGMT (TCP port 807) Endpoint to the secondary firewall:
Get-AzureVM -ServiceName YOUR_CLOUD_SERVICE -Name YOUR_PRIMARY_BARRACUDA_NG_FIREWALL| Remove-AzureEndpoint -Name "MGMT" | Update-AzureVM
Get-AzureVM -ServiceName YOUR_CLOUD_SERVICE -Name YOUR_SECONDARY_BARRACUDA_NG_FIREWALL| Add-AzureEndpoint -Protocol tcp -LocalPort 807 -PublicPort 807 -Name "MGMT" | Update-AzureVM
Step 6.7 Reconfigure the secondary firewall
Complete Steps 6.1 - 6.5 for the secondary firewall.
Both Barracuda NextGen Firewall F-Series systems are now using the static 'eth0' network interfaces (CONTROL > Network).
Step 7. Create a DHA cluster configuration
Create a DHA cluster configuration. Switch the Endpoint to the primary NextGen Firewall F-Series (see Step 6.6.).
- Log into the primary Barracuda NextGen Firewall F-Series.
- Go to CONFIGURATION > Configuration Tree.
- Right-click on Box and select Create DHA Box.
- Go to CONFIGURATION > Configuration Tree > HA Box > HA Network.
- Select eth0 from the Interface Name list.
- Enter the static IP address of the secondary Barracuda NextGen Firewall F-Series as the Management IP (MIP). E.g.,
10.0.20.7
- In the left menu, click Routing.
- Verify the default route is present. (0.0.0.0/0 gateway XX.XX.XX.1).
- In the left menu, click on IP Configuration.
- In the Additional Local IPs section, click + to add a IP Address Configuration. The IP Address Configuration window opens.
- Enter a Name
- Click OK.
- Enter the following settings for the IP Address Configuration:
- Interface Name – Select eth1.
- IP Address – Enter the IP address you assigned to this additional NIC of the secondary firewall during deployment.
- Associated Netmask – Select the netmask for this subnet.
- Responds to Ping – Select Yes.
- Trust Level – Select Trusted.
- Click OK.
- Click Send Changes and Activate.
Step 8. Set the primary and secondary firewall
Configure which NextGen Firewall F-Series is used as the active and backup box for the virtual server.
- Log into the primary Barracuda NextGen Firewall F-Series.
- Go to CONFIGURATION > Configuration Tree > Virtual Servers > your virtual server > Server Properties).
- Click Lock.
- From the Active Box drop-down select This-Box.
- From the Backup Box drop-down select Other-Box.
- Click Send Changes and Activate.
Step 9. Deploy the HA PAR file to the secondary firewall
Step 9.1 Create the PAR file for the HA firewall.
- Log into the primary Barracuda NextGen Firewall F-Series firewall.
- Go to CONFIGURATION > Configuration Tree.
- Right-click on Box and select CREATE PAR FILE for HA box. You are prompted to save the
boxha.par
file.
Step 9.2 Deploy the PAR file on the secondary firewall
Switch the endpoint to the secondary NextGen Firewall F-Series (see Step 6).
- Log into the secondary Barracuda NextGen Firewall F-Series firewall.
- Go to CONFIGURATION > Configuration Tree.
- Right-click on Box and select Restore from PAR file.
- Choose the
boxha.par
file created in Step 9.1. - Click Activate.
- Go to CONTROL > Box.
- In the left navigation in the Network section, click on Activate new network configuration.
- Click Failsafe.
- In the left navigation in the Operating System section, click Firmware Restart.
Step 10. (optional) Remove the SETUP-MGMT-ACCESS access rule
This redirect access rule is no longer needed and can be deleted.
- Log in to the primary Barracuda NextGen Firewall F-Series.
- Go to CONFIGURATION > Configuration Tree > Virtual Servers > S1 > Firewall > Forwarding Rules.
- Click Lock.
- Right-click on SETUP-MGMT-ACCESS firewall rule and click Delete.
- Click Send Changes and Activate.
You can now use the Barracuda NextGen Firewall F-Series HA cluster in the Microsoft Azure cloud.
Step 11. Configure Azure User Defined Routing
Azure User Defined Routing allows you to use the NextGen Firewall F-Series HA cluster in the frontend subnet as the default gateway for all your VMs running in the backend networks. You must enable IP forwarding for the NextGen Firewall F-Series VMS and create and apply an Azure routing table to the backend networks. Using a management Certificate and the Azure subscriber ID the NextGen Firewall F-Series VMs can change the Azure Routing Table on the fly when the virtual server fails over from one VM to the other.
Step 11.1 Configure User Defined Routes for your VNET
Create a User Defined routing table and enable IP Forwarding for the two NextGen Firewall F-Series VMs. Assign this user defined routing table to all subnets that use the NextGen Firewall F-Series HA cluster as the default gateway.
For more information, see How to Configure Azure Route Tables (UDR) in Azure using PowerShell and ASM.
Step 11.2 Create the Azure Management certificate
For the NextGen Firewall F-Series to be able to connect to the Azure backend, you must create and upload a Management certificate.
- Log in to the NextGen Firewall F-Series via ssh .
Create the certificate:
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout mycert.pem -out mycert.pemopenssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout mycert.pem -out mycert.pem
- Answer the questions at the prompt. The Common Name is used to identify this certificate in the Azure web interface.
Convert the vertificate to CER required by Azure:
openssl x509 -inform pem -in mycert.pem -outform der -out mycert.ceropenssl x509 -inform pem -in mycert.pem -outform der -out mycert.cer
You now have two certificates mycert.pem and mycert.cer.
Step 11.3 Upload the Azure Management certificate
- Log into the Microsoft Azure Management Portal (https://manage.windowsazure.com).
- On the bottom of the left menu, click on SETTINGS.
- In the top navigation, click on MANAGEMENT CERTIFICATES.
- On the bottom Click UPLOAD.
- Select the mycert.cer certificate created in Step 12.2. and click OK.
The management certificate is now listed with the Common Name of the certificate used as the Name.
Step 11.4. Configure Cloud Integration
You must enter your Azure SubscriptionId, VNET name and the management certificate to allow the F-Series Firewall to change the Azure User Defined Routing Table.
- Login to the primary firewall.
- Go to CONFIGURATION > Configuration Tree > Box > Advanced Configuration > Cloud Integration.
- Click Lock.
- In the left menu, click Azure Networking.
- Enter your Azure Subscription ID. Use
Get-AzureSubscription
in Azure PowerShell to display your SubscriptionId. - Enter the Virtual Network Name.
- Next to Management Certificate click Ex/Import and select Import from PEM File. The File browser window opens.
- Select the mycert.pem certificate created in step 12.2 and click Open.
Next to Management Key click Ex/Import and select Import from File. The File browser window opens.
Select the mycert.pem certificate created in step 12.2 and click Open.Set Protect IP forwarding settings to yes.
Click Send Changes and Activate.
The Azure Routing table is now updated every time the virtual server fails over.
Next steps
Activate the license on both Barracuda NextGen Firewalls. For more information, see How to Activate and License a Stand-alone Virtual or Public Cloud F-Series Firewall or Control Center.
- Enable Azure Route Table rewriting. For more information, see How to Configure Azure Cloud Integration using ASM.