Cisco ASAのパケット処理フローと注意点

パケット処理フローって大事ですよね。この動作本当？と思っても突き詰めると結局正しかったりします。

Cisco ASAのパケット処理フロー

引用元：ASA 8.3+ パケット処理順序と 処理負荷概要と、パケットトレーサ

ASAは、Stateful Inspectionを実現するためにConnection Tableを持ちます。図中の「Existing Conn」がそれです。話は逸れますが、ASAはコマンドレベルでConnと略していますよね。Connectionじゃ長いから？

初めにConnection Tableを参照することで、既存Connectionは高速に処理されます。

既存コネクションのある場合でパケットを受信した場合、NATやACLのチェックはバイパスし処理されます。 つまり、既存コネクションのあるパケットは より高速に処理されます。

理にかなった設計ですが、裏を返せば既存Connectionが存在する限りはそれに従うということを意味します。

注意点

その1. 設定変更の反映は次回のConnectionから

これは見ての通り、既存Connectionが存在する場合はNAT・Routing Table・ACLをすっ飛ばします。つまり、これらの設定変更を行っても、反映されるのは次回のConnectionからになります。

Application側の実装にもよりますが、Connectionを確立しっぱなしにするのであれば再確立してもらう必要があります。ASAのclear connで切断することもできますが、デフォルトではRSTパケットは投げません。*1

Application側が切断されたことに気付けず、思わぬ障害(パケット消失)になりかねませんのでご注意を。

その2. 既存Connectionが存在する限りはそれに従う(二度目)

何を言っているんだと思われそうですが、これにやられました。

過去に通信ができていた実績があり、Routing Tableに問題なし、ACLも問題なくDropした形跡なし、ASA上でパケットキャプチャを取るとIngressで受信しているがEgressから送信はしていない…。

結局、ある条件下で想定外のConnectionが確立してしまい、その条件が収束したあともConnection Tableに残り続けていたことが原因でした。show connは確認していたのですが、まさかそんなConnectionになっているとは思わなかったので、初めは想定外なことに気付きませんでした。

思い込みはダメですね、反省です。

*1:設定をすれば投げられる。が、UDPで一発投げるだけ。