Назад | Перейти на главную страницу

«Отказ обратного пути NAT» ASA 8.3

Простите меня, поскольку у меня нет большого опыта работы с ASA, но я считаю, что то, что я настроил, должно работать.

У меня есть ASA 5510 с версией 8.3 (2), который подключен к внутренней, внешней и dmz сетям, а также к RA VPN. Как во внутренней, так и в DMZ-сети настроен динамический NAT при переходе из внутреннего / dmz в Интернет. Оба эти динамических NAT работают должным образом.

Проблема возникает при попытке доступа к сети DMZ через VPN.

Сообщение об ошибке, которое я получаю на ASA, гласит:

%ASA-5-305013: Asymmetric NAT rules matched for forward and reverse flows; Connection for icmp src outside:x.x.x.x dst dmz: y.y.y.y (type 8, code 0) denied due to NAT reverse path failure

Я полагал, что это происходит потому, что трафик, возвращаемый из DMZ, будет соответствовать правилу динамического NAT и будет передаваться внешнему интерфейсу.

Поэтому я установил статическое правило без NAT для подсети DMZ для VPN:

nat (dmz,outside) source static DMZ_VLAN DMZ_VLAN destination static VPN VPN

Но ... я все еще получаю сообщение об ошибке.

И вот здесь я еще больше запутался. После добавления статического NAT мой sh nat выглядит так:

1 (inside) to (outside) source static any any destination static VPN VPN description VPN No NAT
    translate_hits = 3, untranslate_hits = 1198

2 (dmz) to (outside) source static DMZ_VLAN DMZ_VLAN destination static VPN VPN
    translate_hits = 0, untranslate_hits = 0

Если я перемещаю DMZ во внешнее правило выше правила изнутри во внешнее, я могу получить доступ к DMZ, но не могу получить доступ к внутренней из VPN.

Я не уверен, почему порядок этих правил имеет значение, потому что, если верхнее правило не совпадает, оно должно продолжать движение вниз по списку ...

Любая помощь будет принята с благодарностью, хотя мои чувства говорят мне, что я просто совершаю глупую ошибку в очевидном месте.

РЕДАКТИРОВАТЬ: Дополнительная информация.

Уровни безопасности интерфейса:

внутри: 100
дмз: 50
снаружи: 0

Правила NAT от show run nat :

nat (inside,outside) source static any any destination static VPN VPN description VPN No NAT
nat (dmz,outside) source static DMZ_VLAN DMZ_VLAN destination static VPN VPN

object network DMZ_VLAN
 nat (dmz,outside) dynamic interface

object network In_VLAN
 nat (inside,outside) dynamic interface

Списки доступа не должны применяться, так как я sysopt connection permit-vpn включен, и, если я неправильно понимаю эту команду, она должна разрешать трафик из VPN независимо от ACL.

Кроме того, трафик ICMP проверяется, поэтому обратный трафик должен вернуться без влияния списка доступа (опять же, если я неправильно понимаю проверку трафика)

Сети:

Внутри: 10.1.4.0/24
DMZ: 10.1.254.0/24
VPN: 10.1.10.0/24

Packet-tracer из DMZ в VPN

Type: NAT
Subtype: 
Result: ALLOW
Config:
nat (dmz,outside) source static DMZ_VLAN DMZ_VLAN destination static VPN VPN
Additional Information:
Static translate 10.1.254.1/0 to 10.1.254.1/0

В packet-tracer доходит до конца с "Allow's" полностью ..

Исправлена!

Я не совсем уверен, что происходило, чтобы вызвать проблему, но это то, что, казалось, происходило.

Давайте еще раз вернемся к правилам NAT ..

nat (inside,outside) source static any any destination static VPN VPN
nat (dmz,outside) source static DMZ_VLAN DMZ_VLAN destination static VPN VPN

Обратите внимание на разницу между двумя правилами, которые (должны) делать одно и то же для разных интерфейсов.

Причина, по которой верхний NAT так широко открыт (any any) потому, что на самом деле существует несколько сетей, которые могут исходить изнутри нашей сети, поэтому мы подумали, что оставить его открытым будет проще, чем определять каждую сеть, которая может появиться.

Проблема, которая, кажется, происходила, заключалась в том, что когда трафик поступает из VPN, ASA, по-видимому, просматривает свои NAT, прежде чем решить, какой путь он пройдет через межсетевой экран. Таким образом, он будет проверять трафик по верхнему NAT, и он совпадает, потому что он определенно идет от VPN к любому ... Тогда как обратный трафик будет от DMZ_VLAN к VPN, и, следовательно, не будет соответствовать верхнему правилу.

Я не уверен, что соответствие этого первого NAT заставляет ASA направлять трафик внутрь, или он просто понимает, что исходящий трафик будет соответствовать другому NAT.

Как только я изменил главное правило NAT, чтобы быть более конкретным:

nat (inside,outside) source static IN_VLANS IN_VLANS destination static VPN VPN

Все работает отлично!

Странная проблема ... но кажется, что мораль этой истории - быть конкретным во всем, даже если вы не думаете, что это вызовет какие-либо проблемы ... потому что может.

Ладно, беспорядка чуть меньше. Тем не менее - я не вижу никаких определений сети; что заставляет вас думать, что использование nonat вообще здесь полезно? Участвующие сети могли бы раскрыть эту загадку, но мы пока не знаем.

Для DMZ (которая в основном имеет общедоступные IP-адреса) не принято напрямую подключаться к VPN (чего в большинстве случаев нет).

Мое внимание привлекло следующее:

Поэтому я установил статическое правило без NAT для подсети DMZ для VPN:

nat (dmz, external) источник статический DMZ_VLAN DMZ_VLAN назначение статический VPN VPN

Однако это делает прямо противоположное: nat (X,Y) статический нац из Y к Икс

Это тоже не nonat правило.

Nonat для VPN должен исходить от другого интерфейса:

nat 0 (outside,dmz) DMZ VPN

Это представляет IP-адреса DMZ для интерфейса VPN без применения правил внешнего интерфейса.

Конечно, вы также можете выполнить обычную обработку данных извне в демилитаризованную зону, но обычно это не рекомендуется, поскольку вы создаете доступ от более низкого до более высокого уровня безопасности.

Азз,

Доступ к DMZ от клиентов VPN. Cisco ASA 9.x

Спасибо за информацию, поскольку она помогла мне решить мою проблему. Мой код ASA - 9.x, который больше не использует нонаты, а вместо этого использует статические NAT. Я нашел то же самое, что и вы, где на моем брандмауэре у меня были какие-либо натсы, примененные к целевым сетям VPN. Удаление этого и добавление специфики решило мою проблему, и я могу подтвердить доступ к внутренней и DMZ от моих клиентов VPN. Я исправил свою проблему с помощью следующих строк ниже. Надеюсь, это поможет другим.

Устранена проблема NATS, с любого IP-адреса на сеть VPN: 10.10.8.x

no nat (inside,any) source static any any destination static OBJ-10.10.8.0-24 OBJ-10.10.8.0-24 no-proxy-arp description NONAT
no nat (outside,any) source static any any destination static OBJ-10.10.8.0-24 OBJ-10.10.8.0-24 no-proxy-arp description NONAT

Ниже добавлены специальные NAT для доступа изнутри и DMZ к сетям VPN.

nat (inside,outside) source static NETWORK_OBJ_10.0.0.0_8 NETWORK_OBJ_10.0.0.0_8 destination static NETWORK_OBJ_10.10.8.0_24 NETWORK_OBJ_10.10.8.0_24 no-proxy-arp route-lookup
nat (dmz,outside) source static OBJ-10.10.7.0-24 OBJ-10.10.7.0-24 destination static NETWORK_OBJ_10.10.8.0_24 NETWORK_OBJ_10.10.8.0_24 no-proxy-arp route-lookup