Порядок записей NAT в Cisco Router имеет значение?

Question

[Дмитрий]

Суть вопроса:
Имеется Cisco Router C2921, IOS 15.4(3)M

На нем сделаны 2 интерфейса (Dialer1 и Tunnel1), а также стандартные Gi0/0 как внутренний и Gi0/1 как внешний.
Соответственно, на Tunnel1, Dialer1 и Gi0/1 сделан NAT(PAT), через два первых реализован выход в другие сети (VPN), через Gi0/1 - в интернет. Входящий для NAT - Gi0/0. Внутренняя сеть 10.0.0.0/24

Трафик маршрутизируется статическими маршрутами:
ip route 192.168.0.0 255.255.255.0 Dialer1
ip route 192.168.1.0 255.255.255.0 Dialer1
ip route 192.168.5.0 255.255.255.0 Dialer1
ip route 192.168.10.0 255.255.255.0 Tunnel1
ip route 192.168.11.0 255.255.255.0 Tunnel1

Далее, происходит выборка по ACL:
ip access-list extended DIALER
permit ip 10.0.0.0 255.255.255.0 192.168.0.0 255.255.255.0
permit ip 10.0.0.0 255.255.255.0 192.168.1.0 255.255.255.0
permit ip 10.0.0.0 255.255.255.0 192.168.5.0 255.255.255.0
ip access-list extended TUNNEL
permit ip 10.0.0.0 255.255.255.0 192.168.10.0 255.255.255.0
permit ip 10.0.0.0 255.255.255.0 192.168.11.0 255.255.255.0

И далее, NAT:
ip nat inside source list DIALER interface Dialer1 overload
ip nat inside source list TUNNEL interface Tunnel1 overload

=============

Как-то вдруг возник такой вопрос - "Если я уже направил роутом трафик куда надо, зачем его еще выбирать дополнительно в ACL? Ведь можно же упростить конфиг - и сделать ACL вида "permit ip 10.0.0.0 255.255.255.0 192.168.0.0 255.255.0.0" для обоих. И, согласно NAT order of operations, все будет работать - ведь куда направили - там и NATим".

Сделав так, удивился - все начало матчиться в Dialer, и доступ через Tunnel1 пропал.
Экспериментом определил, что если "ip nat inside source list TUNNEL interface Tunnel1 overload" обозвать как "ip nat inside source list A-TUNNEL interface Tunnel1 overload" (переименовав, соответственно, ACL в A-TUNNEL вместо TUNNEL),
то он поднимется выше в конфиге, и встанет перед "ip nat inside source list DIALER interface Dialer1 overload". И тогда уже он заматчит все, и доступ через Dialer пропадет.

Не нашел точного подтверждения такого поведения в документации пока, отсюда и вопрос - так и должно быть?

Ведь я всегда предполагал, что роутинг происходит раньше, и траффик мы уже направили куда нужно статическим маршрутом. А выходит, что он все равно попадает в ACL для другого NAT, причем еще согласно порядку появления в конфиге правила.

Answer 1

[Валентин]

Спешу вас огорчить. Конечно по приложенной ссылке можно найти информацию по дополнительным модулям IPS-AIM, но в целом порядок прохождения трафика в части NAT остается таким, а именно Source NAT делается раньше роутинга. Собственно, аналогичная ситуация будет и в Linux, Junos.



Если бы была схема, было бы понятнее.

Comments

[Дмитрий]

То есть, насколько я понял, так будет вести себя любой NAT, при использовании выборки по ACL с заданным адресом источника? То есть пакеты будут как-бы перехватываться/помечаться, проходя через NAT-inside интерфейс?

А о чем же тогда говорит известная таблица NAT - order of operations?
=================
Inside-to-Outside:

If IPSec then check input access list
decryption - for CET (Cisco Encryption Technology) or IPSec
check input access list
check input rate limits
input accounting
redirect to web cache
policy routing
routing
NAT inside to outside (local to global translation)
crypto (check map and mark for encryption)
check output access list
inspect (Context-based Access Control (CBAC))
TCP intercept
encryption
Queueing
================