【2026年最新版】UniFi Dream Machine Pro Max ゾーンベースファイアウォールでデバイス通信遮断の完全解決

※本ページにはプロモーション(広告)が含まれています

Ubiquiti UniFi Dream Machine Pro Max(UDM Pro Max)はUniFi Network 9.xで刷新された「Zone-Based Firewall(ゾーンベースファイアウォール)」をデフォルト採用しており、従来のLegacy FirewallからZone-Basedへの自動移行を契機に、VLAN間通信の遮断、IoTデバイス(Chromecast、Sonos、Google Homeなど)の突然のオフライン化、mDNSによるサービス検出の失敗といったトラブルが複数報告されています。本記事は、新旧ファイアウォールモデルの挙動差、Zone Policyの評価順序とDefault Zoneの設定、mDNS Reflectorの再有効化、UniFi Network 8.xへのロールバック手順、UniFi OS Network Conf出力の活用まで、ネットワーク管理者が実務で直面する切り分け手順を体系的に解説します。対象読者はUDM Pro Maxを含むUniFi Gatewayを運用するSMB/プロシューマー層、自宅に複数VLAN(LAN/IoT/Guest/Cameras等)を構築しているユーザー、およびネットワーク機器のファーム更新に伴う突然の通信不能に直面した方です。

この記事でわかること

• Legacy Firewall(UniFi 8.x)とZone-Based Firewall(UniFi 9.x)の設計思想の違い
• 自動移行時にZone Policyがどのように生成されるかの実態
• IoTデバイス(Chromecast/Sonos)がオフライン化する具体的な経路
• mDNS Reflectorの再有効化とZone-Based下での挙動
• UniFi Network 8.xへのロールバック手順と必要バックアップ

基礎解説

Zone-Based Firewallは、ネットワークを「ゾーン」という論理単位に区切り、ゾーン間の通信を明示的にポリシーで定義する設計思想です。UniFi Network 9.xではデフォルトで「Internal」「External」「Guest」「IoT」「DMZ」といった既定ゾーンが用意され、各VLANは対応するゾーンに自動的に割り当てられます。この設計は従来のLegacy Firewallよりもセキュリティが高く、Zero Trustの考え方に近いのですが、既存環境からの自動移行時にユーザーが暗黙に依存していた通信経路が明示ルールとして書き出されないと、通信が遮断されます。

Legacy Firewallでは、デフォルトで「LAN内の任意のVLAN間」は暗黙に許可されており、管理者が明示的に「LAN IN」ルールで拒否しない限り通信できました。これに対しZone-Based Firewallでは「ゾーン間はデフォルト拒否」で、許可ルールを明示する必要があります。UniFi 9.xへの自動移行では旧ルールから変換生成されますが、IoTからLAN(クライアントデバイスのプリンタやNASへ)への通信のように、ユーザーがルールを明示せず「暗黙で動いていた」経路は変換されず、結果としてChromecastのキャストやSonosの自動検出が失敗します。

もう一つ重要な要素がmDNS(Multicast DNS)です。Chromecast・Sonos・AirPrint対応プリンタなどの「サービス自動検出」はmDNS(ポート5353)で実現されており、マルチキャストパケットがVLANを超えるにはUniFi Networkの「mDNS Reflector」機能が必須です。Legacy Firewallでこれを有効化していても、Zone-Based移行時にリセットまたはデフォルト無効の状態に戻るケースが報告されています。ReflectorがOFFだとユーザーのスマホ(LAN側)がIoT VLAN上のChromecastを発見できず、キャストデバイスが一覧に表示されなくなります。

さらに、Zone Policyの評価順序がLegacy Firewallのルール順序と完全一致しないことも混乱の原因です。Zone-Basedでは「ゾーン間のマトリクス」で評価され、Legacy Firewallの「LAN IN/OUT/LOCAL」といった分類とは異なる概念になっています。管理者が旧来の分類で思考していると、Zone Policyで意図通りの許可ルールを書けない落とし穴があります。

原因の切り分け

Zone-Based移行後の通信遮断は、複数のレイヤーで発生するため段階的な切り分けが必要です。

管理者はまずZone Policyマトリクス(設定 > セキュリティ > ファイアウォール > Zone Matrix)を開き、通信したいVLAN間のセルが「Allow」か「Deny」かを確認します。ほとんどのChromecast問題はmDNS Reflector無効化が原因で、この2点だけで大半が解決します。

解決手順（段階別）

ステップ1: 現状の設定スナップショットを取得

UniFi Networkで「設定 > システム > バックアップ」を開き、現状のバックアップを作成して安全なストレージに保存します。Zone-Based Firewallの変更は広範囲に影響するため、ロールバックできる状態を必ず確保してから作業します。

ステップ2: Zone Matrixの確認

「設定 > セキュリティ > ファイアウォール > Zone Matrix」を開き、VLANごとの送信元ゾーン×宛先ゾーンの許可状況を確認します。IoTからInternalへ、またはGuestからInternalへの通信が「Deny」になっていれば、それが遮断の根本原因です。必要な経路のみ「Allow」または「Allow with restriction」に変更します。

ステップ3: mDNS Reflectorの再有効化

「設定 > ネットワーク > ネットワーク一覧」から各VLAN(LAN、IoT等)を開き、「詳細設定 > mDNS」を有効化します。「Enable mDNS Reflector」トグルがONになっていることを確認し、必要なVLAN間の転送を有効にします。これによりChromecastやSonosの検出が復活します。

ステップ4: Zone Policyの追加(必要に応じて)

Zone Matrixで一括許可は過度に緩い場合、個別のZone Policyを作成します。例としてIoTゾーンからInternalゾーンへの「TCP/IP 5353 mDNS許可」「TCP/IP 8008/8009 Chromecast許可」「TCP/IP 1400-1499 Sonos許可」を明示します。送信先ポートを絞ることで攻撃面を最小化できます。

ステップ5: Zone割当の見直し

各VLANのZone割当(設定 > ネットワーク > [VLAN名] > 詳細 > Zone)を確認し、意図したゾーンに属しているか検証します。例えば「IoT」と命名したVLANが誤って「Internal」に割り当てられていると、期待と異なる通信が許可されます。

ステップ6: Policy順序の調整

Zone Policyは上位ルールが優先されるため、個別Denyルールが全許可ルールより上にあると意図しない遮断が発生します。Policy Indexの並び替えで、Allowルールを先頭寄りに、広範囲のDenyを末尾に配置することで整合性を保ちます。

ステップ7: IGMP Snoopingの確認

UniFi Switchの設定でIGMP Snoopingが有効になっているか確認します。これが無効だとマルチキャストがフラッディングし、ネットワーク全体の負荷が増大するだけでなくSonos等のマルチキャストベースのサービス検出が不安定になります。デフォルト有効ですが、旧設定を引き継いでいると無効のままになっている場合があります。

ステップ8: UniFi Network 8.xへのロールバック

上記で解決しない、または時間的制約で元に戻したい場合、UniFi OS Consoleから「UniFi Network > Version History」で8.x系最終バージョンに戻せます。ただし、Zone Policyで追加した設定は失われるため、ロールバック前にスクリーンショットで記録しておきます。ロールバック後はLegacy Firewall設定が復活し、従来の動作に戻ります。

設定値・パラメータ比較表

よくある失敗と再発防止

管理者の最も多い失敗は「自動移行後にスナップショットを取らずに運用開始」し、問題発生時に移行前の状態が再現できないケースです。Zone-Based移行は広範囲に影響するため、必ず移行前と移行直後の2つのバックアップを保存し、さらにZone Policyを大きく変更する前にも追加でバックアップを取る習慣が重要です。UniFi OSはバックアップ世代管理が標準で30件程度残せるため、積極的に活用します。

もう一つの典型的失敗は「Chromecast/Sonosのトラブルをゾーン間通信ではなくデバイス側の故障と誤判定」して時間を浪費するパターンです。IoTデバイスは通常非常に安定しており、複数デバイスが同時に不調になった場合はネットワーク側の要因を最初に疑うべきです。スマホをIoT VLAN側に一時的に接続してChromecastが見えるか確認すれば、5分で切り分けできます。

再発防止の観点では、UniFi Network更新前の手順として「リリースノートの確認」「バックアップ取得」「主要デバイスの動作確認タスクリスト」を用意しておくことを推奨します。特にリリースノートでZone-Based Firewall関連の変更が言及されていれば、自動移行の再度発生を警戒し、手動で変更適用のタイミングを制御すべきです。UniFi OSの「Auto Update」設定をOFFにし、手動更新に切り替えることも選択肢です。

FAQ

Q1. Zone-Based Firewallに移行すべきですか、Legacyに戻すべきですか

新規構築ならZone-Basedを強く推奨しますが、複雑な既存設定がありダウンタイムを許容できない場合はLegacy 8.xを継続して使い、時間を取って計画的に移行するのが安全です。Zone-Basedは学習コストが高い分、長期的には優れたセキュリティを提供します。

Q2. Chromecastだけが見えず、他のIoTは動作しています

mDNS Reflectorが該当VLANで無効化されている可能性が最も高いです。対象VLANの詳細設定からmDNSを有効化し、同時に「必要に応じて」Zone間のポート8008/8009/5353を明示許可してください。

Q3. ロールバックしたら設定が大量に消えました

Zone-Based Firewallで追加した設定はLegacy環境には存在しない概念のため、ロールバック時に失われます。ロールバック前に「Zone Policy一覧のスクリーンショット」「設定エクスポート」を必ず実施してください。

Q4. SonosがVLAN間で再生されません

Sonosはmdns+ポート1400-1499のUDP/TCPを使います。IoTゾーンからLAN/Internalゾーンへの両方向で該当ポートを明示許可し、Zone MatrixのIoT↔Internalセルが「Allow with restriction」になっているか確認してください。

Q5. Zone Matrixの「Allow with restriction」とは何ですか

デフォルト拒否のまま、個別Zone Policyで定義した特定の通信だけを許可する状態を意味します。これが推奨される最もセキュアな設定で、Full Allowは避けるべきです。

Q6. mDNS Reflectorが有効なのにChromecastがオフラインです

Reflectorが有効でもZone PolicyでmDNS(UDP 5353)が拒否されていれば動きません。Zone Policyで5353を明示許可し、さらに関連するTCPポートも許可してください。

Q7. 設定変更後に一部のデバイスだけ通信できません

Stateful Session Tableに古いセッション情報が残っている可能性があります。UDM Pro Maxを再起動するか、該当デバイス側でネットワーク設定のリセット(Wi-Fi再接続)を実施してください。

Q8. UniFi OSのCLIでZone Policyを一括管理できますか

SSHでUDM Pro Maxに接続し、`mca-dump`コマンドで現在の設定をJSON形式で出力できます。これをバージョン管理リポジトリで追跡することで、設定変更履歴を追えます。直接JSON編集でのPolicy適用は非対応ですが、参照用途には有用です。

まとめ

UniFi Dream Machine Pro MaxのUniFi Network 9.xへの自動移行は、Zone-Based Firewallというセキュリティ強化の恩恵と引き換えに、既存環境の暗黙の通信経路を失わせる副作用を伴います。Zone Matrix確認、mDNS Reflector再有効化、Zone Policy明示定義、割当見直し、順序調整、IGMP Snooping確認、必要に応じたUniFi 8.xロールバックという段階的対応で、ほぼ全てのケースが解決可能です。特にバックアップの取得と、リリースノート確認からなる運用規律を整えることで、将来のファーム更新時のトラブルを未然に防げます。Zone-Basedの学習コストは高いものの、習熟すれば自宅やSMBネットワークに高度な防御を適用できる強力な武器となります。