Windows Server 2019 の RRAS でサイト間 VPN（デマンドダイヤル）を組んだのに、「IP Demand-Dial Filter（IP デマンドダイヤル フィルター）」の設定場所が見当たらない…という悩みは定番です。結論はシンプルで、通常の LAN NIC ではなく「Demand-dial として作成したインターフェイス」にだけ表示されます。この記事では GUI と PowerShell の両面から、迷わず有効化する手順と設計のコツをまとめます。
結論：IP デマンドダイヤル フィルターは「Demand-dial インターフェイス専用」
まず押さえるべきポイントは、RRAS の IP Demand-Dial Filter（IP デマンドダイヤル フィルター）は、すべてのネットワーク アダプターに共通で出てくる機能ではないという点です。これは名前のとおり、需要時接続（Demand-dial）を開始する「きっかけ（トリガー）」となる通信を定義するためのフィルターで、対象はDemand-dial として作成したインターフェイスだけです。
そのため、通常の LAN NIC（Intel/VMware の仮想 NIC など）を選んで「どこに項目があるの？」と探しても見つかりません。管理コンソール上で New Demand-dial Interface（新しいデマンドダイヤル インターフェイス）を作成し、作成したインターフェイスに対して Set IP Demand-Dial Filters を実行する、という順番になります。
IP デマンドダイヤル フィルターは何を制御するのか
RRAS には「IP フィルター」や Windows Defender ファイアウォールなど、似た名前の“通す／遮断する”仕組みが複数あります。IP デマンドダイヤル フィルターは、その中でも目的が少し特殊です。
| 仕組み | 主な目的 | 効くタイミング | よくある用途 |
|---|---|---|---|
| IP Demand-Dial Filter | 需要時接続を開始させる通信を定義（トリガーの制御） | 接続が未確立の状態で、送信しようとしたパケットが発生したとき | サイト間 VPN を“必要なときだけ”自動接続、不要な常時接続の防止 |
| IP Filter（インターフェイスの IP フィルター） | インターフェイスを通過する IP パケットを許可／拒否 | 接続中・非接続を問わず（インターフェイスを通る通信） | RRAS を経由する特定通信の遮断、簡易 ACL 的な用途 |
| Windows Defender ファイアウォール | OS のホスト単位で通信を許可／拒否 | ホストに到達する前後（プロファイル/ルール次第） | RDP/SMB/管理ポートの保護、最小権限の防御 |
ポイントは、IP デマンドダイヤル フィルターは「セキュリティ目的のフィルター」ではなく「接続開始の制御」だということです。もちろん結果的に“勝手に接続が上がる”ことを防げるため、運用面ではセキュリティにも寄与しますが、まずは需要時接続の自動化を意図通りに動かすための機能として捉えるのがコツです。
「設定場所が分からない」原因チェック
見つからない原因はほぼ次のどれかです。先に自分の状況を当てはめると、遠回りせずに解決できます。
| 状況 | 原因 | 次にやること |
|---|---|---|
| LAN NIC のプロパティを見ている | Demand-dial ではないのでメニューが出ない | RRAS の「Network Interfaces」配下で Demand-dial を作成する |
| 「VPN 接続」を作ったつもりだが RRAS 側に見当たらない | クライアント VPN（RASPHONE）を作っている可能性 | RRAS 管理コンソールで「New Demand-dial Interface」を実行する |
| Demand-dial を作成したのにメニューが薄い/実行できない | RRAS が未構成、または IPv4 ルーティングが無効 | RRAS の構成ウィザードで VPN/ルーティングを有効化し、サービス稼働を確認 |
GUI で IP デマンドダイヤル フィルターを有効化する手順
ここからは Windows Server 2019 の標準 GUI（Routing and Remote Access コンソール）での手順です。画面の言い回しは OS 言語や更新状況で多少変わりますが、探す場所は共通です。
RRAS 管理コンソールを開く
- サーバー マネージャー → 「ツール」→ 「Routing and Remote Access（ルーティングとリモート アクセス）」
- または、
rrasmgmt.mscを実行
Demand-dial インターフェイスを作成する
- 左ペインでサーバー名を展開し、「Network Interfaces（ネットワーク インターフェイス）」を選択します。
- 空白部分を右クリックし、「New Demand-dial Interface（新しいデマンドダイヤル インターフェイス）」をクリックします。
- ウィザードで次を設定します（代表例）：
- Interface name：拠点名など（例：S2S-TOKYO）
- Connection type：VPN（サイト間 VPN の場合）
- VPN type：環境に合わせて IKEv2 / SSTP / L2TP / PPTP など
- Destination：相手側の VPN 終端の FQDN または IP
- Credentials / Shared secret：認証方式に合わせて設定
- ウィザード完了後、Network Interfaces の一覧に新しいインターフェイスが追加されます。
重要：ここで作成されるのは「需要が発生したときに接続するための“ルーティング用インターフェイス”」です。これが存在して初めて、IP デマンドダイヤル フィルターの設定メニューが表示されます。
作成したインターフェイスで「Set IP Demand-Dial Filters」を開く
- Network Interfaces の一覧から、先ほど作成した Demand-dial インターフェイスを右クリックします。
- 「Set IP Demand-Dial Filters（IP デマンドダイヤル フィルターの設定）」をクリックします。
- 「Outbound（送信方向）」と「Inbound（受信方向）」のどちらに適用するかを選び、Allow / Deny のルールを追加します。
一般的なサイト間 VPN の需要時接続では、まずOutbound（送信方向）の Allow だけを必要最小限で定義し、意図しない通信（ブロードキャストや探索系トラフィックなど）で勝手に接続が上がるのを防ぐ設計が扱いやすいです。
フィルターの作り方（実務で迷わないコツ）
IP デマンドダイヤル フィルターは「どの通信が発生したら接続するか」を決めるため、最初から完璧に作るよりも、“接続させたい用途”を先に言語化してからルールに落とす方が失敗しません。
| 用途（例） | トリガーにする代表的な通信 | 補足 |
|---|---|---|
| 拠点間のファイル共有 | TCP 445（SMB）/ TCP 139（必要な場合） | SMB だけで接続させると無駄な常時接続を避けやすい。DNS 解決が必要なら別途考慮。 |
| リモート管理（サーバーに RDP） | TCP 3389（RDP） | 管理端末からのアクセスだけで接続させたい場合に有効。踏み台を用意する設計とも相性が良い。 |
| ドメイン参加・AD 連携 | DNS（UDP/TCP 53）、Kerberos（TCP/UDP 88）、LDAP（TCP/UDP 389）、SMB（445）など | 必要ポートが多くなる。需要時より常時接続の方が運用しやすいこともあるため、要件と運用で判断。 |
| 監視/ログ転送 | Syslog（UDP 514）やエージェント通信など | 監視が常に動くと接続も常に上がる。需要時接続にしたいなら監視のポーリング設計も見直す。 |
また、次のような通信は「意図せずトリガーになる」代表例です。需要時接続を安定させるなら、最初からトリガーに含めない（または Deny する）方がトラブルが減ります。
- ブロードキャスト/マルチキャスト（名前解決や探索系）
- ネットワーク探索、LLMNR/NBNS などの自動解決トラフィック
- ルーティング プロトコルや監視のヘルスチェックなど、定期的に出続ける通信
設定後の動作確認：どこを見れば「効いている」と判断できるか
「設定はできたが、実際にトリガーで接続しているのか分からない」という場合は、次の順に確認すると判断が早いです。
まずは“意図した通信”を発生させる
- 例：ファイル共有をトリガーにしたなら、相手拠点のファイルサーバーに
\\10.20.0.10\shareでアクセス - 例：RDP をトリガーにしたなら、相手拠点のサーバーに RDP 接続を開始
接続状態を RRAS コンソールで確認する
- 「Network Interfaces」で該当インターフェイスの状態が Connected になるか
- 「Remote Access Clients」や「Ports」で該当セッションが確立しているか
疎通確認は ICMP だけに頼らない
ICMP（ping）はネットワーク機器やセキュリティ ポリシーで落とされていることが多く、需要時接続の検証では誤判定しがちです。Windows なら次のように TCP ポートで疎通を取ると、原因切り分けが一気に楽になります。
Test-NetConnection 10.20.0.10 -Port 445
Test-NetConnection 10.20.0.10 -Port 3389
よくあるトラブルと解決の近道
Demand-dial は“便利な自動化”の一方で、ちょっとした条件で「接続が上がらない／上がりっぱなし」になりやすい構成です。現場で頻出する症状を表にまとめました。
| 症状 | 原因の候補 | チェック/対処 |
|---|---|---|
| 「Set IP Demand-Dial Filters」が表示されない | 対象が Demand-dial インターフェイスではない | 「Network Interfaces」配下で作成した Demand-dial を右クリックしているか確認 |
| トリガー通信を出しても接続が始まらない | フィルターが一致していない／ルーティングが不足 | 宛先サブネットへのルート（静的ルートやダイヤルアウト ルート）を再確認。まずは広めに Allow して切り分け→最後に絞る |
| 接続がすぐ切れる | 認証失敗、PSK 不一致、アイドル タイムアウト | イベント ログ（RemoteAccess/RasClient）や RRAS のログを確認。必要ならアイドル タイムアウトを調整 |
| 何もしなくても勝手に接続が上がる | 許可範囲が広すぎ、探索/監視がトリガー | トリガーを「本当に必要な宛先・ポート」に限定し、ブロードキャスト/探索系の通信をトリガーに含めない |
| Demand-dial の作成はできるが接続が確立しない | WAN Miniport の Demand-dial 接続が無効、またはポート不足 | RRAS の「Ports」で対象の VPN ポート（IKEv2 など）のプロパティを開き、Demand-dial routing connections（inbound/outbound）が有効か確認 |
運用で効く“設計のコツ”
最後に、需要時接続を安定運用するための実践的なコツをまとめます。GUI の手順だけだとハマりやすい部分なので、導入前に一度チェックしておくと事故が減ります。
トリガーは「宛先サブネット × 必要ポート」で最小化する
Demand-dial は“上がった後の通信制御”ではなく“上げるきっかけの制御”です。ここを広くしすぎると、監視・探索・名前解決などの裏側トラフィックで常時接続になり、当初の狙い（必要なときだけ接続）が崩れます。
名前解決（DNS）の設計を先に決める
トリガーを SMB や RDP に絞ったのに、接続が上がらない原因として多いのが DNS です。宛先をホスト名でアクセスすると、まず DNS クエリが発生します。DNS もトリガーに入れるのか、IP 直指定で運用するのか、あるいは拠点間で名前解決をどう通すのかを先に決めておくと、フィルター設計がぶれません。
“需要時”が向かない用途もある
Active Directory 連携や常時監視など、通信が途切れる前提だと不都合が出やすい用途では、需要時接続に固執しない判断も大切です。常時接続（Always On）にして、別途ファイアウォールや経路制御で最小権限にする方が、結果的に安定・安全なケースもあります。
PowerShell で自動化したい場合の考え方（S2S VPN）
拠点数が多い、検証環境を繰り返し作る、といった場合は PowerShell による自動化が効きます。RRAS のサイト間 VPN（S2S）であれば、Add-VpnS2SInterface / Set-VpnS2SInterface でインターフェイス作成や設定変更が可能で、トリガー（需要時接続を開始させる条件）も -IPv4TriggerFilter 系のパラメーターで扱えます。
ただし、トリガーフィルターは「指定書式」を間違えると意図通りに動きません。まずはヘルプで書式と例を確認し、GUI で動く最小構成を作ってから PowerShell に落とすと失敗が少ないです。
# コマンドレットの仕様と例を確認（まずここから）
Get-Help Set-VpnS2SInterface -Full
Get-Help Set-VpnS2SInterface -Examples
# 既存の S2S インターフェイスの設定を確認
Get-VpnS2SInterface -Name "S2S-TOKYO" | Format-List *
# （概念例）IPv4 のトリガーフィルターを設定
# ※ -IPv4TriggerFilter の書式は Get-Help の例に合わせて指定してください
Set-VpnS2SInterface -Name "S2S-TOKYO" -IPv4TriggerFilterAction Allow -IPv4TriggerFilter @(
"（ここにトリガー条件の定義）"
)
PowerShell での一括展開は、同じ設計を複数拠点に適用するほど効果が高まります。逆に、拠点ごとに要件がバラバラな場合は、GUI で確実に動かしながら設計を固め、最後にスクリプト化するのが現実的です。
参考リンク（公式・関連ドキュメント）
- Microsoft Q&A: Configuration Set IP Demand-Dial Filter in RRAS
- Microsoft Learn: Demand-dial interface 構成手順（旧版ドキュメント）
- Microsoft Learn: Remote Access（VPN）導入
- Microsoft Learn: Set-VpnS2SInterface（RemoteAccess）
IP デマンドダイヤル フィルターは「見つけにくい」だけで、仕組みが分かれば設定自体は難しくありません。Demand-dial インターフェイスを正しく作り、トリガー通信を最小化する。これだけで、RRAS の需要時接続は一気に扱いやすくなります。
コメント