Я подрядчик по разработке программного обеспечения, и мне предоставили Cisco VPN-доступ к сети заказчика. Это типичная настройка с использованием программного токена RSA SecureID, и я могу успешно подключиться через VPN-клиент (v 5.0.07.0440), когда я запускаю его в экземпляре VirtualBox (Win 7) на моей рабочей станции разработки.
Однако, когда я запускаю VPN-клиент непосредственно на самой ОС рабочей станции разработки (также Win 7), он дает сбой и дает мне ошибку аутентификации 413. Эта ошибка обычно связана с введением неверных учетных данных и каждой справкой по устранению неполадок, которую я ' ve found указывает на то, что ошибка пользователя является единственной возможной причиной.
Тем не менее, я уверен, что проблема здесь не в этом, поскольку я могу легко доказать себе, когда использую VPN-клиент на виртуальной машине и ничего не меняю. Я не понимаю, в чем разница между этими двумя средами. Любое руководство будет оценено.
Далее следует журнал от VPN-клиента. (Я отредактировал определенные значения сервера и IP и заменил их на {text}.)
Cisco Systems VPN Client Version 5.0.07.0440
Copyright (C) 1998-2010 Cisco Systems, Inc. All Rights Reserved.
Client Type(s): Windows, WinNT
Running on: 6.1.7601 Service Pack 1
1 15:54:10.121 01/24/14 Sev=Info/4 CM/0x63100002
Begin connection process
2 15:54:10.132 01/24/14 Sev=Info/4 CM/0x63100004
Establish secure connection
3 15:54:10.132 01/24/14 Sev=Info/4 CM/0x63100024
Attempt connection with server "{server name}"
4 15:54:10.139 01/24/14 Sev=Info/6 IKE/0x6300003B
Attempting to establish a connection with {IP}.
5 15:54:10.144 01/24/14 Sev=Info/4 IKE/0x63000001
Starting IKE Phase 1 Negotiation
6 15:54:10.284 01/24/14 Sev=Info/6 GUI/0x63B00012
Authentication request attributes is 102h.
7 15:54:10.149 01/24/14 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID(Xauth), VID(dpd), VID(Frag), VID(Nat-T), VID(Unity)) to {IP}
8 15:54:10.155 01/24/14 Sev=Info/4 IPSEC/0x63700008
IPSec driver successfully started
9 15:54:10.155 01/24/14 Sev=Info/4 IPSEC/0x63700014
Deleted all keys
10 15:54:10.207 01/24/14 Sev=Info/5 IKE/0x6300002F
Received ISAKMP packet: peer = {IP}
11 15:54:10.207 01/24/14 Sev=Info/4 IKE/0x63000014
RECEIVING <<< ISAKMP OAK AG (SA, KE, NON, ID, HASH, VID(Unity), VID(Xauth), VID(dpd), VID(Nat-T), NAT-D, NAT-D, VID(Frag), VID(?)) from {IP}
12 15:54:10.207 01/24/14 Sev=Info/5 IKE/0x63000001
Peer is a Cisco-Unity compliant peer
13 15:54:10.207 01/24/14 Sev=Info/5 IKE/0x63000001
Peer supports XAUTH
14 15:54:10.207 01/24/14 Sev=Info/5 IKE/0x63000001
Peer supports DPD
15 15:54:10.207 01/24/14 Sev=Info/5 IKE/0x63000001
Peer supports NAT-T
16 15:54:10.207 01/24/14 Sev=Info/5 IKE/0x63000001
Peer supports IKE fragmentation payloads
17 15:54:10.212 01/24/14 Sev=Info/6 IKE/0x63000001
IOS Vendor ID Contruction successful
18 15:54:10.212 01/24/14 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK AG *(HASH, NOTIFY:STATUS_INITIAL_CONTACT, NAT-D, NAT-D, VID(?), VID(Unity)) to {IP}
19 15:54:10.213 01/24/14 Sev=Info/6 IKE/0x63000055
Sent a keepalive on the IPSec SA
20 15:54:10.213 01/24/14 Sev=Info/4 IKE/0x63000083
IKE Port in use - Local Port = {port}, Remote Port = {port}
21 15:54:10.213 01/24/14 Sev=Info/5 IKE/0x63000072
Automatic NAT Detection Status:
Remote end is NOT behind a NAT device
This end IS behind a NAT device
22 15:54:10.213 01/24/14 Sev=Info/4 CM/0x6310000E
Established Phase 1 SA. 1 Crypto Active IKE SA, 0 User Authenticated IKE SA in the system
23 15:54:10.272 01/24/14 Sev=Info/5 IKE/0x6300002F
Received ISAKMP packet: peer = {IP}
24 15:54:10.273 01/24/14 Sev=Info/4 IKE/0x63000014
RECEIVING <<< ISAKMP OAK TRANS *(HASH, ATTR) from {IP}
25 15:54:10.273 01/24/14 Sev=Info/4 CM/0x63100015
Launch xAuth application
26 15:54:20.310 01/24/14 Sev=Info/6 IKE/0x63000055
Sent a keepalive on the IPSec SA
27 15:54:28.172 01/24/14 Sev=Info/4 CM/0x63100017
xAuth application returned
28 15:54:28.172 01/24/14 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK TRANS *(HASH, ATTR) to {IP}
29 15:54:30.396 01/24/14 Sev=Info/5 IKE/0x6300002F
Received ISAKMP packet: peer = {IP}
30 15:54:30.397 01/24/14 Sev=Info/4 IKE/0x63000014
RECEIVING <<< ISAKMP OAK TRANS *(HASH, ATTR) from {IP}
31 15:54:30.397 01/24/14 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK TRANS *(HASH, ATTR) to {IP}
32 15:54:30.397 01/24/14 Sev=Info/4 IKE/0x63000017
Marking IKE SA for deletion (I_Cookie={cookie} R_Cookie={cookie}) reason = DEL_REASON_WE_FAILED_AUTH
33 15:54:30.398 01/24/14 Sev=Info/4 IKE/0x63000013
SENDING >>> ISAKMP OAK INFO *(HASH, DEL) to {IP}
34 15:54:30.453 01/24/14 Sev=Info/5 IKE/0x6300002F
Received ISAKMP packet: peer = {IP}
35 15:54:30.454 01/24/14 Sev=Info/4 IKE/0x63000058
Received an ISAKMP message for a non-active SA, I_Cookie={Cookie} R_Cookie={Cookie}
36 15:54:30.454 01/24/14 Sev=Info/4 IKE/0x63000014
RECEIVING <<< ISAKMP OAK INFO *(Dropped) from {IP}
37 15:54:30.965 01/24/14 Sev=Info/4 IKE/0x6300004B
Discarding IKE SA negotiation (I_Cookie={Cookie} R_Cookie={Cookie}) reason = DEL_REASON_WE_FAILED_AUTH
38 15:54:30.965 01/24/14 Sev=Info/4 CM/0x63100014
Unable to establish Phase 1 SA with server "{server}" because of "DEL_REASON_WE_FAILED_AUTH"
39 15:54:30.965 01/24/14 Sev=Info/5 CM/0x63100025
Initializing CVPNDrv
40 15:54:30.979 01/24/14 Sev=Info/6 CM/0x63100046
Set tunnel established flag in registry to 0.
41 15:54:30.979 01/24/14 Sev=Info/4 IKE/0x63000001
IKE received signal to terminate VPN connection
42 15:54:30.987 01/24/14 Sev=Info/4 IPSEC/0x63700014
Deleted all keys
43 15:54:30.987 01/24/14 Sev=Info/4 IPSEC/0x63700014
Deleted all keys
44 15:54:30.987 01/24/14 Sev=Info/4 IPSEC/0x63700014
Deleted all keys
45 15:54:30.987 01/24/14 Sev=Info/4 IPSEC/0x6370000A
IPSec driver successfully stopped
Мне сложно понять проблему без вывода Cisco «router # debug crypto ipsec on». Однако, если аутентификация осуществляется через сертификаты SSL (режим RSA), вы можете в конечном итоге обратиться к http://vouters.dyndns.org/tima/Linux-Windows-Cisco-VPN-Cisco_may_abort_when_attempting_to_establish_a_VPN.html В этом документе описываются две проблемы между некоторыми клиентами VPN и Cisco IOS. Первый - это проблема с отсутствующим отправленным эмитентом (информация находится в сертификате SSL). Последний описывает проблему обмена полезной нагрузкой NAT-T.
В противном случае для работы с конфигурациями Cisco IOS вы можете запросить поисковую систему по адресу http://vouters.dyndns.org/ с ключевым словом "Cisco"
Надеюсь, это поможет вам. С уважением, Филипп
Это может быть снимок в темноте, но пробовали ли вы Обновление DNE (Deterministic Network Enhancer) из Citrix? В прошлом у меня было волшебное решение проблем с устаревшим клиентом Cisco VPN. Очевидно, что при новой установке Win7 в этом нет необходимости. Но если это более старая, более грубая установка, в которой, возможно, было несколько клиентов VPN, установленных за время ее существования, которые возились с сетевым стеком, похоже, что она настраивает вещи и снова делает их счастливыми. Это также один из ключей к тому, чтобы старый клиент работал в Windows 8 и более поздних версиях. С сайта:
Citrix поставляет программное обеспечение ряду компаний, производящих программное обеспечение и оборудование. Когда они устанавливают свои продукты в ваших системах, они часто содержат DNE.
DNE расширяет операционные системы и устройства и стеки сетевых протоколов, чтобы ввести измерения и средства управления. Наши клиенты используют эти расширения для создания продуктов, которые выполняют такие функции, как обнаружение вторжений, VPN, преобразование сетевых адресов (NAT), измерение трафика, измерение времени отклика, управление полосой пропускания, сжатие, фильтрация контента, защита контента, управление политиками, прокси, биллинг, пакет маркировка, маршрутизация, трансляция протоколов, беспроводная связь, безопасные туннели и многое другое.
Если хотите попробовать, сделайте следующее:
Я наконец решил свою проблему, и это оказалось моей собственной ошибкой пользователя! Я публикую это, чтобы не смущать будущих пользователей:
После того, как я установил программное обеспечение RSA SecureID на свою ОС хоста и перезагрузился, VPN-клиент начал ожидать моего ПИН-кода RSA, а не постоянно меняющихся паролей RSA, к которым я привык. Такое поведение было для меня в новинку, и я продолжал вводить коды доступа вместо ПИН-кода. (Я не заметил изменения в запросе аутентификации VPN-клиента с «пароля» на «PIN».) Как только я наконец поумнел и начал вводить PIN-код, все заработало нормально.
(На виртуальной машине не было установлено приложение RSA, поэтому оно отлично работало с паролями.)