Ipsec windows 10 ошибка сопоставления групповой политики

Я полный профан, искренне надеюсь на помощь простыми словами

На удаленном сервере с OS Debian по вот этому гайду с использованием strongSwan организовал для себя VPN. Все отлично работает на iPhone и Mac, однако для подключения с Windows нужно проделать какие-то дополнительные манипуляции, потому что ни так, ни этак подключится не удается. Ошибки подключения разные, в зависимости от настроек создаваемого подключения в Windows.

Если делать подключение в лоб:

то получаем ошибку сопоставления групповой политики:

В свойствах подключения можно переставить проверку подлинности на «Использовать сертификаты компьютеров»:

правда это ничего не меняет.

Вот этот мануал по 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, понять как одно с другим связано квалификации моей не хватает

Вобщем, достаточно разрозненный набор фактов выглядит вот так, очень прошу помощь от гуру.

Настройка IKEv2 VPN соединения в Windows 10

Выберите Параметры сети и Интернет.

На вкладке VPN нажмите Добавить VPN-подключение.

В разделе Подписки посмотрите IP адреса IKEv2 VPN серверов, Логин и Пароль VPN.

Откройте настройки параметров адаптера.

Откройте свойства IKEv2 VPN-подключения.

Откройте свойства протокола TCP/IPv4.

Перейдите на вкладку дополнительных параметров и установите галку «Использовать основной шлюз в удаленной сети».

Сохраните параметры и подключитесь к IKEv2 VPN.

Источник

question

Windows10 VPN using IPSEC/IKEv2 won’t connect

I have set up a VPN server using IPSEC/IKEv2. Certificates are used for authentication, both for the server and a client.

VPN connection works great with a third party VPN client (Greenbow) but native Windows VPN client won’t even try to connect.

Certificate chain and a user certificate are installed in ‘Local Computer’ certificate storage. I don’t really understand which «sign-in info» is being verified. I have also tried to set up the connection with power shell, but that wouldn’t help either:

System info:
OS Name Microsoft Windows 10 Pro
Version 10.0.18363 Build 18363

How to fix this? I would really like to use VPN client included in Windows10 if only it wasn’t broken.

5 Answers

It is difficult to believe that no IKEv2 messages are being exchanged. Did you perform the Wireshark trace on the VPN server or client? Was Wireshark listening on all network interfaces? Were any capture filters active that might have excluded UDP ports 500 or 4500?

You could try the following steps in a command window running as administrator:

try to connect to the VPN; wait until it fails

issue the command: wevtutil qe /lf /f:text ikev2.etl

examine the output for messages like: «IPsec: Send ISAKMP Packet» and «IPsec: Receive ISAKMP Packet»

If any ISAKMP packets are being sent/received (the progress message «Verifying your sign-in info» suggests very much that packets are being sent and received), then it should be possible to capture them with Wireshark. You could try searching your Wireshark capture for UDP ports 500 and 4500 rather than the VPN server IP address.

Trace shows no ISAKMP packets sent, instead there are many events like this:

WFP is filtering out some packets, however this may have nothing to do with VPN as these event are visible also when I take a trace with no VPN connection trial.

Thank you for posting in Q&A!

According to the errror message, can you check the user account in the VPN connection and the permission&configuration of this account?

Since «Wireshark shows no traffic related to the connection excluding a DNS query.» the Network connectivity between the client and VPN server seems to have some probelm.
Can you ping VPN server from your client?

============================================
If the Answer is helpful, please click «Accept Answer» and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Client certificate is used instead of username/password. VPN server accepts connection based on a CN verified by the client certificate. VPN tunnel using the client certificate works with the 3rd party VPN client SW.

@IsmoM-7569 Hi, Can you ping VPN server from your windows client?

You could try repeating the previous procedure, replacing Microsoft-Windows-WFP with Microsoft-Windows-RRAS.

Below is the trace text that I get using the same set-up (IKEv2 with machine certificates). Check where your trace diverges in substance from mine.

Источник

Windows 10 ikev2 параметр задан неверно

Соединяется с сервером без замечаний. работает без замечаний.

Приходит время через 4 часа для rekeying, сервер шлет соответствующие пакеты, но в ответ получает нечто непечатное, что отражается в следующих записях:

verifying encrypted payload integrity failed
could not decrypt payloads
integrity check failed

initiating IKE_SA rw-cert-windows-10[78] to 115.34.28.6
Mar 2 14:13:07 host12 charon: 16[ENC] generating CREATE_CHILD_SA request 6 [ SA No KE ]
Mar 2 14:13:07 host12 charon: 16[NET] sending packet: from 99.12.3.45[4500] to 115.34.28.6[54856] (245 bytes)
Mar 2 14:13:07 host12 charon: 06[NET] received packet: from 115.34.28.6[54856] to 99.12.3.45[4500] (264 bytes)
Mar 2 14:13:07 host12 charon: 06[ENC] verifying encrypted payload integrity failed
Mar 2 14:13:07 host12 charon: 06[ENC] could not decrypt payloads
Mar 2 14:13:07 host12 charon: 06[IKE] integrity check failed
Mar 2 14:13:07 host12 charon: 06[IKE] CREATE_CHILD_SA response with message ID 6 processing failed
Mar 2 14:13:11 host12 charon: 14[IKE] retransmit 1 of request with message ID 6
Mar 2 14:13:11 host12 charon: 14[NET] sending packet: from 99.12.3.45[4500] to 115.34.28.6[54856] (245 bytes)
Mar 2 14:13:17 host12 charon: 08[NET] received packet: from 115.34.28.6[54856] to 99.12.3.45[4500] (72 bytes)
Mar 2 14:13:17 host12 charon: 08[ENC] verifying encrypted payload integrity failed
Mar 2 14:13:17 host12 charon: 08[ENC] could not decrypt payloads
Mar 2 14:13:17 host12 charon: 08[IKE] integrity check failed
Mar 2 14:13:17 host12 charon: 08[IKE] INFORMATIONAL request with message ID 4 processing failed
Mar 2 14:13:18 host12 charon: 10[IKE] retransmit 2 of request with message ID 6
Mar 2 14:13:18 host12 charon: 10[NET] sending packet: from 99.12.3.45[4500] to 115.34.28.6[54856] (245 bytes)
Mar 2 14:13:18 host12 charon: 13[NET] received packet: from 115.34.28.6[54856] to 99.12.3.45[4500] (72 bytes)
Mar 2 14:13:18 host12 charon: 13[ENC] verifying encrypted payload integrity failed
Mar 2 14:13:18 host12 charon: 13[ENC] could not decrypt payloads
Mar 2 14:13:18 host12 charon: 13[IKE] integrity check failed
Mar 2 14:13:18 host12 charon: 13[IKE] INFORMATIONAL request with message ID 4 processing failed
Mar 2 14:13:19 host12 charon: 15[NET] received packet: from 115.34.28.6[54856] to 99.12.3.45[4500] (72 bytes)
Mar 2 14:13:19 host12 charon: 15[ENC] verifying encrypted payload integrity failed
Mar 2 14:13:19 host12 charon: 15[ENC] could not decrypt payloads
Mar 2 14:13:19 host12 charon: 15[IKE] integrity check failed
Mar 2 14:13:19 host12 charon: 15[IKE] INFORMATIONAL request with message ID 4 processing failed
Mar 2 14:13:22 host12 charon: 12[NET] received packet: from 115.34.28.6[54856] to 99.12.3.45[4500] (72 bytes)
Mar 2 14:13:22 host12 charon: 12[ENC] verifying encrypted payload integrity failed
Mar 2 14:13:22 host12 charon: 12[ENC] could not decrypt payloads
Mar 2 14:13:22 host12 charon: 12[IKE] integrity check failed
Mar 2 14:13:22 host12 charon: 12[IKE] INFORMATIONAL request with message ID 4 processing failed
Mar 2 14:13:29 host12 charon: 09[NET] received packet: from 115.34.28.6[54856] to 99.12.3.45[4500] (72 bytes)
Mar 2 14:13:29 host12 charon: 09[ENC] verifying encrypted payload integrity failed
Mar 2 14:13:29 host12 charon: 09[ENC] could not decrypt payloads
Mar 2 14:13:29 host12 charon: 09[IKE] integrity check failed
Mar 2 14:13:29 host12 charon: 09[IKE] INFORMATIONAL request with message ID 4 processing failed
Mar 2 14:13:31 host12 charon: 11[IKE] retransmit 3 of request with message ID 6
Mar 2 14:13:31 host12 charon: 11[NET] sending packet: from 99.12.3.45[4500] to 115.34.28.6[54856] (245 bytes)
Mar 2 14:13:43 host12 charon: 14[NET] received packet: from 115.34.28.6[54856] to 99.12.3.45[4500] (72 bytes)
Mar 2 14:13:43 host12 charon: 14[ENC] verifying encrypted payload integrity failed
Mar 2 14:13:43 host12 charon: 14[ENC] could not decrypt payloads
Mar 2 14:13:43 host12 charon: 14[IKE] integrity check failed
Mar 2 14:13:43 host12 charon: 14[IKE] INFORMATIONAL request with message ID 4 processing failed
Mar 2 14:13:54 host12 charon: 08[IKE] retransmit 4 of request with message ID 6
Mar 2 14:13:54 host12 charon: 08[NET] sending packet: from 99.12.3.45[4500] to 115.34.28.6[54856] (245 bytes)
Mar 2 14:14:11 host12 charon: 15[NET] received packet: from 115.34.28.6[54856] to 99.12.3.45[4500] (72 bytes)
Mar 2 14:14:11 host12 charon: 15[ENC] verifying encrypted payload integrity failed
Mar 2 14:14:11 host12 charon: 15[ENC] could not decrypt payloads
Mar 2 14:14:11 host12 charon: 15[IKE] integrity check failed
Mar 2 14:14:11 host12 charon: 15[IKE] INFORMATIONAL request with message ID 4 processing failed
Mar 2 14:14:36 host12 charon: 11[IKE] retransmit 5 of request with message ID 6
Mar 2 14:14:36 host12 charon: 11[NET] sending packet: from 99.12.3.45[4500] to 115.34.28.6[54856] (245 bytes)
Mar 2 14:15:08 host12 charon: 14[NET] received packet: from 115.34.28.6[54856] to 99.12.3.45[4500] (72 bytes)
Mar 2 14:15:08 host12 charon: 14[ENC] verifying encrypted payload integrity failed
Mar 2 14:15:08 host12 charon: 14[ENC] could not decrypt payloads
Mar 2 14:15:08 host12 charon: 14[IKE] integrity check failed
Mar 2 14:15:08 host12 charon: 14[IKE] INFORMATIONAL request with message ID 4 processing failed
Mar 2 14:15:52 host12 charon: 10[IKE] giving up after 5 retransmits
Mar 2 14:15:52 host12 charon: 10[IKE] rekeying IKE_SA failed, peer not responding
Mar 2 14:15:52 host12 charon: 10[CFG] lease 192.168.1.85 by ‘CN=Windows_10_Client_5’ went offline

Причем в Windows после этого все равно отображается состояние «Подключено», но сети реально нет.

Что-то похожее было здесь https://wiki.strongswan.org/issues/3208

That it fails is really bad and should cause you to run to Microsoft and complain about it.

Источник

В чем проблема с подключением к ipsec+ikev2 через сертификаты?

Смотрю wireshark’ом на клиенте и tcpdump’ом на сервере.

Проходит так:
клиент запрашивает у сервера ikev_init
сервер отвечает
клиент отправляет свой сертификат и поддерживаемые шифры
сервер их получает и отправляет ответ
клиент не получает этот ответ! (в некоторых сетях тот же самый клиент получает его и тогда подключение к VPN проходит успешно)

Сервер отправляет пакет, но на клиент он не доходит:

На клиенте wireshark’ом этого пакета нет, остальные есть:

В чем может быть проблема?

Такое в некоторых сетях(2ком, некоторые от мгтс). В некоторых сетях от мгтс данный волшебный пакетик доходит и тогда к VPN подключается успешно.

И похожих статей/гайдов еще много. Везде strongswan и без L2TP.

athacker: к сожалению, я не очень прошаренный в таких вещах, так что очень бы помогла wiki/guide.

Правильно ли я понял:
Нужно поднять l2tp туннель с помощью чего-угодно(что порекомендуете?)
уже внутри этого туннеля поднимать шифрование(тогда тут не понимаю, как заставить strongswan, например, влезать в этот туннель?)

IPSec определяет, какой трафик шифровать, на основе policy. Полиси включает в себя набор IP-адресов и/или подсетей и список портов. То есть, в полиси можно указать: «трафик между такой-то и такой-то подсетью необходимо шифровать». И тогда туннель будет строиться на L2TP, а внутри него трафик уже будет шифроваться IPSec’ом.

В стронгсване это делается так:

conn hm
left=192.168.3.1
leftsubnet=192.168.4.17/32
right=192.168.17.50
rightsubnet=192.168.1.0/28
type=tunnel
auto=start

Недавно был вынужден временно переключиться на злополучный МГТС*, и тоже столкнулся со схожей проблемой. IKEv2 RSA не работает на Windows, в то время как L2TP+IPsec (IKEv1 PSK) спокойно заводилось. При этом на iOS 11.1 beta 5 IKEv2 RSA также спокойно заводилось.

После проверки через WireShark выяснилось, что пакеты в сети МГТСа фрагментируются (забегая вперёд скажу сразу, что принудительное понижение MTU на клиентском интерфейсе ни к чему не привело).
(естественно это было бы невозможно выявить при использовании жёсткого фильтра на порты UDP 500 и 4500, как это было показано на скриншоте в изначальном вопросе)

И с этим вроде бы должна справляться опция fragmentation = yes на стороне strongSwan, однако Windows 10, по всей видимости, так и не научилась работать с фрагментированными пакетами в IKEv2:

Windows clients support IKEv1 fragmentation, but not IKEv2 fragmentation.

* — после подключения белого IP-адреса (МГТС по умолчанию всех прячет за NAT) указанная проблема исчезла.

Источник

Почему я люблю IKEv2 больше других VPN

Сейчас все вокруг настраивают VPN для удаленных сотрудников. Мне больно смотреть, как люди устанавливают монструозные глючные программы, настраивают какие-то сертификаты, устанавливают драйвера TUN/TAP и делают множество сложных операций, в то время как лучшее решение уже встроено в операционную систему.

IKEv2 — это современный протокол VPN, разработанный Microsoft и Cisco. Он используется по умолчанию для новых VPN-подключений в Windows, macOS, iOS. Он быстрее и безопаснее большинства VPN-протоколов и может легко настраиваться на стороне клиента в два клика без использования сторонних программ.

Я считаю, что IPsec IKEv2 отлично подходит не только для соединения серверов, но и для обычных VPN-подключений конечных пользователей. В этом посте я постараюсь убедить вас использовать IPsec IKEv2 для обычных домашних пользователей вместо OpenVPN.

IKEv2 быстрее

При прочих равных условиях, IKEv2 будет всегда быстрее OpenVPN. Это особенно заметно на маломощных системах с медленной памятью, например на роутерах или одноплатных компьютерах.

Дело в том, что IPsec работает в контексте ядра операционной системы, а OpenVPN в контексте пользователя (userspace), и на обработку каждого пакета происходит переключение контекста между процессами ядра и процессами пользователя. Это влияет как на пропускную способность, так и на задержки.

Сравнение задержек для разных протоколов VPN.

Скриншот выше показывает разницу в задержке в два раза между IPsec и OpenVPN. Разумеется, разницу в 1мс невозможно заметить на глаз, но при нагрузке на систему эти значения могут значительно изменяться. Кроме того, реальные показатели сильно зависят от характеристик конкретной системы, поэтому я не буду приводить абсолютные цифры для сравнения двух протоколов. Задержки очень важны при использовании голосовой и видеосвязи через VPN.

По моим субъективным ощущениям IKEv2 на Windows 10 работает заметно отзывчивее чем OpenVPN. Ведь реальное использование десктопного компьютера сильно отличается от синтетических тестов VPN-протоколов. Нагрузка на процессор и память непостоянная, пользователь может запускать ресурсоемкие программы, все это будет влиять на показатели.

IKEv2 проще в настройке

Все современные операционные системы (кроме Android) поддерживают IPsec IKEv2 прямо из коробки. Не нужно устанавливать никакие программы, драйвера виртуальных адаптеров TUN/TAP и прочее. Всё управление VPN происходит из системного меню.

При этом настройку на клиенте можно упростить до трех строчек:

Настройка на Windows 10

Мастер настройки VPN вызывается из меню подключения к WiFi. С настройкой одного окна справится пользователь любой квалификации. Созданное подключение активируется из меню со списком WiFi-сетей.

Интерфейс настройки нового IKEv2 подключения в Windows 10

В macOS поддерживается IKEv2 начиная с версии 10.11 (El Capitan). Создание подключения происходит через меню настроек сети.

Добавляем новое подключение. В качестве имени подключения задаем любое произвольное имя.

Для проверки подлинности сертификата, нужно указать доменное имя. При этом в поле «Server Address» можно указать IP-адрес сервера, а домен только в «Remote ID», тогда для подключения не будет выполняться DNS-резолв, и оно будет происходить чуть быстрее.

Логин и пароль пользователя указываем из файла /etc/ipsec.secrets

Настройку iOS можно выполнить вручную через мастер, но намного удобнее использовать профиль автоконфигурации mobileconfig.

Ручная настройка по смыслу аналогична десктопной macOS:

IKEv2 это безопасно

На предыдущем шаге мы выяснили, что для настройки подключения достаточно логина и пароля. Но как клиенту проверить, что подключение не прослушивается, не подменяются данные и сервер действительно тот, за кого себя выдает? Для этого используются обычные SSL-сертификаты, которые мы привыкли использовать для веб-сайтов и HTTPS.

Клиент устанавливает защищенный SSL-тоннель с сервером, и уже внутри него передается логин-пароль. По умолчанию в Windows и macOS для передачи пароля используется алгоритм mschapv2. Таким образом с помощью SSL-сертификата клиент проверяет подлинность сервера, а по логину-паролю сервер проверяет подлинность клиента.

Сервер IKEv2 может использовать один и тот же сертификат вместе с веб-сервером, например от популярного Let’s Encrypt. Это сильно упрощает управлением сертификатами.

Такая же модель используется в OpenVPN, и при желании в нем можно использовать сертификат от Lets Encrypt, однако администратору в любом случае потребуется передать пользователю файл для настройки VPN.

Настраиваем IKEv2 сервер

Развернуть свой IKEv2 сервер можно за пару минут с помощью скриптов автоматической установки или используя готовые контейнеры. Использовать docker не рекомендуется, так как его сетевая подсистема снижает производительность IPsec на дешевых тарифах VPS. Вы также можете настроить IKEv2-сервер вручную, на Хабре есть статьи с примерами настройки сервера Strongswan.

Мы будем использовать один из наиболее удачных вариантов скриптов автонастройки github.com/jawj/IKEv2-setup
Этот скрипт хорош тем, что использует сертификаты от Lets Encrypt и автоматически генерирует валидный сертификат.

Шаг 1: Выбор сервера

Для запуска VPN сервера нам потребуется VDS. Подойдет самая простая конфигурация с одним ядром процессора. Скрипт из нашего примера лучше всего протестирован на Ubuntu 18.04, поэтому при создании сервера выбираем этот образ ОС.

Ждем окончания установки сервера и копируем реквизиты для подключения. Пароль root придет на почту, либо его можно задать вручную через веб-интервейс. Далее все команды мы вводим

Шаг 2: Установка Strongswan

Подключаемся SSH-клиентом и запускаем скрипт установки:

Шаг 3: Настройка клиента

Введенные реквизиты пользователя VPN теперь нужно использовать для настройки на клиенте. Важно использовать именно то доменное имя, которое вы вводили в Hostname for VPN.

Шаг 4: Добавление новых пользователей

Чтобы добавить нового пользователя в уже созданный сервер, отредактируйте файл /etc/ipsec.sectes.

После добавления пользователя выполните команду ipsec secrets чтобы Strongswan перечитал конфиг.

Заключение

Мы рассмотрели удобство IKEv2 со стороны пользователя. Администрирование такого сервера не сложнее, а иногда даже проще чем OpenVPN. Если вы только планируете организовать удаленный доступ для своих сотрудников, обязательно посмотрите в сторону IKEv2. Не заставляйте своих пользователей устанавливать лишние программы, если все необходимое уже есть на их компьютере. Это удобнее, безопаснее и намного прогрессивнее.

Источник