Windows Server 2022のWindowsファイアウォールで特定IP（国別・ブラジル）を全ポート遮断できない原因と解決策

Windows Server 2022で「特定国（例：ブラジル）からのアクセスを全ポート遮断したい」とWindowsファイアウォール規則を作ったのに、RDPやHTTPが普通に通ってしまう――この手のトラブルは“設定ミス”というより「適用条件の見落とし」が原因で起きがちです。最短で原因を切り分け、確実にブロックできる手順をまとめます。

起きている現象（今回の前提）

Windows Server 2022 で、以下のような「受信規則」を作成したにもかかわらず、VPN等でブラジルIPを利用しても RDP（TCP 3389）や HTTP（TCP 80）にアクセスできてしまうケースを想定します。

項目	設定内容（例）	意図
名前	Block-Brazil	ブラジル由来の通信を識別しやすくする
種類	受信の規則（Inbound）	外部→サーバーへの到達を遮断
プロトコル/ポート	すべて（全ポート）	3389/80/443など個別設定漏れを防ぐ
リモートIP	ブラジルのIP（約200件）	国別ブロック（ただし“完全”ではない）
プロファイル	ドメイン／プライベート／パブリック	どのネットワーク状態でも遮断
操作	ブロック	該当IPからの受信を拒否

この状況で「通ってしまう」場合、次の5点のどれか（または複合）がほぼ原因です。

まず押さえる：Windowsファイアウォール規則が効く“条件”

Windows Defender ファイアウォール（Windowsファイアウォール）の受信規則は、ざっくり言うと次をすべて満たしたときに期待どおり動きます。

• 対象プロファイルでファイアウォール自体が有効になっている
• 規則が「有効（Enabled）」になっている
• 規則の条件（方向、プロトコル、ローカル/リモートIP、プログラム/サービス等）が実トラフィックに一致している
• 実際にサーバーが見ている“送信元IP”が、あなたの想定と一致している（VPN/プロキシ/NATの罠）
• GPO、IPsec、上位FW（クラウドのセキュリティグループ等）など、別レイヤの制御が挙動に影響していない

つまり「ブロック規則を作ったのに効かない」は、規則の中身の問題だけでなく、“規則が適用される世界線にいない”（無効、プロファイル不一致、実IP違い）ことが多いです。

原因切り分けの最短チェック表（ここから順番に潰す）

チェック	よくある原因	確認方法	直し方
規則が無効	作成しただけで「無効」のまま	Get-NetFirewallRule	Enable（有効化）
ファイアウォール自体がOFF	対象プロファイルでFWが無効	Get-NetFirewallProfile	プロファイルをON
プロファイル不一致	NICが想定外のプロファイル	Get-NetConnectionProfile	規則/プロファイルを合わせる
リモートIPが一致していない	VPN出口IP、プロキシIP、LBのIPになっている	netstat / Get-NetTCPConnection / ログ	“サーバーから見えるIP”を基準に再設計
IPv6が抜けている	IPv4のみ登録、実通信はIPv6	接続元IPの表示でv6確認	IPv6レンジも追加、またはIPv6受信設計を見直し

規則が本当に「有効」か確認する（最優先）

今回のような「作ったのに効かない」の最頻出は、シンプルに規則が無効です。GUIで作成しても、テンプレートや複数管理者の運用、インポート作業などで無効のまま残ることがあります。

管理者権限の PowerShell で、まずこれを実行します。

Get-NetFirewallRule -DisplayName "Block-Brazil" | Select-Object DisplayName, Enabled

Enabled が False の場合は、以下で有効化します。

Set-NetFirewallRule -DisplayName "Block-Brazil" -Enabled True

そして、念のため「どのプロファイルに適用される設定か」も同時に確認します。

Get-NetFirewallRule -DisplayName "Block-Brazil" |
  Select-Object DisplayName, Enabled, Direction, Action, Profile, PolicyStoreSourceType, PolicyStoreSource

ここで確認したいポイントは次のとおりです。

• Direction が Inbound になっているか（受信規則になっているか）
• Action が Block になっているか
• Profile が意図したプロファイルを含んでいるか
• PolicyStoreSourceType が「Local」以外（GPO由来）になっていないか（意図せず上書きされることがあります）

ファイアウォール自体が有効か（プロファイル別に確認）

規則が正しくても、FWが対象プロファイルで無効なら素通りします。プロファイル別に状態を確認します。

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction

確認のコツ：

• 通常、サーバーの受信は「Block」が基本です（公開サーバーで “許可したものだけ” を通す）。
• DefaultInboundAction が Allow になっている環境は、意図せぬ受信が通りやすく、ルール設計が難しくなります。

なお、既存環境でいきなり既定受信をBlockに切り替えると業務影響が出る場合があります。まずは今回のような「明確な遮断目的」のルールを確実に効かせることが先決です。

ネットワークプロファイルが規則と一致しているか

規則で「ドメイン／プライベート／パブリック」にチェックを入れていても、実際のNICがどれとして認識されているかは必ず確認してください。

Get-NetConnectionProfile

ここで表示される NetworkCategory（DomainAuthenticated / Private / Public）が、規則の Profile と一致している必要があります。運用現場でありがちな罠は次です。

• 「ドメインだけ有効」なルールを作っていたが、NICが一時的に Public 扱いになっていて適用されていなかった
• 複数NICがあり、管理者が見ている接続と、実際にインターネット側を向いているNICのプロファイルが別だった

サーバーは複数NIC・仮想スイッチ・チーミングなど構成が複雑になりやすいので、“このNICが外を向いている”前提で確認するのが重要です。

リモートIPの一覧は十分か（IPv4/IPv6、レンジの網羅）

国単位の遮断をIPリストで実現する場合、最初に理解しておくべきポイントがあります。

• 国別IPは「点」ではなく、多数のネットワークレンジ（CIDR）で割り当てられている
• IPv4だけ登録しても、IPv6で到達できる経路があればすり抜ける
• 割り当ては変動するため、リストは定期更新が前提

今回のケースでも、ブラジルのIPを約200件登録したとのことですが、これは「たまたま拾えた一部」になっている可能性があります。国別ブロックの精度を上げるには、IPv4/IPv6両方の国別レンジを取得して反映する必要があります。

「IPを200件入れたのに通る」典型パターン

• 接続元がIPv6で来ていて、登録リストがIPv4のみ
• VPNの出口がブラジル以外の国にあり、サーバーから見ると別国のIP
• HTTPはCloud/CDN/リバースプロキシ経由で、サーバーから見ると“プロキシのIP”
• 拾ったリストが古く、現在の割り当てとズレている

この段階で重要なのは、「自分が思っている送信元IP」ではなく、サーバーが実際に観測している送信元IPを根拠にすることです。

サーバーから見えている「実際のリモートIP」を確認する

VPN・プロキシ・NAT・踏み台などが絡むと、クライアント側で見えているIPと、サーバー側で見えているIPが一致しないことが普通に起こります。ブロックが効かないときは、まずログ/接続情報から実IPを確定させてください。

RDP（TCP 3389）の接続元IPを確認する

RDPで接続できてしまっているなら、接続直後にサーバー側で以下を実行し、3389の接続元を確認します。

netstat -n | findstr :3389

よりPowerShellらしく確認するならこちらも便利です（確立済み接続の例）。

Get-NetTCPConnection -LocalPort 3389 -State Established |
  Select-Object -Property LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess

表示された RemoteAddress が、あなたがブロック規則に登録したリストに含まれているかを照合します。含まれていないなら、ブロックできないのは当然で、リストの不足か、IPの見え方（VPN出口など）の問題です。

HTTP（TCP 80）の接続元IPを確認する

HTTPも同様に、確立済み接続のRemoteAddressを見ます。

Get-NetTCPConnection -LocalPort 80 -State Established |
  Select-Object -Property LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess

IISを使っている場合は、IISログ（例：C:\inetpub\logs\LogFiles）でクライアントIPを確認できます。ただし、リバースプロキシやCDNの背後にある場合、ログにはプロキシのIPしか残らないことがあります。その場合、サーバーOSのファイアウォールで「国別ブロック」をやろうとしても、そもそも判断材料がサーバーに届いていません。

イベントログで「ログオン元アドレス」を確認する

RDPログオンの証跡はイベントビューアーでも追えます。

• イベント ビューアー → Windows ログ → セキュリティ（ログオン/失敗）
• RDP関連のログ（運用によっては専用ログも有効化）

「どのIPから来ているか」が確定すれば、ブロック対象の正誤がはっきりします。

作った規則の“中身”をPowerShellで可視化する

GUI上は「全ポート」「リモートIP設定済み」に見えても、実際のフィルター条件が想定と違うことがあります。次のコマンドで、アドレス条件やポート条件を直接確認します。

アドレスフィルター（リモートIP）を確認

Get-NetFirewallRule -DisplayName "Block-Brazil" |
  Get-NetFirewallAddressFilter |
  Select-Object -Property RemoteAddress, LocalAddress

ポート/プロトコル条件を確認

Get-NetFirewallRule -DisplayName "Block-Brazil" |
  Get-NetFirewallPortFilter |
  Select-Object -Property Protocol, LocalPort, RemotePort

ここで RemoteAddress が「Any」になっていたり、意図したレンジが入っていなかったりするなら、GUI操作の過程で設定が反映されていない可能性があります（特にインポート/エクスポートやツール投入時）。

IPv6の抜け道を塞ぐ（国別ブロックの落とし穴）

近年はクライアント環境によってはIPv6が優先されることがあります。ブラジルIPをIPv4だけ登録していると、IPv6で来た通信は普通に通る可能性があります。

切り分けの実務ポイント：

• netstat / Get-NetTCPConnection の RemoteAddress が “:” を含む形式（IPv6）なら、IPv6通信です。
• IPv6も含めて国別レンジを用意し、規則に反映する必要があります。

「国別のIPv4/IPv6リスト」を扱えるサービスやリスト（例：国別レンジ提供サイト、GeoIP系データ）から取得し、IPv4とIPv6を両方取り込むのが現実的です。質問者のケースでも、国別GeoIPリスト（IPv4/IPv6）を取り込み、ツールで一括登録することで期待どおりにブロックできるようになっています。

国別IPレンジをWindowsファイアウォールに取り込む方法

国別ブロックをOSのファイアウォールでやるなら、ポイントは「レンジの収集」「取り込み方法」「更新運用」です。

方法A：国別リスト＋一括登録ツールで運用する

質問者のケースに近い、現場で回しやすい手順です。

• 国別のGeoIPリスト（IPv4/IPv6）を入手する
• NFWR.exe などの一括登録ツールで、CIDRレンジを Windows ファイアウォール規則として投入する
• 投入後に規則が有効になっていることを確認する（無効のままが多い）

この方法のメリットは、手作業で200件・1000件のレンジを貼り付けないで済むこと。デメリットは、ツールやリストの品質・更新タイミングに依存することです。

方法B：PowerShellでテキストファイルから投入する（自動化向き）

外部ツールを使わず、運用をコード化したい場合はPowerShellが向いています。例えば、CIDRレンジが1行1レンジで並んだテキスト（IPv4/IPv6それぞれ）を用意して投入します。

例：テキストファイル（Brazil_IPv4.txt）

200.147.0.0/16
170.0.0.0/8
...（CIDRが1行ずつ）

投入例（サイズが大きい場合に備えて“分割”して複数ルール化するイメージ）：

# 例：200件ずつ分割して複数ルールを作る（運用しやすい）
$baseName = "Block-Brazil"
$chunkSize = 200

$ipv4 = Get-Content "C:\Temp\Brazil_IPv4.txt" | Where-Object { $_ -and $_ -notmatch '^\s*#' }
$ipv6 = Get-Content "C:\Temp\Brazil_IPv6.txt" | Where-Object { $_ -and $_ -notmatch '^\s*#' }

$all = @()
$all += $ipv4
$all += $ipv6

# 既存ルールを整理（必要に応じて）
Get-NetFirewallRule -DisplayName "$baseName*" -ErrorAction SilentlyContinue | Remove-NetFirewallRule

# 分割して作成
$index = 1
for ($i = 0; $i -lt $all.Count; $i += $chunkSize) {
    $chunk = $all[$i..([Math]::Min($i + $chunkSize - 1, $all.Count - 1))]
    $name = "{0}-{1:000}" -f $baseName, $index

    New-NetFirewallRule -DisplayName $name `
      -Direction Inbound -Action Block `
      -Protocol Any `
      -RemoteAddress $chunk `
      -Profile Domain,Private,Public

    $index++
}

ポイント：

• 国別レンジは量が増えがちなので、1ルールに詰め込みすぎないほうが管理しやすいです。
• 投入後に Enabled = True か必ず確認します。
• 更新運用（例：月1回）を前提に、スクリプト化しておくとブレません。

「許可規則」との競合を疑う（ただし“考え方”が重要）

Windows Defender ファイアウォールは一般的に「ブロックが優先」と理解されがちですが、現場では次の要因で“期待どおりに見えない”ことがあります。

• RDPやHTTP向けに複数の許可ルールが存在し、想定外のルールが効いている
• 「許可（セキュアなら許可）」のような特殊な条件付きルールがある
• GPO配布ルールとローカルルールが混在し、管理者の想定と実効構成がズレている
• そもそも“ブロックしたい通信”が別の経路（別NIC、別IP、ポートフォワード、LB等）で入っている

したがって、競合を疑うときは「許可があるからブロックが効かない」と短絡せず、どのルールが、どの条件で、その通信にマッチしたのかを見に行くのが正解です。

RDP/HTTP関連の許可ルールを棚卸しする

例えばRDPのルール群（表示グループ）を確認します。

Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
  Select-Object DisplayName, Enabled, Direction, Action, Profile

さらに「スコープ（リモートIP）」を見たい場合、アドレスフィルターを紐づけて確認します。

Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
  Get-NetFirewallAddressFilter |
  Select-Object -Property RemoteAddress

HTTP/HTTPSはIISやアプリのルール名が環境で異なるため、「80/443を許可しているルール」を探すやり方が確実です。

Get-NetFirewallRule -Enabled True -Direction Inbound |
  ForEach-Object {
    $r = $_
    $pf = $r | Get-NetFirewallPortFilter -ErrorAction SilentlyContinue
    if ($pf) {
      [PSCustomObject]@{
        DisplayName = $r.DisplayName
        Action      = $r.Action
        Protocol    = $pf.Protocol
        LocalPort   = $pf.LocalPort
      }
    }
  } | Where-Object { $_.LocalPort -in @("80","443","3389","Any") } |
  Sort-Object DisplayName

もし「Any（任意）」や「広すぎる許可」が大量に見つかったら、セキュリティ上は整理の余地が大きいです。国別ブロック以前に、RDPは許可元IPを自社拠点/VPNに限定するだけでも効果が高いです。

“効いているはず”を卒業：実際にブロックできたか検証する手順

設定変更後は、検証のやり方を統一すると迷子になりません。おすすめの検証フローを載せます。

手順	やること	合格ライン
接続元IPの確定	サーバー側で netstat / Get-NetTCPConnection で RemoteAddress を確認	“サーバーから見える送信元”が特定できる
規則の一致確認	Block-Brazil の RemoteAddress に、そのIP/CIDRが入っているか照合	入っている（入っていないならリスト不足）
規則の適用確認	Enabled=True、プロファイル一致、FW有効を確認	すべて満たす
遮断の再テスト	同じ経路でRDP/HTTP接続を試す	接続できない（タイムアウト/拒否）

この流れで確認すれば、「ルールはあるのに効かない」状態から、どこでズレているかをかなり短時間で特定できます。

最終的な解決パターン（今回のQAで多い着地点）

今回のような相談で、実際に落ち着くことが多い解決パターンは次の組み合わせです。

• 作成した Block-Brazil 規則が無効だったので有効化した
• ブラジルの IPv4・IPv6レンジを網羅できていなかったため、国別GeoIPリストを取り込み、NFWR.exe等で一括登録した（またはPowerShellで自動投入した）
• サーバー側で「実際に見えている送信元IP」を確認し、リストに含まれることを根拠にブロックを検証した

これにより、RDP/HTTPを含む受信が「ブラジル由来のIPレンジに該当する場合」に期待どおり遮断され、国外からの直接アクセスに対する不安を大きく減らすことができます。

重要な補足：国別ブロックは“万能ではない”ので、併用が前提

国別IPブロックは、攻撃表面を減らすうえで有効ですが、次の理由で「完全な防御」にはなりません。

• VPN・プロキシ・踏み台を使われると、送信元IPが別国になる
• 国別IP割り当ては変動し、リストが古いと抜ける
• CDN/リバースプロキシ配下だと、サーバーが“本当のクライアントIP”を見ないことがある

そのため、RDPや管理系ポート（3389等）をインターネットに直接公開している場合は、次のような対策を併用するのが現実的です。

レイヤ	対策	狙い
入口の設計	RDPはVPN経由、またはRD Gatewayで集約	そもそも3389を晒さない
許可の最小化	RDP許可元を拠点IP/特定VPNに限定	総当たり/スキャンを激減
OS側防御	Windowsファイアウォールで国別レンジ遮断（補助）	雑な攻撃の入口を狭める
認証強化	NLA、強固なパスワード、MFA（可能なら）	突破されにくくする
監視/ログ	失敗ログオン監視、アラート、ロックアウト設計	兆候を早期検知

国別ブロックは「追加の柵」としては優秀です。ですが、最終的には“入ってきてほしくない入口を公開しない”設計に寄せるほど堅くなります。

よくある追加トラブルと対処

GPOで配布されたルールに上書きされている気がする

Active Directory配下のサーバーでは、ローカルで作ったルールより、GPOで配布された設定が優先・上書きされることがあります。前述の PolicyStoreSourceType を確認し、想定外にGPO由来なら、GPO側でルールを管理するほうが運用が安定します。

ブロックしているのに、なぜか一部だけ通る

まずは「通っている通信の RemoteAddress」を確定してください。実務上は、ここで“想定と違うIP（VPN出口、LB、別NIC）”が見つかることが多いです。通っている通信を、ブロックルールの条件に一致させられない限り、ルールの追加・変更は当たりません。

HTTPはプロキシ配下なので、OSで国別遮断しても意味が薄い

その理解は正しいです。HTTP/HTTPSは、WAFやCDN側で国別ブロックやBOT対策ができるなら、入口（プロキシ）側でやるほうが効果が高く、運用も楽です。OS側でやるのは「直アクセスが来る構成」のときに向いています。