お問い合わせ

IPv6(MAP-E)で盛大に沼った話

Summary

目次 引っ越したらVPNがつながらなくなった！ 自宅を引っ越したあと、これまで問題なく利用できていたIPsec VPNが突然接続できなくなりました。 回線は引き続きNURO光を利用していたため、当初は特に問題は発生しない […]

目次

引っ越したらVPNがつながらなくなった！

自宅を引っ越したあと、これまで問題なく利用できていたIPsec VPNが突然接続できなくなりました。

回線は引き続きNURO光を利用していたため、当初は特に問題は発生しないと考えていました。実際、インターネット接続自体は正常です。Webサイトの閲覧もできるし、通常の通信には大きな違和感がありません。

さらに、社内には同じ回線を利用しているメンバーもいて、そちらではVPN接続できていました。つまり、単純に「NURO光だから接続できない」「回線全体が悪い」とは言い切れない状況です。

  • インターネット接続は正常
  • 同じ回線を使っている他メンバーはVPN接続できている
  • 自分の環境だけIPsec VPNが接続できない
  • Windows標準VPNからの接続が失敗する

最初は原因がまったく見えず、「回線を解約するしかないのでは……」とまで考えました。しかし、結果的には回線そのものではなく、IPv6(MAP-E)環境、証明書認証、FortiGate側の設定、Windows VPN側の設定が複合的に絡んだ問題でした。

検証環境

今回検証・切り分けを行った環境は以下の通りです。FortiOSについては、当初 v7.4.7 の環境から調査を開始し、その後 v7.4.12 へアップデートしたうえで確認しています。

VPNゲートウェイ

FortiGate 60F
 

FortiOS

v7.4.7 → v7.4.12
アップデート後に挙動・設定項目を確認

クライアントOS

Windows 11 Home

VPN方式

IKEv2

認証方式

証明書認証（自己署名）

回線環境

IPv6（IPoE / MAP-E）

発生した事象

今回発生していた事象を整理すると、以下のような状態でした。

  • 引っ越し後にIPsec VPNが接続できなくなった
  • インターネット接続は正常
  • 社内LANへのVPN接続のみ失敗
  • 同じ回線を利用している他ユーザーはVPN接続可能
  • Windows標準VPN（IKEv2）で接続できない
  • FortiGate側ログとWindows側の表示が一致しない場面があった

ポイント

一見すると回線障害のように見える状況でしたが、実際には複数の設定要素が絡み合っており、

一つずつ切り分けて確認する必要がありました。

今回の構成

今回の構成は、FortiGate 60FをVPNゲートウェイとし、クライアント側ではFortiClientではなくWindows標準VPNを利用する形です。VPN方式はIKEv2、認証は証明書認証を採用しています。

FortiGate 60FとWindows標準VPNを利用した、IPv6(MAP-E)環境での接続全体像です。

今回の接続イメージ

💻自宅PCWindows標準VPN / IKEv2
→
☁️IPv6回線IPoE / MAP-E環境
→
🌐InternetIPv6経路で到達
→
🛡️FortiGate 60FVPN Gateway
→
🏢社内LANRDP / 社内システム

まず疑ったのはMAP-E環境

調査を進めるうちに、自宅回線がMAP-E環境で動作していることが分かりました。

MAP-Eは、ざっくり言えばIPv6ネットワーク上でIPv4通信を扱うための方式です。家庭向け回線では、IPv4アドレス不足への対応や通信方式の変化により、IPv6(IPoE)やIPv4 over IPv6の利用が増えています。

通常のWeb閲覧ではあまり意識しなくても問題になりにくい一方、従来のIPv4前提で構成されたVPNでは、NAT、ポート利用、経路、名前解決、証明書検証などが複合的に影響する場合があります。

従来のIPv4前提の接続と、IPv6(IPoE) / MAP-E環境での接続イメージを比較しています。

従来のイメージ：IPv4前提

💻 PC
↓
🔢 IPv4経路
↓
🛡️ VPN装置へ接続

今回のイメージ：IPv6 / MAP-E

💻 PC
↓
☁️ IPv6(IPoE)
↓
🔁 MAP-E / IPv4 over IPv6
↓
🛡️ VPN装置へ接続

ポイント

「インターネットは普通に使えるのにVPNだけ繋がらない」という場合、回線側のIPv6化やIPv4 over IPv6方式が影響している可能性があります。ただし、今回のように証明書名やVPN設定も絡むため、MAP-Eだけを原因と決めつけるのは危険です。

FortiClientではなくWindows標準VPNを使った理由

今回はFortiClientではなく、Windows標準のVPN機能を利用する方針としました。

  • クライアントソフトの追加配布を避けたい
  • アップデート管理の負荷を下げたい
  • Windows標準機能で運用できる構成にしたい
  • 証明書認証を前提に、将来的な管理性も確保したい

環境によっては専用クライアントを使う方が適している場合もあります。今回は「Windows標準VPNでどこまで安定運用できるか」を重視しました。

IPv6対応IPsec VPNの構築開始

まずは社内側のIPv6通信基盤を整備しました。もともと社内側にはIPv6が導入済みだったため、必要な箇所へ設定を追加していきます。

  • 必要箇所へのIPv6アドレス設定
  • ルーティング設定
  • ファイアウォールポリシー追加
  • 疎通確認

ここまでは問題なく完了しました。IPv6通信自体は通っており、経路や基本的な疎通には大きな問題はなさそうです。しかし、本当の沼はここから始まります。

第1の沼：VPNが接続できない

FortiGate 60FにIPv6用のIPsec VPNを作成し、Windows標準VPNから接続を試みます。しかし、接続は失敗します。

しかも厄介だったのは、エラーメッセージやログの見え方が毎回微妙に違うことでした。

  • 認証失敗のように見える
  • 名前解決失敗のように見える
  • ポリシー不一致のように見える
  • 単純な接続タイムアウトにも見える

ログを見ては設定を変え、また接続して失敗。原因が一つに絞れず、まさに沼という状態でした。

第2の沼：FortiOSアップデート後に見えた "cert-id-validation"

当初のFortiOSは v7.4.7 でした。調査の過程でFortiOSを v7.4.12 へアップデートしたところ、設定項目として以下が確認できました。

set cert-id-validation enable

デバッグログでは、次のようなメッセージが確認できました。

gw validation failed

この設定は、IKEで送信されるIDと証明書内のIDを照合する機能に関連するものと考えられます。今回の環境では、ここが認証フェーズの切り分けポイントになりました。

試しに以下のように変更します。

set cert-id-validation disable

するとデバッグログの内容が変化し、認証フェーズを通過するようになりました。

注意

ここで重要なのは、「無効化すれば常に正解」という意味ではないです。証明書認証におけるID検証はセキュリティ上重要な意味を持つ場合があります。実際の環境では、証明書CN/SAN、接続先名、IKE IDの整合性を確認したうえで判断する必要があります。

なぜ改善したのか

証明書認証では、単に証明書が存在していればよいわけではありません。接続時に使われるID情報と、証明書のCNやSANがどのように一致しているかが重要になります。

Windows VPNから送信されるID情報と、FortiGate側で確認される証明書CN/SANの関係を整理した図です。

IKE ID と証明書情報の照合イメージ

💻Windows VPNIKE ID / 接続先情報を送信
→
🛡️FortiGate受信したIDを確認
→
📜証明書CN / SAN と照合
→
✅認証継続一致すれば次フェーズへ

今回のようにIPv6アドレスで接続しようとしている一方で、証明書はFQDNを前提に発行されている場合、接続先・ID・証明書名の関係が重要になります。

第3の沼：FortiGateでは成功、Windowsでは失敗

さらに調査を進めると、FortiGate側では以下のようなログが出ていました。

authentication succeeded
established IKE SA
added IPsec SA

このログだけを見ると、FortiGate側からは接続が成功しているように見えます。しかし、Windows側では接続失敗と表示されます。

FortiGateでは成功、Windowsでは失敗。ログ上の見え方が一致せず、ここで完全に混乱しました。

ただし、この状態は「FortiGate側のフェーズでは一定の処理が進んでいるが、Windows側が最終的に接続確立と判断できていない」と考えると整理しやすくなります。つまり、FortiGate側ログだけで完了判断するのではなく、Windows側の接続先名や証明書検証も含めて見る必要があります。

原因は接続先と証明書名の不一致

接続先として設定していたのはFortiGateのIPv6アドレスでした。

2001:xxxx:xxxx:xxxx::1

一方で、FortiGateのサーバ証明書はFQDNを前提に発行されていました。

vpn.example.jp

つまり、Windows VPNの接続先はIPv6アドレス、FortiGateの証明書はFQDNという不一致が発生していました。

自己署名証明書のSANが適切に設定されていなかったことも原因であった。

失敗時のIPv6アドレス接続と、解決後のFQDN接続を比較しています。

失敗時：接続先と証明書名が不一致

接続先2001:xxxx:xxxx::1
証明書CNvpn.example.jp
名前が一致せず接続失敗

解決後：FQDNで接続

接続先vpn.example.jp
名前解決2001:xxxx:xxxx::1
証明書CNvpn.example.jp
名前が一致し接続成功

対応として、hostsファイルに対象のIPv6アドレスとFQDNを登録し、Windows VPNの接続先もFQDNへ変更しました。すると、ようやくVPN接続に成功しました。ここで一度、沼から生還した気持ちになりました。

第4の沼：接続できたのにクライアントPCでWebが見れない

VPN接続そのものは成功しました。RDPも通る、Pingも通る。これで解決したと思いました。

  • VPN接続：成功
  • Ping：成功
  • RDP：成功
  • Webブラウザ：RDP側 成功　クライアント側 失敗

しかし、今度はクライアントPC側のWebブラウザでインターネットが見られません。今日の天気予報すら確認できない状態です。

ここは比較的すぐに、スプリットトンネル設定が怪しいと考えました。Windows VPNの設定を確認します。

Get-VpnConnection -Name "vpn-gw" | fl SplitTunneling

結果は以下の通りでした。

SplitTunneling : False

スプリットトンネルが無効のため、VPN接続後の全通信がVPN側へ流れていました。今回の用途では、社内向け通信のみVPNへ流し、それ以外のインターネット通信は通常経路へ出したかったため、以下のコマンドで変更します。

Set-VpnConnection -Name "vpn-gw" -SplitTunneling $True

設定後は、VPN接続中でも通常のインターネットアクセスができるようになりました。これで、ようやく実用上の問題も解消しました。

切り分け時に使ったコマンド例

実際の調査では、Windows側で以下のようなコマンドを使うと状況を整理しやすくなります。

VPN設定確認

Get-VpnConnection -Name "vpn-gw" | fl *

スプリットトンネル確認

Get-VpnConnection -Name "vpn-gw" | fl SplitTunneling

名前解決確認

Resolve-DnsName vpn.example.jp

疎通確認

Test-NetConnection vpn.example.jp -Port 500
Test-NetConnection vpn.example.jp -Port 4500

ネットワーク構成確認

Get-NetIPConfiguration
Get-NetRoute

注意

IPsec/IKEv2ではUDP 500/4500や証明書、名前解決、経路など複数要素が絡みます。単一のコマンド結果だけで判断せず、FortiGate側ログとWindows側状態を突き合わせることが重要です。

FortiGate側で確認したいポイント

環境ごとに設定値は異なりますが、切り分けの観点としては以下を確認します。

  • IPv6アドレスとルーティングが正しいか
  • IPsec VPNのPhase1 / Phase2設定がWindows側と整合しているか
  • 証明書のCN/SANと接続先名が一致しているか
  • IKE IDの扱いが想定どおりか
  • ファイアウォールポリシーで必要な通信が許可されているか
  • FortiOS v7.4.7 と v7.4.12 の設定項目・挙動差を確認しているか
# 例：デバッグ確認時の観点
# 実際のコマンドや出力は環境により異なります

gw validation failed
authentication succeeded
established IKE SA
added IPsec SA

今回の切り分けの流れ

引っ越し後のVPN接続不可から、FortiOS更新、証明書名不一致の発見、スプリットトンネル修正までの流れです。

1. 引っ越し後にVPN接続不可
インターネット接続は正常。他ユーザーは接続できるため、単純な回線断とは言い切れない状態。
2. MAP-E環境を確認
IPv6(IPoE) / MAP-E環境になっていることを確認。IPv4前提のVPN構成に影響している可能性を疑う。
3. IPv6対応VPNを構築
FortiGate 60F側でIPv6アドレス、ルーティング、ファイアウォールポリシーを整備。
4. FortiOSを v7.4.7 から v7.4.12 へ更新
cert-id-validation 周辺の挙動を確認し、gw validation failed を手がかりに切り分け。
5. 証明書名不一致を発見
接続先IPv6アドレスと証明書CN(FQDN)が一致していないことを確認。
6. FQDN接続へ変更
hosts登録とVPN接続先変更により、VPN接続に成功。
7. スプリットトンネルを修正
VPN接続後のWeb通信不可を、SplitTunneling=True で解消。

今回の原因まとめ

VPN接続失敗および接続後の通信不具合に関係した3つの要因を整理した図です。

VPN接続失敗 / 接続後の通信不具合
原因1cert-id-validation
IKE IDと証明書情報の検証
原因2IPv6アドレス接続
証明書CN/FQDNとの不一致
原因3SplitTunneling=False
全通信がVPN側へ流れる
各要素を切り分け、FQDN接続・設定調整・スプリットトンネル有効化で解決

今回のトラブルは、どれか1つだけが原因だったわけではありません。IPv6(MAP-E)、証明書認証、Windows標準VPN、FortiGate 60F側の設定、FortiOSバージョン差分が複合的に影響していました。

[広告] 専用VPNクライアント不要のリモートアクセスVPN

Windows標準VPNを活用し、IPv4・IPv6・MAP-E環境でのリモートアクセスを支援します。

まとめ

今回の問題は単純なVPN障害ではなく、以下のような複数要素が重なって発生していました。

  • IPv6(MAP-E)環境
  • FortiGate 60F / FortiOS設定
  • FortiOS v7.4.7 から v7.4.12 へのアップデート前後の確認
  • 証明書認証
  • 接続先名称(FQDN)と証明書CNの整合性
  • Windows標準VPN側のスプリットトンネル設定

最終的には、以下の構成で正常接続を確認できました。

  • FortiGate 60F
  • FortiOS v7.4.12
  • Windows標準VPN（IKEv2）
  • 証明書認証
  • IPv6（IPoE / MAP-E）

引っ越し直後は回線変更も考えましたが、最終的には構成をIPv6環境に合わせて見直すことで解決できました。

同様に、「インターネットは使えるのにVPNだけ接続できない」「FortiGateとWindows標準VPNの証明書認証でうまくいかない」「IPv6(MAP-E)環境でVPNが不安定」という事象に遭遇した方の参考になれば幸いです。

※本ブログに掲載している図版および画像は、当社にて作成したイメージです。一部画像には生成AIを利用しています。

関連投稿

ClickFixイメージ
MS365
「脆弱性の悪用」ではなく、ユーザー自身に操作させる社会工学攻撃「ClickFix」へのMS365での対策案

2026年3月、Microsoft Threat Intelligence は、ClickFix と呼ばれる社会工学攻撃キャンペーンが進化し、Windows Terminal（wt.exe）を悪用してマルウェアを実行させる手口を確認したと公表しました。
本記事では、Microsoft 365（Intune + WDAC）を用いて ClickFix にどう対抗すべきかを、実運用を前提に整理します。

2026-03-09
Read More

お問い合わせ

@2026 Osaki Computer Engineering Co., Ltd.

株式会社大崎コンピュータエンヂニアリング　｜　会社概要　｜　プライバシーポリシー