FWログとセッションテーブルの正しい読み合わせ方【通信トラブル即解決ガイド】

「FWログでは許可されているのに通信できない」
「セッションは見えるがアプリが動かない」

このような FWトラブルの9割 は、
ログとセッションテーブルを“別々に見ている” ことが原因です。

本記事では、FWログとセッションテーブルを正しく読み合わせる実務手順 を、 通信フェーズ単位・失敗パターン別 に徹底解説します。

なぜ「ログだけ」「セッションだけ」では不十分なのか

FWログが示すもの

• ポリシー判断（許可／拒否）
• 通信の「入口」の可否

セッションテーブルが示すもの

• 通信の状態（SYN / ESTABLISHED など）
• NAT変換の実体
• 戻り通信が成立しているか

ログ＝入口の可否
セッション＝通信の生死

この両方を突き合わせて初めて「真の原因」が見えます。

まず押さえるべき通信のライフサイクル

• パケット到達
• FWポリシー判定（ログ）
• セッション生成
• NAT変換
• 戻り通信
• セッション維持／終了

どのフェーズで止まっているか を特定するのが本記事のゴールです。

基本手順①：ログで「入口」を確認する

見るべきログのポイント

• Action：allow / deny
• ポリシー名
• 送信元 / 宛先IP・Port
• Hit数

典型ログ例

Allow TCP 203.0.113.50:51234 → 203.0.113.10:443 policy=INTERNET_TO_DMZ

この時点で分かること

• FWに通信は届いている
• ポリシーで遮断されていない

＝次はセッションを見るフェーズ

基本手順②：セッションテーブルで「通信状態」を確認

確認項目（最重要）

• セッションの有無
• NAT前 / NAT後 IP
• TCP状態
• 最終通信時刻

セッション例

State: SYN_SENT
Original: 203.0.113.50:51234
Translated: 192.168.1.10:443

この時点で ログとセッションを必ず突き合わせます。

失敗パターン①：ログはAllow、セッションが存在しない

状態

• FWログ：Allow
• セッション：なし

原因

• ログはポリシー評価のみ（初期パケット）
• 即座に破棄されている

疑うポイント

• NAT設定漏れ
• サービス（Port）不一致
• ポリシー順序ミス

「ログOK＝通信OK」ではありません。

失敗パターン②：SYN_SENT のまま進まない

ログ

Allow TCP ...

セッション

State: SYN_SENT

意味

• SYNは送った
• SYN/ACKが返ってこない

原因候補

• サーバ未起動
• サーバFW遮断
• 戻り経路不備（非対称）

FW外ではなく、FW内側を疑う段階 です。

失敗パターン③：セッションが一瞬で消える

症状

• セッション生成 → 即消失

ログと突き合わせる

• 再試行ごとにログは出る
• セッションが維持されない

典型原因

• 非対称ルーティング
• SNAT未設定

FWが戻り通信を受け取れていません。

失敗パターン④：ESTABLISHEDなのに通信不可

ログ

Allow TCP ...

セッション

State: ESTABLISHED

この時点での結論

FW・NATは正常

次に疑うべき層

• アプリケーションエラー
• SSL/TLS証明書
• MTU不一致

FW切り分けはここで終了 です。

ベンダー別 実務コマンド例

Cisco ASA / FTD

show conn
show xlate

Palo Alto

show session all filter

FortiGate

diagnose sys session list

最短で原因に辿り着く実務フロー

1. FWログで通信が届いているか
2. セッションが作成されているか
3. TCP状態はどこで止まっているか
4. NAT変換は正しいか
5. 戻り通信は同一FWか

この順番を守るだけで、切り分け時間は1/3以下 になります。

設計・運用での再発防止策

• FWログとセッションを必ずセットで見る
• NAT通信は非対称を作らない
• 変更前後でセッション状態を確認

まとめ

• FWログ＝入口の可否
• セッション＝通信の成否
• 両者を突き合わせて初めて原因が確定する

FWトラブル対応力は、ログ×セッションを読めるか で決まります。
この記事の手順を「型」として身につけてください。