WSLでVPNが「No route to host」原因はKB5067036、対処はmirrored解除

Windows 11を更新したら、なぜかWSL（Windows Subsystem for Linux／Windows上でLinuxを動かす仕組み）だけ社内ネットワークに届かない。Windows本体はVPN越しに普通にアクセスできるのに、WSL内の git や ssh や社内APIだけが沈黙して「No route to host」……地味に仕事が止まります。

今回の話は「Windows 11の更新が、WSLのmirrored networking（ミラーネットワーク）と一部VPNの組み合わせを壊す」というやつで、企業VPNを使ってる開発者・情シス・在宅勤務勢が直撃しがちです。報道（BetaNews）と、Microsoftの既知の問題（Known issue）としても記載が出ています。(BetaNews)

何が起きてる？症状は「WSLだけ通信できない」

WSL内では「No route to host」が出るのに、Windowsホスト側は同じ宛先へ到達できるのが典型パターンです。 (マイクロソフトサポート)

エラー表示はまんま “No route to host”（ホストへの経路がない）で、WSLから社内のGitサーバや踏み台、VPN配下のDNS、DirectAccess（ダイレクトアクセス）系の宛先に行けなくなります。一方でWindows側のブラウザやPowerShellからは通るので、「DNS？プロキシ？社内FW？」と迷子になりやすいんですよね。(マイクロソフトサポート)

発生日時と、関係している更新プログラム

Microsoftは“2025年10月28日公開のKB5067036以降”で起きうると明記しています。 (マイクロソフトサポート)

時系列で押さえると、まず起点が 2025年10月28日公開のWindows非セキュリティ更新プログラム KB5067036。そこから「以降の更新でも発生しうる」で、2025年12月9日公開の累積更新 KB5072033（OS Builds 26200.7462 / 26100.7462）でも同じ既知の問題として載っています。つまり“直ったと思って12月パッチ当てたらまだいた”になり得るタイプ。(マイクロソフトサポート)

BetaNews側も「10月のKB5067036から始まって、その後の更新でも続いている」とまとめています。(BetaNews)

影響を受ける条件は「mirrored networking × 一部VPN」

トリガーはWSLのmirrored networking（ミラーネットワーク）を有効にしていることです。 (マイクロソフトサポート)

WSLはネットワークの持ち方がいくつかあって、mirroredは“Windows側のネットワークに寄せて、LANからWSLへ繋ぎやすくしたり、VPNとの相性を良くしたりする狙い”のモードです。ところが今回、そのmirroredが「特定のVPN仮想NICと噛み合わない」方向に倒れました。(BleepingComputer)

Microsoftが名指しで「影響の報告がある」としているのは Cisco Secure Client（旧Cisco AnyConnect）と OpenVPN（オープンブイピーエヌ）。ただし“これが全部”ではない、とも読める書き方です。(マイクロソフトサポート)

明確な原因はARPが返ってこないこと

原因は「VPNアプリの仮想インターフェースがARP（Address Resolution Protocol）要求に応答しない」ことだと説明されています。 (マイクロソフトサポート)

ARPはざっくり言うと「このIPアドレスって、LAN上のどの機器（MACアドレス）？」を解決する仕組みです。mirroredのWSLはWindows側のネットワークに“同居”しようとするので、ここでARPが詰まると、結果としてルーティング（経路）が成立せず「No route to host」に見える。DNSが合ってても、名前解決できても、最後の一歩で倒れます。(BleepingComputer)

公式の対応状況：修正は未提供、調査中

2025年12月時点でMicrosoftは“調査中（under investigation）”で、恒久修正や確実な回避策はまだ提示していません。 (マイクロソフトサポート)

ここがつらいところで、Microsoftのリリースノート上は「追加情報は分かり次第共有する」止まりです。BetaNewsも「修正もワークアラウンドも出ていない」と指摘しています。(BetaNews)

なおMicrosoftは「HomeやProの家庭利用者は起きにくく、主に企業リソースへのVPN接続で影響」とも書いています。けど在宅で社内VPN使ってる“個人端末っぽい運用”は普通にあり得るので、読者的には他人事じゃないはず。(マイクロソフトサポート)

対象ユーザー層：開発・運用でWSL＋企業VPNを使う人

刺さるのは「Windowsは社内VPNで仕事、WSLで開発・自動化」という構成の人です。 (マイクロソフトサポート)

たとえばWSLでコンテナやCI用スクリプトを回してたり、WSL内のssh鍵で踏み台に入っていたり、VPN配下の社内DNSに依存していたり。こういう“いつもの道具立て”ほど、突然の「WSLだけ繋がらない」で被害が大きいです。

他ユーザーの報告事例：GitHubやRedditでも増加

GitHubのmicrosoft/WSLでは、特定KB以降に「mirrored＋VPNでNo route to host」になったという報告が複数出ています。 (GitHub)

例として、Issueでは Windows 11 24H2・WSL 2.6.x 系で、社内VPN越しの通信が失敗する、といった書きぶりが見えます（環境は投稿者ごとに差あり）。(GitHub)
Reddit側でも「テストしてないの？」みたいな愚痴含みで話が伸びています。温度感、わかる…。(Reddit)

まず確認して：あなたはmirroredを使ってる？

“何も設定してないWSL”だと、そもそもmirroredを使っていない可能性が高いです。 (マイクロソフトサポート)

mirroredは便利なので、有効化している人は .wslconfig で networkingMode=mirrored を入れていたり、WSLの設定変更を試していることが多いです。「以前VPN対策でmirroredに変えた記憶がある」なら、今回の当たり判定が濃いめ。

現場の暫定対処：mirroredをやめてNATに戻す

公式がワークアラウンド未提示でも、現場では“mirroredを無効化してNATへ戻す”がまず試されます（ただし自己責任）。 (マイクロソフトサポート)

手順はシンプルです。コードブロックは使わずに書くね。

(1) %USERPROFILE%\.wslconfig をメモ帳で開きます。存在しない場合は新規作成します。
(2) [wsl2] の下に networkingMode=nat を書く、または networkingMode=mirrored を削除します。
(3) 管理者権限のターミナルで wsl --shutdown を実行してWSLを完全停止します。
(4) もう一度WSLを起動し、VPN越しの宛先へ疎通（sshやcurl）を確認します。

NATに戻すと、LANからWSLへ直接入る運用や、一部の“同居感”は弱くなることがあります。なので「mirroredじゃないと困る用途」がある人は、会社の情シスと相談しつつ、いったん仕事を回すための暫定にするのが現実的です。

ここから先は、コメント欄で情報戦しよう

この手のネットワーク不具合は“環境の組み合わせ”で当たり外れが出るので、みんなの報告が一番効きます。 (マイクロソフトサポート)

もし今まさに踏んだ人、次の形式で置いていってください。誰かの復旧が速くなるやつです。
Windowsのバージョン（24H2/25H2など）とOS Build。
入れた更新プログラム（KB5067036 / KB5072033 など）。
WSLのバージョン（例：2.6.2.0）。
VPN製品名（Cisco Secure Client / OpenVPN / それ以外）。
mirroredの有効・無効、NATに戻して直ったか。

あなたのところでは「mirroredを切ったら即復活」でした？ それとも、切ってもまだ詰まる？ その場合、どこで詰まってる感じか（DNSだけ？特定サブネットだけ？）も聞きたいです。ちょっと眠いけど、こういうの集まると強いんだよね…。