Azure上にBarracuda CloudGen FirewallをHA構成で構築

Azure, Barracuda
目次

はじめに

Barracuda CloudGen Firewallの試用版ライセンスを2つお借りすることができたので、Azure上にHA構成で構築しました。

ネットワーク構成

こちらのサイトにほぼ答えがありましたので、流用します。

Barracuda CloudGen Firewall for Azure - HA Cluster
https://www.barracuda.com/resource/ref_architectures/azure_high_availability_cluster

img

手順を確認すると、Quick Start用のzipファイル一式をダウンロードしてきて、中にあるAzure CLI若しくはAzure PowershellからARMテンプレートをデプロイする方式です。

スクリプトを流せば上記の構成が一通り作成されて、Red Tier/Green Tierのサブネット内に好きな追加VMを入れればHA構成でFirewall経由で通信されるようになります。

CGFWのデプロイ

前述のARMテンプレートはそのまま流用しますが、仮想ネットワークのアドレス空間の指定をデフォルトから変更したい場合にはARMテンプレートに渡すパラメータを追加してあげる必要があるため、少しだけAzure CLI用のスクリプトを作成しましたので以下に示します。

プログラムからAzure Marketplaceのイメージをデプロイするための手順も入っています。

#!/bin/bash

# common
prefix=Barracuda-CGFW
location=japaneast
rgname=$prefix"-rg"

# CGFW
adminPassword=******** # 要編集
vNetAddressSpace=192.168.192.0/22
subnetCGF=192.168.192.0/24
subnetRed=192.168.193.0/24
subnetGreen=192.168.194.0/24
#
# create resource group
#
az group create --name $rgname --location $location

#
# Allow program deploy to Barracuda CGFW
#
az vm image accept-terms \
    --publish barracudanetworks \
    --offer barracuda-ng-firewall \
    --plan byol

#
# Download template files
#
wget -q -nc https://github.com/barracudanetworks/cloud-reference-architectures/archive/master.zip
unzip -o -q ./master.zip
rm -f master.zip

json_template="./cloud-reference-architectures-master/Quickstart-Azure-CGF-HA/azuredeploy.json"
json_parameters="./cloud-reference-architectures-master/Quickstart-Azure-CGF-HA/azuredeploy.parameters.json"


az group deployment create --resource-group $rgname \
    --template-file $json_template \
    --parameters "@"$json_parameters \
    --parameters \
        adminPassword=$adminPassword \
        prefix=$prefix \
        vNetAddressSpace=$vNetAddressSpace \
        subnetCGF=$subnetCGF \
        subnetRed=$subnetRed \
        subnetGreen=$subnetGreen

こちらのスクリプトを使ってデプロイすると、仮想ネットワーク及びサブネットのアドレス空間を自由に変更できます。
ただし、ARMテンプレート内ではサブネットの第4オクテットのアドレスを直値で設定している箇所があるので、サブネットのネットマスクは「/24」にしておくのが良いでしょう。

こちらを実行すると、prefixで指定した値+"-rg"のリソースグループが作成されて、中に必要なリソースが全て作成されます。

img

CGFWの仮想マシンも2台、実行中となっています。

img

管理コンソールに接続

Windows用管理コンソール「NGAdmin.exe」を入手して実行します。
2019/7/18時点では上記デプロイスクリプトをそのまま流すとファームウェアVersion 8.x系の最新版がインストールされるので、それに対応したNGAdmin.exeを使用します。

私は「FirewallAdmin_8.0.0-819.exe」を入手して使用しました。こちらは試用版ライセンスの発行元に問い合わせれば良いでしょう。

サーバA,B共にAzureポータル上からPublic IP Addressを確認して控えておきます。

img

管理ツールを起動して、先ずはサーバAにログインします。
「IP Address / Name」には先に確認したサーバAのPublic IP Addressを、「Username」はroot、「Password」にはデプロイ時に指定したパスワードを入力して「Sign in」をクリックします。

img

初回接続時のみ警告画面が出るので「Trust」をクリックします。

img

ライセンスの投入

無事管理画面のダッシュボードが開いたら、「SUBSCRIPTION STATUS」内の「Activation State」右の「→」をクリックします。

img

ポップアップしてきた「Enter license token and activate appliance」をクリックします。

img

払い出してもらったライセンスのトークンを入力して、「OK」をクリックします。

img

Activation画面では必要事項を入力後、下部の利用許諾はスクロールさせて最後まで表示されると「I Accept….」のチェックが有効になるので、こちらをチェック後に「Activate」をクリックします。

img

暫く待つと、無事ライセンスが登録されました。
いつまで待っても画面が更新されないときには、一度管理クライアントの再接続を行うと良さそうです。

img

サーバBにも同様の手順でライセンスを投入します。同じライセンストークンは使用できないので、別のトークンを入力します。

ローケールの設定

サーバAにて作業を実施します。

「Configuration」画面のツリーから「Administrative Settings」をダブルクリックします。

img

「Time Settings / NTP」を選択し、「Lock」ボタンをクリック後に、「Time Zone」を「Asia/Tokyo」に変更後、「Send Changes」をクリックします。

その後表示される「Activation Pending」をクリックすると適用されます。

img

こちらの操作を行うと、サーバBにも同じ設定が反映されます。

内部Load Balancerへの正常性プローブ許可

先に紹介したBarracudaのURL( https://www.barracuda.com/resource/ref_architectures/azure_high_availability_cluster )の「Post Deployment Configuration」にかかれている通り、Azure Load Balancerは正常性プローブの送信元として 168.63.129.16 からアクセスされてくるので、こちらに応答できるようにCGFWのFirewall Ruleを追加します。

サーバA側で操作します。

「CONFIGURATION」→「Configuration Tree」画面を開き、ツリーから「BOX>Virtual Servers>S1>Assigned Services>NGFW>Forwarding Rules」をダブルクリックします。

img

Forwarding Rules一覧が表示されたら、右上の「Lock」をクリックしてUnlock状態にします。
Mail Rulesの中から「CLOUD-NET-2-INTERNET」の行で右クリックして、表示されたポップアップメニューから「New」→「Rule」を選択します。

img

  • 「Block」を「App Redirect」に変更します
  • 名前を「NewRule」から「AZURE-LB-PROBE-Redirect」に変更します
  • Source：ドロップダウンをクリックして「」を選択します。 ドロップダウンのすぐ下のグリッドで、右クリックして[Edit]をクリックします。新しいウィンドウが開きます
  • 「Include Entries」の下の緑色の「+」をクリックし、「IP」フィールドに「168.63.129.16/32」と入力してから「Insert and Close」をクリックして「OK」をクリックします
  •   Service：ドロップダウンをクリックして「 」を選択します。 ドロップダウンのすぐ下のグリッドで、右クリックして[Edit]をクリックします。新しいウィンドウが開きます
  •   「New Object」をクリックし、「Port Range」フィールドに「65000」と入力してから、もう一度「OK」と「OK」をクリックします。
    ※Barracudaのドキュメントには「65500」と書かれていますが、Azure Resource Managerテンプレートで作成されるAzure Load Balancerの正常性プローブのポートが65000となっているのでこちらが正解です。
  •   Destination：ドロップダウンをクリックして「Management IP」を選択します
  • Redirection ： Local Addressフィールドに「127.0.0.1:450」と入力します。
  • 最後にOKをクリックして適用します

img

最後に「Send Changes」をクリック後、「Activation Pending」をクリックして適用します。

img

サーバBにも自動反映されます。

アクティブな方のCGFW(下図例ではサーバB)の「FIREWALL」→「Live」画面を見ていると、定期的に 168.63.129.16 から TCP/65000 宛に通信が来ていることがわかります。これで、Azure Load Balancerからもアクティブ側のCGFWに対して通信が行われる準備が出来ました。

img

確認用Linuxサーバのデプロイ

Green Tierのサブネット内に1台 UbuntuサーバをPublic IP Addressなしでデプロイします。

以下のAzure CLIを作成したので、これをそのまま流しました。

#!/bin/bash

# common
rgname=Barracuda-CGFW-Web-rg
vnet_rgname=Barracuda-CGFW-rg
location=japaneast

# vnet
vnet_name=Barracuda-CGFW-VNET
vnet_subnet_name=Barracuda-CGFW-SUBNET-GREEN

# web vm
vm_name=linuxwebvm11
vm_ipaddress=192.168.194.4
vm_size=Standard_D1_v2
linuximage=UbuntuLTS
vm_id=azureuser
vm_password=******** # 要編集

az group create --name $rgname --location $location

subnetid=$(az network vnet show --name $vnet_name --resource-group $vnet_rgname --query "id" -o tsv)"/subnets/"$vnet_subnet_name
az network nic create \
    --name ${vm_name}-nic \
    --resource-group $rgname \
    --subnet $subnetid \
    --private-ip-address $vm_ipaddress

az vm create \
    --name ${vm_name} \
    --resource-group $rgname \
    --location $location \
    --image $linuximage \
    --size $vm_size \
    --nics ${vm_name}-nic \
    --admin-username $vm_id \
    --admin-password $vm_password

さくっと作成できました。

img

確認用Linuxサーバへのssh接続設定

以下の経路でLinuxサーバに接続できるようにします。

PC → (TCP/22)Azure External Load Balancer → (TCP/8022)Barracuda CGFW(Active) → (TCP/22)Linux Server

CGFWの待受ポートを変更しているのは、既にTCP/22がCGFWの管理用にバインドされているからです。

先ずは、Azure Load Balancer(*-ELB-CGF)の負荷分散規則を追加します。

「名前」は「ssh」など適当に。「プロトコル」は「TCP」、「ポート」は「22」、「バックエンドポート」は「8022」で登録します。

img

続いてCGFWのFirewall Ruleを追加します。場所は先に登録した「 AZURE-LB-PROBE-Redirect 」の上あたりで良いかと。

「Action」は「Dst NAT」、名前は「Internet-2-srv-ssh」など適当に、「Source」は「Internet」、「Service」は「TCP/8022」、「Destination」は「Management IP」、「Redirection」に「(LinuxサーバのIPアドレス):22」(今回は192.168.194.4:22)、「Connection Method」は「Original Source IP」を設定します。

img

これで、Azure Load Balancer経由でTCP/22でssh接続が可能です。

img

確認用Linuxサーバへのhttp接続設定

GREEN TierのサブネットからInternetに向かうOutbound通信が許可されていないので、更にCGFWのFirewallルールを追加します。

「Action」は「Pass」、名前は「GREEN-NET-2-INTERNET」など適当に、「Source」はGREEN TierのサブネットのCIDRである「192.168.194.0/24」、「Service」は「Any」、「Destination」は「Internet」、「Connection Method」は「Dynamic NAT」を設定します。

img

これで、Linuxサーバから外部へのアクセスが可能になるので、以下のコマンドでnginxをインストールします。

$ sudo apt install nginx -y

curl loalhostを実行してnginxが正しく動作していることを確認します。

img

http用にAzure Load Balancer(*-ELB-CGF)の負荷分散規則を追加します。

「名前」は「http」など適当に。「プロトコル」は「TCP」、「ポート」は「80」、「バックエンドポート」も「80」で登録します。

img

最後にCGFWでhttpのFirewallルールを登録されば完了です。

「Action」は「Dst NAT」、名前は「Internet-2-srv-http」など適当に、「Source」は「Internet」、「Service」は「http」、「Destination」は「Management IP」、「Redirection」に「(LinuxサーバのIPアドレス)」(今回は192.168.194.4)、「Connection Method」は「Original Source IP」を設定します。

img

Web接続確認

では、クライアントPCからAzure Load BalancerのPublic IP Addressに向けて接続してみましょう。

img

無事繋がって、CGFWの「FIREWALL」→「Live」画面で見ていると、Internet側からTCP/80やTCP/8022宛の通信が来ていることが確認できました。

img

おわりに

Barracudaが用意してくれているAzure Resource Managerテンプレートで基本的なHA構成の構築は比較的簡単に行えることがわかりました。

無論、既存の仮想ネットワークに導入したり、より複雑な構成を行う場合にはテンプレートファイルを改修する必要はあると思いますが、手間としてはゼロから構築するのに比べれば少しは軽減されるでしょう。