NATの設定は合っているのに、ACLが想定したIPへ一致しない。そんなときは、アドレスだけでなく、NATとACLが評価される順番を確認します。
従来型のCisco IOSのinside／outside NATでは、通信の方向によってNATと経路検索の順序が変わります。ここでは公式資料の基本例を使い、変換装置の入口と出口でパケットがどう見えるかを追います。別製品やNVI、FW機能を含む構成へ、そのまま同じ順序を当てはめるものではありません。
順番は、insideから入るかoutsideから入るかで変わる
insideはこのNAT設定で内側に指定したインターフェース、outsideは外側に指定したインターフェースです。単に社内・社外という言葉から推測せず、設定で確認します。
Ciscoの従来型NATの解説では、insideからoutsideへは入力ACL、経路検索、NAT、出力ACLの順です。outsideからinsideへは入力ACL、NAT、経路検索、出力ACLになります。表は主要部分だけを抜き出しています。
| 方向 | 主要な処理順（簡略） | 設計で見る点 |
|---|---|---|
| inside → outside | input ACL → routing → NAT → output ACL | 入力側は変換前の送信元、出力側は変換後の送信元 |
| outside → inside | input ACL → NAT → routing → output ACL | 入力側は公開宛先、出力側は変換後の内部宛先 |
順番を覚える目的は、設定を暗記することではなく、その場所のACLがどのIPを見るかを判断することです。
insideからの要求では、送信元が途中で変わる
社内PCの10.0.0.10から、外部サーバー203.0.113.20へ接続する例です。NAT装置は送信元を198.51.100.10へ変換します。
insideの入力ACLでは、まだ送信元は10.0.0.10です。outsideの出力ACLでは、基本例の順序なら送信元が198.51.100.10に変わっています。宛先はサーバーのままです。
| 観測点 | 送信元IP | 宛先IP |
|---|---|---|
| inside入力ACL | 10.0.0.10（変換前） | 203.0.113.20 |
| 経路検索 | 10.0.0.10 | 203.0.113.20宛の出力先を選ぶ |
| NAT後／outside出力ACL | 198.51.100.10（変換後） | 203.0.113.20 |
198.51.100.0/24と203.0.113.0/24は、外部側の説明に使う文書用アドレスです。実在するサービスのグローバルIPや、社内LANの設計値として使っているわけではありません。
NAT対象を選ぶACLと、ip access-groupで通信を許可・拒否するACLも別の役割です。同じACLという名前でも、何の設定から参照されているかを確認します。
outsideからの返信では、宛先が内部IPへ戻る
返信は203.0.113.20から198.51.100.10へ来ます。outsideの入力ACLは、逆変換前の宛先198.51.100.10を見ます。
そのあとNATで宛先を10.0.0.10へ戻し、その宛先で内部への経路を検索します。insideの出力ACLでは、内部PCのIPへ戻ったパケットを評価します。
| 観測点 | 送信元IP | 宛先IP |
|---|---|---|
| outside入力ACL | 203.0.113.20 | 198.51.100.10（公開側） |
| NAT後の経路検索 | 203.0.113.20 | 10.0.0.10（内部側） |
| inside出力ACL | 203.0.113.20 | 10.0.0.10 |
変換情報があるだけで、返信が届くとは限りません。外部からNAT装置までの経路、内部への経路、両側のACLが必要です。別のNAT装置へ返信が流れる場合は、変換状態へ一致できるかも調べます。
表を見るときは、送信元と宛先を同じ行で読んでください。「NAT前のIP」という一語だけでは、どちらのフィールドを指しているか分かりません。
ACLは、評価点で見えるIPに合わせて設計する
入力と出力のACLへ同じIPを書いてよいかは、通信方向と変換対象によって変わります。各取得点で見える送信元・宛先を先に表へ書き、その値をACLの条件と照合します。
設定レビューでも、NATの行とACLの行を別々に見るだけでは足りません。どのインターフェースのどの方向で、そのアドレスになるかまで確認します。
| 症状・誤り | 主な原因候補 | 次に確認すること |
|---|---|---|
| 図とカウンターが不一致 | 別ルール/経路/参照範囲 | matched sequenceとVRF |
| 変換なし | NAT ACL不一致・inside/outside誤り | statisticsと設定 |
| 変換あり通信なし | 戻り経路・outside ポリシー | reverse direction |
| debugで高負荷 | 無条件debug | カウンター/ログ/キャプチャを先に使う |
カウンターが想定どおり増えないときは、別ルールへの一致、NAT前後の取り違え、経路、取得条件を調べます。通信が評価点へ来ているかも確認してください。
FW製品のポリシー評価では、Cisco IOSのこの順序と異なる場合があります。対象の製品・版の説明へ戻り、実際の変換表とキャプチャで確かめます。
変換表・カウンター・両側の通信を一つの試験でそろえる
同じ試験時刻にshow ip nat translationsなどで変換を取り、ACLの前後の値と、内外のパケットを照合します。動的変換では通信を発生させたあとに登録されるので、取得タイミングも必要です。
最初から大量のdebugを流すより、show表示とカウンター、対象を絞った取得から始めます。本番のdebugは負荷やログ量を考えた手順が必要です。
処理順を図へ書いたら、各場所の送信元と宛先も添えてみてください。その図と実際の試験結果が合うかを確認すると、「ACLはどのIPを見るか」を具体的に説明できます。
順序表の丸暗記から、対象の方向・装置・変換の条件で確かめる読み方へ進みましょう。
動画・筆者の投稿で補足する
文章と図で流れをつかんだら、関連する動画も参考にしてください。画面の表示や操作は、機種・ソフトウェアの版によって異なる場合があります。
⭕️インフラエンジニアが
設計で理解しておきたいことNAT
ACL
Routing
の処理順L3機器に
インターフェイスACL
NAT
Routing
を設定しているとする。では、Gi0/1にパケットが着信した瞬間、
そのパケットは何から処理されるのか。ここを理解していないと、
設計や障害切り分けでハマる。… pic.twitter.com/YPQH7f8FhI— けんと＠設計構築チャンネル (@yeiquer12) 2026年6月21日
Cisco IOSのinside→outside通信でinput ACL、Routing、NAT、output ACLの順を整理したポスト。
関連する動画・筆者の投稿：2026年6月21日
確認に使った公式資料
