質問
⚠️ この事例は公開されてから1年以上経過しています。 情報が古い可能性がありますので、ご注意ください。
🕓 事例公開日 : 2025-02-04
【背景】
3つの環境（開発、検証、本番）で運用しているマネージドVPNにおいて、6本のトンネルが不定期に約20分間同時ダウンする現象が発生している。毎回必ず20分で自動回復するが、原因が不明で調査が必要な状況。1. 事象
症状の説明：
・6本のVPNトンネルが不定期に同時ダウンする・ダウン時間は毎回約20分間で、その後自動回復する
・全環境（開発、検証、本番）で同時に発生
・障害中もグローバルアドレスまでのtracerouteは通る
エラーメッセージ・スタックトレース：
[IKE] ICMP: dead peer detection SA[18] [AWSのVPNエンドポイントIPアドレス][IKE] SA[17] DPD: detected dead peer[IKE] SA[12] change state to OLD[IKE] inactivate ISAKMP socket[1][IKE] initiate ISAKMP phase to [AWSのVPNエンドポイントIPアドレス] (local address [カスタマーゲートウェイのIPアドレス])[IKE] inactivate IPsec socket[tunnel:1](outbound)[IKE] inactivate IPsec socket[tunnel:1](inbound)IP Tunnel[1] Down
2. 発生条件
・対象：マネージドVPN 6本のトンネル全て・頻度：不定期（数日に1回程度）
・時間帯：特定の時間帯に限定されない
・環境：YAMAHA RTX-1220ルーター使用
・ネットワーク構成：インターネット回線経由でのVPN接続
回答
1. 原因
技術的な原因：
Fortigateファイアウォールに残存していたVPN設定（無効状態）が、ARPリクエストに対して不正な応答を行い、VPNトラフィックの経路を誤って変更していたことが原因でした。技術的要因の分析：
・Fortigateに残存していた古いVPN設定 → ARPリクエストに対する不正な応答・プロバイダー接続用RTX-1210での経路混乱 → VPNトラフィックがFortigateに誤転送
・AWS側からの応答パケットの到達阻害 → DPD（Dead Peer Detection）による切断判定
・6本のトンネル共通経路での問題発生 → 全トンネルの同時ダウン
・約20分後のARP更新タイミング → 正常経路への自動復旧
根本的な要因：
VPN導入初期にテスト用として設定されたFortigateの設定が完全に削除されておらず、無効状態でも同一IPアドレスに対するARPリクエストに応答し続けていたため、定期的にVPNトラフィックの経路が不正に変更されていました。2. 対応方法
根本解決方法：
1. Fortigateファイアウォールから古いVPN関連設定を完全削除2. ARPテーブルの確認と不要なエントリの削除
3. ネットワーク機器間でのIP重複設定の確認と修正
暫定対処方法：
障害発生時は約20分で自動回復するため、特別な暫定対処は不要でしたが、今後同様の問題を避けるため、定期的なARPテーブルの監視を実施することを推奨します。3. 原因究明に至るまでの調査方法
1. AWS側VPNログの有効化と詳細分析2. カスタマーゲートウェイ（YAMAHA RTX-1220）のログ詳細調査
3. パケットキャプチャによる通信フローの確認
4. UDP500ポートの通信状況とフラッド検知機能の調査
5. ネットワーク構成の見直しとファイアウォール設定の確認
6. プロバイダー接続用RTX-1210のARPログ分析
7. Fortigateファイアウォールの設定確認と不要設定の特定