https://error-daizenn.hatenablog.com/entry/2025/12/17/214547

2025年12月中旬、「Windows 11の更新を入れたらVPN（仮想プライベートネットワーク）越しの社内リソースに、WSL（Windows Subsystem for Linux／Windows上でLinuxを動かす仕組み）だけ到達できない」という報告が急増しています。Windows側は普通に開けるのに、WSL内だけが「No route to host（ホストへの経路がありません）」で詰まる、あのタイプ。仕事でWSL＋企業VPNを使ってる人ほど刺さるやつです。(マイクロソフトサポート)

何が起きてる？「WindowsはOK、WSLだけNG」の不気味さ

問題の核心は「WSLのミラーモード（mirrored mode／ミラーリングネットワーク）」と一部VPNの組み合わせが、更新後に破綻する点です。(マイクロソフトサポート)
症状はシンプルで、VPN接続そのものは生きているように見えるのに、WSLから社内DNSや社内IPへ行こうとした瞬間に死にます。開発でWSL上のgitやapt、社内API疎通、Kubernetesの社内クラスター操作などをやってる人は、体感で「仕事が止まる」やつ。

発生日時と該当アップデート：KB5067036以降、12月のKB5072033でも継続

Microsoftが既知の問題として明記している起点は、2025年10月28日公開の非セキュリティ更新KB5067036以降です。(マイクロソフトサポート)
そこから「以降の更新」で起き得るとされ、2025年12月9日公開のセキュリティ更新（Patch Tuesday／パッチチューズデーの定例更新）KB5072033でも同様の症状が載っています。(マイクロソフトサポート)
対象の目安として、KB5067036はWindows 11 24H2/25H2でOSビルド26200.7019/26100.7019、KB5072033はOSビルド26200.7462/26100.7462です。(マイクロソフトサポート)

エラー表記と“それっぽい”ログ：No route to host、connect() failed: 101

代表的なエラーはWSL側で出る「No route to host（ホストへの経路がありません）」です。(マイクロソフトサポート)
GitHubのWSL公式Issueでは、WSLの設定でnetworkingMode=mirroredを有効にしている前提で、更新後にVPN越しの宛先だけ落ち、WSLログ（dmesg）にgetaddrinfo() failed: -5やconnect() failed: 101が出た例が載っています。(GitHub)
この“番号”があなたの環境でも見えていたら、かなり同じ筋を踏んでる可能性が高いです。

原因は何？ARPに返事しない仮想インターフェイス問題

Microsoftの説明では「VPNアプリの仮想インターフェイスがARP（Address Resolution Protocol／アドレス解決プロトコル）要求に応答しない」のが直接原因です。(マイクロソフトサポート)
要するに、宛先IPへ行くための“同一ネットワーク上の相手を見つける手続き”が噛み合わず、WSLのミラーモード側が経路を作れなくなる、という説明になっています。Cisco Secure Client（旧Cisco AnyConnect）やOpenVPN（オープンブイピーエヌ）で報告がある、と名指しもされています。(マイクロソフトサポート)

公式対応状況：調査中。Home/Proの一般ユーザーは当たりにくい

現時点でMicrosoftは「調査中（under investigation）」で、明確な回避策（workaround）は提示していません。(マイクロソフトサポート)
また「Windows 11 Home/Proの家庭用途ユーザーは遭遇しにくく、企業リソースへのVPN接続（DirectAccess／ダイレクトアクセス含む）が中心に影響」とも書かれています。(マイクロソフトサポート)
つまり“普通のVPNが全部死ぬニュース”ではなく、「WSL＋特定のネットワークモード＋企業VPN」という、ピンポイントな地雷です。だからこそ、社内で気づくのが遅れて炎上しがち。うわ…ってなる。

まず切り分け：あなたのWSLはミラーモードになってない？

この不具合は「mirrored mode（ミラーモード）」が条件に入るので、そこを最初に確認するのが最短ルートです。(マイクロソフトサポート)
Microsoftのドキュメントでは、.wslconfigのnetworkingMode=mirroredでミラーモードを有効化できる、とされています。(Microsoft Learn)
もし「VPNで楽にするためにmirroredにした」「最近WSL SettingsでネットワークをMirroredに切り替えた」心当たりがあるなら、かなり怪しいです。

今すぐの対処：mirroredを一旦やめて“元に戻す”のが現実的

公式が回避策を出していない以上、当面は“問題が出るモードを使わない”が一番堅いです（悔しいけど）。(マイクロソフトサポート)
以下は「戻したら直った」系の動き方として、現場でやりやすい順番です（※環境によって挙動は変わります。とりあえすここから）。

(1) Windows側で、%UserProfile%\.wslconfig（例：C:\Users\あなた\.wslconfig）の中身を確認します。
(2) [wsl2]配下にnetworkingMode=mirroredがあれば、いったん削除するか、networkingMode=natへ変更します（NAT＝従来モード）。(Microsoft Learn)
(3) PowerShellでwsl --shutdownを実行して、WSLを完全再起動します。(Microsoft Learn)
(4) VPN接続を張り直し、WSL内から社内DNSや社内IPに疎通（pingやcurl）を試します。
(5) それでもダメなら、WSLの設定でdnsTunnelingやプロキシ周りを触っていた人は、一旦“追加の実験設定”も外して挙動を見ます（mirrored関連の機能なので影響が連鎖しがち）。(Microsoft Learn)

「mirroredの恩恵がないと困る」人もいると思うんですが、今は“仕事が動く”を優先した方が勝率が高いです。don’t try to be a hero…みたいなやつ。

企業IT目線：更新管理でやるなら“影響範囲の見える化”が先

利用者に個別対応させる前に「WSL＋mirrored＋特定VPNの組み合わせ」を資産管理で炙り出すのが、結局いちばん安いです。(マイクロソフトサポート)
今回のポイントは、Windows全体のVPN障害ではなく、WSLのネットワークモード依存で起きるところ。だからヘルプデスクに「VPN繋がりません」が来ても、Windows側でWebが見えるなら“WSL限定か？”の質問を差し込むだけで、無駄な切り分けを減らせます。

みんなの報告：現場の温度感はかなり荒れてる

ユーザー側の不満は「なぜこれが更新で壊れる？」に集約されていて、再現性の高さが逆に怖いです。(Reddit)
たとえばRedditでは「Why is there no testing for this…?」みたいな怒りの声が目立ちます（言い回しはそのまま載せにくいので省略したけど、空気は伝わるはず）。(Reddit)
GitHub側でも「更新をアンインストールすると戻る」という趣旨の報告があり、更新と症状の紐づきはかなり濃いです。(GitHub)
国内でも窓の杜が、KB5067036以降でWSLのミラーリングネットワークがVPNと問題を起こす、と整理して報じています。(窓の杜)
そして海外ではForbesも「Microsoftが認めた（confirms）」として取り上げています。(フォーブス)

コメント欄で募集：あなたの環境、どうなってる？

あなたの1行報告が、同じ沼にいる人の最短の救命ロープになります。
コメントするなら、できればこの5点だけ揃えてください。Windows 11のバージョン（24H2/25H2など）とOSビルド、該当KB（KB5067036/KB5072033など）、WSLのバージョン（wsl --version）、VPN製品名（Cisco Secure Client/OpenVPN/その他）、そしてWSLがmirroredかNATか。
「mirrored→NATで直った／直らない」「特定の社内サブネットだけ死ぬ」みたいな差分も、めちゃくちゃ価値あります。