クラスタ構成のファイアウォール（FW）は、冗長化と可用性向上のために広く採用されています。 しかし「フェイルオーバーした瞬間に通信が全断する」「アクティブ／スタンバイ切替後に既存通信だけ落ちる」といったトラブルが発生することがあります。
その原因の多くはセッション同期（State Sync）の失敗です。
本記事では、クラスタFWでセッション同期が失敗するメカニズム・診断基準・具体的な解決方法を、現場でそのまま使えるレベルで解説します。
1. まず理解すべき前提：クラスタFWは「状態」を共有している
ステートフルFWは、TCP/UDPセッション情報を保持しています。 クラスタ構成ではこの「セッションテーブル」をノード間で同期します。
同期される主な情報：
- 5-tuple（SrcIP / DstIP / SrcPort / DstPort / Protocol）
- NAT変換情報（SNAT/DNAT）
- TCPシーケンス番号
- タイマー情報
- フラグ状態（SYN済み等）
つまり、同期が正常であればフェイルオーバーしても既存通信は継続可能です。
逆に言えば、
既存通信だけが落ちる場合、ほぼ確実にセッション同期の問題です。
2. 典型症状パターン
パターン① フェイルオーバー直後に既存通信だけ切れる
- 新規通信は通る
- 既存TCPセッションのみRSTで終了
→ 同期未実施 or 同期遅延
パターン② ECMPや非対称経路時に断続的に通信断
- あるFWノードにのみセッションが存在
- 戻り通信が別ノードへ到達
→ セッション不整合
パターン③ 大量通信時のみ発生
- ピーク時だけ切断
- ログに同期キュー溢れ
→ 同期帯域不足 / CPU不足
3. 診断の基本フロー（現場用チェックリスト）
Step1：本当にセッション同期が原因か？
まず確認すべきこと：
- フェイルオーバー時のみ発生するか？
- 既存通信のみ影響か？
- 片系のみセッションが存在していないか？
この3条件が揃えば、ほぼセッション同期問題です。
Step2：両ノードのセッションテーブルを比較
確認ポイント：
- 同一セッションが両方に存在するか？
- セッションIDは一致しているか？
- NAT情報は同一か？
- TCPステートは一致しているか？
差分がある場合、同期が破綻しています。
Step3：同期インターフェースの状態確認
チェック項目：
- リンクアップ状態
- エラーカウンタ増加有無
- MTU一致
- VLANタグ誤設定
- 帯域使用率
同期リンクは本番通信と分離した専用リンクが推奨です。
4. よくある根本原因
① セッション同期機能が無効
意外と多い初歩的ミス。 ポリシーは同期していても、セッション同期は無効というケース。
確認：クラスタ設定で state sync が有効か
② 同期インターフェースのMTU不一致
MTUが違うと同期パケットが断片化・破棄される。
症状：大量通信時のみ同期漏れ発生
解決：両ノードで完全一致させる
③ NAT情報が同期対象外
製品によってはNATテーブル同期が別設定。
症状：
- DNATセッションだけ失敗
- 戻り通信で不整合
確認：NAT sync有効化
④ 非対称ルーティング
ECMPやルーティング設計により、 往路＝FW-A 復路＝FW-B となると、同期失敗時に通信断。
解決策：
- セッション同期強化
- ルーティング固定
- フロー単位で経路固定
⑤ 同期キュー溢れ
高トラフィック時、同期処理が追いつかない。
ログ例：
- sync queue full
- dropped state update
解決策：
- 同期専用帯域増強
- CPU強化
- セッション数制限見直し
5. tcpdumpでの実践診断
同期インターフェースでキャプチャ
見るべきポイント：
- セッション生成時に同期パケットが流れているか
- 再送が多発していないか
- パケットロスがないか
同期パケットが流れていなければ、設定ミス。 流れているのに反映されないなら、受信側問題。
6. 製品別の代表的実装例
- FortiGate：FGCP HA + session pickup
- Cisco ASA：Stateful Failover
- Palo Alto：Session Owner / Session Setup
- Check Point：ClusterXL
どの製品でも原理は同じ： セッション情報が完全同期されていなければ通信は継続できない
7. 判断基準まとめ（これで即断できる）
| 症状 | 原因可能性 | 優先確認項目 |
|---|---|---|
| フェイルオーバーで既存通信断 | 同期未実施 | state sync設定 |
| DNAT通信だけ失敗 | NAT未同期 | NAT sync設定 |
| 高負荷時のみ断 | 同期帯域不足 | 同期IF帯域/CPU |
| 断続的に片方向通信 | 非対称経路 | ルーティング設計 |
8. 設計段階で防ぐためのベストプラクティス
- 同期専用インターフェースを物理分離
- MTU完全一致
- NAT同期を明示的に有効化
- ECMP時はフロー単位固定
- 同期帯域はピークトラフィック想定
- 定期的に強制フェイルオーバーテスト実施
設計段階で対策すれば、ほぼ防げる障害です。
9. 結論
クラスタFWで通信がフェイルオーバー時に落ちる場合、 原因の9割はセッション同期の不備です。
診断の鉄則：
- 既存通信のみ影響 → 同期を疑う
- セッションテーブルを両系で比較
- 同期IFの物理・論理状態確認
- NAT同期と非対称経路確認
セッション同期は「動いているように見えて実は壊れている」ことが多い機能です。
本記事の手順通りに確認すれば、 再現・特定・解決まで到達できます。
