FWログは正常なのに通信できない？現場で頻発する典型トラブル7選【原因別に完全解説】

「FWログでは allow になっている」
「deny ログも出ていない」
それなのに 通信できない。

これは FW運用の現場で 最も多い“勘違いトラブル” です。

本記事では、
「ログは正常なのに通信できない」典型パターン を 通信フェーズ別・原因別 に整理し、 どこを見れば一発で気づけるのか まで踏み込んで解説します。

まず結論：FWログは「通信成功」を保証しない

FWログが示しているのは、多くの場合 以下だけ です。

• FWにパケットが届いた
• ポリシー上は許可された

通信が成立したかどうか は、 FWログだけでは分かりません。

この前提を理解していないと、以降の切り分けは必ず迷走します。

典型パターン①：FWログはAllow、でもセッションが存在しない

よくある状況

• FWログ：Allow
• セッションテーブル：該当なし

なぜ起きる？

FWログは ポリシー評価時点 で出力されます。 その後、以下の理由で即破棄されることがあります。

• NAT未設定
• サービス（ポート）不一致
• ポリシー順序ミス

気づくポイント

ログは出ているのにセッションが1件も残らない 場合、 NATまたはFW内部処理を疑います。

典型パターン②：SYNは通るがACKが返らない

ログとセッション

FWログ：Allow TCP
セッション：SYN_SENT

通信の意味

• SYNは送信済み
• SYN/ACKが返ってきていない

主な原因

• サーバでサービス未起動
• サーバ側FWで遮断
• 戻り通信の経路不備

FWログは「行き」しか見ていません。
問題は「戻り」にあります。

典型パターン③：非対称ルーティングで通信が壊れる

状況

• FWログ：毎回Allow
• セッション：すぐ消える

なぜFWは通信を破棄する？

FWは ステートフル です。 戻り通信が別経路を通ると、同一セッションと認識できません。

結果

• ログは正常
• でも通信は成立しない

FWログだけ見ていると100%ハマる罠 です。

典型パターン④：ESTABLISHEDなのに通信できない

セッション状態

State: ESTABLISHED

この時点で分かること

FW・NATは正常

それでも通信できない理由

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

この状態でFWを疑い続けるのは 時間の無駄 です。

典型パターン⑤：ログはAllowだが、別ポリシーで落ちている

ありがちな設計

• ポリシーA：Allow（ログ有）
• ポリシーB：Deny（ログなし）

現象

ログには Allow しか出ないのに、実際は後段で遮断。

対策

• ポリシー順序の可視化
• 暗黙denyの存在確認

典型パターン⑥：NAT変換は正しいが、戻りがSNATされていない

症状

• DNATは見える
• 通信は成立しない

原因

• 戻り通信が別ルータへ
• SNAT未設定

FWログは行きのDNATしか示しません。

典型パターン⑦：ログ対象外通信で落ちている

例

• セッション確立後のRST
• タイムアウト切断

これらは 通常ログに出ません。

対処

• セッションテーブル確認
• タイムアウト設定確認

実務での最短切り分けフロー

1. FWログで入口確認
2. セッション有無を確認
3. TCP状態を見る
4. NAT変換を見る
5. 戻り経路を確認

ログだけを見続けない。 これが最大のポイントです。

まとめ

• FWログは「許可」を示すだけ
• 通信成立はセッションで判断する
• 非対称・戻り通信が最大の落とし穴

「ログは正常なのに…」と感じた瞬間、 セッションテーブルを見る。 これを習慣にすれば、FWトラブルは怖くありません。