Хорошо ... У меня действительно странная проблема с IPSec (по крайней мере, странная для меня :-)). У меня есть Sonicwall Pro 2040, подключенный к ASA 5510. Когда трафик инициирован со стороны Sonicwall сети, он работает нормально ... но если он исходит со стороны ASA, никаких кубиков. Например, эхо icmp от ПК-А на звуковой стене принимается ПК-В на ASA. ПК-В отвечает ответом icmp, и ПК-А принимает его. Если PC-B отправляет эхо-запрос на PC-A, он даже не проходит через туннель IPSec (что подтверждается отсутствием трафика ESP, генерируемого по сети). Wireshark на ПК-B показывает ТОЧНЫЕ ИДЕНТИФИКАЦИОННЫЕ IP-адреса и MAC-адреса источника в эхо-запросе icmp в качестве эхо-ответа icmp ... какие-либо идеи относительно того, что может вызвать такое поведение? :(
Дополнительное примечание: если я очищаю isakmp на ASA и пытаюсь выполнить эхо-запрос с ПК-B на ПК-A, он не пытается активировать туннель ... похоже, он не понимает, что этот трафик предназначен для сеть sonicwall, хотя когда я отправляю ответы, она работает нормально.
Еще одно примечание: я выполнил захват пакетов на ASA, используя тот же самый ACL, что и туннель IPsec, и он совпал с пакетами запроса icmp с ПК-B ... поэтому по какой-то причине он просто не пытается отправить их через туннель, хотя это совпадает.
Ага ... видимо, потому что я подкреплял внутренний интерфейс (тестировал, прежде чем отправить его на удаленный сайт), а маршрут по умолчанию был вне внешнего интерфейса, мне нужно было поместить туда статический маршрут, чтобы направить трафик VPN обратно во внутренний интерфейс, а затем отправит его через туннель. Я заметил это, когда использовал средство отслеживания пакетов, и в нем упоминались потоки ... Я предполагаю, что поток, созданный входящим VPN-соединением, может иметь приоритет над статическими маршрутами ... полезно знать :-)