Я полный профан, искренне надеюсь на помощь простыми словами 
На удаленном сервере с OS Debian по вот этому гайду с использованием strongSwan организовал для себя VPN. Все отлично работает на iPhone и Mac, однако для подключения с Windows нужно проделать какие-то дополнительные манипуляции, потому что ни так, ни этак подключится не удается. Ошибки подключения разные, в зависимости от настроек создаваемого подключения в Windows.
Если делать подключение в лоб:
вот так
то получаем ошибку сопоставления групповой политики:
ошибка
В свойствах подключения можно переставить проверку подлинности на «Использовать сертификаты компьютеров»:
настройки vpn
правда это ничего не меняет.
Вот этот мануал по strongSwan’у подсказывает, что «By default Windows 7 up to Windows 11 propose only the weak modp1024 Diffie-Hellman key exchange algorithm» и предлагает соотвествующую настройку для ipsec.conf:
ike = 3des-aes128-aes192-aes256-sha1-sha256-sha384-modp1024О том, что именна эта строчка портит малину подсказывают коллеги из комментов в оригинальной статье на vc.ru:
скриншот комментариев
мне, правда, это не помогло 
Из какого-то источника, который я уже не могу нагуглить, я узнал что на компьютере нужно иметь корневой сертификат, который я создал на удаленном сервере. Сертификат был создан в формате *.pem, установить его в Windows я смог только переименовав файл в *.der и кликнув по нему два раза. Создать сертификат с помощью pki в формате, который винда переварила бы by-design я не смог. Установка сертификата в хранилице «Доверенных корневых центров сертификации» не помогла.
Вот эта статья из мануала strongSwan подсказывает, что для windows сертификат должен быть сгенерирован с дополнительным ключом:
subjectAltName = DNS:<YOUR_VPS_IP>
но увы и это мне тоже не помогло.
В конце уже упомянутого выше мануала есть ссылки, в том числе на Configuring strongSwan for Windows clients для случая, когда Windows client «Using Passwords with EAP-MSCHAPv2«, однако он предлагает конфигурировать файл swanctl.conf, а у меня конфигурация уже задана в ipsec.conf, понять как одно с другим связано квалификации моей не хватает
Вобщем, достаточно разрозненный набор фактов выглядит вот так, очень прошу помощь от гуру.
Почему я не купил готовый сконфигурированный сервер?
Да
- Remove From My Forums
-
Вопрос
-
Всем доброго!
Настроил я сервак впн для работы с ikev2. Но не очень понял в чем проблема при подключении: Пока проверяю внутри сети на отдельной машине. Если в свойствах впн подключения на клиенте указано полное доменное имя впн сервера vpnserver.firma.local,
то я могу подключиться к серверу, если указать просто vpnserver без домена, то клиентское подключение сообщает «неприемлемые учетные данные проверки подлинности ike». И соответственно, сейчас открыли все что нужно на маршрутизаторе,
чтобы можно было на впн сервак попадать уже из инета, и получается в свойствах клиентского подключения мы меняем адрес пока на внешний ip 2xx.xx.xx.xx. И при попытке подключиться к впн серверу получаем такую же ошибку «неприемлемые
учетные данные проверки подлинности ike». Это с чем может быть связано?Соответсвенно в логах ВПН сервера регистрируется вот такое событие:
«Имя журнала: System
Источник: RemoteAccess
Дата: 02.06.2017 16:04:24
Код события: 20255
Категория задачи:Отсутствует
Уровень: Ошибка
Ключевые слова:Классический
Пользователь: Н/Д
Компьютер: VPNSRV.Firma.local
Описание:
CoID={F55B7B1A-90C5-51A1-58E3-887C43DB27A2}: Следующая ошибка возникла в модуле протокола точка-точка (PPP), порт: VPN1-47, пользователь: <Непроверенный пользователь>. Таймаут согласования»Единственное место где я указал vpnserver.firma.local при настройке всего этого хозяйства (RRAS+CA+NAP) — это когда через веб интерфейс на сервере сертификатов СА (http://caserver/srvcert) делал сертификат для ВПН сервера. Там при выборе
шаблона этого сертификата становятся доступны поля и надо было заполнить поле имя. Процесс делал по видео https://www.techdays.ru/videos/1503.html.
Сталкивался кто-то с подобной конфигурацией по настройкам и такой ошибкой?
Для L2TP/IPsec с общим ключом
Важно: L2TP IPsec клиенты, находящиеся за одним NAT’ом, могут испытывать проблемы подключения если их более одного. Решить проблему может помочь
инструкция
. Рекомендуем вместо L2TP IPsec использовать IKEv2 IPsec.
Имя подключения — название создаваемого подключения;
-
Имя или адрес сервера — адрес VPN-сервера;
-
Тип VPN — Протокол L2TP/IPsec с общим ключом;
-
Общий ключ — значение строки PSK в разделе Пользователи -> VPN-подключение -> Основное -> Подключение по L2TP/IPsec;
-
Тип данных для входа — Имя пользователя и пароль;
-
Имя пользователя — имя пользователя, которому разрешено подключение по VPN;
-
Пароль — пароль пользователя.
При настройке подключения по VPN из сети Интернет, в свойствах VPN-подключения нужно указать следующие параметры:
-
Перейдите в Настройки параметров адаптера;
-
Нажмите на созданное подключение правой кнопкой мыши и выберите Свойства;
-
Перейдите во вкладку Безопасность и установите:
-
Шифрование данных — обязательное (отключиться, если нет шифрования)
-
Протокол расширенной проверки подлинности (EAP) — Microsoft защищенный пароль (EAP MSCHAPV2)
-
Если вы создаете VPN-подключение к UTM через проброс портов, рекомендуем выполнить следующие действия:
-
1.
Откройте Редактор реестра;
-
2.
Перейдите в
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesPolicyAgentи создайте DWORD-параметр с именем AssumeUDPEncapsulationContextOnSendRule и значением2;
-
1.
Неправильно указан логин или пароль пользователя. Часто при повторном соединении предлагается указать домен. Старайтесь создавать цифро-буквенные пароли, желательно на латинице для ваших учетных записей. Если есть сомнения в этом пункте, то временно установите логин и пароль пользователю «user» и «123456».
-
2.
Для того, чтобы пакеты пошли через VPN-туннель, надо убедиться, что в настройках этого подключения стоит чекбокс Использовать основной шлюз в удалённой сети в разделе Настройка параметров адаптера -> Правой кнопкой мыши по подключению -> Свойства -> Сеть -> Свойства опции «Протокол Интернета версии 4 (TCP/IPv4)» ->Дополнительно. Если же маршрутизировать все пакеты в этот интерфейс не обязательно, то маршрут надо писать вручную.
-
3.
Подключение происходит через DNAT, т.е. внешний интерфейс Ideco UTM не имеет «белого» IP-адреса, а необходимые для работы порты (500 и 4500) «проброшены» на внешний интерфейс устройства, расположенного перед Ideco UTM и имеющего «белый» IP-адрес. В данном случае VPN-подключение либо вообще не будет устанавливаться, либо будут периодические обрывы. Решение — исключить устройство перед Ideco UTM и указать на внешнем интерфейсе Ideco UTM «белый» IP-адрес, к которому в итоге и будут осуществляться L2TP/IPsec-подключения. Либо используйте протокол SSTP, потому что его проще опубликовать с помощью проброса портов.
-
4.
Если в OC Windows 10 повторно подключиться по L2TP, но при этом использовать невалидный ключ PSK (введя его в дополнительных параметрах (скриншот ниже)), подключение все равно будет установлено успешно. Это связано с особенностями работы ОС.
Убедитесь, что локальная сеть (или адрес на сетевой карте) на удалённой машине не пересекается с локальной сетью организации. Если пересекается, то доступа к сети организации не будет (трафик по таблице маршрутизации пойдёт в физический интерфейс, а не в VPN). Адресацию необходимо менять.
I have the newest version of Strongswan vpn on my ubuntu server running.
I followed this tutorial here and got it to work on my android and Iphone.
Now I want to get it to work on my windows 10 laptop but when I try to connect via the vpn settings in windows I only get a «policy match error» and the event view gives me the error code «13868».
After much googling I still cant find any working solution.
What can I do?
asked Apr 30, 2019 at 10:02
sirzentosirzento
1931 gold badge1 silver badge5 bronze badges
The problem is most likely that the Windows client proposes a weak Diffie-Hellman (DH) group (1024-bit MODP). That group is not used anymore by strongSwan unless the user configures it explicitly.
You have two options:
- Configure Windows to use a stronger DH group. This can be done either
- via Set-VpnConnectionIPsecConfiguration PowerShell cmdlet, which allows enabling stronger DH groups (e.g. group 14/2048-bit MODP or 384-bit ECP) and even other algorithms (e.g. AES-GCM combined-mode encryption/integrity, which is more efficient, but needs to be enabled explicitly on the server too)
- or via registry by adding the DWORD key
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesRasmanParametersNegotiateDH2048_AES256. Set it to1to enable (the other algorithms are still proposed), or2to enforce the use of 256-bit AES-CBC and 2048-bit MODP DH (only these will be proposed).
- Add the proposed, weak DH group (1024-bit MODP) to the IKE proposal on the server (e.g. configure something like
ike=aes256-aes128-sha256-sha1-modp3072-modp2048-modp1024, which adds it at the end so other clients may use stronger DH groups).
Option 1 is definitely preferred.
answered Apr 30, 2019 at 13:16
ecdsaecdsa
3,91515 silver badges29 bronze badges
3
To find out what is the problem you should, as a first step, turn on logging and see what happens during the connection process. Here is the example config I use on my server.
/etc/strongswan.d/charon-logging.conf
charon {
# Section to define file loggers, see LOGGER CONFIGURATION in
# strongswan.conf(5).
filelog {
# <filename> is the full path to the log file.
/var/log/strongswan.log {
# Loglevel for a specific subsystem.
# <subsystem> = <default>
# If this option is enabled log entries are appended to the existing
# file.
append = yes
# Default loglevel.
default = 2
# Enabling this option disables block buffering and enables line
# buffering.
# flush_line = no
# Prefix each log entry with the connection name and a unique
# numerical identifier for each IKE_SA.
ike_name = yes
# Adds the milliseconds within the current second after the
# timestamp (separated by a dot, so time_format should end with %S
# or %T).
# time_add_ms = no
# Prefix each log entry with a timestamp. The option accepts a
# format string as passed to strftime(3).
# time_format =
}
}
}
U can use it and analyze the log file to discover the issue. If you will not able to figure it out, post a connection log here I will try to help you.
answered Apr 30, 2019 at 10:31
3
The Internet Key Exchange version 2 (IKEv2) VPN protocol is the protocol of choice for Windows 10 Always On VPN deployments where the highest levels of security and assurance are required. However, as I’ve written about in the past, often the default IKEv2 security settings are less than desirable. Before using IKEv2 VPN in a production environment the administrator will need to update these security settings accordingly.
Connection Failure
When configuring Windows Server Routing and Remote Access Service (RRAS) or a third-party VPN appliance to support IKEv2 using custom security policies, the administrator may encounter a scenario in which a connection cannot be established due to a policy mismatch error. When the connection attempt fails, an error will be recorded in the Windows Application event log from the RasClient source with Event ID 20227. The error message states the following:
“The user [username] dialed a connection named [connection name] which has failed. The error code returned on failure is 13868.”
Error Code 13868
Error code 13868 translates to ERROR_IPSEC_IKE_POLICY_MATCH. Essentially this error indicates that the IKEv2 security policy on the client did not match the configuration on the server.
Server Configuration
To view the current IKEv2 IPsec policy configuration, open an elevated PowerShell command window and run the following command.
Get-VpnServerIPsecConfiguration
Client Configuration
To ensure interoperability, the VPN client must be configured to use the same IKEv2 security policy as defined on the sever. To view a VPN client’s currently configured IKEv2 security policy, open an elevated PowerShell command window and run the following command.
Get-VpnConnection -Name [connection name] | Select-Object -ExpandProperty IPsecCustomPolicy
Note: If this PowerShell command returns no output, the VPN connection is not using a custom IKEv2 IPsec security policy.
Updating Settings
Guidance for configuring IKEv2 security policies on Windows Server RRAS and Windows 10 can be found here.
NPS Policy
Another common cause of IKEv2 policy mismatch errors is a misconfigured Network Policy Server (NPS) network policy. Specifically, administrators may disable Basic and Strong encryption for MPPE in an attempt to improve security.
The NPS policy for Always On VPN must include Strong encryption at a minimum. Basic and No encryption can be safely disabled.
Summary
IKEv2 policy mismatch errors can be resolved easily by ensuring both the VPN server and client are configured to use the same IPsec security policies. Use the PowerShell commands in the above referenced above to validate settings and make changes when necessary.
Additional Information
Windows 10 Always On VPN IKEv2 Security Configuration
Windows 10 Always On VPN IKEv2 Features and Limitations
Show-VpnConnectionIPsecConfiguration PowerShell script on Github
Set-IKEv2SecurityBaseline PowerShell script on Github