Устранение наиболее распространенных неполадок удаленных VPN-подключений и VPN-туннелей ЛВС-ЛВС на базе протокола IPSec
Содержание
Введение
В этом документе описываются стандартные решения проблем VPN-подключений на базе протокола IPsec. Эти решения были разработаны непосредственно в ходе выполнения запросов на обслуживание, полученных и обработанных службой технической поддержки Cisco. Многие из этих решений могут быть реализованы до выполнения детальной диагностики VPN-соединения IPsec. Поэтому в этом документе предоставляется контрольный список общих процедур, которые следует попробовать выполнить, прежде чем переходить к устранению неполадок соединения и звонить в службу технической поддержки Cisco.
Если необходимы документы с примерами для VPN типа "сеть-сеть" и VPN удаленного доступа, см. разделы VPN-подключения удаленного доступа, VPN-туннели "сеть-сеть" (ЛВС-ЛВС) на базе PIX, VPN-туннели "сеть-сеть" (ЛВС-ЛВС) на базе ПО IOS) и VPN-туннели "сеть-сеть" (ЛВС-ЛВС) на базе VPN3000 документа Примеры и технические примечания к настройке.
Примечание. Несмотря на то что приведенные в этом документе примеры конфигурации предназначены для использоваться на маршрутизаторах и устройствах безопасности, почти все эти принципы также применимы к концентратору VPN 3000.
Примечание: см. Устранение проблем системы безопасности IP - Понимание и Использование команд отладки для обеспечения объяснения распространенных команд отладки команды отладки, которые используются для решения проблем IPsec и на программном обеспечении Cisco IOS и на PIX.
Примечание. ASA/PIX не передает многоадресный трафик по VPN-туннелям IPSec.
Примечание. Любую команду, указанную в этом документе, можно найти с помощью средства поиска команд (только для зарегистрированных заказчиков).
******************************* Warning *******************************: Использование многих решений, представленных в настоящем документе, может привести к временной потере возможности VPN-подключения IPsec на устройстве. При применении этих решений рекомендуется соблюдать осторожность и требования политики контроля изменений.
Предварительные условия
Требования
Cisco рекомендует ознакомиться с конфигурацией IPSec VPN на следующих устройствах Cisco:
-
Устройства защиты Cisco PIX серии 500
-
Устройства защиты Cisco ASA серии 5500
-
Маршрутизаторы Cisco IOS
-
Концентраторы Cisco VPN серии 3000 (дополнительно
Используемые компоненты
Сведения, содержащиеся в данном документе, касаются следующих версий программного обеспечения и оборудования:
-
Устройства защиты Cisco ASA серии 5500
-
Устройства защиты Cisco PIX серии 500
-
Cisco IOS
Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.
Условные обозначения
Конфигурация IPSec VPN не работает
Проблема
Недавно настроенное или модифицированное решение для IPSec VPN не работает.
Текущая конфигурация IPSec VPN больше не работает.
Решения
В этом разделе содержатся решения наиболее распространенных проблем IPSec VPN. Хотя порядок, в котором перечислены решения, не имеет особого значения, список можно использовать в качестве контрольного списка для проверки или тестирования до выполнения детальной диагностики и вызова TAC. Все эти решения получены в процессе обработки запросов к службе TAC и использовались для устранения неполадок на стороне клиентов.
-
Очистка старых или существующих сопоставлений безопасности (туннелей)
-
Повторное введение или восстановление предварительных общих ключей
-
Проверка правильности списков контроля доступа и их привязки к криптокарте
Примечание. Некоторые из приведенных в этих разделах команд были перенесены на вторую строку с учетом имеющегося места.
Включение NAT-Traversal (основная проблема RA VPN)
NAT-Traversal или NAT-T позволяет трафику VPN проходить через устройства NAT или PAT, такие как маршрутизатор Linksys SOHO. Если функция NAT-T не включена, часто возникает видимость стабильного подключения VPN-клиентов к PIX или ASA, однако при этом они не могут получить доступ к внутренней сети за устройством защиты.
Если не включить NAT-T в устройстве NAT/PAT, можно получить сообщение об ошибке: regular translation creation failed for protocol 50 src inside:10.0.1.26 dst outside:10.9.69.4 (сбой создания обычной транзакции для протокола 50 ист. внутри:10.0.1.26 назн. снаружи:10.9.69.4) в PIX/ASA.
Точно так же, если невозможно выполнить одновременный вход из одного IP-адреса, появляется сообщение об ошибке Secure VPN connection terminated locally by client. Reason 412: The remote peer is no longer responding. (Безопасное подключение VPN разорвано локально клиентом. Причина 412: удаленный узел больше не отвечает). Для устранения этой ошибки включите NAT-T в головном устройстве VPN.
Примечание. Начиная с выпуска программного обеспечения Cisco IOS 12.2(13)T, NAT-T включена по умолчанию в Cisco IOS.
Здесь приводится команда для включения NAT-T в устройстве защиты Cisco. В данном примере 20 — это время поддержки активности (по умолчанию).
PIX/ASA 7.1 и более ранние версии
pix(config)#isakmp nat-traversal 20
PIX/ASA 7.2 (1) и последующие версии
securityappliance(config)#crypto isakmp nat-traversal 20
Чтобы она работала, также необходимо модифицировать клиенты.
В Cisco VPN Client выберите Connection Entries (Записи соединения) и нажмите Modify. При этом открывается новое окно, где необходимо выбрать вкладку Transport (Транспорт). На этой вкладке выберите Enable Transparent Tunneling (Включить прозрачное туннелирование) и установить переключатель в положение IPSec over UDP (NAT / PAT) (IPSec через UDP (NAT/PAT)). Затем нажмите Save (Сохранить) и протестируйте соединение.
Примечание. Эта команда одинакова для PIX 6.x и для PIX/ASA 7.x.
Примечание. Важно разрешить порты UDP 4500 для NAT-T, UDP 500 и ESP в настройках ACL, поскольку PIX/ASA действует как устройство NAT. Дополнительные сведения см. в статье Настройка туннеля IPsec через межсетевой экран с NAT, в которой подробно описана настройка ACL в PIX/ASA.
VPN-концентратор
Выберите Configuration> Tunneling and Security> IPSEC> NAT Transparency> Enable: (Настройка > Туннелирование и безопасность > IPSEC > Прозрачность NAT > Включить): IPsec over NAT-T (IPsec через NAT-T), чтобы включить NAT-T на концентраторе VPN.
Примечание. NAT-T также позволяет нескольким клиентам VPN одновременно устанавливать подключение через устройство PAT к любому головному устройству, будь то PIX, маршрутизатор или концентратор.
Правильное тестирование подключения
При идеальных условиях возможность VPN-подключения тестируется с устройств за оконечными точками, выполняющих шифрование. При этом многие пользователи могут проверить возможность VPN-подключения, выполнив команду ping на устройствах, выполняющих шифрование. Команда ping вполне подходит для выполнения этой задачи, однако важно отправить эту команду с соответствующего интерфейса. Если источник ping выбран неправильно, может отобразиться сбой VPN-подключения, тогда как в действительности подключение было успешно установлено. Рассмотрим для примера следующий вариант:
Маршрутизатор A с ACL шифрования
access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
Маршрутизатор B с ACL шифрования
access-list 110 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
В этой ситуации эхозапрос необходимо отправить из внутренней сети, находящейся за любым из маршрутизаторов. Причина в том, что ACL шифрования настроены только для шифрования трафика с использованием этих исходных адресов. Команда ping, отправленная с внешнего интерфейса (со стороны Интернета) одного из маршрутизаторов, не шифруется. Используйте расширенные параметры команды ping в привилегированном режиме EXEC, чтобы отправить эхозапрос из внутреннего интерфейса маршрутизатора:
routerA#ping Protocol [ip]: Target IP address: 192.168.200.10 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 192.168.100.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.200.1, timeout is 2 seconds: Packet sent with a source address of 192.168.100.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = ½/4 ms
Представьте, что маршрутизаторы на этой схеме заменили устройствами защиты PIX или ASA. Команду ping, используемую для проверки подключения, также можно отправить из внутреннего интерфейса с ключевым словом inside:
securityappliance#ping inside 192.168.200.10 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.200.10, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Примечание. Не рекомендуется направлять эхозапрос на внутренний интерфейс устройства безопасности. Если необходимо выбрать внутренний интерфейс в качестве целевого объекта команды ping, необходимо включить management-access для этого интерфейса, иначе устройство не сможет ответить.
securityappliance(config)#management-access inside
Примечание. Когда существует проблема с подключением, не работает даже этап 1 сети VPN. В ASA в случае сбоя подключения выходные данные SA подобны данным в этом примере, который указывает на возможно неправильную конфигурацию криптографического равноправного узла и/или неправильную конфигурацию предложения ISAKMP:
Router#show crypto isakmp sa
1 IKE Peer: XX.XX.XX.XX
Type : L2L Role : initiator
Rekey : no State : MM_WAIT_MSG2
Примечание. Состояние может иметь значение от MM_WAIT_MSG2 до MM_WAIT_MSG5, что обозначает сбой соответствующего обмена состояниями в основном режиме (MM).
Примечание. Выходные данные Crypto SA, получаемые, когда этап 1 работает, подобны следующему примеру:
Router#show crypto isakmp sa
1 IKE Peer: XX.XX.XX.XX
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
Включение ISAKMP
Если отсутствует указание на использование VPN-туннеля IPsec, причина может заключаться в том, что ISAKMP не был активирован. На своих устройствах обязательно включите ISAKMP. Используйте одну из этих команд, чтобы включить на устройствах поддержку ISAKMP:
-
Cisco IOS
router(config)#crypto isakmp enable
-
Cisco PIX 7.1 и более ранние версии (замените outside на необходимый интерфейс),
pix(config)#isakmp enable outside
-
Cisco PIX/ASA 7.2(1) и более поздние версии (замените outside на необходимый интерфейс),
securityappliance(config)#crypto isakmp enable outside
Эту ошибку также можно получить, если включить ISAKMP на внешнем интерфейсе:
UDP: ERROR - socket <unknown> 62465 in used ERROR: IkeReceiverInit, unable to bind to port
Возможная причина ошибки: клиент, расположенный за ASA/PIS, получает пакет PAT через UDP-порт 500, прежде чем в интерфейсе включается протокол ISAKMP. После удаления трансляции PAT (команда clear xlate) протокол ISAKMP можно включить.
Примечание. Всегда резервируйте порты с номерами UDP 500 и 4500 для согласования соединений ISAKMP с узлом.
Примечание. Когда протокол ISAKMP не включен на интерфейсе, клиент VPN показывает сообщение об ошибке приблизительно следующего содержания:
Secure VPN connection terminated locally by client. Reason 412: The remote peer is no longer responding
Примечание. Для того чтобы устранить эту ошибку, включите ISAKMP на криптоинтерфейсе шлюза VPN.
Включение/отключение безопасной пересылки (PFS)
При согласовании IPsec безопасная пересылка (PFS) позволяет гарантировать отсутствие связи нового ключа шифрования со всеми предыдущими ключами. Или включите или отключите безопасную пересылку (PFS) на обоих равноправных узлах туннеля; в противном случае в маршрутизаторе PIX/ASA/IOS не устанавливается IPSec-туннель ЛВС-ЛВС (L2L).
PIX/ASA:
По умолчанию безопасная пересылка (PFS)отключена. Для включения PFS используйте команду pfs с ключевым словом enable в режиме настройки групповой политики. Чтобы отключить PFS, введите ключевое слово disable.
hostname(config-group-policy)#pfs {enable | disable}
Чтобы удалить атрибут PFS из текущей конфигурации, введите эту команду с ключом no. Групповая политика может наследовать значение безопасной пересылки (PFS) от другой групповой политики. Введите эту команду с ключом no, чтобы предотвратить наследование значения.
hostname(config-group-policy)#no pfs
Маршрутизатор IOS:
Чтобы указать, что протокол IPsec должен запрашивать PFS при запросе новых сопоставлений безопасности для текущей записи криптокарты либо что IPsec должен запрашивать PFS при получении запросов на новые сопоставления безопасности, используйте команду set pfs в режиме настройки криптокарты. Если необходимо, чтобы IPsec не запрашивал PFS, используйте эту команду с ключом "no". По умолчанию PFS не запрашивается. Если никакая группа не задана с помощью этой команды, по умолчанию используется group1.
set pfs [group1 | group2] no set pfs
Для команды set pfs:
-
group1 — указывает, что во время нового обмена ключами по схеме Диффи-Хеллмана следует использовать 768-битную группу Диффи-Хеллмана по простому модулю.
-
group2 — указывает, что IPSec должен использовать 1024-разрядную главную группу модулей Диффи-Хеллмана при выполнении нового обмена Диффи-Хеллмана.
Пример:
Router(config)#crypto map map 10 ipsec-isakmp Router(config-crypto-map)#set pfs group2
Примечание. Perfect Forward Secrecy (PFS) является запатентованной функцией Cisco. Она не поддерживается на устройствах сторонних производителей.
Очистка старых или существующих сопоставлений безопасности (туннелей)
Если это сообщение об ошибке возникает в маршрутизаторе IOS, проблема заключается в истечении срока действия или очистке SA. Удаленный туннель конечного устройства не распознает данные об использовании устаревшего SA для отправки пакета (не пакета создания SA ). Когда устанавливается новый SA, связь возобновляется, поэтому инициируйте необходимый трафик через туннель, чтобы создать новый SA и восстановить туннель.
%CRYPTO-4-IKMP_NO_SA: IKE message from x.x.x.x has no SA
Очистка сопоставлений безопасности (SA) ISAKMP (этап I) и IPSec (этап II) — самое простое и часто лучшее решение проблем IPSec VPN.
При очистке SA часто удается устранить разнообразные сообщения об ошибках и странное поведение без необходимости в выполнении процедуры поиска и устранения неполадок. Хотя этот способ можно легко использовать в любой ситуации, он почти всегда обязателен для очистки SA после изменения текущей конфигурации IPSec VPN. Более того, хотя поддерживается возможность очистки только определенного сопоставления безопасности, наибольшими преимуществами можно воспользоваться при глобальной очистке SA на устройстве.
Примечание. После удаления сопоставлений безопасности, возможно, необходимо будет отправить трафик через туннель, чтобы восстановить их.
******************************* Warning *******************************: Если не указать сопоставления безопасности, которые требуется очистить, перечисленные здесь команды могут очистить все сопоставления безопасности в устройстве. Соблюдайте осторожность, если используются другие туннели IPsec VPN.
-
До очистки сопоставлений безопасности их необходимо просмотреть
-
Cisco IOS
router#show crypto isakmp sa router#show crypto ipsec sa
-
Cisco PIX/ASA Security Appliance
securityappliance#show crypto isakmp sa securityappliance#show crypto ipsec sa
Примечание. Эти команды являются одинаковыми для Cisco PIX 6.x и для PIX/ASA 7.x
-
-
Очистка ассоциаций безопасности. Каждую команду (они выделены полужирным шрифтом) можно вводить с параметрами.
-
Cisco IOS
-
ISAKMP (этап I)
router#clear crypto isakmp ? <0 - 32766> connection id of SA <cr>
-
IPSec (этап II)
router#clear crypto sa ? counters Reset the SA counters map Clear all SAs for a given crypto map peer Clear all SAs for a given crypto peer spi Clear SA by SPI <cr>
-
-
Cisco PIX/ASA Security Appliance
-
ISAKMP (этап I)
securityappliance#clear crypto isakmp sa
-
IPSec (этап II)
security appliance#clear crypto ipsec sa ? counters Clear IPsec SA counters entry Clear IPsec SAs by entry map Clear IPsec SAs by map peer Clear IPsec SA by peer <cr>
-
-
Проверка времени существования ISAKMP
Если соединения пользователей через туннель L2L часто разъединяются, проблема может быть вызвана тем, что в ISAKMP SA настроено меньшее время существования. В случае какого-либо несоответствия во времени существования ISAKMP можно получить сообщение об ошибке %PIX|ASA-5-713092: Group = x.x.x.x, IP = x.x.x.x, Failure during phase 1 rekeying attempt due to collision (%PIX|ASA-5-713092: группа = x.x.x.x, IP = x.x.x.x, сбой при попытке повторного ввода на этапе 1 из-за коллизии) в PIX/ASA. Для FWSM можно получить сообщение об ошибке %FWSM-5-713092: Group = x.x.x.x, IP = x.x.x.x, Failure during phase 1 rekeying attempt due to collision (%FWSM-5-713092: группа = x.x.x.x, IP = x.x.x.x, сбой при попытке повторного ввода на этапе 1 из-за коллизии). Для устранения проблемы настройте одинаковое значение в обоих равноправных узлах.
Значение по умолчанию: 86 400 секунд или 24 часа. Как правило, более короткое время существования обеспечивает более безопасные (в какой-то степени) согласования ISAKMP, но чем короче время существования, тем быстрее устройство защиты устанавливает будущие сопоставления безопасности IPSec.
Соответствие достигается, когда обе политики на двух равноправных узлах содержат одинаковые значения параметров шифрования, хэша, аутентификации и Диффи-Хеллмана и когда политика удаленного равноправного узла задает время существования, которое меньше или равно времени существования в сравниваемой политике. Если значения времени существования не идентичны, используется более короткое время существования из политики удаленного равноправного узла. Если приемлемое соответствие не найдено, IKE отказывает в согласовании и сопоставление безопасности IKE не устанавливается.
Задайте время существования сопоставления безопасности. В данном примере задано время существования 4 часа (14400 секунд). Значение по умолчанию: 86400 секунд (24 часа).
PIX/ASA
hostname(config)#isakmp policy 2 lifetime 14400
Маршрутизатор IOS
R2(config)#crypto isakmp policy 10 R2(config-isakmp)#lifetime 86400
В случае превышения максимального настроенного времени существования при завершении VPN-подключения отображается это сообщение об ошибке:
Безопасное подключение VPN прервано локально клиентом. Причина 426: превышено заданное максимальное время существования.
Для того чтобы устранить причину появления этого сообщения об ошибке, установите параметру lifetime значение 0, чтобы задать бесконечное время существования сопоставления безопасности IKE. VPN-соединение будет поддерживаться постоянно и не будет завершено.
hostname(config)#isakmp policy 2 lifetime 0
Для решения этой проблемы также можно выполнить команду disable re-xauth in the group-policy.
Включение или отключение пакетов Keepalive ISAKMP
При настройке пакетов Keepalive ISAKMP это помогает предотвращать спорадический сброс соединений ЛВС-ЛВС или VPN для удаленного доступа, включая клиенты и туннели VPN, а также туннели, отброшенные после истечения периода бездействия. Эта функция позволяет оконечной точке туннеля отслеживать постоянное присутствие удаленного равноправного узла и сообщать ему о собственном присутствии. Если равноправный узел перестает отвечать, данная оконечная точка удаляет соединение. Чтобы пакеты Keepalive ISAKMP работали, обе оконечные точки VPN должны их поддержать.
-
Настройте пакеты Keepalive ISAKMP в Cisco IOS с помощью следующей команды:
router(config)#crypto isakmp keepalive 15
-
Используйте эти команды для настройки пакетов Keepalive ISAKMP в устройствах защиты PIX/ASA:
-
Cisco PIX 6.x
pix(config)#isakmp keepalive 15
-
PIX/ASA Cisco 7.x и более поздней версии для туннельной группы с именем 10.165.205.222
securityappliance(config)#tunnel-group 10.165.205.222 ipsec-attributes securityappliance(config-tunnel-ipsec)#isakmp keepalive threshold 15 retry 10
В некоторых ситуациях для решения проблемы эту функцию необходимо отключить, например, если VPN-клиент находится за брандмауэром, который блокирует DPD-пакеты.
PIX/ASA Cisco 7.x и более поздней версии для туннельной группы с именем 10.165.205.222
Отключает обработку пакетов Keepalive IKE, которая включена по умолчанию.
securityappliance(config)#tunnel-group 10.165.205.222 ipsec-attributes securityappliance(config-tunnel-ipsec)#isakmp keepalive disable
Отключение поддержки активности для клиента Cisco VPN Client 4.x
Откройте папку %System Root% > Program Files > Cisco Systems > VPN Client > Profiles на клиентском ПК, где возникла проблема, чтобы отключить поддержку активности IKE, а также внесите изменения в файл PCF, если необходимо, для подключения.
Измените 'ForceKeepAlives=0' (по умолчанию) на 'ForceKeepAlives=1'.
-
Примечание. Механизм поддержки активности является собственностью Cisco и не поддерживается устройствами сторонних производителей.
Повторное введение или восстановление предварительных общих ключей
Во многих случаях в неработоспособности VPN-туннеля IPSec может быть виновата простая опечатка. Например, в устройстве защиты предварительные общие ключи становятся скрытыми после ввода. Это не позволяет увидеть, является ли ключ неправильным. Необходимо с особой внимательностью правильно вводить предварительные общие ключи в каждой оконечной точке VPN. Повторно введите ключ, чтобы быть уверенными в его правильности; это простое решение может помочь избежать тщательного поиска и устранения проблем.
В VPN удаленного доступа убедитесь, что в VPN-клиенте Cisco введены действительные имя группы и предварительный ключ. Эта ошибка может возникнуть, если имя группы/предварительный ключ, указанные для VPN-клиента и головного устройства, не совпадают.
1 12:41:51.900 02/18/06 Sev=Warning/3 IKE/0xE3000056 The received HASH payload cannot be verified 2 12:41:51.900 02/18/06 Sev=Warning/2 IKE/0xE300007D Hash verification failed 3 14:37:50.562 10/05/06 Sev=Warning/2 IKE/0xE3000099 Failed to authenticate peer (Navigator:904) 4 14:37:50.593 10/05/06 Sev=Warning/2 IKE/0xE30000A5 Unexpected SW error occurred while processing Aggressive Mode negotiator:(Navigator:2202) 5 14:44:15.937 10/05/06 Sev=Warning/2 IKE/0xA3000067 Received Unexpected InitialContact Notify (PLMgrNotify:888) 6 14:44:36.578 10/05/06 Sev=Warning/3 IKE/0xE3000056 The received HASH payload cannot be verified 7 14:44:36.593 10/05/06 Sev=Warning/2 IKE/0xE300007D Hash verification failed... may be configured with invalid group password. 8 14:44:36.609 10/05/06 Sev=Warning/2 IKE/0xE3000099 Failed to authenticate peer (Navigator:904) 9 14:44:36.640 10/05/06 Sev=Warning/2 IKE/0xE30000A5 Unexpected SW error occurred while processing Aggressive Mode negotiator:(Navigator:2202)
Кроме того, предварительный общий ключ можно восстановить без изменения конфигурации в устройстве защиты PIX/ASA. Подробное описание настройки сети VPN на базе IPSec между двумя узлами в устройстве защиты Cisco с версией ПО 7.x см. в документе PIX/ASA 7.x: Восстановление общего ключа.
******************************* Warning *******************************: При удалении команд шифрования возникает высокая вероятность отключения одного или всех VPN-туннелей. Соблюдайте осторожность при работе с этими командами и просмотрите политику контроля изменений до выполнения следующих действий.
-
Используйте следующие команды, чтобы удалить и повторно ввести предварительный общий ключ secretkey для узла 10.0.0.1 или группы vpngroup в IOS:
-
Cisco VPN (ЛВС-ЛВС)
router(config)#no crypto isakmp key secretkey address 10.0.0.1 router(config)#crypto isakmp key secretkey address 10.0.0.1
-
Cisco VPN для удаленного доступа
router(config)#crypto isakmp client configuration group vpngroup router(config-isakmp-group)#no key secretkey router(config-isakmp-group)#key secretkey
-
-
Используйте следующие команды, чтобы удалить и повторно ввести предварительный общий ключ secretkey для узла 10.0.0.1 на устройствах безопасности PIX/ASA:
-
Cisco PIX 6.x
pix(config)#no isakmp key secretkey address 10.0.0.1 pix(config)#isakmp key secretkey address 10.0.0.1
-
Cisco PIX/ASA 7.x и более поздние версии
securityappliance(config)#tunnel-group 10.0.0.1 ipsec-attributes securityappliance(config-tunnel-ipsec)#no pre-shared-key securityappliance(config-tunnel-ipsec)#pre-shared-key secretkey
-
Несогласованный предварительный общий ключ
Инициирование VPN-туннеля разъединяется. Эта проблема может возникать из-за несогласованного предварительного общего ключа на первом этапе согласований.
Сообщение MM_WAIT_MSG_6 в команде show crypto isakmp sa указывает на наличие несовпадающего предварительного общего ключа, как показано в следующем примере:
ASA#show crypto isakmp sa
Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
1 IKE Peer: 10.7.13.20
Type : L2L Role : initiator
Rekey : no State : MM_WAIT_MSG_6
Для устранения этой проблемы повторно введите предварительный общий ключ в обоих устройствах; предварительный общий ключ должен быть уникальным и соответствующим. Дополнительные сведения см. в разделе Повторный ввод или восстановление предварительных общих ключей.
Удаление и повторное применение криптокарт
******************************* Warning *******************************: При удалении криптокарты из интерфейса это определенно вызывает перевод в нерабочее состояние всех туннелей IPSec, привязанных к той криптокарте. Осторожно выполните эти действия и рассмотрите политику управления изменениями организации, прежде чем продолжить.
-
Следующие команды используются для удаления и замены криптокарты в Cisco IOS:
Начните с удаления криптокарты из интерфейса. Не Не Не используйте форму no команды crypto map.
router(config-if)#no crypto map mymap
Продолжая использовать форму no, удалите всю криптокарту.
router(config)#no crypto map mymap 10
Замените криптокарту в интерфейсе Ethernet0/0 для равноправного узла 10.0.0.1. В этом примере показана настройка криптокарты с минимальными требованиями:
router(config)#crypto map mymap 10 ipsec-isakmp router(config-crypto-map)#match address 101 router(config-crypto-map)#set transform-set mySET router(config-crypto-map)#set peer 10.0.0.1 router(config-crypto-map)#exit router(config)#interface ethernet0/0 router(config-if)#crypto map mymap
-
Следующие команды используются для удаления и замены криптокарты в PIX или ASA:
Начните с удаления криптокарты из интерфейса. Не Не Не используйте форму no команды crypto map.
securityappliance(config)#no crypto map mymap interface outside
Продолжая использовать форму no, удалите другие команды crypto map.
securityappliance(config)#no crypto map mymap 10 match address 101 securityappliance(config)#no crypto map mymap set transform-set mySET securityappliance(config)#no crypto map mymap set peer 10.0.0.1
Замените криптокарту для равноправного узла 10.0.0.1. В этом примере показана настройка криптокарты с минимальными требованиями:
securityappliance(config)#crypto map mymap 10 ipsec-isakmp securityappliance(config)#crypto map mymap 10 match address 101 securityappliance(config)#crypto map mymap 10 set transform-set mySET securityappliance(config)#crypto map mymap 10 set peer 10.0.0.1 securityappliance(config)#crypto map mymap interface outside
Примечание. Если удалить и повторно применить криптокарту, это также позволит решить проблему с подключением в случае изменения IP-адреса головного узла.
Проверка присутствия команд sysopt (только для PIX/ASA)
Команды sysopt connection permit-ipsec и sysopt connection permit-vpn позволяют пакетам из туннеля IPsec и содержащимся в них полезным данным обходить списки контроля доступа интерфейса на устройстве безопасности. Без выполнения одной из этих команд вероятен отказ туннелей IPSec, которые завершаются в устройстве защиты.
В ПО устройства защиты версии 7.0 и более ранней соответствующая команда sysopt для этой ситуации имеет вид sysopt connection permit-ipsec.
В ПО устройства защиты версии 7.1(1) и более поздней соответствующая команда sysopt для этой ситуации имеет вид sysopt connection permit-vpn.
В PIX 6.x эта функция отключена по умолчанию. В PIX/ASA, начиная с версии 7.0(1), эта функция по включена по умолчанию. С помощью команд show определите, включена ли на вашем устройстве соответствующая команда sysopt:
-
Cisco PIX 6.x
pix# show sysopt no sysopt connection timewait sysopt connection tcpmss 1380 sysopt connection tcpmss minimum 0 no sysopt nodnsalias inbound no sysopt nodnsalias outbound no sysopt radius ignore-secret no sysopt uauth allow-http-cache no sysopt connection permit-ipsec !--- sysopt connection permit-ipsec is disabled no sysopt connection permit-pptp no sysopt connection permit-l2tp no sysopt ipsec pl-compatible
-
Cisco PIX/ASA 7.x
securityappliance# show running-config all sysopt no sysopt connection timewait sysopt connection tcpmss 1380 sysopt connection tcpmss minimum 0 no sysopt nodnsalias inbound no sysopt nodnsalias outbound no sysopt radius ignore-secret sysopt connection permit-vpn !--- sysopt connection permit-vpn is enabled !--- This device is running 7.2(2)
Воспользуйтесь следующими командами, чтобы включить правильную команду sysopt для устройства:
-
PIX Cisco 6.x и PIX/ASA 7.0
pix(config)#sysopt connection permit-ipsec
-
Cisco PIX/ASA 7.1(1) и более поздней версии
securityappliance(config)#sysopt connection permit-vpn
Примечание. Если вы не хотите использовать команду sysopt connection, то необходимо явно разрешить во внешнем списке контроля доступа необходимый трафик, которым является интересующий вас трафик, идущий от источника к назначению, например, из локальной сети удаленного устройства в локальную сеть локального устройства, а также от порта UDP 500 для внешнего интерфейса удаленного устройства к внешнему интерфейсу локального устройства.
Проверка ISAKMP-идентичности
Если VPN-туннель IPSec отказал в процессе IKE-согласования, это могло произойти из-за PIX или неспособности его равноправного узла распознать идентичность другого равноправного узла. Когда два равноправных узла используют IKE для установления сопоставлений безопасности IPSec, каждый узел передает свою ISAKMP-идентичность удаленному узлу. Каждый узел передает свой IP-адрес или имя хоста в зависимости от того, как задана его ISAKMP-идентичность. По умолчанию в качестве ISAKMP-идентичности брандмауэра PIX задается IP-адрес. Как правило, следует одинаковым образом задавать устройство защиты и идентичность его равноправных узлов, чтобы избежать сбоя IKE-согласования.
Для того чтобы настроить отправку узлу идентификатора этапа 2, воспользуйтесь командой isakmp identity в режиме глобальной настройки
crypto isakmp identity address !--- If the RA or L2L (site-to-site) VPN tunnels connect !--- with pre-shared key as authentication type
Или
crypto isakmp identity auto !--- If the RA or L2L (site-to-site) VPN tunnels connect !--- with ISAKMP negotiation by connection type; IP address for !--- preshared key or cert DN for certificate authentication.
Или
crypto isakmp identity hostname !--- Uses the fully-qualified domain name of !--- the host exchanging ISAKMP identity information (default). !--- This name comprises the hostname and the domain name.
VPN-туннель перестает работать после переноса конфигурации из PIX в ASA с помощью средства переноса конфигурации PIX/ASA; в журнале появляются следующие сообщения:
[IKEv1]: группа = x.x.x.x, IP-адрес = x.x.x.x. Найдена устаревшая запись PeerTblEntry. Удаление! [IKEv1]: группа = x.x.x.x, IP-адрес = x.x.x.x. Не удалось удалить равноправный узел из таблицы коррелятора, не совпадает! [IKEv1]: группа = x.x.x.x, IP-адрес = x.x.x.x, construct_ipsec_delete(): нет SPI для идентификации SA этапа 2! [IKEv1]: группа = x.x.x.x, IP-адрес = x.x.x.x. Не удалось удалить равноправный узел из таблицы коррелятора, не совпадает!
Эта проблема возникает из-за того, что по умолчанию PIX идентифицирует соединение по имени хоста, а ASA — по IP-адресу. Для решения этой проблемы используйте команду crypto isakmp identity в режиме глобальной настройки, как показано далее:
crypto isakmp identity hostname !--- Use the fully-qualified domain name of !--- the host exchanging ISAKMP identity information (default). !--- This name comprises the hostname and the domain name.
При получении сообщения об ошибке Received an un-encrypted INVALID_COOKIE (Получен незашифрованный INVALID_COOKIE) подайте команду crypto isakmp identity address, чтобы устранить эту проблему.
Примечание. Команда isakmp identity больше не используется, начиная с версии программного обеспечения 7.2(1). Дополнительные сведения см. в документе Справочник по командам устройства безопасности Cisco, версия 7.2.
Проверка времени ожидания простоя/сеанса
Если для времени ожидания простоя задано 30 минут (по умолчанию), это означает, что туннель сбрасывается через 30 минут после прохождения последнего пакета трафика. Клиент VPN отключается через 30 минут, независимо от значения времени ожидания в состоянии бездействия, и получает ошибку PEER_DELETE-IKE_DELETE_UNSPECIFIED.
Задайте параметрам idle timeout и session timeout значение none, чтобы туннель всегда был в состоянии up и никогда не отбрасывался, даже при использовании устройств сторонних производителей.
PIX/ASA 7.x и более поздние
Введите команду vpn-idle-timeout в режиме конфигурации политики группы или в режиме конфигурации имени пользователя, чтобы задать период времени ожидания для пользователя:
hostname(config)#group-policy DfltGrpPolicy attributes hostname(config-group-policy)#vpn-idle-timeout none
Задайте максимальное количество времени для VPN-подключений с помощью команды vpn-session-timeout в режиме конфигурации политики группы или режиме конфигурации имени пользователя:
hostname(config)#group-policy DfltGrpPolicy attributes hostname(config-group-policy)#vpn-session-timeout none
Примечание. Когда настроен параметр tunnel-all, задавать параметр idle-timeout не требуется, поскольку он все равно не будет работать, так как весь трафик проходит через туннель (поскольку задан параметр tunnel-all). Поэтому содержательный трафик (или даже трафик, генерируемый ПК) будет содержательным и не допустит истечения времени ожидания простоя.
Маршрутизатор с ПО Cisco IOS
Для настройки таймера бездействия IPsec SA используйте команду crypto ipsec security-association idle-time в режиме глобальной настройки или режиме конфигурации криптокарты. По умолчанию время ожидания простоя сопоставлений безопасности IPSec отключено.
crypto ipsec security-association idle-time seconds
Время задается в секундах. В течение этого времени таймер бездействия позволяет неактивному узлу сохранять SA. Диапазон допустимых значений аргумента в секундах: 60–86400.
Проверка правильности списков контроля доступа и их привязки к криптокарте
В стандартной конфигурации IPsec VPN используются два списка доступа. Один список используется для исключения трафика, направленного в туннель VPN, из процесса NAT. Другой список доступа определяет трафик для шифрования; он включает в себя список шифрования ACL в настройке ЛВС-ЛВС или список раздельного туннелирования в конфигурации удаленного доступа. Если эти списки доступа неправильно настроены или отсутствуют, трафик может идти по туннелю VPN только в одном направлении или может вообще не проходить через туннель.
Примечание. Обязательно свяжите криптосписок контроля доступа с криптокартой с помощью команды crypto map match address в режиме глобальной настройки.
Убедитесь, что все списки доступа, необходимые для конфигурации IPsec VPN, настроены и что эти списки определяют правильный трафик. В списке далее описаны простые способы проверки в тех случаях, когда подозревается, что причина проблем с IPsec VPN в списке доступа.
-
Убедитесь, что в исключении NAT и списках доступа шифрования ACL указан правильный трафик.
-
Если имеется несколько туннелей VPN и списков шифрования ACL, убедитесь, что эти списки не пересекаются.
Примечание. На концентраторе VPN вы увидите журнал, подобный следующему:
Туннель отклонен: равноправный узел IKE не соответствует удаленному равноправному узлу, как определено в политике L2L
Чтобы избежать появления этого сообщения и активировать туннель, удостоверьтесь в том, что крипто-списки контроля доступа не перекрываются и один и тот же содержательный трафик не используется другим настроенным VPN-туннелем.
-
Не используйте ACL дважды. Даже если в ACL исключения NAT и в списке шифрования ACL указан одинаковый трафик, используйте два разных списка доступа.
-
Для конфигурации удаленного доступа не применяйте список доступа к содержательному трафику с динамической криптокартой. В результате VPN-клиент может оказаться неспособным соединиться с головным устройством. Если крипто-ACL был по ошибке настроен для VPN для удаленного доступа, можно получить сообщение об ошибке:%ASA-3-713042: IKE Initiator unable to find policy: Intf 2 (%ASA-3-713042: инициатор IKE не может найти политику: Intf 2).
Примечание. Если это туннель VPN типа «сеть-сеть», обязательно сопоставьте список контроля доступа с узлом. На равноправном узле они должны располагаться в обратном порядке.
-
Убедитесь, что конфигурация устройства позволяет использовать ACL исключения NAT. Для маршрутизаторов это означает использование команды route-map. Для PIX или ASA это означает использование команды nat (0). Список ACL исключения NAT необходимо для конфигураций ЛВС-ЛВС и удаленного доступа.
-
Здесь в маршрутизаторе IOS настраивается исключение применения NAT для трафика, который пересылается между 192.168.100.0 /24 и 192.168.200.0 /24 или 192.168.1.0 /24. Трафик, адресованный любым другим узлам, подвергается перегруженному NAT:
access-list 110 deny ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255 access-list 110 deny ip 192.168.100.0 0.0.0.255 192.168.1.0 0.0.0.255 access-list 110 permit ip 192.168.100.0 0.0.0.255 any route-map nonat permit 10 match ip address 110 ip nat inside source route-map nonat interface FastEthernet0/0 overload
-
Здесь в PIX настраивается исключение применения NAT для трафика, который передается между 192.168.100.0 / 24 и 192.168.200.0 / 24 или 192.168.1.0 / 24. Например, весь остальной трафик подвергается перегруженному NAT:
access-list noNAT extended permit ip 192.168.100.0 255.255.255.0 192.168.200.0 255.255.255.0 access-list noNAT extended permit ip 192.168.100.0 255.255.255.0 192.168.1.0 255.255.255.0 nat (inside) 0 access-list noNAT nat (inside) 1 0.0.0.0 0.0.0.0 global (outside) 1 interface
Примечание. Списки контроля доступа с исключением NAT работают только с IP-адресами или сетями IP, как упомянутые в примерах (access-list noNAT). Они должны быть такими же, как списки контроля доступа криптокарты. Списки контроля доступа с освобождением от NAT не работают с номерами портов (например, 23, 25, и т. д.).
Примечание. В среде VoIP, где голосовые вызовы между сетями передаются через VPN, голосовые вызовы не будут работать, если списки контроля доступа NAT 0 будут настроены неправильно. Прежде чем глубоко погружаться в процесс устранения проблем VoIP, рекомендуется проверить состояние VPN-подключений, так как проблема может быть вызвана неверной настройкой списков контроля доступа с освобождением от NAT.
Примечание. Если списки контроля доступа с исключением применения NAT (nat 0) настроены неправильно, может отображаться следующее сообщение об ошибке.
%PIX-3-305005: No translation group found for icmp src outside:192.168.100.41 dst inside:192.168.200.253 (type 8, code 0)
%ASA-3-305005: No translation group found for udp src Outside:x.x.x.x/p dst Inside:y.y.y.y/p
Примечание. Неправильный пример:
access-list noNAT extended permit ip 192.168.100.0 255.255.255.0 192.168.200.0 255.255.255.0 eq 25
Если освобождение NAT (nat 0) не работает, то попытайтесь удалить его и выполнить команду NAT 0.
-
-
Убедитесь в том, что ваши списки контроля доступа не организованы в обратном порядке и имеют правильный тип.
-
Списки контроля доступа криптографической защиты и освобождения от NAT для конфигураций ЛВС-ЛВС должны быть записаны с точки зрения устройства, на котором они настроены. Это означает, что списки контроля доступа (ACL) должны быть зеркальными друг другу. В этом примере настроен туннель ЛВС-ЛВС между 192.168.100.0 /24 и 192.168.200.0 /24.
Маршрутизатор A с ACL шифрования
access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
Маршрутизатор B с ACL шифрования
access-list 110 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
Примечание. Хотя здесь это не показано, аналогичная концепция применяется также и к устройствам обеспечения безопасности PIX и ASA.
-
В PIX/ASA списки контроля доступа раздельного туннелирования для конфигураций удаленного доступа должны быть стандартными и разрешать трафик к сети, доступ к которой необходим клиентам VPN. Маршрутизаторы IOS могут использовать для разделенного туннеля расширенный список контроля доступа.
Примечание. В расширенных списках контроля доступа использование параметра "any" для источника в списке контроля доступа разделенного туннелирования аналогично отключению разделенного туннелирования. В расширенном списке контроля доступа для разделенного туннелирования следует использовать только исходные сети.
Примечание.Правильный пример:
access-list 140 permit ip 10.1.0.0 0.0.255.255 10.18.0.0 0.0.255.255
Примечание. Неправильный пример:
access-list 140 permit ip any 10.18.0.0 0.0.255.255
-
Cisco IOS
router(config)#access-list 10 permit ip 192.168.100.0 router(config)#crypto isakmp client configuration group MYGROUP router(config-isakmp-group)#acl 10
-
Cisco PIX 6.x
pix(config)#access-list 10 permit 192.168.100.0 255.255.255.0 pix(config)#vpngroup MYGROUP split-tunnel 10
-
Cisco PIX/ASA 7.x
securityappliance(config)#access-list 10 standard permit 192.168.100.0 255.255.255.0 securityappliance(config)#group-policy MYPOLICY internal securityappliance(config)#group-policy MYPOLICY attributes securityappliance(config-group-policy)#split-tunnel-policy tunnelspecified securityappliance(config-group-policy)#split-tunnel-network-list value 10
-
-
Эта ошибка возникает в ASA 8.3, если в ASA не настроены (правильно или неправильно) списки контроля доступа NAT:
%ASA-5-305013: Асимметричные правила NAT совпадают для прямых и обратных потоков; отказано в соединении для udp ист. снаружи: x.x.x.x/xxxxx назн. внутри:x.x.x.x/xx из-за сбоя обратного пути NAT
Для решения этой проблемы убедитесь в том, что конфигурация правильная, или измените конфигурацию, если ее параметры имеют неверные значения.
Конфигурация освобождения от NAT в ASA версии 8.3 для VPN-туннеля типа «узел-узел»:
VPN-соединение типа «узел-узел» должно быть установлено между HOASA и BOASA. На обоих ASA должна использоваться версия 8.3. Конфигурация освобождения от NAT в HOASA выглядит подобно следующему:
object network obj-local subnet 192.168.100.0 255.255.255.0 object network obj-remote subnet 192.168.200.0 255.255.255.0 nat (inside,outside) 1 source static obj-local obj-local destination static obj-remote objremote
Проверка политик ISAKMP
Если туннель IPSec не работает, проверьте, что политики ISAKMP согласованы с удаленными равноправными узлами. Эта политика ISAKMP применима как для VPN-конфигураций IPsec "сеть-сеть" (ЛВС-ЛВС), так и для IPsec VPN удаленного доступа.
Если VPN-клиенты Cisco или VPN типа "сеть-сеть" не могут установить туннель к удаленному устройству, убедитесь, что два узла содержат одни и те же значения шифрования, хеша, аутентификации и параметра Диффи-Хеллмана, а также убедитесь, что в политике удаленных узлов для жизненного цикла указано значение, меньшее или равное аналогичному значению в политике, отправленной инициатором. Если значения времени существования не идентичны, устройство защиты использует самое короткое значение. Если приемлемого соответствия нет, ISAKMP отказывает в согласовании и сопоставление безопасности не устанавливается.
"Error: Unable to remove Peer TblEntry, Removing peer from peer table failed, no match!"
Вот подробное сообщение журнала:
4|Mar 24 2010 10:21:50|713903: IP = X.X.X.X, Error: Unable to remove PeerTblEntry 3|Mar 24 2010 10:21:50|713902: IP = X.X.X.X, Removing peer from peer table failed, no match! 3|Mar 24 2010 10:21:50|713048: IP = X.X.X.X, Error processing payload: Payload ID: 1 4|Mar 24 2010 10:21:49|713903: IP = X.X.X.X, Information Exchange processing failed 5|Mar 24 2010 10:21:49|713904: IP = X.X.X.X, Received an un-encrypted NO_PROPOSAL_CHOSEN notify message, dropping
Это сообщение обычно появляется из-за несогласованных политик ISAKMP или отсутствующего утверждения NAT 0.
Кроме того, появляется следующее сообщение:
Error Message %PIX|ASA-6-713219: Queueing KEY-ACQUIRE messages to be processed when P1 SA is complete.
Это сообщение указывает, что сообщения этапа 2 ставятся в очередь после завершения этапа 1. Это сообщение об ошибках могло появиться по одной из этих причин:
-
Несовпадение этапов на любом из равноправных узлов
-
Список контроля доступа не позволяет равноправным узлам завершить этап 1
Это сообщение обычно появляется после сообщения об ошибке Removing peer from peer table failed, no match! (Не удалось удалить узел из таблицы равноправных узлов, нет совпадений!).
Если приложению Cisco VPN Client не удается подключить головное устройство, данная проблема может быть следствием несоответствия политики ISAKMP. Головное оконечное устройство должно соответствовать одному из Предложений IKE приложения Cisco VPN Client.
Примечание. Для политики ISAKMP и команды IPsec Transform-set, которая используется в устройстве PIX/ASA: клиент Cisco VPN не может использовать политику с сочетанием DES и SHA. При использовании DES необходимо применить MD5 для алгоритма хеширования или можно воспользоваться другими комбинациями: 3DES и SHA или 3DES и MD5.
Проверка правильности маршрутизации
Маршрутизация — это важная часть любого развертывания IPsec VPN. Чтобы передавать трафик по VPN-туннелю, ваши устройства шифрования, такие как маршрутизаторы и PIX или устройства защиты ASA, обязательно должны иметь правильную информацию о маршрутизации. Более того, другим маршрутизаторам (если есть) за вашим шлюзом должно быть известно о том, как достигнуть туннеля и какие сети находятся с другой стороны.
Ключевой компонент маршрутизации при развертывании VPN — функции внесения обратного маршрута (RRI). RRI размещает в таблице маршрутизации шлюза VPN динамические записи для удаленных сетей или VPN-клиентов. Эти маршруты полезны для устройства, на котором они установлены, а также для других устройств в сети, потому что маршруты, установленные функцией RRI, могут быть перераспределены посредством протокола маршрутизации, такого как EIGRP или OSPF.
-
В конфигурации ЛВС-ЛВС для каждой оконечной точки важно иметь маршрут или маршруты к сетям, для которых предполагается шифрование трафика. В данном примере у маршрутизатора обязательно должны быть маршруты к сетям, расположенным за маршрутизатором B, через узел 10.89.129.2. Маршрутизатор B должен иметь подобный маршрут к сети 192.168.100.0/24:
-
Чтобы каждый маршрутизатор знал соответствующие маршруты, в первую очередь следует настроить статические маршруты для каждой сети назначения. Например, в маршрутизаторе A могут быть настроены следующие инструкции маршрутов:
ip route 0.0.0.0 0.0.0.0 172.22.1.1 ip route 192.168.200.0 255.255.255.0 10.89.129.2 ip route 192.168.210.0 255.255.255.0 10.89.129.2 ip route 192.168.220.0 255.255.255.0 10.89.129.2 ip route 192.168.230.0 255.255.255.0 10.89.129.2
Если маршрутизатор A был заменен устройством PIX или ASA, конфигурация может иметь следующий вид:
route outside 0.0.0.0 0.0.0.0 172.22.1.1 route outside 192.168.200.0 255.255.255.0 10.89.129.2 route outside 192.168.200.0 255.255.255.0 10.89.129.2 route outside 192.168.200.0 255.255.255.0 10.89.129.2 route outside 192.168.200.0 255.255.255.0 10.89.129.2
-
Если за каждой оконечной точкой существует больше сетей, поддержание конфигурации статических маршрутов становится трудной задачей. Вместо этого рекомендуется использовать внесение обратного маршрута в соответствии с приведенным описанием. RRI помещает в таблицу маршрутизации маршруты для всех удаленных сетей, указанных в ACL шифрования. Например, крипто-списки контроля доступа и криптокарта маршрутизатора A могут иметь следующий вид:
access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255 access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.210.0 0.0.0.255 access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.220.0 0.0.0.255 access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.230.0 0.0.0.255 crypto map myMAP 10 ipsec-isakmp set peer 10.89.129.2 reverse-route set transform-set mySET match address 110
Если маршрутизатор A был заменен устройством PIX или ASA, конфигурация может иметь следующий вид:
access-list cryptoACL extended permit ip 192.168.100.0 255.255.255.0 192.168.200.0 255.255.255.0 access-list cryptoACL extended permit ip 192.168.100.0 255.255.255.0 192.168.210.0 255.255.255.0 access-list cryptoACL extended permit ip 192.168.100.0 255.255.255.0 192.168.220.0 255.255.255.0 access-list cryptoACL extended permit ip 192.168.100.0 255.255.255.0 192.168.230.0 255.255.255.0 crypto map myMAP 10 match address cryptoACL crypto map myMAP 10 set peer 10.89.129.2 crypto map myMAP 10 set transform-set mySET crypto map mymap 10 set reverse-route
-
-
В конфигурации удаленного доступа изменения маршрутизации не всегда необходимы. Однако если за шлюзом VPN или средством Security Appliance имеются другие маршрутизаторы, эти маршрутизаторы должны каким-то образом получить данные о пути к VPN-клиентам. В данном примере предполагается, что при подключении клиенты VPN получают адреса в диапазоне 10.0.0.0 /24.
Если между шлюзом и другими маршрутизаторами протокол маршрутизации не используется, на маршрутизаторах, таких как маршрутизатор 2, можно использовать статические маршруты:
ip route 10.0.0.0 255.255.255.0 192.168.100.1
Если между шлюзом и другими маршрутизаторами используется протокол маршрутизации, такой как EIGRP или OSPF, рекомендуется использовать функцию внесения обратного маршрута (см. выше). RRI автоматически добавляет в таблицу маршрутизации шлюза маршруты для VPN-клиента. Затем эти маршруты могут быть распространены на другие маршрутизаторы в сети.
-
Маршрутизатор с ПО Cisco IOS:
crypto dynamic-map dynMAP 10 set transform-set mySET reverse-route crypto map myMAP 60000 ipsec-isakmp dynamic dynMAP
-
Cisco PIX или устройство защиты ASA:
crypto dynamic-map dynMAP 10 set transform-set mySET crypto dynamic-map dynMAP 10 set reverse-route crypto map myMAP 60000 ipsec-isakmp dynamic dynMAP
-
Примечание. Проблема с маршрутизацией возникает, если пул IP-адресов, назначенный для клиентов VPN, перекрывается с внутренними сетями головного оконечного устройства. Для получения дополнительной информации обратитесь к разделу Наложение частных сетей.
Проверка правильности набора преобразований
Убедитесь в том, что IPSec-шифрование и алгоритмы хэширования, которые будут использоваться набором преобразований на обоих концах, одинаковы. Дополнительные сведения см. в разделе Справочник по командам руководства по настройке устройства обеспечения безопасности Cisco.
Примечание. Для политики ISAKMP и команды IPsec Transform-set, которая используется в устройстве PIX/ASA: клиент Cisco VPN не может использовать политику с сочетанием DES и SHA. При использовании DES необходимо применить MD5 для алгоритма хеширования или можно воспользоваться другими комбинациями: 3DES и SHA или 3DES и MD5.
Проверка порядковых номеров и имени криптокарты, а также применения криптокарты в правильном интерфейсе, в котором начинается/заканчивается туннель IPSec
Если статические и динамические равноправные узлы настроены на одной криптокарте, порядок записей криптокарты очень важен. Порядковый номер динамической записи криптокарты должен быть больше всех прочих статических записей криптокарты. Если номера статических записей выше, чем у динамической записи, соединения с такими равноправными узлами разрываются и появляются результаты отладки, как показано ниже.
IKEv1]: Group = x.x.x.x, IP = x.x.x.x, QM FSM error (P2 struct &0x49ba5a0, mess id 0xcd600011)! [IKEv1]: Group = x.x.x.x, IP = x.x.x.x, Removing peer from correlator table failed, no match!
Примечание. Для каждого интерфейса в устройстве обеспечения безопасности может использоваться только одна динамическая криптокарта.
Далее предлагается пример должным образом пронумерованной криптокарты, которая содержит статическую и динамическую записи. Обратите внимание на то, что у динамической записи самый высокий порядковый номер и оставлен резерв для добавления дополнительных статических записей:
crypto dynamic-map cisco 20 set transform-set myset crypto map mymap 10 match address 100 crypto map mymap 10 set peer 172.16.77.10 crypto map mymap 10 set transform-set myset crypto map mymap interface outside crypto map mymap 60000 ipsec-isakmp dynamic cisco
Примечание. Имена криптокарт чувствительны к регистру.
Примечание. Это сообщение об ошибке также может появляться в случае неправильной последовательности динамических криптокарт, что приводит к попаданию равноправного узла в неправильную криптокарту. Также это может быть связано с неправильным списком контроля доступа к криптокарте, который определяет представляющий интерес трафик: %ASA-3-713042: инициатору IKE не удается найти политику:
Если несколько VPN-туннелей завершается на одном интерфейсе, необходимо создать криптокарту с таким же именем (допускается только одна криптокарта на интерфейс), но с другим порядковым номером. Это верно для маршрутизатора, PIX и ASA.
Для получения дополнительных сведений о PIX-конфигурации концентратора для той же криптокарты с другими порядковыми номерами на том же интерфейсе см. документ Настройка IPsec между концентратором и удаленными PIX с VPN-клиентом и расширенной аутентификацией. Также см. PIX/ASA 7. X: Добавление нового туннеля или удаленного доступа к существующей VPN L2L для получения дополнительной информации о настройке криптокарт для сценариев VPN L2L и удаленного доступа.
Проверка правильности IP-адреса равноправного узла
Для конфигурации LAN-LAN (L2L) IPSec VPN на устройстве безопасности PIX/ASA 7.x необходимо в команде tunnel-group <name> type ipsec-l2l в качестве значения параметра <name> туннельной группы задать IP-адрес удаленного однорангового узла (удаленный конец туннеля) для создания и управления базой данных, содержащей относящиеся к соединению записи для IPsec. IP-адрес равноправного узла должен быть одинаковым в командах tunnel group name и Crypto map set address. При настройке VPN с помощью ASDM автоматически создается имя туннельной группы с правильным IP-адресом равноправного узла. Если IP-адрес равноправного узла настроен неправильно, в журналах может содержать приведенное ниже сообщение, которое можно устранить, правильно настроив IP-адрес равноправного узла.
[IKEv1]: Group = DefaultL2LGroup, IP = x.x.x.x, ERROR, had problems decrypting packet, probably due to mismatched pre-shared key. Aborting
Для успешного создания соединения IPsec VPN в конфигурации LAN-LAN (L2L) устройства PIX 6.x IP-адрес равноправного узла (удаленный конец туннеля) должен быть одинаковым в командах isakmp key address и set peer в криптокарте.
Если IP-адрес равноправного узла в конфигурации криптокарты устройства ASA настроен неправильно, ASA будет не в состоянии создать VPN-туннель и «зависнет» на этапе MM_WAIT_MSG4. Для решения этой проблемы в конфигурации необходимо исправить IP-адрес равноправного узла.
Ниже приведен вывод команды show crypto isakmp sa, когда VPN-туннель «завис» в состоянии MM_WAIT_MSG4.
hostname#show crypto isakmp sa
1 IKE Peer: XX.XX.XX.XX
Type : L2L Role : initiator
Rekey : no State : MM_WAIT_MSG4
Проверка туннельной группы и имен групп
%PIX|ASA-3-713206: Tunnel Rejected: Conflicting protocols specified by tunnel-group and group-policy
Данное сообщение появляется при сбросе туннеля, так как в групповой политике и конфигурации туннельной группы указаны разные разрешенные туннели.
group-policy hf_group_policy attributes vpn-tunnel-protocol l2tp-ipsec username hfremote attributes vpn-tunnel-protocol l2tp-ipsec Both lines should read: vpn-tunnel-protocol ipsec l2tp-ipsec
Включите IPSec в групповой политике по умолчанию в дополнение к имеющимся в ней протоколам .
group-policy DfltGrpPolicy attributes vpn-tunnel-protocol L2TP-IPSec IPSec webvpn
Отключение XAUTH для равноправных узлов L2L
Если на одной и той же криптокарте настроены туннель LAN-LAN и туннель VPN для удаленного доступа, у равноправного узла LAN-LAN запрашивается информация о XAUTH, после чего происходит сбой туннеля LAN-LAN, а выходные данные команды show crypto isakmp sa содержат текст " CONF_XAUTH ".
Вот пример выходных данных SA:
Router#show crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id slot status X.X.X.X Y.Y.Y.Y CONF_XAUTH 10223 0 ACTIVE X.X.X.X Z.Z.Z.Z CONF_XAUTH 10197 0 ACTIVE
Примечание.Эта проблема относится только к Cisco IOS и PIX 6.x. не затрагивая PIX/ASA 7.x, так как здесь используются туннельные группы.
Не Не Не Используйте команду no-xauth при вводе ключа isakmp, чтобы устройство не отправляло запрос о данных XAUTH на узел (имя пользователя и пароль). Это ключевое слово отключает XAUTH для статических равноправных узлов IPSec. В устройстве, в котором на одной криптокарте настроены L2L и VPN RA, введите команду, подобную следующей:
router(config)#crypto isakmp key cisco123 address 172.22.1.164 no-xauth
Если PIX/ASA 7.x действует как сервер Easy VPN, клиент Easy VPN неспособен подключиться к головному узлу из-за проблемы с Xauth. Чтобы устранить данную проблему, отключите в PIX/ASA аутентификацию пользователей, как показано ниже:
ASA(config)#tunnel-group example-group type ipsec-ra ASA(config)#tunnel-group example-group ipsec-attributes ASA(config-tunnel-ipsec)#isakmp ikev1-user-authentication none
Исчерпание пула VPN
Если не достаточно диапазона IP-адресов, назначенных пулу VPN, доступность IP-адресов можно расширить двумя способами:
-
Удалите существующий диапазон и определите новый. Например:
CiscoASA(config)#no ip local pool testvpnpool 10.76.41.1-10.76.41.254 CiscoASA(config)#ip local pool testvpnpool 10.76.41.1-10.76.42.254
-
CiscoASA(config)#ip local pool testvpnpoolAB 10.76.41.1-10.76.42.254 CiscoASA(config)#ip local pool testvpnpoolCD 10.76.45.1-10.76.45.254 CiscoASA(config)#tunnel-group test type remote-access CiscoASA(config)#tunnel-group test general-attributes CiscoASA(config-tunnel-general)#address-pool (inside) testvpnpoolAB testvpnpoolCD CiscoASA(config-tunnel-general)#exit
Порядок указания пулов очень важен, так как ASA выделяет адреса из этих пулов в порядке, в котором пулы появляются в этой команде.
Примечание. Параметры настройки пулов адресов в команде group-policy address-pools всегда заменяют собой параметры настройки локального пула в команде tunnel-group address-pool.
Проблемы с задержкой для трафика VPN-клиента
Для устранения проблем задержки передачи трафика через VPN-подключением следует выполнить следующие проверки:
-
Проверьте, можно ли еще больше уменьшить MSS пакета.
-
Если вместо IPSec/udp используется IPSec/tcp, настройте preserve-vpn-flow.
-
Повторно загрузите Cisco ASA.
Неспособность VPN-клиентов соединяться с ASA/PIX
Проблема
Если Xauth используется вместе с RADIUS-сервером, клиенты Cisco VPN не могут выполнить аутентификацию.
Решение
Проблема может быть связана с истечением времени ожидания xauth. Чтобы решить эту проблему, увеличьте время ожидания для AAA-сервера.
Пример:
Hostname(config)#aaa-server test protocol radius hostname(config-aaa-server-group)#aaa-server test host 10.2.3.4 hostname(config-aaa-server-host)#timeout 10
Проблема
Если Xauth используется вместе с RADIUS-сервером, клиенты Cisco VPN не могут выполнить аутентификацию.
Решение
Сначала убедитесь в том, что аутентификация работает должным образом. Чтобы конкретизировать проблему, сначала проверьте аутентификацию с использованием локальной базой данных в ASA.
tunnel-group tggroup general-attributes
authentication-server-group none
authentication-server-group LOCAL
exit
Если это сработало, то проблема связана с конфигурацией RADIUS-сервера.
Проверьте подключение RADIUS-сервера из ASA. Если эхо-запрос работает без проблем, проверьте связанную с Radius-сервером конфигурацию в ASA и конфигурацию базы данных на RADIUS-сервере.
Для поиска и устранения неполадок, связанных с сервером RADIUS, можно использовать команду debug radius. Пример выходных данных команды debug radius см. в разделе Пример выходных данных.
Примечание. Перед использованием команды debug на устройстве ASA ознакомьтесь со следующей документацией: Предупреждающее сообщение.
Клиент VPN часто теряет подключение при первой попытке или «Безопасное подключение VPN разорвано узлом». Причина 433 или «Безопасное VPN-подключение завершено равноправным узлом. Причина 433: (причина не указана равноправным узлом)»
Проблема
При попытке соединения с головным устройством VPN пользователи Cisco VPN Client могут получить эту ошибку.
Клиент VPN часто теряет подключение при первой попытке или «Безопасное подключение VPN разорвано узлом». Причина 433 или «Безопасное VPN-подключение завершено равноправным узлом. Причина 433: (Причина не указана одноранговым узлом)», или «Предпринята попытка назначить IP-адрес сети или широковещательной рассылки, удаление (x.x.x.x) из пула»
Решение 1
Могла возникнуть проблема с назначением пула IP-адресов посредством ASA/PIX, RADIUS-сервер, DHCP-сервер или RADIUS-сервер, действующий как DHCP-сервер. Используйте команду debug crypto, чтобы проверить правильность маски подсети и IP-адреса. Также следует проверить, что пул не включает сетевой и широковещательный адреса. RADIUS-серверы должны быть в состоянии назначать клиентам правильные IP-адреса.
Решение 2
Эта проблема также возникает из-за сбоя расширенной аутентификации. Для устранения этой ошибки необходимо проверить AAA-сервер. Эта проблема может быть устранена проверкой пароля аутентификации сервера на сервере и клиенте и повторной загрузкой AAA-сервера.
Решение 3
Другой обходной путь решения этой проблемы — отключить функцию обнаружения угроз. Иногда ASA с включенной функцией обнаружения угроз принимает множественные повторные передачи для различных неполных сопоставлений безопасности (SA) за атаку сканирования и VPN-порты отмечаются как основные нарушители. Попробуйте отключить функцию обнаружения угроз, поскольку в противном случае ASA при обработке придется нести дополнительную нагрузку. Используйте эти команды для отключения обнаружения угрозы:
no threat-detection basic-threat no threat-detection scanning-threat shun no threat-detection statistics no threat-detection rate
Дополнительную информацию об этой функции см. в разделе Обнаружение угроз.
Примечание. Этот способ можно использовать в качестве обходного пути, чтобы проверить, будет ли в результате исправлена фактическая проблема. Отключение обнаружения угрозы в Cisco ASA фактически ставит под угрозу несколько характеристик безопасности, таких как нейтрализация попыток сканирования, DoS с недопустимыми SPI, пакетов, которые не проходят проверку приложений, и неполных сеансов.
Решение 4
Данная проблема возникает, если набор преобразований настроен не должным образом. Проблему можно решить, правильно настроив набор преобразований.
Пользователи удаленного доступа и EZVPN подключаются к VPN, но не могут получить доступ к внешним ресурсам
Проблема
У У У После подключения к VPN пользователи удаленного доступа теряют интернет-подключение.
Пользователям удаленного доступа не доступны ресурсы, расположенные за другими сетями VPN на том же устройстве.
Пользователям удаленного доступа доступна только локальная сеть.
Решения
Попробуйте применить эти решения для разрешения данной проблемы:
Недоступность серверов в DMZ
Как только VPN-клиент устанавливает туннель IPSec с головным устройством VPN (маршрутизатор PIX/ASA/IOS), пользователи VPN-клиента получают доступ к ресурсам внутренней сети (10.10.10.0/24), но не к сети DMZ (10.1.1.0/24).
Схема
Проверьте, что в головное устройство НЕ добавлена конфигурация NAT разделенного туннеля для доступа к ресурсам сети DMZ.
Пример
| ASA/PIX |
|---|
ciscoasa#show running-config !--- Split tunnel for the inside network access access-list vpnusers_spitTunnelAcl permit ip 10.10.10.0 255.255.0.0 any !--- Split tunnel for the DMZ network access access-list vpnusers_spitTunnelAcl permit ip 10.1.1.0 255.255.0.0 any !--- Create a pool of addresses from which IP addresses are assigned !--- dynamically to the remote VPN Clients. ip local pool vpnclient 192.168.1.1-192.168.1.5 !--- This access list is used for a nat zero command that prevents !--- traffic which matches the access list from undergoing NAT. !--- No Nat for the DMZ network. access-list nonat-dmz permit ip 10.1.1.0 255.255.255.0 192.168.1.0 255.255.255.0 !--- No Nat for the Inside network. access-list nonat-in permit ip 10.10.10.0 255.255.255.0 192.168.1.0 255.255.255.0 !--- NAT 0 prevents NAT for networks specified in the ACL nonat . nat (DMZ) 0 access-list nonat-dmz nat (inside) 0 access-list nonat-in |
Конфигурация ASA версии 8.3:
Эта конфигурация показывает, как настроить освобождение от NAT для сети DMZ, чтобы позволить пользователям VPN иметь доступ к сети DMZ:
object network obj-dmz subnet 10.1.1.0 255.255.255.0 object network obj-vpnpool subnet 192.168.1.0 255.255.255.0 nat (inside,dmz) 1 source static obj-dmz obj-dmz destination static obj-vpnpool obj-vpnpool
После добавления новой записи для конфигурации NAT очистите преобразование NAT.
Clear xlate Clear local
Проверка:
Если туннель установлен, перейдите к приложению Cisco VPN Client и выберите Status > Route Details (Состояние > Сведения о маршрутах), чтобы убедиться, что защищенные маршруты отображаются и для сети DMZ, и для внутренней сети.
VPN-клиентам не удается разрешить DNS
Если VPN-клиентам не удается разрешить DNS после установления туннеля, проблема может быть связана с конфигурацией DNS-сервера в головном устройстве (ASA/PIX). Также проверьте соединения между VPN-клиентами и DNS-сервером. Конфигурация DNS-сервера должна быть настроена в групповой политике и применена как групповая политика в общих атрибутах туннельной группы; пример:
!--- Create the group policy named vpn3000 and !--- specify the DNS server IP address(172.16.1.1) !--- and the domain name(cisco.com) in the group policy. group-policy vpn3000 internal group-policy vpn3000 attributes dns-server value 172.16.1.1 default-domain value cisco.com !--- Associate the group policy(vpn3000) to the tunnel group !--- using the default-group-policy. tunnel-group vpn3000 general-attributes default-group-policy vpn3000
VPN-клиентам не удается подключить внутренние серверы по имени
Клиенту VPN не удается проверить с помощью ping-запросов связь с хостами или серверами удаленной сети или внутренней сети головного узла по имени. Для решения этой проблемы необходимо в ASA включить настройку split-dns.
Разделенный туннель — Недоступность Интернета или исключенных сетей
Разделенное туннелирование позволяет клиентам IPSEC удаленного доступа условно направлять пакеты через туннель IPSec в зашифрованной форме или направлять расшифрованные пакеты к сетевому интерфейсу в форме открытого текста, где они затем направляются к конечному назначению. Разделенное туннелирование по умолчанию отключено, то есть трафик трактуется как tunnelall.
split-tunnel-policy {tunnelall | tunnelspecified | excludespecified}
Примечание. Параметр excludespecified поддерживается только для клиентов Cisco VPN, но не для клиентов EZVPN.
ciscoasa(config-group-policy)#split-tunnel-policy excludespecified
Подробные примеры конфигурации раздельного туннелирования можно найти в следующих документах:
-
PIX/ASA 7.x: Разрешение разделенного туннелирования для VPN-клиентов на примере конфигурации ASA
-
Пример настройки расщепления туннелей для клиентов VPN на концентраторе VPN 3000
Разворот пакетов
Эта функция полезна для трафика VPN, который входит по интерфейсу и маршрутизируется на выход из этого же интерфейса. Например, если имеется концентратор и оконечная сеть VPN, в которой устройствами защиты являются концентраторы, а удаленные сети VPN являются оконечными, для обеспечения взаимодействия между оконечными устройствами трафик должен переходить к устройству защиты, а затем к другому оконечному устройству.
Используйте конфигурацию same-security-traffic, чтобы разрешить вход и выход трафика через один и тот же интерфейс.
securityappliance(config)#same-security-traffic permit intra-interface
Доступ к локальной сети
Пользователи удаленного доступа подключаются к VPN и могут соединиться только с локальной сетью.
Наложение частных сетей
Проблема
Если после установки туннеля не удается получить доступ к внутренней сети, проверьте IP-адрес, назначенный VPN-клиенту, который перекрывается с внутренней сетью, расположенной за головным устройством.
Решение
Всегда удостоверяйтесь в том, что IP-адреса в пуле, которые назначаются VPN-клиентам, внутренней сети головного устройства и внутренней сети VPN-клиента, относятся к разным сетям. Можно назначить одну крупную сеть с разными подсетями, но иногда возникают проблемы маршрутизации.
Для дальнейших примеров см. Схему и Пример в разделе Невозможно получить доступ к серверам в DMZ.
Невозможно подключить больше трех пользователей VPN-клиента
Проблема
Только три клиента VPN могут подключиться к ASA/PIX; подключение четвертого клиента завершается сбоем. После сбоя отображается это сообщение об ошибке:
Secure VPN Connection terminated locally by the client. Reason 413: User Authentication failed.
tunnel rejected; the maximum tunnel count has been reached
Решения
В большинстве случаев эта проблема связана с настройкой одновременного входа в систему в групповой политике и ограничением максимального количества сеансов.
Попробуйте применить эти решения для разрешения данной проблемы:
Для получения дополнительных сведений см. раздел Настройка групповых политик Выбранные процедуры настройки ASDM VPN для Cisco ASA серии 5500, версия 5.2.
Настройка одновременных входов в систему
Если флажок Inherit в ASDM установлен, для данного пользователя разрешено только значение по умолчанию для количества одновременных входов в систему. Для одновременных входов в систему значение по умолчанию равняется трем.
Чтобы решить данную проблему, увеличьте количество одновременных входов в систему.
-
Запустите ASDM, а затем перейдите к разделу Configuration > VPN > Group Policy.
-
Выберите соответствующую Группу и щелкните Edit (Редактировать).
-
На вкладке General (Общие), снимите флажок Inherit (Наследовать) для Simultaneous Logins (Одновременные входы в систему) в разделе Connection Settings. Выберите соответствующее значение в поле.
Примечание. Минимальное значение для этого поля равно 0, то есть вход в систему отключен и доступ пользователей невозможен.
Примечание. При входе в систему с использованием той же учетной записи пользователя с другого ПК текущий сеанс (соединение, установленное с другого ПК с использованием той же учетной записи пользователя) завершается и устанавливается новый сеанс. Это поведение по умолчанию, которое не зависит от одновременных входов в систему через VPN.
Настройка ASA/PIX в интерфейсе командной строки
Выполните указанные ниже действия, чтобы настроить нужное число одновременных входов в систему. В данном примере в качестве желаемого значения выбрано число 20.
ciscoasa(config)#group-policy Bryan attributes ciscoasa(config-group-policy)#vpn-simultaneous-logins 20
Используйте команду vpn-sessiondb max-session-limit в режиме глобальной настройки, чтобы указать допустимое максимальное количество сеансов VPN, меньшее разрешенного устройством обеспечения безопасности. Используйте версию no этой команды для удаления ограничения количества сеансов. Для перезаписи текущего параметра данная команда используется повторно.
vpn-sessiondb max-session-limit {session-limit}
В этом примере показано, как задать максимальное ограничение на количество сеансов VPN (450):
hostname#vpn-sessiondb max-session-limit 450
Настройка концентратора
Сообщение об ошибке
20932 10/26/2007 14:37:45.430 SEV=3 AUTH/5 RPT=1863 10.19.187.229 Authentication rejected: Reason = Simultaneous logins exceeded for user handle = 623, server = (none), user = 10.19.187.229, domain = <not specified>
Решение
Выполните указанные ниже действия, чтобы настроить нужное число одновременных входов в систему. Для этого SA можно также попытаться задать число одновременных входов в систему равным 5:
Выберите Configuration > User Management > Groups > Modify 10.19.187.229 > General > Simultaneous Logins (Конфигурация > Управление пользователями > Группы > Изменить 10.19.187.229 > Общее > Одновременные входы в систему) и измените количество входов в систему, задав 5.
Невозможность инициирования сеанса или приложения и медленная передача после установки туннеля
Проблема
После установления туннеля IPSec через него не инициируется приложение или сеанс.
Решения
Используйте команду ping для проверки работы сети или проверьте доступность сервера приложений из сети пользователя. Эта проблема может быть связана с максимальным размером сегмента (MSS) для переходных пакетов, которые проходят через маршрутизатор или устройство PIX/ASA, в частности, сегменты TCP с установленным битом SYN.
Маршрутизатор Cisco IOS — изменение значения MSS во внешнем интерфейсе (интерфейс конца туннеля) маршрутизатора
Чтобы изменить значение MSS во внешнем интерфейсе (интерфейс конца туннеля) маршрутизатора, следует выполнить эти команды:
Router>enable Router#configure terminal Router(config)#interface ethernet0/1 Router(config-if)#ip tcp adjust-mss 1300 Router(config-if)#end
Эти сообщения показывают выходные данные отладки для TCP MSS:
Router#debug ip tcp transactions Sep 5 18:42:46.247: TCP0: state was LISTEN -> SYNRCVD [23 -> 10.0.1.1(38437)] Sep 5 18:42:46.247: TCP: tcb 32290C0 connection to 10.0.1.1:38437, peer MSS 1300, MSS is 1300 Sep 5 18:42:46.247: TCP: sending SYN, seq 580539401, ack 6015751 Sep 5 18:42:46.247: TCP0: Connection to 10.0.1.1:38437, advertising MSS 1300 Sep 5 18:42:46.251: TCP0: state was SYNRCVD -> ESTAB [23 -> 10.0.1.1(38437)]
MSS получает значение 1300 на маршрутизаторе согласно конфигурации.
Для получения дополнительной информации обратитесь к документу PIX/ASA 7.x и IOS: Фрагментация VPN.
PIX/ASA 7. X. См. документацию по PIX/ASA
Невозможно получить соответствующий доступ к Интернету или трафик медленно передается через туннель, так как появляются сообщение об ошибке максимального размера передаваемого блока данных и проблемы MSS. Чтобы разрешить данную проблему, см. следующие документы:
Не удается инициировать VPN-туннель из ASA/PIX
Проблема
Не удается инициировать VPN-туннель из интерфейса ASA/PIX, а после установления туннеля клиент/VPN удаленного конца неспособен проверять доступность (ping) внутреннего интерфейса ASA/PIX вVPN-туннеле. Например, клиент pn может быть неспособен инициировать соединение SSH или HTTP с внутренним интерфейсом ASA по VPN-туннелю.
Решение
Нельзя проверить связь с внутренним интерфейсом PIX с помощью ping-запросов с другого конца туннеля, если команда management-access не настроена в режиме глобальной настройки.
PIX-02(config)#management-access inside PIX-02(config)#show management-access management-access inside
Примечание. Эта команда также помогает инициировать соединение SSH или HTTP с внутренним интерфейсом ASA через VPN-туннель.
Примечание. Эта информация применима и для интерфейса DMZ. Например, если необходимо проверить связь с интерфейсом DMZ устройства PIX/ASA с помощью ping-запросов или инициировать туннель из интерфейса DMZ, следует использовать команду management-access DMZ.
PIX-02(config)#management-access DMZ
Примечание. Если клиенту VPN не удается установить соединение, убедитесь, что порты ESP и UDP открыты; если эти порты не открыты, попытайтесь установить соединение через порт TCP 10000, выбрав его в записи подключения клиента VPN. Правой кнопкой щелкните modify > transport tab > IPSec over TCP. См. PIX/ASA 7.x для поддержки IPsec по TCP на любом примере конфигурации портов для получения дополнительной информации об IPsec по TCP.
Не удается передать трафик по VPN-туннелю
Проблема
Невозможно передать трафик по VPN-туннелю.
Решение
Эта неполадка связана с проблемой, описанной в идентификаторе ошибки Cisco CSCtb53186 (только для зарегистрированных заказчиков). Чтобы устранить данную неполадку, перезагрузите ASA. Обратитесь к данной ошибке для получения дополнительной информации.
Эта проблема также может возникнуть, когда пакеты ESP заблокированы. Чтобы разрешить эту проблему, измените конфигурацию VPN-туннеля.
Эта проблема может возникнуть, когда данные не зашифрованы, но они дешифруются только при передаче по VPN-туннелю, как показано в следующих выходных данных:
ASA# sh crypto ipsec sa peer x.x.x.x
peer address: y.y.y.y
Crypto map tag: IPSec_map, seq num: 37, local addr: x.x.x.x
access-list test permit ip host xx.xx.xx.xx host yy.yy.yy.yy
local ident (addr/mask/prot/port): (xx.xx.xx.xx/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (yy.yy.yy.yy/255.255.255.255/0/0)
current_peer: y.y.y.y
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 393, #pkts decrypt: 393, #pkts verify: 393
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
Чтобы решить эту проблему, проверьте следующее:
-
Крипто-списки доступа должны соответствовать удаленному сайту и списки доступа NAT 0 должны быть правильными.
-
Маршрутизация должна быть правильной, а трафик должен попадать во внешний интерфейс, проходя через внутренние узлы. В примере выходных данных показано, что расшифровка сделана, но шифрование не выполняется.
-
Если команда sysopt permit connection-vpn настроена на устройстве ASA. Если это не так, настройте эту команду, так как она позволяет устройству ASA освобождать зашифрованный и VPN-трафик от проверки списков контроля доступа интерфейса.
Настройка резервного равноправного узла для VPN-туннеля на одной криптокарте
Проблема
Для одиночного VPN-туннеля требуется использовать несколько резервных равноправных узлов.
Решение
Настройка нескольких равноправных узлов эквивалентна предоставлению списка переключения на резерв. Для каждого туннеля устройство безопасности пытается выполнить согласование с первым равноправным узлом в списке.
Если равноправный узел не отвечает, устройство защиты последовательно перебирает весь список, пока какой-либо из равноправных узлов не ответит, или пока не закончится данный список.
В ASA должна быть криптокарта, уже настроенная как равноправный узел. После основного равноправного узла можно добавить вторичный.
В данном примере конфигурации основной равноправный узел представлен как X.X.X.X, а резервный равноправный узел — как Y.Y.Y.Y:
ASA(config)#crypto map mymap 10 set peer X.X.X.X Y.Y.Y.Y
Отключение/перезапуск VPN-туннеля
Проблема
Чтобы временно отключить VPN-туннель и перезапустить сервис, выполните процедуру, описанную в этом разделе.
Решение
Используйте команду crypto map interface в режиме глобальной настройки, чтобы удалить ранее определенный набор криптокарт из интерфейса. Используйте эту команду с параметром no, чтобы удалить набор криптокарт из интерфейса.
hostname(config)#no crypto map map-name interface interface-name
Эта команда удаляет набор криптокарт любого активного интерфейса устройства защиты, и делает VPN-туннель IPSec неактивным в этом интерфейсе.
Для перезапуска Туннеля IPSec в интерфейсе необходимо назначить интерфейсу набор криптокарт, прежде чем этот интерфейс сможет предоставлять сервисы IPSec.
hostname(config)#crypto map map-name interface interface-name
Некоторые туннели не зашифрованы
Проблема
Когда в шлюзе VPN настроено очень много туннелей, некоторые туннели не пропускают трафик. ASA не получает зашифрованные пакеты для таких туннелей.
Решение
Эта проблема возникает из-за того, что ASA не удается передавать зашифрованные пакеты через данные туннели. В таблице ASP созданы двойные правила шифрования. Это известная неполадка, и для ее устранения был создан идентификатор ошибки CSCtb53186 (только для зарегистрированных заказчиков). Для решения этой проблемы следует повторно загрузить ASA или обновить программное обеспечение до версии, в которой эта ошибка исправлена.
Ошибка:- %ASA-5-713904: Группа = DefaultRAGroup, IP = x.x.x.x, клиент использует неподдерживаемую версию режима транзакции v2. Туннель завершен.
Проблема
Появляется сообщение об ошибке %ASA-5-713904: Группа = DefaultRAGroup, IP = 99.246.144.186, Клиент использует неподдерживаемую версию v2 режима транзакции. Туннельное соединение разорвано.
Решение
Причина появления сообщения об ошибке Transaction Mode v2 состоит в том, что ASA поддерживает только режим настройки IKE версии V6, а не старую версию V2. Для устранения этой ошибки следует использовать режим настройки IKE версии V6.
Ошибка:- %ASA-6-722036: Пользователь группы client-group xxxx IP x.x.x.x передает пакет большого размера 1220 (порог 1206)
Проблема
Сообщение об ошибке %ASA-6-722036: пользователь группы < client-group > < xxxx > IP < x.x.x.x> передает пакет большого размера 1220 (макс. размер 1206) появляется в журналах ASA. Что означает регистрация этой ошибки и как это ее можно устранить?
Решение
В этом сообщении журнала сообщается, что клиенту был отправлен большой пакет. Источнику пакета не известен MTU клиента. Это может также произойти из-за сжатия несжимаемых данных. Обходной путь: выключить сжатие SVC с помощью команды svc compression none, что устранит проблему.
Ошибка: Команда authentication-server-group none была исключена
Проблема
При передаче конфигурации VPN из устройства PIX/ASA, на котором запущена версия 7.0.x, в другое устройство защиты, на котором запущена версия 7.2.x, отображается следующее сообщение об ошибке:
ERROR: The authentication-server-group none command has been deprecated. The "isakmp ikev1-user-authentication none" command in the ipsec-attributes should be used instead.
Решение
Команда authentication-server-group больше не поддерживается в версии 7.2 (1) и последующих версиях. Эта команда была исключена и переведена в режим настройки tunnel-group general-attributes.
Отображается сообщение об ошибках, если на одном конце VPN-туннеля включено QoSо
Проблема
При включении QoS на одном конце VPN-туннеля может появиться это сообщение об ошибке:
IPSEC: Received an ESP packet (SPI= 0xDB6E5A60, sequence number= 0x7F9F) from 10.18.7.11 (user= ghufhi) to 172.16.29.23 that failed anti-replay checking
Решение
Это сообщение обычно появляется, когда на одном конце туннеля включена поддержка QoS. Это происходит при обнаружении испорченного пакета. Можно отключить QoS, чтобы остановить появление сообщения, но это можно игнорировать, пока трафик пересекает туннель.
ПРЕДУПРЕЖДЕНИЕ: запись криптокарты будет неполной
Проблема
При выполнении команды crypto map mymap 20 ipsec-isakmp может возникать следующая ошибка:
ПРЕДУПРЕЖДЕНИЕ: запись криптокарты будет неполной
Пример:
ciscoasa(config)#crypto map mymap 20 ipsec-isakmp WARNING: crypto map entry will be incomplete
Решение
Это предупреждение обычно появляется при определении новой криптокарты, напоминая о необходимости настроить параметры, такие как список доступа (адрес соответствия), набор преобразований и адрес равноправного узла, прежде чем криптокарта сможет работать. Кроме того, обычно первая строка, которая вводится для определения криптокарты, не отображается в конфигурации.
Ошибка:- %ASA-4-400024: IDS:2151. Большой ICMP-пакет к интерфейсу снаружи
Проблема
Через VPN-туннель не удается передать большой ping-пакет. При попытке передачи больших ping-пакетов возникает ошибка %ASA-4-400024: IDS:2151 Большой ICMP-пакет на внешнем интерфейсе
Решение
Чтобы решить данную проблему, отключите сигнатуры 2150 и 2151. После отключения сигнатур эхо-запросы работают хорошо.
Для отключения сигнатур используйте следующие команды:
ASA(config)#ip audit signature 2151 disable
ASA(config)#ip audit signature 2150 disable
Ошибка:- %PIX|ASA-4-402119: IPSEC: Получен пакет протокола (SPI=spi, порядковый номер = seq_num) от remote_IP (имя пользователя) для узла local_IP, который не прошел проверку антивоспроизведения.
Проблема
Эта ошибка получена в сообщениях журнала ASA:
Ошибка:- %PIX|ASA-4-402119: IPSEC: Получен пакет протокола (SPI=spi, порядковый номер = seq_num) от remote_IP (имя пользователя) для узла local_IP, который не прошел проверку антивоспроизведения.
Решение
hostname(config)#crypto ipsec security-association replay window-size 1024
Примечание. Cisco рекомендует использовать полный размер окна 1024, чтобы избежать любых проблем с антивоспроизведением.
Сообщение об ошибке — %PIX|ASA-4-407001: запрет трафика для local-host interface_name:inside_address, превышено ограничение на количество лицензий
Проблема
Нескольким хостам не удается подключиться к Интернету и в системном журнале появляется это сообщение об ошибке:
Сообщение об ошибке — %PIX|ASA-4-407001: запрет трафика для local-host interface_name:inside_address, превышено ограничение на количество лицензий
Решение
Это сообщение об ошибке возникает, когда количество пользователей превышает предельную для используемой лицензии величину. Эта ошибку можно устранить, обновив лицензию до большего количества пользователей. При необходимости лицензия пользователя может включать 50, 100 или неограниченное количество пользователей.
Сообщение об ошибке %VPN_HW-4-PACKET_ERROR:
Проблема
Сообщение об ошибке %VPN_HW-4-PACKET_ERROR: указывает на несоответствие пакета ESP и HMAC, полученного маршрутизатором. Эта ошибка может быть вызвана следующими проблемами:
-
Неисправный аппаратный модуль VPN
-
Поврежденный ESP-пакет
Решение
Чтобы устранить это сообщение об ошибке:
-
Игнорируйте это сообщение об ошибках, если нет нарушения трафика.
-
В случае нарушения трафика замените модуль.
Сообщение об ошибке: Команда отклонена: сначала удалите криптосоединения между VLAN XXXX и XXXX.
Проблема
Это сообщение об ошибке появляется при попытке добавления разрешенного VLAN-соединения на магистральный порт коммутатора: Команда отклонена: сначала удалите крипто-соединение между сетями VLAN XXXX и VLAN XXXX..
Граничный магистральный канал глобальной сети (WAN) невозможно модифицировать, чтобы разрешить дополнительные сети VLAN. Т. е. вы не можете добавлять сети VLAN в магистральный канал IPSEC VPN SPA.
Эта команда отклонена, так как разрешение ее выполнение привело бы к созданию сети VLAN связанного крипто-интерфейса, которая входит в список разрешенных сетей VLAN интерфейса, и потенциальной угрозы безопасности IPSec. Обратите внимание на то, что это поведение применяется ко всем магистральным портам.
Решение
Вместо команды no switchport trunk allowed vlan (vlanlist) используйте команду switchport trunk allowed vlan none или команду "switchport trunk allowed vlan remove (vlanlist)".
Сообщен об ошибке — % FW-3-RESPONDER_WND_SCALE_INI_NO_SCALE: отбрасывание пакета — недопустимая настройка масштаба окна для сеанса x.x.x.x:27331 – x.x.x.x:23 [Инициатор (флаг 0, коэффициент 0). Респондент (флаг 1, коэффициент 2)]
Проблема
Эта ошибка возникает при попытке использования telnet из устройства на дальнем конце VPN-туннеля или из самого маршрутизатора:
Сообщен об ошибке — % FW-3-RESPONDER_WND_SCALE_INI_NO_SCALE: отбрасывание пакета — недопустимая настройка масштаба окна для сеанса x.x.x.x:27331 – x.x.x.x:23 [Инициатор (флаг 0, коэффициент 0). Респондент (флаг 1, коэффициент 2)]
Решение
При необходимости лицензия пользователя может включать 50, 100 или неограниченное количество пользователей. Масштабирование окна было добавлено, чтобы разрешить быструю передачу данных в протяженных сетях с высокой пропускной способностью (LFN). Как правило, это соединения с очень высокой пропускной способностью, но также и с большой задержкой. Сети со спутниковыми соединениями — один из примеров LFN, так как спутниковые соединения всегда имеют высокие значения задержки распространения, но, как правило, обладают высокой пропускной способностью. Чтобы включить масштабирование окна для поддержки сетей LFN, размер окна TCP должен быть больше 65 535. Это сообщение об ошибке можно устранить, увеличив размер окна TCP, чтобы оно было больше 65 535.
%ASA-5-305013: Асимметричные правила NAT совпадают для прямой и обратной передачи. Обновите последовательности этой проблемы
Проблема
Это сообщение об ошибке появляется при активации VPN-туннеля:
%ASA-5-305013: Асимметричные правила NAT совпадают для прямой и обратной передачи. Обновите последовательности этой проблемы
Решение
Чтобы решить данную проблему, если интерфейс не относится к хосту, использующему NAT, для подключения к хосту используйте сопоставленный адрес вместо фактического адреса. Кроме того, включите команду inspect, если приложение включает IP-адрес.
%PIX|ASA-5-713068: получено нестандартное уведомление: notify_type
Проблема
Если не удается активировать VPN-туннель, появляется это сообщение об ошибке:
%PIX|ASA-5-713068: получено нестандартное уведомление: notify_type
Решение
Это сообщение появляется из-за неверной конфигурации (т. е. когда политики или списки контроля доступа по-разному настроены на равноправных узлах). Когда политики и списки контроля доступа совпадают, туннель активируется без проблем.
%ASA-5-720012: (Вторичный VPN) Не удалось обновить данные времени выполнения аварийного переключения IPSec на резервном модуле (или) %ASA-6-720012: (VPN-модуль) не удалось обновить данные времени выполнения аварийного переключения IPSec на резервном модуле
Проблема
При попытке обновления многофункционального устройства защиты Cisco (ASA) появляется одно из этих сообщений об ошибке:
%ASA-5-720012: (Вторичный VPN) Не удалось обновить данные времени выполнения аварийного переключения IPSec на резервном модуле.
%ASA-6-720012: (VPN-модуль) не удалось обновить данные времени выполнения аварийного переключения IPSec на резервном модуле.
Решение
Эти сообщения об ошибках носят информативный характер. Они не влияют на функциональность ASA или VPN.
Эти сообщения появляются, когда подсистеме аварийного переключения VPN не удается обновить связанные с IPSec данные времени выполнения из-за того, что соответствующий туннель IPSec был удален на резервном модуле. Для устранения этих ошибок выполните команду wr standby на активном модуле.
Были зарегистрированы две ошибки, чтобы устранить это поведение и выполнить обновление до версии программного обеспечения ASA, в которой эти ошибки исправлены. См. идентификаторы ошибок Cisco CSCtj58420 (только для зарегистрированных заказчиков) и CSCtn56517 (только для зарегистрированных заказчиков) для получения дополнительной информации.
Ошибка:- %ASA-3-713063: Адрес равноправного узла IKE не настроен для узла назначения 0.0.0.0
Проблема
Появляется сообщение об ошибке %ASA-3-713063: Адрес равноправного узла IKE не настроен для узла назначения 0.0.0.0, и туннель не создается.
Решение
Это сообщение появляется, если адрес равноправного узла IKE не настроен для туннеля L2L. Эта ошибку можно устранить, изменив порядковый номер криптокарты, а затем удалив и повторно применив криптокарту.
Ошибка: %ASA-3-752006: Диспетчеру туннелей не удалось отправить сообщение KEY_ACQUIRE.
Проблема
Сообщение об ошибке %ASA-3-752006: «Tunnel Manager не удалось отправить сообщение KEY_ACQUIRE. Возможна ошибка конфигурации криптокарты или туннельной группы» регистрируется на устройстве Cisco ASA.
Решение
Это сообщение об ошибке может быть вызвано неверной конфигурацией криптокарты или туннельной группы. Убедитесь в том, что они оба настроены должным образом. Дополнительную информацию об этом сообщении об ошибке см. в разделе Ошибка 752006.
Вот некоторые корректирующие действия:
-
Удалите крипто-списки контроля доступа (например, привязанные к динамической схеме).
-
Удалите неиспользованную связанную конфигурацию IKEv2, если такая есть.
-
Проверьте надлежащее соответствие крипто-списка контроля доступа.
-
Удалите двойные записи в списке доступа, если таковые имеются.
Ошибка: %ASA-4-402116: IPSEC: Получен пакет ESP (SPI = 0x99554D4E, порядковый номер = 0x9E) от XX.XX.XX.XX (пользователь = XX.XX.XX.XX) для YY.YY.YY.YY
При настройке туннеля VPN между локальными сетями на одном конечном ASA получено это сообщение об ошибке:
Декапсулированный внутренний пакет не соответствует согласованной политике в SA.
Пакет указывает свое место назначение как 10.32.77.67, свой источник как 10.105.30.1 и свой протокол как ICMP.
SA указывает свой локальный прокси-сервер как 10.32.77.67/255.255.255.255/ip/0 и свой удаленный прокси-сервер как 10.105.42.192/255.255.255.224/ip/0.
Решение
Необходимо проверить списки доступа содержательного трафика, определенные на обоих концах VPN-туннеля. Они оба должны совпасть как точные зеркальные образы.
Из-за ошибки 0xffffffff не удалось запустить 64-разрядный установщик VA для включения виртуального адаптера
Проблема
Сообщение журнала Не удалось запустить установщик 64-разрядного VA для включения виртуального адаптера, ошибка 0xffffffff появляется, если AnyConnect не удается установить соединение.
Решение
Для устранения указанной неполадки выполните следующие действия:
-
Перейдите в меню System > Internet Communication Management > Internet Communication settings (Система > Управление интернет-соединениями > Параметры интернет-соединений) и убедитесь, что опция Turn Off Automatic Root Certificates Update (Выключить автоматическое обновление корневых сертификатов) отключена.
-
Если она отключена, целиком отключите часть Административный шаблон в GPO, назначенном для проблемной машины, и повторите проверку.
Ошибка 5: Отсутствует имя хоста для этого подключения. Невозможно установить VPN-подключение.
Проблема
Сообщение об ошибке Ошибка 5: отсутствует имя хоста для этого подключения. Невозможно установить VPN-подключение. получено во время установки нового ПК.
Решение
Эта проблема связана с идентификатором ошибки Cisco CSCso94244 (только для зарегистрированных заказчиков). Для получения дополнительных сведений обратитесь к документации по данной ошибке.
Cisco VPN Client не работает с картой данных в Windows 7
Проблема
Cisco VPN Client не работает с картой данных в Windows 7.
Решение
ПО Cisco VPN Client, установленное в Windows 7, не работает с соединениями 3G, так как карты данных не поддерживаются VPN-клиентами, установленными на компьютерах под управлением Windows 7.
Предупреждающее сообщение: «Функциональные возможности VPN вообще не работают»
Проблема
При попытке включить isakmp на внешнем интерфейсе ASA получено это предупреждающее сообщение:
ASA(config)# crypto isakmp enable outside WARNING, system is running low on memory. Performance may start to degrade. VPN functionality may not work at all.
На этом этапе обратитесь к ASA посредством ssh. Протокол HTTPS остановлен. Также затронуты другие клиенты SSL.
Решение
Эта проблема возникает из-за требований к памяти со стороны разных модулей, таких как регистратор и крипто-модуль. Удостоверьтесь, что отсутствует команда logging queue 0. Она задает размер очереди равным 8192, и распределение памяти быстро увеличивается.
На платформах, таких как ASA5505 и ASA5510, такое распределение памяти ведет к тому, что другие модули (IKE и т. д.) испытывают недостаток памяти. Зарегистрирован идентификатор ошибки Cisco CSCtb58989 (зарегистрированные заказчики) для устранения подобного поведения. Чтобы устранить эту неполадку, настройте для очереди журналов меньшее значение, например 512.
Ошибка заполнения IPSec
Проблема
Получено следующее сообщение об ошибке:
%PIX|ASA-3-402130: CRYPTO: Received an ESP packet (SPI = 0xXXXXXXX, sequence number= 0xXXXX) from x.x.x.x (user= user) to y.y.y.y with incorrect IPsec padding
Решение
Данная проблема возникает из-за того, что IPSEC VPN выполняет согласование без алгоритма хеширования. Хеширование пакетов гарантирует проверку целостности для канала ESP. Поэтому без хеширования Cisco ASA при приеме не обнаруживает неправильно сформированные пакеты и пытается их дешифровать. Однако, так как эти пакеты неправильно сформированы, ASA находит дефекты при дешифровании пакета. Это вызывает отображений сообщений об ошибках заполнения.
Рекомендуется включать алгоритм хэширования в набор преобразований для VPN и убедиться в том, что в канале между равноправными узлами минимальный уровень неправильно сформированных пакетов.
Время задержки с тишиной в эфире на телефонах удаленного сайта
Проблема
На телефонах удаленного сайта возникает время задержки с тишиной в эфире. Как устранить эту проблему?
Решение
Чтобы решить данную проблему, отключите облегченную проверку и проверку SIP:
asa(config)# no inspect sip asa(config)# no inspect skinny
Каждые 18 часов VPN-туннель разъединяется
Проблема
Каждые 18 часов VPN-туннель разъединяется несмотря на то, что задано время существования 24 часа.
Решение
Это максимальное время существования, которое SA может использовать для смены ключа. Введенное в конфигурации значение времени существования отличается от времени смены ключа в SA. Поэтому необходимо согласовать новое SA (или пару SA в случае IPSec), прежде чем истечет текущее. Время смены ключа всегда должно быть меньше времени существования, чтобы разрешить несколько попыток в случае неудачной первой попытки смены ключа. В RFC не указан способ вычисления времени смены ключа. Это остается на усмотрение разработчиков. Поэтому значение времени будет зависеть от используемой платформы, версии программного обеспечения и т. д.
В некоторых реализациях для вычисления таймера смены ключа может использоваться случайный фактор. Например, если ASA инициирует туннель, то обычно смена ключа выполняется через 64800 секунд = 75 % от 86400. Если инициирует маршрутизатор, ASA может ждать дольше, чтобы дать равноправному узлу больше времени для инициирования смены ключа. Таким образом это нормально, когда VPN-сеанс разъединяется каждые 18 часов, чтобы использовать другой ключ для согласования VPN. Это не должно вызывать сброс VPN или другую проблему.
После повторного согласования туннеля между локальными сетями не поддерживается поток трафика
Проблема
После повторного согласования туннеля между локальными сетями не поддерживается поток трафика.
Решение
ASA отслеживает каждое проходящее через него соединение и поддерживает запись в своей таблице состояний согласно функции проверки приложений. Сведения о зашифрованном трафике, которые проходят через VPN, поддерживаются в форме базы данных сопоставлений безопасности (SA). Для VPN-соединений между локальными сетями поддерживаются два разных потока трафика. Первый — зашифрованный трафик между VPN-шлюзами. Второй — поток трафика между сетевым ресурсом за VPN-шлюзом и конечным пользователем за другим оконечным узлом. После завершения VPN сведения о потоке для данного конкретного SA удаляются. Однако запись в таблице состояний, сохраненная устройством ASA для этого TCP-соединение, становится устаревшей из-за бездействия, что затрудняет загрузку. Это означает, что ASA сохраняет TCP-соединение для данного конкретного потока, а пользовательское приложение его завершает. Однако такие TCP-соединения станут паразитными и, в конечном счете, завершатся после истечения времени ожидания простоя TCP.
Эта проблема была решена путем введения функции под названием постоянные туннелированные потоки IPSec. Новая команда, sysopt connection preserve-vpn-flows, включена в Cisco ASA для сохранения информации о таблице состояний при повторном согласовании VPN-туннеля. По умолчанию эта команда отключена. После ее включения Cisco ASA будет поддерживать сведения о таблице состояний TCP в случае восстановления прерванного VPN-соединения L2L и повторного установления туннеля.
В сообщении об ошибке указано, что для функций шифрования достигнута максимальная пропускная способность
Проблема
Это сообщение об ошибке возникает в маршрутизаторе серии 2900:
Ошибка: мар 20 10:51:29: %CERM-4-TX_BW_LIMIT: для функций шифрования с лицензией технологического пакета securityk9 достигнута максимальная пропускная способность приема 85000 Кбит/с.
Решение
Это известная проблема, которая возникает из-за строгих указаний правительства США. В соответствии с ними лицензия securityk9 допускает шифрование полезной нагрузки со скоростью до 90 Мбит/с и ограничивает количество зашифрованных сеансов туннелей/TLS для устройства. Дополнительную информацию об ограничениях экспорта криптографических технологий см. в разделе Cisco ISR G2: лицензирование SEC и HSEC.
В случае устройств Cisco это ограничение не превышает 85 Мбит/с для входящего и исходящего однонаправленного трафика маршрутизатора ISR G2. Для двунаправленного трафика в сумме это составляет 170 Мбит/с. Это требование применяется к платформам Cisco ISR G2 1900, 2900 и 3900. Эта команда позволяет просмотреть данные ограничения:
Router#show platform cerm-information Crypto Export Restrictions Manager(CERM) Information: CERM functionality: ENABLED ---------------------------------------------------------------- Resource Maximum Limit Available ---------------------------------------------------------------- Tx Bandwidth(in kbps) 85000 85000 Rx Bandwidth(in kbps) 85000 85000 Number of tunnels 225 225 Number of TLS sessions 1000 1000 ---Output truncated----
В целях устранения такого поведению зарегистрирована ошибка. См. идентификатор ошибки Cisco CSCtu24534 (только зарегистрированные заказчики) для получения дополнительной информации.
Чтобы избежать возникновения этой проблемы, необходимо купить лицензию HSECK9. Лицензия «hseck9» для активации функций предоставляет улучшенные функциональные возможности шифрования полезной нагрузки с увеличенным количеством VPN-туннелей и безопасными голосовыми сеансами. Дополнительную информацию о лицензировании маршрутизатора Cisco ISR см. в разделе Активация ПО.
Проблема: Возможен отказ исходящего трафика шифрования в Туннеле IPSec, даже если входящий трафик расшифровки работает.
Решение
Эта проблема была замечена в соединении IPSec после многократной смены ключа, но более точное условие ее возникновения не ясно. Наличие этой проблемы можно выявить, проверив выходные данные команды show asp drop и убедившись, что значение счетчика контекста VPN с истекшим сроком действия увеличивается для каждого отправленного исходящего пакета. См. идентификатор ошибки Cisco CSCtd36473 (только зарегистрированные заказчики) для получения дополнительной информации.
Прочее
В выходных данных команд «show crypto isakmp sa» и «debug» появляется сообщение AG_INIT_EXCH
Если туннель не инициируется, сообщение AG_INIT_EXCH появляется в выходных данных команды show crypto isakmp sa и команды debug. Возможная причина: несоответствие политик ISAKMP или на пути туннеля заблокирован UDP-порт 500.
Появляется сообщение отладки «В недопустимом состоянии получено сообщение IPC»
Это информационное сообщение, которое не имеет никакого отношения к разъединению VPN-туннеля.
Дополнительные сведения
- Проблема PIX/ASA 7.0: Превышено допустимое значение MSS — HTTP-клиенты не могут просматривать определенные веб-узлы
- PIX/ASA 7.x и IOS: Фрагментация VPN
- Устройства обеспечения безопасности Cisco ASA серии 5500
- Cisco PIX 500 Series Security Appliances
- IPSec Negotiation/IKE
- Cisco VPN 3000 Series Concentrators
- Cisco Systems – техническая поддержка и документация
Обратная связь