Download PC Repair Tool to quickly find & fix Windows errors automatically
A virtual private network (VPN) is mostly used to protect a user’s privacy in the online world and skit their physical location. While most of the time these perform well, there are some occasions when the user can encounter errors, crashes, or different connection issues with their VPN program. When your VPN is not working, not connecting, or has been blocked, there are some quick fixes you can try to get it solved. Though there are many possible errors that a user can encounter with VPNs, there are a few who gain more eminence than others; one such error code is VPN Error 13801, IKE authentication credentials are unacceptable
Fix VPN Error 13801 on Windows 11/10
This Internet Key Exchange version 2 (IKEv2) error are related to problems with the server authentication certificate. Basically, the machine certificate required for authentication is either invalid or doesn’t exist on your client’s computer, on the server, or both.
Here’s a quick breakup of the possible causes of Error 13801:
- The machine certificate on the RAS server has expired
- The trusted root certificate to validate the RAS server certificate is absent on the client
- VPN server name as given on the client doesn’t match the subject name of the server certificate
- The machine certificate used for IKEv2 validation on RAS Server does not have “Server Authentication” as the EKU (Enhanced Key Usage).
Since the users do not have any control over the server, there’s very little that can be done to fix this issue. And in most cases, the user might have to the VPN provider’s help desk and get them to repair the error 13801.
VPN error 13801 clearly references the protocols being used by the VPN service, so you don’t have to waste time figuring out what IKEv2 for VPN error 1380 is. Look for the correct IKEv2 certificate in the documentation provided by the VPN admin. There are a few ways in which you can confirm this issue:
- The certificate does not have the required Enhanced Key Usage (EKU) values assigned
- The machine certificate on the RAS server has expired.
- The trusted root for the certificate is not present on the client.
- The subject name of the certificate does not match the remote computer
Let’s look at these options in detail:
The certificate does not have the required Enhanced Key Usage (EKU) values assigned
You can check it by the following steps:
1] On the VPN server, run mmc, add snap-in ‘certificates.’
2] Expand certificates-personal-certificates, double click the certificate installed
3] Click detail for ‘enhanced key usage’, verify if there is ‘server authentication’ below
The machine certificate on the RAS server has expired.
If the issue is caused by this reason, connect the CA administrator and enroll a new certificate that doesn’t expire.
The trusted root for the certificate is not present on the client.
If the client and server are domain members, the root certificate will be installed automatically in ‘trusted root certification authorities.’ You can check if the certificate is present on the client here.
Related errors:
- VPN Error 789, The L2TP connection attempt failed
- VPN error 812, Connection prevented because of a policy configured on RAS/VPN server
- VPN Error 720, Error connecting to a VPN Connection
- VPN Error 868, Name of the Remote Access Server did not resolve
- VPN Error 809, Network connection between your computer and the VPN server could not be established.
The subject name of the certificate does not match the remote computer
You can verify using the below steps:
1] On the client, open ‘VPN connection properties’, click ‘General.’
2] In ‘host name or IP address of destination’ you will need to enter the ‘subject name’ of the certificate used by the VPN server instead of the IP address of the VPN server.
Note: The subject name of the server’s certificate is usually configured as the FQDN of the VPN server.
When to call your VPN Server administrator
Having to deal with VPN errors can be extremely frustrating, and when you cannot troubleshoot them independently, the frustration is even more. That’s exactly the case with VPN Error 13801, so waste no time and contact your VPN administrator to make sure the correct certificate is configured on your PC, which is validated by the remote server.
Ankit Gupta is a writer by profession and has more than 7 years of global writing experience on technology and other areas. He follows technological developments and likes to write about Windows & IT security. He has a deep liking for wild life and has written a book on Top Tiger Parks of India.
Download PC Repair Tool to quickly find & fix Windows errors automatically
A virtual private network (VPN) is mostly used to protect a user’s privacy in the online world and skit their physical location. While most of the time these perform well, there are some occasions when the user can encounter errors, crashes, or different connection issues with their VPN program. When your VPN is not working, not connecting, or has been blocked, there are some quick fixes you can try to get it solved. Though there are many possible errors that a user can encounter with VPNs, there are a few who gain more eminence than others; one such error code is VPN Error 13801, IKE authentication credentials are unacceptable
Fix VPN Error 13801 on Windows 11/10
This Internet Key Exchange version 2 (IKEv2) error are related to problems with the server authentication certificate. Basically, the machine certificate required for authentication is either invalid or doesn’t exist on your client’s computer, on the server, or both.
Here’s a quick breakup of the possible causes of Error 13801:
- The machine certificate on the RAS server has expired
- The trusted root certificate to validate the RAS server certificate is absent on the client
- VPN server name as given on the client doesn’t match the subject name of the server certificate
- The machine certificate used for IKEv2 validation on RAS Server does not have “Server Authentication” as the EKU (Enhanced Key Usage).
Since the users do not have any control over the server, there’s very little that can be done to fix this issue. And in most cases, the user might have to the VPN provider’s help desk and get them to repair the error 13801.
VPN error 13801 clearly references the protocols being used by the VPN service, so you don’t have to waste time figuring out what IKEv2 for VPN error 1380 is. Look for the correct IKEv2 certificate in the documentation provided by the VPN admin. There are a few ways in which you can confirm this issue:
- The certificate does not have the required Enhanced Key Usage (EKU) values assigned
- The machine certificate on the RAS server has expired.
- The trusted root for the certificate is not present on the client.
- The subject name of the certificate does not match the remote computer
Let’s look at these options in detail:
The certificate does not have the required Enhanced Key Usage (EKU) values assigned
You can check it by the following steps:
1] On the VPN server, run mmc, add snap-in ‘certificates.’
2] Expand certificates-personal-certificates, double click the certificate installed
3] Click detail for ‘enhanced key usage’, verify if there is ‘server authentication’ below
The machine certificate on the RAS server has expired.
If the issue is caused by this reason, connect the CA administrator and enroll a new certificate that doesn’t expire.
The trusted root for the certificate is not present on the client.
If the client and server are domain members, the root certificate will be installed automatically in ‘trusted root certification authorities.’ You can check if the certificate is present on the client here.
Related errors:
- VPN Error 789, The L2TP connection attempt failed
- VPN error 812, Connection prevented because of a policy configured on RAS/VPN server
- VPN Error 720, Error connecting to a VPN Connection
- VPN Error 868, Name of the Remote Access Server did not resolve
- VPN Error 809, Network connection between your computer and the VPN server could not be established.
The subject name of the certificate does not match the remote computer
You can verify using the below steps:
1] On the client, open ‘VPN connection properties’, click ‘General.’
2] In ‘host name or IP address of destination’ you will need to enter the ‘subject name’ of the certificate used by the VPN server instead of the IP address of the VPN server.
Note: The subject name of the server’s certificate is usually configured as the FQDN of the VPN server.
When to call your VPN Server administrator
Having to deal with VPN errors can be extremely frustrating, and when you cannot troubleshoot them independently, the frustration is even more. That’s exactly the case with VPN Error 13801, so waste no time and contact your VPN administrator to make sure the correct certificate is configured on your PC, which is validated by the remote server.
Ankit Gupta is a writer by profession and has more than 7 years of global writing experience on technology and other areas. He follows technological developments and likes to write about Windows & IT security. He has a deep liking for wild life and has written a book on Top Tiger Parks of India.
Виртуальная частная сеть (VPN) в основном используется для защиты конфиденциальности пользователей в онлайн-мире и определения их физического местоположения. Хотя в большинстве случаев они работают хорошо, в некоторых случаях пользователь может столкнуться с ошибками, сбоями или другими проблемами с подключением в своей программе VPN. Если ваша VPN не работает, не подключается или заблокирована, вы можете попробовать несколько быстрых решений. Хотя существует множество возможных ошибок, с которыми пользователь может столкнуться при использовании VPN, некоторые из них получают большее признание, чем другие; один из таких кодов ошибки Ошибка VPN 13801.
Ошибка VPN 13801 в Windows 10
Ошибка 13801 выражает сообщение — Учетные данные для аутентификации IKE недопустимы.
Эти ошибки Internet Key Exchange версии 2 (IKEv2) связаны с проблемами с сертификатом проверки подлинности сервера. По сути, сертификат компьютера, необходимый для аутентификации, либо недействителен, либо отсутствует на вашем клиентском компьютере, на сервере или на обоих.
Учетные данные для аутентификации IKE недопустимы
Вот краткое описание возможных причин ошибки 13801:
- Срок действия сертификата компьютера на сервере удаленного доступа истек.
- Доверенный корневой сертификат для проверки сертификата сервера удаленного доступа отсутствует на клиенте.
- Имя VPN-сервера, указанное на клиенте, не соответствует имени субъекта сертификата сервера.
- Сертификат компьютера, используемый для проверки IKEv2 на сервере удаленного доступа, не имеет «проверки подлинности сервера» в качестве EKU (расширенного использования ключа).
Поскольку пользователи не имеют никакого контроля над сервером, мало что можно сделать для решения этой проблемы. И в большинстве случаев пользователю, возможно, придется обратиться в службу поддержки провайдера VPN и попросить их исправить ошибку 13801.
Ошибка VPN 13801 явно ссылается на протоколы, используемые службой VPN, поэтому вам не нужно тратить время на выяснение того, что такое IKEv2 для ошибки 1380 VPN. Найдите правильный сертификат IKEv2 в документации, предоставленной администратором VPN. Есть несколько способов подтвердить эту проблему:
- Сертификату не присвоены требуемые значения расширенного использования ключа (EKU).
- Срок действия сертификата компьютера на сервере удаленного доступа истек.
- Доверенный корень сертификата отсутствует на клиенте.
- Имя субъекта сертификата не соответствует удаленному компьютеру
Давайте рассмотрим эти варианты подробнее:
Сертификату не присвоены требуемые значения расширенного использования ключа (EKU).
Вы можете проверить это, выполнив следующие действия:
1]На сервере VPN запустите ммс, добавить оснастку ‘сертификаты. ‘
2]Разверните сертификаты-личные-сертификаты, дважды щелкните установленный сертификат
3]Щелкните подробное описание для «улучшенное использование ключа ‘, проверьте, есть ли ‘проверка подлинности сервера‘ ниже
Срок действия сертификата компьютера на сервере удаленного доступа истек.
Если проблема вызвана этой причиной, подключите Администратор ЦС и зарегистрируйте новый сертификат, срок действия которого не истекает.
Доверенный корень сертификата отсутствует на клиенте.
Если клиент и сервер являются членами домена, корневой сертификат будет автоматически установлен в ‘доверенные корневые центры сертификации.’ Проверить наличие сертификата на клиенте можно здесь.
Имя субъекта сертификата не соответствует удаленному компьютеру
Вы можете подтвердить, используя следующие шаги:
1]На клиенте открыть ‘Свойства VPN-подключения‘, щелкните’Общий. ‘
2]В ‘имя хоста или IP-адрес назначения‘вам нужно будет ввести’имя субъекта‘сертификата, используемого сервером VPN вместо IP-адреса сервера VPN.
Примечание: Имя субъекта сертификата сервера обычно настраивается как полное доменное имя VPN-сервера.
Когда звонить администратору VPN-сервера
Необходимость иметь дело с ошибками VPN может быть чрезвычайно неприятным, а когда вы не можете устранить их самостоятельно, разочарование еще больше. Это именно тот случай с ошибкой VPN 13801, поэтому не теряйте времени и обратитесь к администратору VPN, чтобы убедиться, что на вашем ПК настроен правильный сертификат, который подтвержден удаленным сервером.
Thanks for filing this issue, @b0d8mr4zu.
I don’t think that particular Let’s Encrypt forum thread draws the right conclusion here. The problem is not that strongSwan fails to send the intermediate cert chain (after all, it works just fine with the Mac client, for example).
Instead, the underlying problem seems to be a Windows 10 bug, where certificates are supposed to be lazy-loaded, but rasdial doesn’t lazy load them. See this thread: https://community.letsencrypt.org/t/isrg-root-lazy-loading-problem-missing-from-random-updated-windows-10-versions/141550
The solution that’s suggested does work for now, but may fail in future if and when Let’s Encrypt change their signing setup again.
An alternative solution, at least for new installations, is that we just add the following line to the Windows PowerShell client setup script:
$Response = Invoke-WebRequest -UseBasicParsing -Uri https://valid-isrgrootx1.letsencrypt.org
We can ignore the contents of $Response
, but this simple get request has the side effect of loading the ISRG Root X1 cert into the certificate store (you can see this in certmgr.exe under Third-Party Root Certificate Authorities > Certificates).
And once that’s happened, the VPN will connect without issues once again.
The problem here, of course, is that existing Win 10 VPN client setups will need fixing (e.g. by simply visiting that URL in Edge). So I guess I might also add instructions for the alternative-cert fix to the README and/or setup script output.
@glifed Отдельные машины, по моему мнению, лучше через OpenVPN цеплять. Быстрее работают и быстрее ре-коннект при обрыве связи. Ставишь клиента OpenVPN, сертификат в PF генеришь и на основании него делаешь файл .ovpn, подгружаешь в клиента и в автозагрузку его. При старте win машины он сам автоматом соединяется. У меня так кассы в магазинах работают. А IPSec, опять таки по моему мнению, лучше сети соединять. Так у меня и сделано.
Настройка OpenVPN Win: https://softnastroy.com/content/avtomaticheskiy-zapusk-openvpn-v-windows-ispolzuya-nuzhnyy-vam-konfiguracionnyy-fayl-ovpn.html
Шаблон файла .ovpn, что бы долго не искать и не мучаться:
client
dev tun
proto tcp (у меня tcp у себя можешь и udp сделать, как удобно)
remote (адрес твоего сервера)
port //порт твоего сервера
auth SHA256
cipher AES-256-GCM
keysize 256
resolv-retry infinite
nobind
persist-key
persist-tun
keepalive 10 120
comp-lzo
verb 3
<ca> (сертификат сервера, тот который ca из PF)
——BEGIN CERTIFICATE——
——END CERTIFICATE——
</ca>
<cert> (сертификат клиента из PF)
——BEGIN CERTIFICATE——
——END CERTIFICATE——
</cert>
<key> (ключ клиента из PF)
——BEGIN PRIVATE KEY——
——END PRIVATE KEY——
</key>
Содержание
- Ошибка 13801, учетные данные для аутентификации IKE недопустимы
- Ошибка VPN 13801 в Windows 10
- Учетные данные для аутентификации IKE недопустимы
- Сертификату не присвоены требуемые значения расширенного использования ключа (EKU).
- Срок действия сертификата компьютера на сервере удаленного доступа истек.
- Доверенный корень сертификата отсутствует на клиенте.
- Имя субъекта сертификата не соответствует удаленному компьютеру
- Когда звонить администратору VPN-сервера
- strongSwan IKEv2 + Windows 7 Agile VPN: что вызывает ошибку 13801
- 3 ответа
- Об ошибке
- VPN-подключение IKEv2 завершается неудачей с ошибкой 13806 когда используется сертификат ECDSA в Windows Server 2012 R2 или Windows 8.1
- Симптомы
- Решение
- Сведения об обновлении
- Сведения об исправлении
- Предварительные условия
- Сведения о реестре
- Необходимость перезагрузки
- Сведения о замене исправлений
- Устранение неполадок Always On VPN
- Коды ошибок
- Код ошибки: 800
- Код ошибки: 809
- Код ошибки: 812
- Код ошибки: 13806
- Код ошибки: 13801
- Код ошибки: 0x80070040
- Код ошибки: 0x800B0109
- Журналы
- Журналы приложений
- Журналы NPS
- Проблемы в работе скрипта VPN_Profile.ps1
- Проблемы с подключением клиента Always On VPN
- Проблемы подключения при использовании условного доступа Azure AD
- Ой! вы еще не можете получить доступ к этому
- Не удалось удалить сертификат из колонки VPN-подключения
- Устранение неполадок подключения типа «точка — сеть» Azure
- Ошибка VPN-клиента: не удалось найти сертификат
- Симптом
- Причина
- Решение
- Не удалось установить сетевое подключение между компьютером и VPN-сервером, так как удаленный сервер не отвечает
- Симптом
- Причина
- Решение
- Ошибка VPN-клиента: получено непредвиденное или неправильно отформатированное сообщение
- Симптом
- Причина
- Решение
- Ошибка VPN-клиента: цепочка сертификатов обработана, но обработка прервана
- Симптом
- Решение
- Произошла ошибка скачивания файла. Целевой URI не указан
- Симптом
- Причина
- Решение
- Ошибка VPN-клиента: сбой настраиваемого сценария VPN Azure
- Симптом
- Причина
- Решение
- Не удается установить VPN-клиент
- Причина
- Решение
- Ошибка портала Azure: не удалось сохранить VPN-шлюз, так как данные являются недопустимыми
- Симптом
- Причина
- Решение
- Ошибка портала Azure: не удалось сохранить VPN-шлюз, так как имя ресурса является недопустимым
- Симптом
- Причина
- Ошибка портала Azure: ошибка 503 при скачивании файла пакета VPN
- Симптом
- Решение
- Обновление VPN-шлюза Azure, всем клиентам типа «точка — сеть» не удается подключиться
- Причина
- Решение
- Слишком много одновременно подключенных VPN-клиентов
- VPN-клиент не может получить доступ к сетевым файловым ресурсам
- Симптом
- Причина
- Решение
- Не удается найти VPN-подключение типа «точка — сеть» в Windows после повторной установки VPN-клиента
- Симптом
- Решение
- VPN-клиенту типа «точка — сеть» не удается разрешить полные доменные имена ресурсов в локальном домене
- Симптом
- Причина
- Решение
- VPN-подключение типа «точка — сеть» устанавливается, но по-прежнему не удается подключиться к ресурсам Azure
- Причина
- Решение
- Ошибка: «Функции отзыва не удалось проверить отзыв, так как сервер отзыва был не в сети. (Ошибка 0x80092013.)»
- Причины
- Решение
- Ошибка VPN-клиента: «Подключение не выполнено из-за политики, заданной на сервере службы удаленного доступа/виртуальной частной сети. (Ошибка 812.)»
- Причина
- Решение
- «Ошибка 405» при скачивании корневого сертификата из VPN-шлюза
- Причина
- Ошибка VPN-клиента: «Удаленное подключение не удалось установить из-за сбоя использованных VPN-туннелей. (Ошибка 800.)»
- Причина
- Решение
- Причина
- Решение
- Ошибка: «Произошла ошибка скачивания файла. Целевой URI не указан.»
- Причина
- Решение
- Установщик пакета VPN не завершает установку
- Причина
- Решение
- Через некоторое время VPN-клиент переходит в режим гибернации или спящий режим
- Решение
Ошибка 13801, учетные данные для аутентификации IKE недопустимы
Виртуальная частная сеть (VPN) в основном используется для защиты конфиденциальности пользователей в онлайн-мире и определения их физического местоположения. Хотя в большинстве случаев они работают хорошо, в некоторых случаях пользователь может столкнуться с ошибками, сбоями или другими проблемами с подключением в своей программе VPN. Если ваша VPN не работает, не подключается или заблокирована, вы можете попробовать несколько быстрых решений. Хотя существует множество возможных ошибок, с которыми пользователь может столкнуться при использовании VPN, некоторые из них получают большее признание, чем другие; один из таких кодов ошибки Ошибка VPN 13801.
Ошибка VPN 13801 в Windows 10
Ошибка 13801 выражает сообщение — Учетные данные для аутентификации IKE недопустимы.
Эти ошибки Internet Key Exchange версии 2 (IKEv2) связаны с проблемами с сертификатом проверки подлинности сервера. По сути, сертификат компьютера, необходимый для аутентификации, либо недействителен, либо отсутствует на вашем клиентском компьютере, на сервере или на обоих.
Учетные данные для аутентификации IKE недопустимы
Вот краткое описание возможных причин ошибки 13801:
Поскольку пользователи не имеют никакого контроля над сервером, мало что можно сделать для решения этой проблемы. И в большинстве случаев пользователю, возможно, придется обратиться в службу поддержки провайдера VPN и попросить их исправить ошибку 13801.
Ошибка VPN 13801 явно ссылается на протоколы, используемые службой VPN, поэтому вам не нужно тратить время на выяснение того, что такое IKEv2 для ошибки 1380 VPN. Найдите правильный сертификат IKEv2 в документации, предоставленной администратором VPN. Есть несколько способов подтвердить эту проблему:
Давайте рассмотрим эти варианты подробнее:
Сертификату не присвоены требуемые значения расширенного использования ключа (EKU).
Вы можете проверить это, выполнив следующие действия:
1]На сервере VPN запустите ммс, добавить оснастку ‘сертификаты. ‘
2]Разверните сертификаты-личные-сертификаты, дважды щелкните установленный сертификат
3]Щелкните подробное описание для «улучшенное использование ключа ‘, проверьте, есть ли ‘проверка подлинности сервера‘ ниже
Срок действия сертификата компьютера на сервере удаленного доступа истек.
Если проблема вызвана этой причиной, подключите Администратор ЦС и зарегистрируйте новый сертификат, срок действия которого не истекает.
Доверенный корень сертификата отсутствует на клиенте.
Если клиент и сервер являются членами домена, корневой сертификат будет автоматически установлен в ‘доверенные корневые центры сертификации.’ Проверить наличие сертификата на клиенте можно здесь.
Имя субъекта сертификата не соответствует удаленному компьютеру
Вы можете подтвердить, используя следующие шаги:
1]На клиенте открыть ‘Свойства VPN-подключения‘, щелкните’Общий. ‘
2]В ‘имя хоста или IP-адрес назначения‘вам нужно будет ввести’имя субъекта‘сертификата, используемого сервером VPN вместо IP-адреса сервера VPN.
Примечание: Имя субъекта сертификата сервера обычно настраивается как полное доменное имя VPN-сервера.
Когда звонить администратору VPN-сервера
Необходимость иметь дело с ошибками VPN может быть чрезвычайно неприятным, а когда вы не можете устранить их самостоятельно, разочарование еще больше. Это именно тот случай с ошибкой VPN 13801, поэтому не теряйте времени и обратитесь к администратору VPN, чтобы убедиться, что на вашем ПК настроен правильный сертификат, который подтвержден удаленным сервером.
Источник
strongSwan IKEv2 + Windows 7 Agile VPN: что вызывает ошибку 13801
У меня есть экземпляр AWS, который я хочу быть VPN-сервером. Он подключит клиентов Windows 7 к частной сети в облаке Amazon.
Я добавил сертификат CA, который подписал серверный сертификат сервера в хранилище сертификатов локального компьютера (а не пользователя), чтобы Windows могла аутентифицировать сервер.
В этот момент Windows немедленно выводит сообщение об ошибке:
Через несколько секунд чанов снова попытается закрыть соединение.
Насколько я могу судить, я следую всем инструкциям на сильной вики.
Что я здесь делаю неправильно?
Изменить: это определенно проблема с сертификатами. Я отключил расширенные проверки проверки путем редактирования реестра и перезагрузки, как описано в MSKB926182 (lol, если вы хотите получить ссылку на это), и теперь я могу подключиться к моему VPN-серверу без ошибок. Я выясню, как создавать сертификаты, удовлетворяющие требованиям, и добавлять ответ. Благодаря @ecdsa для указателя на страницу сертификата на вики strongSwan, которая заставила меня указывать в правильном направлении.
3 ответа
Об ошибке
В моем случае моя проблема связана с значениями EKU. Следуя руководству, которое я связал сверху, мне удалось создать сертификат с правильными значениями EKU, и он отлично поработал.
Чтобы устранить эту проблему, вы можете отключить проверку EKU на своем клиенте Windows (конечно, это должно быть сделано только для тестирования):
Источник
VPN-подключение IKEv2 завершается неудачей с ошибкой 13806 когда используется сертификат ECDSA в Windows Server 2012 R2 или Windows 8.1
В данной статье описывается проблема, при algorithmin подписи Windows RT 8.1 Windows 8.1 или Windows Server 2012 R2 с помощью эллиптических кривых цифровой подписи алгоритм ECDSA. Неполадки в 2962409 накопительный пакет обновления или исправление 2961892, описанное в данной статье и необходимых компонентов.
Симптомы
Рассмотрим следующий сценарий:
У центра сертификации (ЦС), соответствует стандартам Suite B (эллиптических кривых), и центр сертификации выдает сертификаты компьютеров для проверки подлинности протокола IP-безопасность (IPsec), используя в качестве алгоритма подписи ECDSA.
У вас есть Windows RT 8.1, Windows 8.1 или компьютерах под управлением Windows Server 2012 R2, запросить сертификат IPSec из центра сертификации.
Настроить Internet Key Exchange версии 2 (IKEv2) VPN на клиентском компьютере.
Включите параметр Разрешить проверку подлинности сертификата компьютера для IKEv2на сервере.
В этом случае при попытке подключения к серверу с использованием VPN IKEv2 с клиентского компьютера, установить подключение не удастся, и появляется следующее сообщение об ошибке:
Решение
Чтобы устранить эту проблему, установите накопительный пакет обновления 2962409 или установить исправление, описанное в данной статье.
Сведения об обновлении
Дополнительные сведения о том, как получить этот накопительный пакет обновления, щелкните следующий номер статьи базы знаний Майкрософт:
Windows RT 8.1, Windows 8.1 и Windows Server 2012 R2 накопительный пакет обновления: Июнь 2014 г
Сведения об исправлении
Существует исправление от корпорации Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте данное исправление только в тех системах, которые имеют данную проблему.
Если исправление доступно для скачивания, имеется раздел «Пакет исправлений доступен для скачивания» в верхней части этой статьи базы знаний. Если этого раздела нет, отправьте запрос в службу технической поддержки для получения исправления.
Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание посетите следующий веб-узел корпорации Майкрософт:
Примечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.
Предварительные условия
Это исправление необходимо сначала установить обновление 2919355 Windows RT 8.1, Windows 8.1 или Windows Server 2012 R2. Для получения дополнительных сведений щелкните следующий номер статьи базы знаний Майкрософт:
Windows RT 8.1, Windows 8.1 и Windows Server 2012 R2 накопительный пакет обновления: Июнь 2014 г
Сведения о реестре
Для использования исправления из этого пакета нет необходимости вносить изменения в реестр.
Необходимость перезагрузки
После установки исправления компьютер необходимо перезагрузить.
Сведения о замене исправлений
Это исправление не заменяет ранее выпущенные исправления.
Источник
Устранение неполадок Always On VPN
применимо к: Windows server 2022, Windows server 2019, Windows Server 2016, Windows Server 2012 R2, Windows 10
Если Always On установки VPN не удается подключить клиентов к внутренней сети, причиной является недопустимый сертификат VPN, неправильные политики NPS или проблемы с сценариями развертывания клиента или маршрутизацией и удаленным доступом. Первым шагом в устранении неполадок и тестировании VPN-подключения является понимание основных компонентов инфраструктуры VPN Always On.
Устранить проблемы с подключением можно несколькими способами. Для проблем на стороне клиента и общего устранения неполадок приложение регистрируется на клиентских компьютерах. Для проблем, связанных с проверкой подлинности, журнал NPS на сервере NPS может помочь определить источник проблемы.
Коды ошибок
Код ошибки: 800
Описание ошибки. «Удаленное подключение не удалось установить из-за сбоя использованных VPN-туннелей. VPN-сервер может быть недоступен. Если это подключение пытается использовать туннель L2TP/IPsec, параметры безопасности, необходимые для согласования IPsec, могут быть настроены неправильно.
Возможная причина. Эта ошибка возникает, если VPN-туннель имеет тип Авто и попытка подключения завершается неудачно для всех VPN-туннелей.
Возможные решения:
Если вы понимаете, какой туннель использовать для развертывания, задайте тип VPN на стороне VPN-клиента для этого типа туннеля.
При установлении VPN-подключения с определенным типом туннеля подключение по-прежнему будет завершаться сбоем, но это приведет к появлению дополнительной ошибки, относящейся к туннелю (например, «GRE заблокирован для PPTP»).
Эта ошибка также возникает, когда не удается подключиться к VPN-серверу или не удается установить туннельное подключение.
Проверьте следующее.
Порты IKE (UDP-порты 500 и 4500) не блокируются.
Правильные сертификаты для IKE существуют как на клиенте, так и на сервере.
Код ошибки: 809
Описание ошибки. Не удалось установить сетевое подключение между компьютером и VPN-сервером, так как удаленный сервер не отвечает. Это может быть вызвано тем, что одно из сетевых устройств (например, брандмауэры, NAT, маршрутизаторы) между компьютером и удаленным сервером не настроено для разрешения VPN-подключений. Обратитесь к администратору или поставщику услуг, чтобы определить, какое устройство может быть причиной проблемы.
Возможная причина. Эта ошибка вызвана блокированием портов UDP 500 или 4500 на VPN-сервере или брандмауэре.
Возможное решение. Убедитесь, что UDP-порты 500 и 4500 разрешены через все брандмауэры между клиентом и сервером RRAS.
Код ошибки: 812
Описание ошибки. Не удается подключиться к Always On VPN. Подключение не выполнено из-за политики, заданной на вашем RAS/VPN сервере. В частности, метод проверки подлинности, используемый сервером для проверки имени пользователя и пароля, может не соответствовать методу проверки подлинности, настроенному в профиле подключения. Обратитесь к администратору сервера RAS и сообщите ему об этой ошибке.
Возможные причины:
Типичная причина этой ошибки заключается в том, что NPS указал условие проверки подлинности, которое клиент не может удовлетворить. Например, NPS может указать использование сертификата для защиты подключения PEAP, но клиент пытается использовать EAP-MSCHAPv2.
Журнал событий 20276 регистрируется в средстве просмотра событий, если параметр протокола проверки подлинности VPN-сервера на основе RRAS не соответствует компьютеру VPN-клиента.
Возможное решение. Убедитесь, что конфигурация клиента соответствует условиям, указанным на сервере NPS.
Код ошибки: 13806
Описание ошибки. IKE не удалось найти действительный сертификат компьютера. Обратитесь к администратору безопасности сети, чтобы установить действительный сертификат в соответствующем хранилище сертификатов.
Возможная причина. Эта ошибка обычно возникает, когда на VPN-сервере отсутствует сертификат компьютера или сертификат корневого компьютера.
Возможное решение. Убедитесь, что сертификаты, указанные в этом развертывании, установлены как на клиентском компьютере, так и на VPN-сервере.
Код ошибки: 13801
Описание ошибки. Учетные данные проверки подлинности IKE недопустимы.
Возможные причины. Эта ошибка обычно возникает в одном из следующих случаев.
Сертификат компьютера, используемый для проверки IKEv2 на сервере RAS, не имеет проверки подлинности сервера в разделе » Расширенное использование ключа«.
Срок действия сертификата компьютера на сервере удаленного доступа истек.
Корневой сертификат для проверки сертификата сервера удаленного доступа отсутствует на клиентском компьютере.
Имя VPN-сервера, используемое на клиентском компьютере, не соответствует SubjectName сертификата сервера.
Возможное решение. Убедитесь, что сертификат сервера включает проверку подлинности сервера в разделе Расширенное использование ключа. Убедитесь, что сертификат сервера все еще действителен. Убедитесь, что используемый центр сертификации указан в списке Доверенные корневые центры сертификации на сервере RRAS. Убедитесь, что VPN-клиент подключается с помощью полного доменного имени VPN-сервера, представленного в сертификате VPN-сервера.
Код ошибки: 0x80070040
Описание ошибки. В сертификате сервера не используется Проверка подлинности сервера в качестве одной из записей использования сертификатов.
Возможная причина. Эта ошибка может возникать, если на сервере удаленного доступа не установлен сертификат проверки подлинности сервера.
Код ошибки: 0x800B0109
Как правило, компьютер VPN-клиента присоединяется к домену на основе Active Directory. Если для входа на VPN-сервер используются учетные данные домена, сертификат автоматически устанавливается в хранилище Доверенные корневые центры сертификации. Однако если компьютер не присоединен к домену или используется другая цепочка сертификатов, может возникнуть эта проблема.
Описание ошибки. Цепочка сертификатов обработана, но была прервана в корневом сертификате, которому не доверяет поставщик доверия.
Возможная причина. Эта ошибка может возникать, если соответствующий доверенный корневой сертификат ЦС не установлен в хранилище доверенных корневых центров сертификации на клиентском компьютере.
Возможное решение. Убедитесь, что корневой сертификат установлен на клиентском компьютере в хранилище доверенных корневых центров сертификации.
Журналы
Журналы приложений
Приложение регистрируется на клиентских компьютерах в большинстве сведений о событиях VPN-подключений более высокого уровня.
Найдите события из источника Расклиент. Все сообщения об ошибках возвращают код ошибки в конце сообщения. Ниже описаны некоторые из наиболее распространенных кодов ошибок, но полный список доступен в кодах ошибок маршрутизации и удаленного доступа.
Журналы NPS
NPS создает и сохраняет журналы учета NPS. По умолчанию они хранятся в файлах% SYSTEMROOT% system32 в файле с именем в XXXX.txt, где XXXX — это Дата создания файла.
По умолчанию эти журналы находятся в формате значений с разделителями-запятыми, но не содержат строки заголовка. Строка заголовка:
если вставить эту строку заголовка в качестве первой строки файла журнала, а затем импортировать файл в Microsoft Excel, столбцы будут помечены правильно.
Журналы NPS могут быть полезны при диагностике проблем, связанных с политиками. Дополнительные сведения о журналах NPS см. в разделе Интерпретация файлов журнала в формате базы данных NPS.
Проблемы в работе скрипта VPN_Profile.ps1
Наиболее распространенные проблемы, возникающие при ручном запуске Profile.ps1 сценария VPN_ включают:
Используется ли средство удаленного подключения? Не следует использовать RDP или другой метод удаленного подключения, так как он перепутать с обнаружением входа пользователя.
Является ли пользователь администратором этого локального компьютера? Убедитесь, что при выполнении сценария VPN_Profile.ps1, у которого у пользователя есть права администратора.
Включены ли дополнительные функции безопасности PowerShell? Убедитесь, что политика выполнения PowerShell не блокирует скрипт. Перед выполнением скрипта можно отключить ограниченный языковой режим, если он включен. Вы можете активировать ограниченный языковой режим после успешного завершения сценария.
Проблемы с подключением клиента Always On VPN
Небольшая неудачная настройка может привести к сбою клиентского подключения, что может быть трудно обнаружить причину. Перед установкой соединения Always On VPN-клиент проходит несколько шагов. При устранении неполадок с подключением клиентов пройдите процесс исключения следующим образом:
Подключен ли шаблон к внешнему компьютеру? При сканировании вхатисмип должен отображаться общедоступный IP-адрес, который не принадлежит вам.
Можно ли разрешить имя сервера удаленного доступа или VPN-адреса в адрес? В окне «Сетевые подключения» панели управления > > откройте свойства профиля VPN. Значение на вкладке Общие должно быть открыто разрешимым с помощью DNS.
Можно ли получить доступ к VPN-серверу из внешней сети? Попробуйте открыть внешний интерфейс с помощью протокола ICMP и проверить связь с именем удаленного клиента. После успешной проверки связи можно удалить правило Allow ICMP.
Правильно ли настроены внутренние и внешние сетевые адаптеры на VPN-сервере? Они находятся в разных подсетях? Подключение внешнего сетевого адаптера к правильному интерфейсу в брандмауэре?
Открыты ли порты UDP 500 и 4500 от клиента к внешнему интерфейсу VPN-сервера? Проверьте брандмауэр клиента, брандмауэр сервера и все аппаратные брандмауэры. IPSEC использует UDP-порт 500, поэтому убедитесь, что ИПЕК отключены или не заблокированы в любом месте.
Вы подключаетесь, но у вас нет доступа к Интернету или локальной сети? Проверьте пулы IP-адресов серверов DHCP и VPN на наличие проблем с конфигурацией.
Вы подключаетесь и имеете действительный внутренний IP-адрес, но не имеете доступа к локальным ресурсам? Убедитесь, что клиенты узнают, как получить эти ресурсы. Для маршрутизации запросов можно использовать VPN-сервер.
Проблемы подключения при использовании условного доступа Azure AD
Ой! вы еще не можете получить доступ к этому
Возможная причина
У пользователя есть допустимый сертификат проверки подлинности клиента в хранилище личных сертификатов, который не был выдан Azure AD.
Возможное решение. Для экранирования этого цикла выполните следующие действия.
Убедитесь, что разделы, и содержат правильное имя и идентификатор объекта.
Чтобы определить наличие допустимых сертификатов в хранилище сертификатов пользователя, выполните команду certutil :
Если в личном хранилище пользователя существует допустимый сертификат проверки подлинности клиента, соединение не будет выполнено (как должно) после выбора пользователем X и существования разделов, и и содержащих правильные данные.
Появляется сообщение об ошибке «не удалось найти сертификат, который может использоваться с протоколом расширяемого протокола проверки подлинности».
Не удалось удалить сертификат из колонки VPN-подключения
Описание ошибки. Не удается удалить сертификаты в колонке VPN-подключения.
Возможная причина. Для сертификата задан первичный сертификат.
Возможное решение.
Источник
Устранение неполадок подключения типа «точка — сеть» Azure
В этой статье перечисляются распространенные проблемы подключения типа «точка — сеть», которые могут возникнуть. Кроме того, здесь рассматриваются возможные причины этих проблем и способы их устранения.
Ошибка VPN-клиента: не удалось найти сертификат
Симптом
При попытке подключения к виртуальной сети Azure с помощью VPN-клиента появляется следующее сообщение об ошибке:
Не удалось найти сертификат, который был бы использован с протоколом расширенной проверки подлинности (EAP). (Ошибка 798)
Причина
Решение
Устранить проблему можно так:
Откройте диспетчер сертификатов. Щелкните Запустить, введите управление сертификатами компьютеров и щелкните Управление сертификатами компьютеров в результатах поиска.
Убедитесь, что перечисленные ниже сертификаты находятся в правильном расположении.
Сертификат | Расположение |
---|---|
AzureClient.pfx | Current UserPersonalCertificates |
AzureRoot.cer | Local ComputerTrusted Root Certification Authorities |
При импорте сертификата клиента не выбирайте параметр Включить усиленную защиту закрытого ключа.
Не удалось установить сетевое подключение между компьютером и VPN-сервером, так как удаленный сервер не отвечает
Симптом
При попытке подключения к шлюзу виртуальной сети Azure с помощью протокола IKE версии 2 в Windows вы получаете следующее сообщение об ошибке:
Не удалось установить сетевое подключение между компьютером и VPN-сервером, так как удаленный сервер не отвечает
Причина
Проблема возникает, если в версии Windows отсутствует поддержка фрагментации IKE
Решение
IKEv2 поддерживается в Windows 10 и Server 2016. Однако для использования IKEv2 необходимо установить обновления и задать значение раздела реестра локально. Версии операционной системы до Windows 10 не поддерживаются и могут использовать только SSTP.
Чтобы подготовить Windows 10 или Server 2016 IKEv2:
Версия ОС | Дата | Номер или ссылка |
---|---|---|
Windows Server 2016 Windows 10 версии 1607 |
17 января 2018 г. | KB4057142 |
Windows 10 версии 1703 | 17 января 2018 г. | KB4057144 |
Windows 10 версии 1709 | 22 марта 2018 г. | KB4089848 |
Установите значение раздела реестра. Создайте ключ REG_DWORD HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesRasMan IKEv2DisableCertReqPayload в реестре или задайте ему значение равное 1.
Ошибка VPN-клиента: получено непредвиденное или неправильно отформатированное сообщение
Симптом
При попытке подключения к виртуальной сети Azure с помощью VPN-клиента появляется следующее сообщение об ошибке:
Получено непредвиденное или неправильно отформатированное сообщение. (Ошибка 0x80090326)
Причина
Эта проблема возникает, если выполняется одно из следующих условий.
Решение
Устранить проблему можно так:
Ошибка VPN-клиента: цепочка сертификатов обработана, но обработка прервана
Симптом
При попытке подключения к виртуальной сети Azure с помощью VPN-клиента появляется следующее сообщение об ошибке:
Цепочка сертификатов обработана, но обработка прервана на корневом сертификате, у которого отсутствует отношение доверия с поставщиком доверия.
Решение
Убедитесь, что перечисленные ниже сертификаты находятся в правильном расположении.
Сертификат | Расположение |
---|---|
AzureClient.pfx | Current UserPersonalCertificates |
Azuregateway-GUID.cloudapp.net | Current UserTrusted Root Certification Authorities |
AzureGateway-GUID.cloudapp.net, AzureRoot.cer | Local ComputerTrusted Root Certification Authorities |
Если сертификаты уже находятся в соответствующих расположениях, попробуйте удалить эти сертификаты и установить их заново. Сертификат azuregateway-GUID.cloudapp.net находится в пакете конфигурации VPN-клиента, скачанном с портала Azure. Для извлечения файлов из пакета можно использовать архиваторы.
Произошла ошибка скачивания файла. Целевой URI не указан
Симптом
Отображается следующее сообщение об ошибке:
Произошла ошибка скачивания файла. URI назначения не указан.
Причина
Эта проблема возникает из-за неправильного типа шлюза.
Решение
Типом VPN-шлюза должен быть VPN, а типом VPN — routebased.
Ошибка VPN-клиента: сбой настраиваемого сценария VPN Azure
Симптом
При попытке подключения к виртуальной сети Azure с помощью VPN-клиента появляется следующее сообщение об ошибке:
Произошел сбой настраиваемого сценария (для обновления таблицы маршрутизации). (Ошибка 8007026f)
Причина
Это может произойти, если вы пытаетесь открыть VPN-подключение типа «сеть — точка» с помощью ярлыка.
Решение
Откройте пакет VPN напрямую, а не с помощью ярлыка.
Не удается установить VPN-клиент
Причина
Для установления отношений доверия между VPN-шлюзом и виртуальной сетью требуется дополнительный сертификат. Этот сертификат включен в пакет конфигурации VPN-клиента, который создается на портале Azure.
Решение
Извлеките содержимое пакета конфигурации VPN-клиента и найдите CER-файл. Для установки сертификата выполните следующие действия:
Ошибка портала Azure: не удалось сохранить VPN-шлюз, так как данные являются недопустимыми
Симптом
При попытке сохранить изменения для VPN-шлюза на портале Azure появляется следующее сообщение об ошибке:
Причина
Эта проблема может возникнуть, если переданный вами открытый ключ корневого сертификата содержит недопустимые знаки, например пробел.
Решение
Убедитесь, что данные в сертификате не содержат недопустимых знаков, таких как разрывы строки (возврат каретки). Значение целиком должно находиться в одной длинной строке. Ниже приведен пример содержимого сертификата.
Ошибка портала Azure: не удалось сохранить VPN-шлюз, так как имя ресурса является недопустимым
Симптом
При попытке сохранить изменения для VPN-шлюза на портале Azure появляется следующее сообщение об ошибке:
Причина
Эта проблема возникает, когда имя сертификата содержит недопустимые знаки, например пробел.
Ошибка портала Azure: ошибка 503 при скачивании файла пакета VPN
Симптом
При попытке скачать пакет конфигурации VPN-клиента появляется следующее сообщение об ошибке:
Не удалось скачать файл. Сведения об ошибке: ошибка 503. Сервер занят.
Решение
Эта ошибка может быть вызвана временным сбоем сети. Попробуйте еще раз скачать пакет VPN через несколько минут.
Обновление VPN-шлюза Azure, всем клиентам типа «точка — сеть» не удается подключиться
Причина
Если время существования сертификата составляет более 50 процентов, то сертификат сменяется.
Решение
Чтобы устранить эту проблему, повторно скачайте и разверните пакет подключения «точка — сеть» на всех клиентах.
Слишком много одновременно подключенных VPN-клиентов
Достигнуто максимальное число допустимых подключений. Общее количество подключенных клиентов можно просмотреть на портале Azure.
VPN-клиент не может получить доступ к сетевым файловым ресурсам
Симптом
VPN-клиент подключился к виртуальной сети Azure. Однако он не может получить доступ к сетевым папкам.
Причина
Для доступа к файловым ресурсам используется протокол SMB. Когда VPN-клиент добавляет учетные данные сеанса при инициировании подключения, происходит сбой. После установления подключения клиент принудительно использует кэшированные учетные данные для аутентификации Kerberos. Это инициирует отправку запросов к центру распространения ключей (контроллеру домена) для получения токена. Так как клиенты подключаются через Интернет, они могут не подключиться к контроллеру домена. Следовательно, клиенты не могут выполнить отработку отказа с Kerberos на NTLM.
Единственный случай, в котором клиенту будет предложено указать учетные данные — когда у клиента есть действительный сертификат (в котором для параметра SAN указано имя участника-пользователя), выданный доменом, к которому присоединен клиент. Клиент также должен быть физически подключен к доменной сети. В этом случае клиент пытается использовать сертификат и подключиться к контроллеру домена. Затем центр распространения ключей возвращает ошибку «KDC_ERR_C_PRINCIPAL_UNKNOWN». Это вынуждает клиента выполнить отработку отказа на NTLM.
Решение
Чтобы обойти эту проблему, отключите кэширование учетных данных домена в следующем подразделе реестра:
Не удается найти VPN-подключение типа «точка — сеть» в Windows после повторной установки VPN-клиента
Симптом
Вы удаляете VPN-подключение типа «точка — сеть», а затем переустанавливаете VPN-клиент. В этом случае VPN-подключение не будет успешно настроено. Вы не видите VPN-подключение в параметрах Сетевые подключения в Windows.
Решение
VPN-клиенту типа «точка — сеть» не удается разрешить полные доменные имена ресурсов в локальном домене
Симптом
Когда клиент подключается к Azure с помощью VPN-подключения типа «точка — сеть», ему не удается разрешить полные доменные имена ресурсов в локальном домене.
Причина
VPN-клиент типа «точка — сеть» обычно использует DNS-серверы Azure, настроенные в виртуальной сети Azure. DNS-серверы Azure имеют приоритет перед локальными DNS-серверами, настроенными в клиенте, если метрика интерфейса Ethernet не ниже, поэтому все запросы DNS отправляются на DNS-серверы Azure. Если на DNS-серверах Azure нет записей для локальных ресурсов, запрос завершается ошибкой.
Решение
Чтобы устранить эту проблему, убедитесь, что DNS-серверы Azure, используемые в виртуальной сети Azure, могут разрешать записи DNS для локальных ресурсов. Для этого можно использовать DNS-серверы пересылки или серверы условной пересылки. Дополнительные сведения см. в разделе Разрешение имен с помощью собственного DNS-сервера.
VPN-подключение типа «точка — сеть» устанавливается, но по-прежнему не удается подключиться к ресурсам Azure
Причина
Это может происходить, если VPN-клиент не получает маршруты из VPN-шлюза Azure.
Решение
Чтобы устранить эту проблему, сбросьте VPN-шлюз Azure. Чтобы убедиться, что используются новые маршруты, клиенты VPN «точка-сеть» необходимо загрузить заново после успешной настройки пиринга виртуальной сети.
Ошибка: «Функции отзыва не удалось проверить отзыв, так как сервер отзыва был не в сети. (Ошибка 0x80092013.)»
Причины
Это сообщение об ошибке появляется, если клиент не может получить доступ к http://crl3.digicert.com/ssca-sha2-g1.crl и http://crl4.digicert.com/ssca-sha2-g1.crl. Для проверки отмены сертификатов требуется доступ к этим двум сайтам. Эта проблема обычно возникает на клиенте, для которого настроен прокси-сервер. В некоторых средах в случае, если запросы не проходят через прокси-сервер, они запрещаются на пограничном межсетевом экране.
Решение
Ошибка VPN-клиента: «Подключение не выполнено из-за политики, заданной на сервере службы удаленного доступа/виртуальной частной сети. (Ошибка 812.)»
Причина
Эта ошибка возникает, если для сервера RADIUS, который использовался для аутентификации VPN-клиента, заданы неправильные параметры или шлюзу Azure не удается подключиться к серверу RADIUS.
Решение
Убедитесь, что сервер RADIUS настроен правильно. Дополнительные сведения см. в разделе Интеграция аутентификации RADIUS с сервером Многофакторной идентификации Azure AD.
«Ошибка 405» при скачивании корневого сертификата из VPN-шлюза
Причина
Корневой сертификат не установлен. Корневой сертификат установлен в хранилище доверенных сертификатов клиента.
Ошибка VPN-клиента: «Удаленное подключение не удалось установить из-за сбоя использованных VPN-туннелей. (Ошибка 800.)»
Причина
Драйвер сетевого адаптера является устаревшим.
Решение
Обновите драйвер сетевого адаптера.
Причина
В параметрах приложения в Windows для VPN-клиент Azure не включено разрешение «Фоновые приложения».
Решение
Ошибка: «Произошла ошибка скачивания файла. Целевой URI не указан.»
Причина
Эта ошибка возникает из-за неправильной настройки типа шлюза.
Решение
Типом VPN-шлюза Azure должен быть «VPN», а типом VPN — RouteBased.
Установщик пакета VPN не завершает установку
Причина
Причиной этой проблемы могут быть предыдущие установки VPN-клиента.
Решение
Через некоторое время VPN-клиент переходит в режим гибернации или спящий режим
Решение
Проверьте параметры спящего режима и режима гибернации на компьютере с VPN-клиентом.
Источник
I’m trying to get a simple IPSEC/IKEv2 server set up with username/password (for now) on Ubuntu 18.04.
I’m using Windows 10 Pro built in client, and the connection fails complaining about the IKE authentication credentials. The event log shows error 13801, which according to https://blogs.technet.microsoft.com/rrasblog/2009/08/12/troubleshooting-common-vpn-related-errors/ could be any one of
- The machine certificate used for IKEv2 validation on RAS Server does not have ‘Server Authentication’ as the EKU (Enhanced Key Usage).
- The machine certificate on RAS server has expired.
- The root certificate to validate the RAS server certificate is not present on the client.
- VPN Server Name as given on client doesn’t match with the subjectName of the server certificate.
I’m using a full chain certificate from letsencrypt. I’m not sure how to check the certificate received on the windows side, but I exported the certificate via firefox (I’m using the same cert for an apache2 webserver) to take a look. In Enhanced Key Usage
, I have Server Authentication (1.3.6.1.5.5.7.3.1)
. The Subject
is CN = domain.com
which is the same domain I’m connecting to (i.e. no subdomains). The cert chain goes to the root DST Root CA X3
, which is in my Trusted Root Certification Authorities Store.
My ipsec.conf is as follows:
# ipsec.conf - strongSwan IPsec configuration file
config setup
charondebug="cfg 2"
conn ikev2-vpn
auto=add
compress=no
type=tunnel
keyexchange=ikev2
fragmentation=yes
forceencaps=yes
ike=aes256-sha1-modp1024,3des-sha1-modp1024!
esp=aes256-sha1,3des-sha1!
dpdaction=clear
dpddelay=300s
rekey=no
left=%any
leftid=@domain.com
leftauth=pubkey
leftcert=/etc/ssl/certs/domain.com.pem
leftsendcert=always
leftsubnet=0.0.0.0/0
right=%any
rightid=%any
rightauth=eap-mschapv2
rightdns=192.168.1.1
rightsourceip=10.11.12.0/24
rightsendcert=never
eap_identity=%identity
The log for this connection is as follows:
Wed, 2018-07-04 17:20 00[DMN] Starting IKE charon daemon (strongSwan 5.6.2, Linux 4.15.0-23-generic, x86_64)
Wed, 2018-07-04 17:20 00[LIB] plugin 'aesni': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'aes': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'rc2': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'sha2': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'sha1': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'md4': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'md5': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'mgf1': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'random': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'nonce': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'x509': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'revocation': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'constraints': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'pubkey': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'pkcs1': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'pkcs7': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'pkcs8': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'pkcs12': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'pgp': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'dnskey': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'sshkey': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'pem': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'openssl': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'fips-prf': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'gmp': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'agent': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'xcbc': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'hmac': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'gcm': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'attr': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'kernel-netlink': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'resolve': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'socket-default': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'connmark': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'stroke': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'updown': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'eap-mschapv2': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'xauth-generic': loaded successfully
Wed, 2018-07-04 17:20 00[LIB] plugin 'counters': loaded successfully
Wed, 2018-07-04 17:20 00[KNL] known interfaces and IP addresses:
Wed, 2018-07-04 17:20 00[KNL] lo
Wed, 2018-07-04 17:20 00[KNL] 127.0.0.1
Wed, 2018-07-04 17:20 00[KNL] ::1
Wed, 2018-07-04 17:20 00[KNL] enp1s0
Wed, 2018-07-04 17:20 00[KNL] 192.168.1.2
Wed, 2018-07-04 17:20 00[KNL] fe80::428d:5cff:fe05:6216
Wed, 2018-07-04 17:20 00[LIB] feature PUBKEY:ED25519 in plugin 'pem' has unmet dependency: PUBKEY:ED25519
Wed, 2018-07-04 17:20 00[LIB] feature PUBKEY:BLISS in plugin 'pem' has unmet dependency: PUBKEY:BLISS
Wed, 2018-07-04 17:20 00[LIB] feature PUBKEY:DSA in plugin 'pem' has unmet dependency: PUBKEY:DSA
Wed, 2018-07-04 17:20 00[LIB] feature PRIVKEY:DSA in plugin 'pem' has unmet dependency: PRIVKEY:DSA
Wed, 2018-07-04 17:20 00[LIB] feature PRIVKEY:BLISS in plugin 'pem' has unmet dependency: PRIVKEY:BLISS
Wed, 2018-07-04 17:20 00[LIB] feature CERT_DECODE:OCSP_REQUEST in plugin 'pem' has unmet dependency: CERT_DECODE:OCSP_REQUEST
Wed, 2018-07-04 17:20 00[LIB] feature PRIVKEY_SIGN:RSA_EMSA_PKCS1_SHA3_224 in plugin 'gmp' has unmet dependency: HASHER:HASH_SHA3_224
Wed, 2018-07-04 17:20 00[LIB] feature PRIVKEY_SIGN:RSA_EMSA_PKCS1_SHA3_256 in plugin 'gmp' has unmet dependency: HASHER:HASH_SHA3_256
Wed, 2018-07-04 17:20 00[LIB] feature PRIVKEY_SIGN:RSA_EMSA_PKCS1_SHA3_384 in plugin 'gmp' has unmet dependency: HASHER:HASH_SHA3_384
Wed, 2018-07-04 17:20 00[LIB] feature PRIVKEY_SIGN:RSA_EMSA_PKCS1_SHA3_512 in plugin 'gmp' has unmet dependency: HASHER:HASH_SHA3_512
Wed, 2018-07-04 17:20 00[LIB] feature PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA3_224 in plugin 'gmp' has unmet dependency: HASHER:HASH_SHA3_224
Wed, 2018-07-04 17:20 00[LIB] feature PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA3_256 in plugin 'gmp' has unmet dependency: HASHER:HASH_SHA3_256
Wed, 2018-07-04 17:20 00[LIB] feature PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA3_384 in plugin 'gmp' has unmet dependency: HASHER:HASH_SHA3_384
Wed, 2018-07-04 17:20 00[LIB] feature PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA3_512 in plugin 'gmp' has unmet dependency: HASHER:HASH_SHA3_512
Wed, 2018-07-04 17:20 00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts'
Wed, 2018-07-04 17:20 00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts'
Wed, 2018-07-04 17:20 00[CFG] loading ocsp signer certificates from '/etc/ipsec.d/ocspcerts'
Wed, 2018-07-04 17:20 00[CFG] loading attribute certificates from '/etc/ipsec.d/acerts'
Wed, 2018-07-04 17:20 00[CFG] loading crls from '/etc/ipsec.d/crls'
Wed, 2018-07-04 17:20 00[CFG] loading secrets from '/etc/ipsec.secrets'
Wed, 2018-07-04 17:20 00[CFG] loaded RSA private key from '/etc/ssl/private/strongswan.key'
Wed, 2018-07-04 17:20 00[CFG] loaded EAP secret for aram %any%
Wed, 2018-07-04 17:20 00[LIB] loaded plugins: charon aesni aes rc2 sha2 sha1 md4 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
Wed, 2018-07-04 17:20 00[LIB] unable to load 14 plugin features (14 due to unmet dependencies)
Wed, 2018-07-04 17:20 00[LIB] dropped capabilities, running as uid 0, gid 0
Wed, 2018-07-04 17:20 00[JOB] spawning 16 worker threads
Wed, 2018-07-04 17:20 01[LIB] created thread 01 [24678]
Wed, 2018-07-04 17:20 04[LIB] created thread 04 [24680]
Wed, 2018-07-04 17:20 06[LIB] created thread 06 [24681]
Wed, 2018-07-04 17:20 11[LIB] created thread 11 [24686]
Wed, 2018-07-04 17:20 12[LIB] created thread 12 [24688]
Wed, 2018-07-04 17:20 13[LIB] created thread 13 [24687]
Wed, 2018-07-04 17:20 05[LIB] created thread 05 [24683]
Wed, 2018-07-04 17:20 14[LIB] created thread 14 [24689]
Wed, 2018-07-04 17:20 08[LIB] created thread 08 [24684]
Wed, 2018-07-04 17:20 16[LIB] created thread 16 [24691]
Wed, 2018-07-04 17:20 10[LIB] created thread 10 [24685]
Wed, 2018-07-04 17:20 02[LIB] created thread 02 [24676]
Wed, 2018-07-04 17:20 07[LIB] created thread 07 [24679]
Wed, 2018-07-04 17:20 03[LIB] created thread 03 [24677]
Wed, 2018-07-04 17:20 09[LIB] created thread 09 [24682]
Wed, 2018-07-04 17:20 15[LIB] created thread 15 [24690]
Wed, 2018-07-04 17:20 03[CFG] received stroke: add connection 'ikev2-vpn'
Wed, 2018-07-04 17:20 03[CFG] conn ikev2-vpn
Wed, 2018-07-04 17:20 03[CFG] left=%any
Wed, 2018-07-04 17:20 03[CFG] leftsubnet=0.0.0.0/0
Wed, 2018-07-04 17:20 03[CFG] leftauth=pubkey
Wed, 2018-07-04 17:20 03[CFG] leftid=@domain.com
Wed, 2018-07-04 17:20 03[CFG] leftcert=/etc/ssl/certs/domain.com.pem
Wed, 2018-07-04 17:20 03[CFG] right=%any
Wed, 2018-07-04 17:20 03[CFG] rightsourceip=10.11.12.0/24
Wed, 2018-07-04 17:20 03[CFG] rightdns=192.168.1.1
Wed, 2018-07-04 17:20 03[CFG] rightauth=eap-mschapv2
Wed, 2018-07-04 17:20 03[CFG] rightid=%any
Wed, 2018-07-04 17:20 03[CFG] eap_identity=%identity
Wed, 2018-07-04 17:20 03[CFG] ike=aes256-sha1-modp1024,3des-sha1-modp1024!
Wed, 2018-07-04 17:20 03[CFG] esp=aes256-sha1,3des-sha1!
Wed, 2018-07-04 17:20 03[CFG] dpddelay=300
Wed, 2018-07-04 17:20 03[CFG] dpdtimeout=150
Wed, 2018-07-04 17:20 03[CFG] dpdaction=1
Wed, 2018-07-04 17:20 03[CFG] sha256_96=no
Wed, 2018-07-04 17:20 03[CFG] mediation=no
Wed, 2018-07-04 17:20 03[CFG] keyexchange=ikev2
Wed, 2018-07-04 17:20 03[CFG] adding virtual IP address pool 10.11.12.0/24
Wed, 2018-07-04 17:20 03[CFG] loaded certificate "CN=domain.com" from '/etc/ssl/certs/domain.com.pem'
Wed, 2018-07-04 17:20 03[CFG] added configuration 'ikev2-vpn'
Wed, 2018-07-04 17:20 02[NET] <1> received packet: from 142.68.61.15[500] to 192.168.1.2[500] (616 bytes)
Wed, 2018-07-04 17:20 02[ENC] <1> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) V V V V ]
Wed, 2018-07-04 17:20 02[CFG] <1> looking for an ike config for 192.168.1.2...142.68.61.15
Wed, 2018-07-04 17:20 02[CFG] <1> candidate: %any...%any, prio 28
Wed, 2018-07-04 17:20 02[CFG] <1> found matching ike config: %any...%any with prio 28
Wed, 2018-07-04 17:20 02[IKE] <1> received MS NT5 ISAKMPOAKLEY v9 vendor ID
Wed, 2018-07-04 17:20 02[IKE] <1> received MS-Negotiation Discovery Capable vendor ID
Wed, 2018-07-04 17:20 02[IKE] <1> received Vid-Initial-Contact vendor ID
Wed, 2018-07-04 17:20 02[ENC] <1> received unknown vendor ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02
Wed, 2018-07-04 17:20 02[IKE] <1> 142.68.61.15 is initiating an IKE_SA
Wed, 2018-07-04 17:20 02[IKE] <1> IKE_SA (unnamed)[1] state change: CREATED => CONNECTING
Wed, 2018-07-04 17:20 02[CFG] <1> selecting proposal:
Wed, 2018-07-04 17:20 02[CFG] <1> no acceptable ENCRYPTION_ALGORITHM found
Wed, 2018-07-04 17:20 02[CFG] <1> selecting proposal:
Wed, 2018-07-04 17:20 02[CFG] <1> proposal matches
Wed, 2018-07-04 17:20 02[CFG] <1> received proposals: IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:3DES_CBC/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024
Wed, 2018-07-04 17:20 02[CFG] <1> configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Wed, 2018-07-04 17:20 02[CFG] <1> selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Wed, 2018-07-04 17:20 02[LIB] <1> size of DH secret exponent: 1023 bits
Wed, 2018-07-04 17:20 02[IKE] <1> local host is behind NAT, sending keep alives
Wed, 2018-07-04 17:20 02[IKE] <1> remote host is behind NAT
Wed, 2018-07-04 17:20 02[ENC] <1> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ]
Wed, 2018-07-04 17:20 02[NET] <1> sending packet: from 192.168.1.2[500] to 142.68.61.15[500] (312 bytes)
Wed, 2018-07-04 17:20 13[NET] <1> received packet: from 142.68.61.15[4500] to 192.168.1.2[4500] (1452 bytes)
Wed, 2018-07-04 17:20 13[ENC] <1> parsed IKE_AUTH request 1 [ IDi CERTREQ N(MOBIKE_SUP) CPRQ(ADDR DNS NBNS SRV ADDR6 DNS6 SRV6) SA TSi TSr ]
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 73:68:b1:9a:19:83:cc:4b:37:b3:45:44:5d:ef:a5:45:46:ee:ff:a4
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 0e:ac:82:60:40:56:27:97:e5:25:13:fc:2a:e1:0a:53:95:59:e4:a4
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid f8:16:51:3c:fd:1b:44:9f:2e:6b:28:a1:97:22:1f:b8:1f:51:4e:3c
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid dd:bc:bd:86:9c:3f:07:ed:40:e3:1b:08:ef:ce:c4:d1:88:cd:3b:15
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 4a:5c:75:22:aa:46:bf:a4:08:9d:39:97:4e:bd:b4:a3:60:f7:a0:1d
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 5c:b8:69:fe:8d:ef:c1:ed:66:27:ee:b2:12:0f:72:1b:b8:0a:0e:04
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 6a:47:a2:67:c9:2e:2f:19:68:8b:9b:86:61:66:95:ed:c1:2c:13:00
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 01:f0:33:4c:1a:a1:d9:ee:5b:7b:a9:de:43:bc:02:7d:57:09:33:fb
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid b7:95:e9:ff:7d:9c:f0:b1:62:4f:a1:c8:f6:0b:e6:37:20:12:b9:e5
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 1b:e3:ae:ad:0f:c1:1d:d0:15:5b:2d:1d:c5:19:13:71:a4:63:95:5b
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 3c:a2:80:2a:31:80:fd:5b:a6:12:86:fb:55:3a:77:ba:e8:0c:12:ad
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 88:a9:5a:ef:c0:84:fc:13:74:41:6b:b1:63:32:c2:cf:92:59:bb:3b
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 34:4f:30:2d:25:69:31:91:ea:f7:73:5c:ab:f5:86:8d:37:82:40:ec
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 3e:df:29:0c:c1:f5:cc:73:2c:eb:3d:24:e1:7e:52:da:bd:27:e2:f0
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid ab:76:88:f4:e5:e1:38:c9:e9:50:17:cd:cd:b3:18:17:b3:3e:8c:f5
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid da:ed:64:74:14:9c:14:3c:ab:dd:99:a9:bd:5b:28:4d:8b:3c:c9:d8
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 5e:8c:53:18:22:60:1d:56:71:d6:6a:a0:cc:64:a0:60:07:43:d5:a8
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 86:26:cb:1b:c5:54:b3:9f:bd:6b:ed:63:7f:b9:89:a9:80:f1:f4:8a
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid c0:7a:98:68:8d:89:fb:ab:05:64:0c:11:7d:aa:7d:65:b8:ca:cc:4e
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid a8:e3:02:96:70:a6:8b:57:eb:ec:ef:cc:29:4e:91:74:9a:d4:92:38
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid b5:99:33:43:ac:a2:17:c5:08:ba:88:8c:a6:92:7e:26:b3:0f:87:a9
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid f7:93:19:ef:df:c1:f5:20:fb:ac:85:55:2c:f2:d2:8f:5a:b9:ca:0b
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 30:a4:e6:4f:de:76:8a:fc:ed:5a:90:84:28:30:46:79:2c:29:15:70
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 48:e6:68:f9:2b:d2:b2:95:d7:47:d8:23:20:10:4f:33:98:90:9f:d4
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 73:97:82:ea:b4:04:16:6e:25:d4:82:3c:37:db:f8:a8:12:fb:cf:26
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 69:9f:1b:7a:e9:b8:da:18:49:6c:60:8b:ce:4f:4e:aa:f9:f0:b7:aa
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 69:c4:27:db:59:69:68:18:47:e2:52:17:0a:e0:e5:7f:ab:9d:ef:0f
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid ba:42:b0:81:88:53:88:1d:86:63:bd:4c:c0:5e:08:fe:ea:6e:bb:77
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 87:db:d4:5f:b0:92:8d:4e:1d:f8:15:67:e7:f2:ab:af:d6:2b:67:75
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 6e:58:4e:33:75:bd:57:f6:d5:42:1b:16:01:c2:d8:c0:f5:3a:9f:6e
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 4a:81:0c:de:f0:c0:90:0f:19:06:42:31:35:a2:a2:8d:d3:44:fd:08
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid d5:2e:13:c1:ab:e3:49:da:e8:b4:95:94:ef:7c:38:43:60:64:66:bd
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 59:79:12:de:61:75:d6:6f:c4:23:b7:77:13:74:c7:96:de:6f:88:72
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 6c:ca:bd:7d:b4:7e:94:a5:75:99:01:b6:a7:df:d4:5d:1c:09:1c:cc
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid ab:30:d3:af:4b:d8:f1:6b:58:69:ee:45:69:29:da:84:b8:73:94:88
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 42:32:b6:16:fa:04:fd:fe:5d:4b:7a:c3:fd:f7:4c:40:1d:5a:43:af
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid a5:06:8a:78:cf:84:bd:74:32:dd:58:f9:65:eb:3a:55:e7:c7:80:dc
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid e2:7f:7b:d8:77:d5:df:9e:0a:3f:9e:b4:cb:0e:2e:a9:ef:db:69:77
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 5f:f3:24:6c:8f:91:24:af:9b:5f:3e:b0:34:6a:f4:2d:5c:a8:5d:cc
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 6d:aa:9b:09:87:c4:d0:d4:22:ed:40:07:37:4d:19:f1:91:ff:de:d3
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 83:31:7e:62:85:42:53:d6:d7:78:31:90:ec:91:90:56:e9:91:b9:e3
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 7e:95:9f:ed:82:8e:2a:ed:c3:7c:0d:05:46:31:ef:53:97:cd:48:49
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 39:e8:80:35:f8:a2:05:a0:08:b4:cd:e9:d8:ca:67:29:22:2e:7e:9b
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 3e:22:d4:2c:1f:02:44:b8:04:10:65:61:7c:c7:6b:ae:da:87:29:9c
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 55:e4:81:d1:11:80:be:d8:89:b9:08:a3:31:f9:a1:24:09:16:b9:70
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid b1:81:08:1a:19:a4:c0:94:1f:fa:e8:95:28:c1:24:c9:9b:34:ac:c7
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 21:0f:2c:89:f7:c4:cd:5d:1b:82:5e:38:d6:c6:59:3b:a6:93:75:ae
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 23:4b:71:25:56:13:e1:30:dd:e3:42:69:c9:cc:30:d4:6f:08:41:e0
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid bb:c2:3e:29:0b:b3:28:77:1d:ad:3e:a2:4d:bd:f4:23:bd:06:b0:3d
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid b0:19:89:e7:ef:fb:4a:af:cb:14:8f:58:46:39:76:22:41:50:e1:ba
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid ee:e5:9f:1e:2a:a5:44:c3:cb:25:43:a6:9a:5b:d4:6a:25:bc:bb:8e
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 67:ec:9f:90:2d:cd:64:ae:fe:7e:bc:cd:f8:8c:51:28:f1:93:2c:12
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 17:4a:b8:2b:5f:fb:05:67:75:27:ad:49:5a:4a:5d:c4:22:cc:ea:4e
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 68:33:0e:61:35:85:21:59:29:83:a3:c8:d2:d2:e1:40:6e:7a:b3:c1
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 9c:a9:8d:00:af:74:0d:dd:81:80:d2:13:45:a5:8b:8f:2e:94:38:d6
Wed, 2018-07-04 17:20 13[IKE] <1> received cert request for unknown ca with keyid 4f:9c:7d:21:79:9c:ad:0e:d8:b9:0c:57:9f:1a:02:99:e7:90:f3:87
Wed, 2018-07-04 17:20 13[IKE] <1> received 56 cert requests for an unknown ca
Wed, 2018-07-04 17:20 13[CFG] <1> looking for peer configs matching 192.168.1.2[%any]...142.68.61.15[192.168.1.133]
Wed, 2018-07-04 17:20 13[CFG] <1> candidate "ikev2-vpn", match: 1/1/28 (me/other/ike)
Wed, 2018-07-04 17:20 13[CFG] <ikev2-vpn|1> selected peer config 'ikev2-vpn'
Wed, 2018-07-04 17:20 13[IKE] <ikev2-vpn|1> EAP-Identity request configured, but not supported
Wed, 2018-07-04 17:20 13[IKE] <ikev2-vpn|1> initiating EAP_MSCHAPV2 method (id 0x52)
Wed, 2018-07-04 17:20 13[IKE] <ikev2-vpn|1> processing INTERNAL_IP4_ADDRESS attribute
Wed, 2018-07-04 17:20 13[IKE] <ikev2-vpn|1> processing INTERNAL_IP4_DNS attribute
Wed, 2018-07-04 17:20 13[IKE] <ikev2-vpn|1> processing INTERNAL_IP4_NBNS attribute
Wed, 2018-07-04 17:20 13[IKE] <ikev2-vpn|1> processing INTERNAL_IP4_SERVER attribute
Wed, 2018-07-04 17:20 13[IKE] <ikev2-vpn|1> processing INTERNAL_IP6_ADDRESS attribute
Wed, 2018-07-04 17:20 13[IKE] <ikev2-vpn|1> processing INTERNAL_IP6_DNS attribute
Wed, 2018-07-04 17:20 13[IKE] <ikev2-vpn|1> processing INTERNAL_IP6_SERVER attribute
Wed, 2018-07-04 17:20 13[IKE] <ikev2-vpn|1> peer supports MOBIKE
Wed, 2018-07-04 17:20 13[IKE] <ikev2-vpn|1> authentication of 'domain.com' (myself) with RSA signature successful
Wed, 2018-07-04 17:20 13[IKE] <ikev2-vpn|1> sending end entity cert "CN=domain.com"
Wed, 2018-07-04 17:20 13[ENC] <ikev2-vpn|1> generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/MSCHAPV2 ]
Wed, 2018-07-04 17:20 13[NET] <ikev2-vpn|1> sending packet: from 192.168.1.2[4500] to 142.68.61.15[4500] (2460 bytes)
Wed, 2018-07-04 17:20 05[IKE] <ikev2-vpn|1> sending keep alive to 142.68.61.15[4500]
Wed, 2018-07-04 17:20 14[JOB] <ikev2-vpn|1> deleting half open IKE_SA with 142.68.61.15 after timeout
Wed, 2018-07-04 17:20 14[IKE] <ikev2-vpn|1> IKE_SA ikev2-vpn[1] state change: CONNECTING => DESTROYING
Any help would be greatly appreciated!
- Remove From My Forums
-
Общие обсуждения
-
Предположительно, после обновления перестал работать удалённый доступ, возникает ошибка 13801 (неприемлемые учётные данные проверки подлинности IKE) при подключении по протоколу IKEv2 (с Windows 8.1/Windows Phone 8.1).
Если подключаемся по протоколу SSTP, то всё отлично соединяется (даже при использовании режима шифрования «самое стойкое»).
Как быть? CN сертификата с именем компьютера в профиле соединения совпадает, OID для IKE прописан.
Вчера всё работало, сегодня не работает. На сервере ничего не делали.
-
Изменен тип
17 сентября 2014 г. 11:41
-
Изменен тип