Windows 11／Windows Server 2025 の環境で、127.0.0.1（::1）などループバック経由か、実質的にループバックにリゾルブされるローカル IP に対して既定ポート 3389 で RDP 接続すると即切断され、「Your computer could not connect to another console session…（すでにコンソール セッションが進行中）」と表示されます。本稿ではこの挙動の原因（仕様変更）と、現実的な回避策・運用上の注意点を、検証手順や設定例とともに詳細に解説します。
事象の整理（症状・前提）
- 対象 OS：Windows 11（23H2/24H2 系を含む）、Windows Server 2025
- 発生条件：
- 接続先に
127.0.0.1／::1（ループバック）や、結果的にループバックにルーティングされるローカル IP を指定し、RDP 既定ポート 3389/TCPへ接続。 - RDP クライアント（mstsc／Microsoft Remote Desktop）は即座に切断し、“Your computer could not connect to another console session on the remote computer because you already have a console session in progress.” と表示。
- パケットキャプチャでも RDP の SYN すら送信されない（クライアント側で事前ブロック）。
- 接続先に
- 比較：
- 同じ条件で Windows Server 2022 では再現しないケースが多数報告。
- 既定ポートを 3389 以外（例：3390）に変更すると接続できる。
原因：ループバック＋3389 を遮断するクライアント側のセキュリティ強化
Windows 11／Windows Server 2025 のリモート デスクトップ クライアントは、「宛先がループバック経由」かつ「宛先ポートが 3389」という組み合わせを検知すると、RDP ハンドシェイク前に接続を拒否します。RDP サービス（TermService）が起動しているか否かを問わず、クライアントが接続を成立させないため、Wireshark でも RDP の通信は観測されません。
背景として、3389/TCP は攻撃面が広く（総当たり・踏み台化・トンネリング悪用等）、ローカルでの 3389 ループバック転送（プロキシ／トンネル）を抑制する意図のハードニングと考えるのが妥当です。実際に「localhost:3389 を経由するトンネル」や「プロセス内フックによるローカル折り返し」は、過去の攻撃・検証文献でも多用されてきました。今回の変更は、こうした悪用余地をクライアント側で潰すアプローチと整合します。
ポイント：本件は クライアント側の接続抑止 であり、サーバー側の「3389 が LISTEN しているか」「ファイアウォールが開いているか」とは切り分けて考える必要があります。
「正式に無効化できる設定」は現時点で存在しない
グループ ポリシーやレジストリで「ループバック検知だけを無効化する」公式設定は、2025 年時点では公開されていません。既存の DisableLoopbackCheck（HTTP/NTLM のループバック検知）などのレジストリは RDP とは無関係で、影響しません。将来的にポリシー追加や KB 改善が入る可能性はありますが、少なくとも現行チャネルでは “ループバック＋3389” を許可するサポート手段は提示されていません。
まずは再現確認（切り分け手順）
- 管理者でサインインし、RDP サービスの状態を確認：
Get-Service TermService netstat -ano | findstr :3389 - ローカルから
mstsc.exeを起動し、127.0.0.1:3389へ接続。即時に前述のエラーで切断される。 - 同時に Wireshark で
tcp.port == 3389フィルタを適用。SYN が飛ばない（= クライアントで事前拒否）ことを確認。 - 接続先を
127.0.0.1:3390に変えて試験（後述のポート変更や転送設定を入れてから）。今度はハンドシェイクが始まることを確認。
実用的な回避策（安全性・運用性・手間で比較）
| 方法 | 概要 | 長所 | 注意点 | おすすめ度 |
|---|---|---|---|---|
| RDP のリッスンポートを変更 | 3389 → 3390 等に変更し、localhost:3390 で接続 | 単純・確実。クライアント側検知を回避 | FW/NAT/公開設定を併せて更新。再起動またはサービス再起動が必要 | ◎（推奨） |
| ローカル L4 転送（portproxy 等） | 127.0.0.1:3390 → 127.0.0.1:3389 へ OS 内で転送 | サーバーポートは 3389 のまま。アプリ側は 3390 に接続 | OS 機能（netsh）や常駐転送ツールの保守が必要 | ◎ |
| 物理/仮想 NIC 経由（NAT/ブリッジ） | VM/コンテナ/WSL2 などからホストの実 IP 宛てに接続 | 設計上ループバックを通らないためブロックされない | ネットワーク設計が複雑化。アドレス管理と分離に配慮 | ○ |
| 旧 OS を利用 | Server 2022 等の検知がない OS で運用 | 即効性あり | サポート/セキュリティ上の見通しが悪化 | △（暫定のみ） |
回避策 1：RDP の受信ポートを 3390 へ変更（最短で堅実）
Windows 公式の手順に沿って、RDP のリッスンポートを変更します。ファイアウォール ルールも合わせて作成してください。 PowerShell（一括適用の例）
# 変更先ポート
$NewPort = 3390
# RDP リッスンポートを変更（レジストリ）
Set-ItemProperty ` -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'`
-Name 'PortNumber' -Value $NewPort
# Windows Defender ファイアウォールに許可ルール（TCP/UDP）を追加
New-NetFirewallRule -DisplayName "RDP-$NewPort-TCP-In" -Profile Any -Direction Inbound -Action Allow -Protocol TCP -LocalPort $NewPort
New-NetFirewallRule -DisplayName "RDP-$NewPort-UDP-In" -Profile Any -Direction Inbound -Action Allow -Protocol UDP -LocalPort $NewPort
# 反映（再起動が最も確実。作業セッションが切れる点に注意）
Restart-Service -Name TermService -Force
# 失敗したら OS 再起動を検討
接続時は mstsc.exe /v:localhost:3390 のようにポート番号を明示してください。インターネット公開・VPN 越しの接続を運用している場合は、NAT・WAF・SASE・クラウド FW などの転送/許可設定も忘れずに更新します。
運用上の注意：ポート変更は「見つかりにくくする」効果しかありません。真正のセキュリティ対策としては、NLA（ネットワーク レベル認証）必須化・多要素認証・IP 制限・踏み台/ゲートウェイ化・ゼロトラスト（ZTNA/VPN）を併用しましょう。
回避策 2：OS 内部転送（portproxy）で 3390 → 3389 にブリッジ
「サーバーの受信ポート（3389）は変えられないが、クライアントは 3389 以外へ接続したい」場合は、Windows 標準の netsh interface portproxy を使います。 コマンド例（IPv4 → IPv4）
:: 登録
netsh interface portproxy add v4tov4 listenaddress=127.0.0.1 listenport=3390 connectaddress=127.0.0.1 connectport=3389
:: 確認
netsh interface portproxy show v4tov4
:: 削除
netsh interface portproxy delete v4tov4 listenaddress=127.0.0.1 listenport=3390 RDP クライアントは 127.0.0.1:3390 に接続するため、“ループバック＋3389” の検知を回避できます。転送自体は OS 内で行われ、最終的に 3389 を利用します。
回避策 3：仮想化／NAT／ブリッジ経由で「実 IP」を使う
Hyper‑V／VMware／WSL2／Docker などを用い、ホストとは別の NIC（仮想 NIC を含む）経由で接続します。例えば、同一ホスト上の VM からホストの 192.168.x.x 宛てに RDP すれば、ループバック インターフェイスを通らないためブロックに該当しません。設計次第で、NAT 越し・ブリッジ接続のいずれでも成立します。
回避策 4：テスト限定の迂回（SSH ローカルフォワード等）
検証・一時対応に限り、OpenSSH のローカルポートフォワードで localhost:3390 → localhost:3389 を張る方法もあります。
ssh -L 3390:127.0.0.1:3389 127.0.0.1
mstsc.exe /v:127.0.0.1:3390
ただし恒久運用には向きません。転送プロセスの死活監視・再接続や、資格情報の保護など付帯設計が必要です。
よくある誤解と非推奨の対処
- DisableLoopbackCheck を触る： これは HTTP/NTLM の “認証ループバック検知” を抑止するための設定であり、RDP には効果がありません。
- 127.0.0.2 を使うと回避できる： 旧来の限定的な裏技に過ぎず、現在のクライアント側検知（ポート 3389 条件）は回避できないケースが大半です。
- FW を全開放する： 問題の本質はクライアント側の事前ブロックであり、ホスト FW を無効化しても変わりません。むしろリスクを増やします。
診断・検証のためのコマンド集
ポート監視・到達性の確認
# 3389/3390 の LISTEN を確認
netstat -ano | findstr /R ":3389|:3390"
# ループバックに対する TCP 到達性（ソケットレベル）
PowerShell: Test-NetConnection -ComputerName 127.0.0.1 -Port 3389
# RDP サービス（TermService）
Get-Service TermService | Format-List Status,StartType ファイアウォール（Windows Defender Firewall）の RDP ルール
# 既定ルールの有効化（TCP/UDP）
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Set-NetFirewallRule -Enabled True
# 変更ポート用の明示ルール追加（例：3390/TCP,UDP）
New-NetFirewallRule -DisplayName "RDP-3390-TCP" -Profile Any -Direction Inbound -Action Allow -Protocol TCP -LocalPort 3390
New-NetFirewallRule -DisplayName "RDP-3390-UDP" -Profile Any -Direction Inbound -Action Allow -Protocol UDP -LocalPort 3390 セキュリティ設計の勘所（ポート変更は万能ではない）
- NLA 必須化：「リモート デスクトップでの接続にネットワーク レベル認証を要求する」 を有効化。
- 多要素・踏み台：Azure AD/Microsoft Entra の条件付きアクセスや RD Gateway、Bastion などの踏み台を活用。
- IP 制限／地理ブロック：公開時は許可元を最小化。SASE/クラウド FW 側ポリシーで制御。
- 監査と検知：ログオン失敗のしきい値、アカウントロックアウト、EDR によるブルートフォース検知。
- 公開不要なら公開しない：インターネットへ直接 3389/UDP,TCP を出さない（VPN/ZTNA を前提に）。
互換性メモと社内検証サマリ
| 組み合わせ | 127.0.0.1:3389 | 127.0.0.1:3390 | VM→ホスト実 IP:3389 | 備考 |
|---|---|---|---|---|
| Windows 11（24H2）＋ mstsc | ×（即時エラー） | ◯（接続可） | ◯（接続可） | クライアント側検知により3389/Loopbackはブロック |
| Windows Server 2025 ＋ mstsc | ×（即時エラー） | ◯ | ◯ | Server 2022 では 127.0.0.1:3389 でも接続可な構成が存在 |
| Windows Server 2022 ＋ mstsc | ◯（接続可） | ◯ | ◯ | 本仕様は未適用（環境差はあり） |
※上表は複数の再現報告と検証結果を整理したもので、すべてのビルドに対して保証するものではありません。累積更新やチャネル差（GA/Insider/セキュリティ更新）で挙動が変わる場合があります。
トラブル時のチェックリスト
- 接続先指定を誤って
:3389にしていないか（3390 等に切替）。 - リッスンポート変更が TermService 再起動・OS 再起動まで反映されているか。
- Windows Defender Firewall／EDR／UTM／クラウド FW の 新ポート許可が反映済みか。
- RD Gateway／Bastion／ZTNA の ポリシーとヘルスチェックに矛盾がないか。
- 同一マシンでの自己 RDP による ユーザー切替・セッション切断の副作用を理解しているか（運用注意）。
補足：なぜ「3389 以外」なら動くのか
今回の拒否条件は「ループバック＋3389」という組み合わせ検知に依存しているため、宛先ポートが 3389 でなければブロックが発火しません。ゆえに、3390 などへクライアントの接続先を変える（サービス側のリッスンポートを変える／OS 内部転送で肩代わりする）ことで、RDP ハンドシェイクまで到達できる、という仕組みです。
まとめ
- Windows 11／Windows Server 2025 では、ループバック インターフェイス経由かつ 3389/TCP 宛ての RDP 接続はクライアント側で事前遮断され、“すでにコンソール セッションが進行中” エラーになります。
- 公式に検知をオフにする手段は現状なし。DisableLoopbackCheck など他機能の設定は RDP に無関係。
- 現実的な回避策は、①リッスンポート変更（推奨）、②OS 内部転送で 3390 → 3389、③NAT/ブリッジ等の別 NIC 経由、④（暫定）旧 OS への切戻し。
- ポート変更は「隠蔽」であって防御ではない。NLA・MFA・踏み台・IP 制限・監査を組み合わせ、攻撃面を最小化するのが必須です。
- 累積更新やリリースで挙動が変わる余地があるため、運用中はリリースノートや既知の問題（Release Health）を定期確認しましょう。
コメント