Azure Firewallを構築する際に躓いた箇所について、3点だけですが、以下のようにまとめました。

 

 

１．AzureFirewallSubnet と AzureFirewallManagementSubnet の違い

Azure Firewallは、デプロイ時に専用のサブネットが必要です。AzureFirewallSubnetが必須であり、/26以上が必要です。利用するSKUや機能により、AzureFirewallManagementSubnet（管理用サブネット）も必要となるのですが、この2つのサブネットの違いが上手く理解できなかったので、詳細について調べました。

 

AzureFirewallSubnet・・・Azure Firewall 本体が配置される専用サブネット。通信の検査・制御を行う。

AzureFirewallManagementSubnet・・・管理トラフィック（ログ収集、監視、更新など）用のサブネット。

 

 

項目	AzureFirewallSubnet	AzureFirewallManagementSubnet
用途	データプレーン（実際のトラフィック処理）	管理プレーン（ログ送信・更新・強制トンネリング時の制御）
必須かどうか	必須	オプション（構成による）
CIDR 要件	/26 以上（64 IP以上）	/26 以上（64 IP以上）
サブネット名（固定）	AzureFirewallSubnet	AzureFirewallManagementSubnet
利用されるタイミング	通常の Firewall デプロイ時	強制トンネリング構成時、Premium SKU利用時など
NSG 設定	基本的に不要（Azureが管理）	同様に不要だが、制限をかける場合は注意

 

AzureFirewallManagementSubnet（管理サブネット）が必要になるケースは以下のような場合です

1. 強制トンネリング（Forced Tunneling）を使う場合
   通常、Firewall はインターネットへ直接出ていきます。
   強制トンネリングを使うと、Firewall がインターネットへ出る代わりに、オンプレミスや別の仮想アプライアンス経由で通信します。
   この場合、Firewall の管理プレーン（更新・ログ送信など）用に別途インターネットアクセスが必要 → 管理サブネットが必要。
   
2. Premium SKU を使う場合
   TLS インスペクションや IDPS（侵入検知防御）など高度な機能を使うと、管理プレーンの分離が推奨される。
   Microsoft 管理のバックエンドとの通信が必要になるため、管理サブネットが必要。

AzureFirewallManagementSubnet を図示した通信イメージ図は以下です。

この構成は、VNET1（Firewall配置）とVNET2（VM配置）の2つの仮想ネットワークを用いた、ハブ＆スポーク型のネットワーク構成です。
Azure Firewall を中心に、NWアプライアンスやインターネットとの通信制御を行っています。AzureFirewallがAzureFirewallSubnetとAzureFirewallManagementSubnetの両方にNICを持っているというのがイメージできそうではないでしょうか？（私はなんとなく、この図を書いて、納得できました）

 

オレンジ色線：AzureFirewallManagementSubnet の NIC を使用した 管理系通信（Azure Monitor へのログ送信、更新、Microsoftバックエンドとの同期など）。この通信は インターネットへ直接出る必要があります。
青線：AzureFirewallSubnet の NIC を使用した データプレーン通信（ユーザーのトラフィック処理）。これは強制トンネリングやルート制御の対象になります。

２．UDRの設定をするとRDPができなくなる

AzureEirewallをデプロイした後、UDR（ユーザー定義ルート）により、アウトバウンドの通信をAzureFirewall経由にすると思います。VMが存在するサブネットにユーザー定義ルートを設定した直後に、VMへのRDPが出来なくなったのでそのことを紹介します。

まず、VMへは以下のようにRDPをしている状況でした。クライアント（アクセス元PC）は VM のパブリックIPに対してインターネット経由で RDP 通信を送信している状況でした。

 

この「VMサブネット」に対して、以下のようなUDRを設定しました。

宛先 0.0.0.0/0 に対して Next Hop を 仮想アプライアンス（Azure Firewall） に設定しています。
ネクストホップの10.0.1.4がAzureFirewallアドレスです。
これにより、VMからの全てのOutbound通信がFirewall経由になります。

 

 

この設定を投入した直後、今までと同じように、VMのグローバルIPを指定してRDPしようとしても、接続できません。

 

 

これは、「非対称ルーティング」が原因です。
VMへのインバウンド通信（クライアントPCからVMへの通信）は、インターネットから直接VMに送付されます。しかし、その戻りの通信（VMからのアウトバウンド通信）はAzureFirewall経由で外部に出ようとする為、送信元と戻りの経路が一致しなくなり、AzureFirewallでパケットが破棄されているのです。

 

イメージ図でいうと、以下です。

 

Azure Firewall は ステートフル（状態保持型）ファイアウォールです。
つまり、Firewallを通過した通信の「戻り」だけを許可する設計になっており、外部から直接届いた通信の応答がFirewall経由になると、整合性が取れず破棄されます。
Firewallが「この通信は自分が通していない」と判断するため、セッションが成立せず、応答パケットが破棄される仕組みです。

これに対する解決策が、AzureFirewallのDNATルールです。

FirewallにDNATルールを設定し、インバウンド通信（クライアントからVMへの通信）もFirewall経由にすれば、Firewallがセッションを認識し、戻りの通信も許可されるようになります。

 

 

３．AzureFirewallのDNATルール設定

AzureFirewallにDNATルールを設定し、外部からVMにRDPできるようにします。

まず、AzureFirewallのリソースを選択し、ポリシーをクリックします。
※AzureFirewallでは、ポリシーに設定を投入していく為、設定先はポリシーです。

 

 

Rules の 「DNAT 規則」をクリックします。

 

 

規則コレクションの追加  から、以下のようにDNATルールを追加します。

 

 

各設定値のポイントを以下にまとめます。

 

 DNATルール コレクション設定項目と設定例

 

項目	意味	設定例	備考
名前	ルールの識別名	RDP-VM	任意
規則コレクションの種類	DNATルールであることを指定	DNAT
優先度	ルールの適用順。小さいほど優先	10001	100～65000の範囲
規則コレクションアクション	DNAT（転送）を指定	完全ネットワークアドレス変換 (DNAT)
規則コレクショングループ	DNATルール用のグループ	DefaultDnatRuleCollectionGroup	デフォルトで用意されているグループを指定

DNATルール 設定項目と設定例

 

項目	意味	設定例	備考
名前	各ルールの名前	RDP-VM01	任意
ソースの種類	通信元の指定方法	IP アドレス
ソース	通信元IP（外部）	* または特定のグローバルIP	*で全外部IPを許可、特定IPなら制限可能
プロトコル	通信プロトコル	TCP	RDPはTCP 3389の為、TCP指定
宛先ポート	Firewallが受け取るポート	10001
宛先（Firewall IP）	FirewallのパブリックIP	<<AzureFWのグローバルIPアドレス>>	AzureFirewallに割り当てたパブリック（グローバル）IP
宛先の種類	IPアドレス	IP アドレス
翻訳されたアドレス	転送先の内部IP（VM）	10.XX.XX.XX	VMのプライベートIP
翻訳されたポート	転送先のポート	3389	VM側のRDPポート

 

ポイントは、赤字の、「Firewallが受け取るポート」です。AzureFirewall配下に複数のVMが存在し、それぞれにRDPしたい場合、VM毎に、接続するポートを分けることを考慮しておく必要があります。

※Azure Firewall の DNATルールでは、Firewallが受け取るポート（＝外部公開ポート）を一意にする必要があるため、複数VMに対して同じ内部ポート（例：3389）を使う場合でも、Firewall側では異なるポート番号を割り当てる必要があります。

 

DNATルールを設定した後のVMへのアクセス方法ですが、AzureFrirewallのパブリックIPと外部公開ポートを指定します。

以下のように、

 

AzureFirewallのグローバルIP:外部公開ポート番号

 

を指定します。

 

上記で接続可能です。

以上、AzureFirewall構築において個人的に躓いた場所を深堀りして記載しました。