Пусть есть какой-нибудь ISR с IOS k9 feature set (это не столь принципиально. Главное, там есть НАТ и SSH)

Привожу необходимые настройки маршрутизатора:
_______________________________________________
!
aaa new-model
!
aaa authentication login LOC local
!
user cisco priv 15 pass cisco
!
int f0
ip nat outside
ip address 1.1.1.1 255.255.255.0
ip access-group FROMOUT in
crypto-map STAT
!
!
int f1
ip nat inside
ip address 192.168.1.1 255.255.255.0
ip inspect FW in
!
!
ip access-list ex VPN
permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
!
crypto map STAT 10
match address VPN
!
!
ip access-list ex FROMOUT
permit tcp any h 1.1.1.1 eq 22
deny ip any any
!
ip inspect name FW tcp
ip inspect name FW udp
ip inspect name FW icmp
!
!
!
ip access-list ex NAT
deny ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
permit ip any any
!
access-list 199 permit ip 192.168.1.0 0.0.0.255 any
access-list 199 permit tcp any any eq 22
!
route-map NAT 10
match ip address NAT
!
ip nat inside source route-map NAT int f0 overload
!
!
line vty 0 4
transport input ssh
login authenticate LOC
access-class 199
!
enable password CISCO
!
_________________________________________________

Условие: подключение из сети 192.168.2.0/24 через IPSec туннель по ssh к маршрутизатору по адресу 192.168.1.1 успешно проходит. Подключение снаружи по ssh к адресу интерфейса f0 не проходит (отваливается по тайм-ауту)

Вопрос 1: почему?
Вопрос 2: как починить?

Дерзайте!

охренеть а почему ж так нат работает
Pro Inside global Inside local Outside local Outside global
tcp 1.1.1.1:6 1.1.1.1:4 1.1.1.2:43926 1.1.1.2:43926
tcp 1.1.1.1:2 1.1.1.1:8 1.1.1.2:27626 1.1.1.2:27626
tcp 1.1.1.1:8 1.1.1.1:22 1.1.1.2:27626 1.1.1.2:27626
tcp 1.1.1.1:1 1.1.1.1:22 1.1.1.2:28640 1.1.1.2:28640
tcp 1.1.1.1:5 1.1.1.1:22 1.1.1.2:42821 1.1.1.2:42821
tcp 1.1.1.1:3 1.1.1.1:22 1.1.1.2:43730 1.1.1.2:43730
tcp 1.1.1.1:4 1.1.1.1:22 1.1.1.2:43926 1.1.1.2:43926
udp 1.1.1.1:500 1.1.1.1:500 1.1.1.2:500 1.1.1.2:500


Кстати IKE у меня с твоими конфигами не заработал. его acl рубит на интерфейсе

Ну забыл учесть Я на IPSec особо внимания не обращал, а писал конфиг с клавы, а не копипастил.
Будем считать, что IPSec проходит на циску:)
crypto map там ведь тоже не полностью написан

(удалено администратором)

Илюх, я знаю, что ты знаешь. Именно тебя прошу пока не публиковать ответы, ладно? )

Ну с если ходу.. может эти строчки помогут?

ip access-list ex NAT
deny ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
permit ip 192.168.1.0 0.0.0.255 any
permit ip 192.168.2.0 0.0.0.255 any

route-map NAT 10
match ip address NAT
match interface f0

Что интересно: думаю, что многие настройщики циски интуитивно знают, как исправить

А объяснить, почему НЕ подключается?

Начиная с 12.4.какой то там ветки, НАТ начал работать именно так.
В подробности не вдавался, потому для это нужно читать changelog на каждый новый релиз.

Суть в том что без проброса ната на внутренний интерфейс или лупбэк, зайти на интерфейс, где строит ip nat outside, будет нельзя.

Вкратце так.

Зайти извне разумеется.

Возможно нужно занатить порт 22 с внешнего адреса на внутренний интерфейс или на loopback.
Если так. То может кто-то сможет объяснить, почему на старых IOS все работало без этого проброса?

не совсем верно, задачка решается и имеет вполне логичное объяснение.

По поему опыту, такая фигня проявляется и без криптотуннелей.

[quote="flashdumper"]По поему опыту, такая фигня проявляется и без криптотуннелей.[/quote]
верно.

Криптотуннели приведены, чтобы
1. Не возникало вопросов типа "а может ssh не настроен"
2. Чтобы немного подзапутать и "обойти" собсно засаду

Не уверен в чем конкретно может быть проблема. Конфиг кажется вполне рабочим.
Может ли быть в этом списке доступа?

ip access-list ex FROMOUT
permit tcp any h 1.1.1.1 eq 22
deny ip any any

нет, не в нем. попробуйте собрать схему и посмотреть :)

Ну возьмем например рабочий конфиг. Я вот сейчас проверил, что могу подключиться по ssh

interface FastEthernet4
description - WAN -
ip address 1.1.2.1 255.255.255.252
ip nat outside

line vty 0 4
session-timeout 15
exec-timeout 15 0
privilege level 15
authorization exec local_author
logging synchronous
login authentication local_authen
transport input telnet ssh
transport output telnet ssh

Если закрыть глаза на допустимые различия IOS, то единственные отличия это дополнительная строчка в моем конфиге transport output telnet ssh и отсутсвие списков доступа. Я так понимаю для начала нужно указать вид исходящего транспорта, а затем искать проблему в списках доступа на внешнем интерфейсе и на line vty. Правильно?

Кнопку редактирования сообщения не нашел. В общем дело не в transport output. Остается только править списки доступа или пробрасывать порт на внутренний интерфейс.

Я старался, чтобы крнфиг выглядел рабочем. Там засада не с misconfigure, а более глубокая, понятийная

Как и писал ранее строчки

ip access-list ex NAT
deny ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
permit ip 192.168.1.0 0.0.0.255 any
permit ip 192.168.2.0 0.0.0.255 any

помогут ). permit ip any any в NAT - это жестко. Такие вещи бросаются в глаза)
На более глубоком уровне - запускаем отладку NAT:

NAT - SYSTEM PORT for 1.1.1.1: allocated port 0, refcount 5, localport 4294967295, localaddr 0.0.0.0, flags 1, syscount 5, proto 6
NAT: [0] Allocated Port for SYSTEM prot 6: 1.1.1.1, 22
NAT - SYSTEM PORT for 1.1.1.1: allocated port 22, refcount 1, localport 4294967295, localaddr 0.0.0.0, flags 1, syscount 1, proto 6
NAT: map match NAT
mapping pointer available mapping:0
NAT: [0] Allocated Port for 1.1.1.1 -> 1.1.1.1: wanted 22 got 1
NAT: i: tcp (1.1.1.1, 22) -> (1.1.1.2, 3745) [49515]
NAT: TCP s=22->1, d=3745
NAT: map match NAT
mapping pointer available mapping:0
NAT: [0] Allocated Port for 1.1.1.1 -> 1.1.1.1: wanted 1 got 2
NAT: i: icmp (1.1.1.1, 1) -> (1.1.1.2, 3745) [76]
NAT: map match NAT
mapping pointer available mapping:0
NAT: [0] Allocated Port for 192.168.0.1 -> 1.1.1.1: wanted 53 got 2
NAT: i: icmp (1.1.1.1, 53) -> (1.1.1.2, 64106) [77]
NAT: i: tcp (1.1.1.1, 22) -> (1.1.1.2, 3745) [49515]
NAT: TCP s=22->1, d=3745
NAT: i: icmp (1.1.1.1, 1) -> (1.1.1.2, 3745) [79]
NAT: i: tcp (1.1.1.1, 22) -> (1.1.1.2, 3745) [49516]
NAT: TCP s=22->1, d=3745
NAT: i: icmp (1.1.1.1, 1) -> (1.1.1.2, 3745) [81]
NAT: i: icmp (1.1.1.1, 53) -> (1.1.1.2, 64106) [82]
NAT: i: tcp (1.1.1.1, 22) -> (1.1.1.2, 3745) [49515]
NAT: TCP s=22->1, d=3745
NAT: i: icmp (1.1.1.1, 1) -> (1.1.1.2, 3745) [84]
NAT: i: icmp (1.1.1.1, 53) -> (1.1.1.2, 64106) [85]
NAT: i: tcp (1.1.1.1, 22) -> (1.1.1.2, 3745) [49516]
NAT: TCP s=22->1, d=3745
NAT: i: icmp (1.1.1.1, 1) -> (1.1.1.2, 3745) [87]
NAT: i: tcp (1.1.1.1, 22) -> (1.1.1.2, 3745) [49515]
NAT: TCP s=22->1, d=3745
NAT: i: icmp (1.1.1.1, 1) -> (1.1.1.2, 3745) [89]

sh ip nat tra
Pro Inside global Inside local Outside local Outside global
tcp 1.1.1.1:2 1.1.1.1:1 1.1.1.2:3745 1.1.1.2:3745
tcp 1.1.1.1:1 1.1.1.1:22 1.1.1.2:3745 1.1.1.2:3745
udp 1.1.1.1:2 192.168.0.1:53 1.1.1.2:64106 1.1.1.2:64106

Видно что комп. инициирует сессию с циской с 1.1.1.2:3745
Можно предположить, что трафик, отправляемый с 1.1.1.1:22 (ответ сервера) подвергается правилам NAT.
Дальше циска пытается отвечать компу с цискиного 1.1.1.1:1 на 1.1.1.2:3745. Следующая попытка породит новую запись и т.д.
Из ната можно route-map убрать и оставить list NAT - будет так же.

Да, совершенно верно.

На маршрутизаторах cisco при задании слова ip nat outside трансляции начинают отрабатывать не только для адресов, находящихся за интерфейсами, помеченными как ip nat inside, но и для трафика самого маршрутизатора, даже инициированного от имени внешнего интерфейса.

Таким образом, если мы устанавливаем сессию на адрес маршрутизатора на порт 22, то отвечать он будет с порта 22, но если вдруг подпадет под правило динамического НАТ, то произойдет подмена порта с 22 на некий, из нижнего диапазона (1-1023) и мы не увидим (проигнорируем) ответ

Зная эту засаду, проблему легко решить несколькими способами. Самый простой - не делать в трансляциях НАТ
permit ip any any
Это действительно очень злая и грубая команда, мало того, весьма жручая по процессору.

Спасибо за участие

в nvi нате маршрутизатор сам себя не натит кстати

подниму древнюю тему если позволите
[quote="Fedia"]
Зная эту засаду, проблему легко решить несколькими способами. Самый простой - не делать в трансляциях НАТ
permit ip any any
[/quote]
а какие еще способы?

Построить туннель во внутреннюю сеть и оттуда заваливаться )