сбой подключения к VPN с удаленным доступом IKEv2

[lridium]

Окончательные правки ниже, tl;dr см.
CSCvo73128
: Интересный сценарий... Я более подробно изучил журналы, о которых вы упомянули выше,
@MHM Cisco World
, и обнаружил следующее в журналах просмотра событий (журналы приложений и служб, Cisco Secure Client) со всеми включенными настройками отладки: [TID=12740 PID=3428]
Функция: CFileDownloader::requestFileFromNetwork
Файл: E:\dev\workspace\cure-client-windows_Raccoon_MR10\vpn\Downloader\FileDownloader.cpp
Строка: 628
Вызванная функция: IHttpSession::SendRequest
Код возврата: -28966885 (0xFE46001B)
Описание: HTTP_SESSION_ERROR_TIMEOUT
Ошибка переведена в «FILEDOWNLOADER_ERROR_CONNECTIVITY» После некоторого поиска по этому тексту я попробовал решение из
CSCvo73128 (
https://quickview.cloudapps.cisco.com/quickview/bug/CSCvo73128
)
,
в котором предлагалось скопировать профиль локальной рабочей станции с ASA. Это сработало и решило проблему подключения на ноутбуке с Windows. Для Android необходимо было следовать инструкциям по импорту профиля (
https://www.cisco.com/c/en/us/td/docs/security/vpn_client/anyconnect/anyconnect46/user/guide/Android_AnyConnect_User_Guide_4-6-x.html#task_DAC3946DAFFC44519E521D4C375662FA
, адаптируйте для той версии клиента, которую вы используете). Теперь все клиенты правильно подключаются и передают трафик. Огромное спасибо
@MHM Cisco World
и
@Rob Ingram
за их тщательную работу и терпение.

[MHM Cisco World]

Показать подробности ikev2 sa Поделитесь этим, пожалуйста MHM

[lridium]

Спасибо, что проверили это! Вот статус с Android-клиентом в подвешенном состоянии (после аутентификации имени пользователя): #sh crypto ikev2 sa detail IKEv2 SAs: Session-id:20, Status:UP-ACTIVE, IKE count:1, CHILD count:1 Tunnel-id Local Remote Status Role
255117379 <outside IP>/4500 <remote host>/3863 READY RESPONDER
Encr: AES-GCM, keysize: 256, Hash: N/A, DH Grp:21, Auth sign: RSA, Auth verify: EAP
Life/Active Time: 86400/46 сек.
Идентификатор сеанса: 20
Описание состояния: Переговоры завершены
Локальный spi: 3DADFDE3FB7ABFAF Удаленный spi: 0BFCB880111BF54A
Локальный id: cn=*.contoso.net (соответствует первичному доверительному пункту cn)
Удаленный id: $AnyConnectClient$
Локальный id запроса: 1 Удаленный id запроса: 6
Локальный id следующего запроса: 1 Удаленный id следующего запроса: 6
Локальный запрос в очереди: 1 Удаленный запрос в очереди: 6
Локальное окно: 1 Удаленное окно: 1
DPD настроен на 30 секунд, повторная попытка 2
NAT-T обнаружен снаружи
Назначенный адрес хоста: 10.10.0.20
Фрагментация IKEv2 Настроенный MTU: 576 байт, накладные расходы: 28 байт, эффективный MTU: 548 байт
Дочерний sa: локальный селектор 0.0.0.0/0 - 255.255.255.255/65535
удаленный селектор 10.10.0.20/0 - 10.10.0.20/65535
ESP spi вход/выход: 0xf3c3ac7d/0x221a3ad5
AH spi вход/выход: 0x0/0x0
CPI вход/выход: 0x0/0x0
Шифрование: AES-GCM, размер ключа: 256, esp_hmac: N/A
ah_hmac: Нет, comp: IPCOMP_NONE, режим tunnel Расширенный
статус родительского SA:
Удаление в процессе: FALSE
Помечено для удаления: FALSE

[MHM Cisco World]

<удаленный хост>/3863 <<- проблема в вашем удаленном Peer' не используйте статический NAT для порта 4500 Поэтому IPsec не сработал MHM

[lridium]

Я не думаю, что это проблема, поскольку речь идет о удаленном доступе, а не о соединении между сайтами; клиент Android подключается к 4500 на ASA, который настроен на статический NAT. Я тоже подозреваю, что проблема в настройках NAT (хотя не думаю, что они изменились), поскольку после установления туннеля трафик не проходит.

[MHM Cisco World]

Если один из пиров находится за NAT Ipsec начинает использовать порт 4500, ваш ASA использует порт 4500, но удаленный одноранговый узел не использует его, поэтому трафик пропадает. MHM

[lridium]

Большое спасибо за всю вашу помощь до сих пор. Я проверил рабочие конфигурации за последние несколько лет, и все они соответствуют текущей рабочей конфигурации, включая NAT и правила маршрутизации (как показано в приложенной рабочей конфигурации). Есть ли что-нибудь еще, что может способствовать этому? Я не ожидаю, что одна и та же версия программного обеспечения и одна и та же конфигурация начнут испытывать проблемы без видимых на то причин.

[Rob Ingram]

Вы можете иметь удаленный узел за динамическим PAT/NAT, удаленный порт не обязательно должен быть 4500. @lridium,
какие изменения были внесены? В ASA включите отладку IKEv2 debug crypto ikev2 protocol 127
debug crypto ikev2 platform 127 https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/116158-trouble-asa-ikev2-00.html Со стороны клиента запустите DART для сбора данных по устранению неполадок, проверьте вывод и найдите соответствующие ошибки.
https://www.cisco.com/c/en/us/support/docs/security/secure-client/221919-collect-dart-bundle-for-secure-client.html

[lridium]

Спасибо, что спасли мое здравомыслие, подтвердив удаленный порт, я нигде не мог его найти, чтобы быть уверенным! Что касается изменений, я обновил trustpoint (обычное обновление сертификата), протестировал, все работало нормально. Я вернулся, чтобы удалить старый trustpoint, и не думаю, что менял что-либо еще в конфигурации VPN (возможно, я сделал это в рамках аудита, но в этом я не уверен). За исключением изменений trustpoint, текущая конфигурация идентична (проверка построчно). Я вернулся и восстановил старый trustpoint и откатился к гораздо более старым версиям Secure Client (просто чтобы исключить оба варианта) и увидел то же поведение. Текущее тестирование проводится с использованием всех последних и лучших версий (сертификаты и Secure Client). Что касается дополнительных данных, которые вы предложили, я обязательно это сделаю, но, вероятно, мне понадобится день или два, чтобы их подготовить и скомпилировать. Я первоначально просмотрел оба (отладочный и DART-журнал) несколько дней назад, перед тем как опубликовать сообщение, но я повторю проверку и отчитаюсь по результатам. Спасибо за ответ!

[MHM Cisco World]

Tunnel-id Local Remote Status Role
255117379 <outside IP>/4500 <remote host>/3863 READY RESPONDER
Encr: AES-GCM, keysize: 256, Hash: N/A, DH Grp:21, Auth sign:
RSA
, Auth verify: EAP Аутентификация прошла успешно, поэтому фаза 1 ikev2 в порядке Показать crypto ipsec sa<<-
Пропингуйте и проверьте, нет ли потерь Сделайте захват пакетов в внешнем специфическом порте upd 4500 и посмотрите, поступает ли трафик от клиента. Если поступает и ASA его теряет, то, как я упоминал ранее, проблема в удаленном порте udp (не 4500). MHM

[lridium]

Я вытащу IPSEC SA для вас, как только вернусь в локальную сеть. После статуса, который вы привели выше, при последнем тестировании проверки ping не прошли.

[MHM Cisco World]

Да, ping не удался, но где именно он не удался: в asa или удаленном узле? Захватите трафик и выполните команду show crypto ipsec sa Вы точно узнаете, где пинг пропадает или не удается. Удачи MHM

[lridium]

Не удалось выполнить пинг с ASA на назначенный адрес пула DHCP удаленного узла. Будет отправлен отчет.

[MHM Cisco World]

Я проверил, что RAVPN может принимать любой UDP-порт, а не только 4500. MHM

[lridium]

Для
@MHM Cisco World
и
@Rob Ingram
прилагаются журналы ipsec и ikev2 sa, а также журналы отладки ikev2. Результаты предложенного теста ping показывают, что показатели «pkts encaps», «encrypt», «digest» и «not compressed» увеличиваются без каких-либо других изменений в статистике. Я все еще работаю над созданием DART для более глубокого изучения. Спасибо за ваши постоянные отзывы и предложения.