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
- Remove From My Forums
-
Общие обсуждения
-
Доброго времени суток имеется win 7 при подключении через ikev2 vpn ошибка 13868 ошибка сопоставления групповой политики я по подключаюсь к windows server 2012 r2 там поднята роль маршрутизация и удаленный доступ чего
ошибка скажите?На других машинах windows7,8.10 проблем нет с ikev2 vpn !
-
Изменено
Александр700
9 февраля 2019 г. 0:41 -
Изменен тип
Anton Sashev Ivanov
20 февраля 2019 г. 8:14
Обсуждение
-
Изменено
Все ответы
-
Попробуйте рекомендации из топика:
ikev2, anyone got it working?
Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется «как есть» без каких-либо гарантий.
-
Попробуйте рекомендации из топика:
ikev2, anyone got it working?
Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется «как есть» без каких-либо гарантий.
где попробувать на серваке 2012r2 или на windows 7?
-
Изменено
Александр700
10 февраля 2019 г. 3:08
-
Изменено
- Печать
Страницы: [1] Вниз
Тема: бьюсь с VPN IPsec IKEv2 strongSwan на Ubuntu-server (Прочитано 2520 раз)
0 Пользователей и 1 Гость просматривают эту тему.
zaka4kin
Доброго времени…
на виртуальной обкатке имею:
Ubuntu-server 20.04 + strongSwan 5.8.2
и
Win10 20H2 x64.
обе лежат в одной сети.
ipsec.conf срисовал отсюда. оттуда же и ipsec.secrets.
подключаюсь… выползла ошибка 13868, пофиксил.
прописал пока «ike=aes256-aes128-sha256-sha1-modp3072-modp2048-modp1024″…
НО винда не унимается… выдаёт «ошибку обработки полезных данных ke» за номером 13833.
может кто сталкивался?
второй вопрос — реально ли замутить VPN IPsec IKEv2 без центра сертификации, генерации сертификата и прочего?
(прошу прощения за возможно неправильные термины/понятия. только начал щупать данную тему).
вопрос возник потому, что у них то инфа про это есть
https://www.strongswan.org/testing/testresults/ikev2/rw-psk-ipv4/.
яж не ошибся, там чисто по ключу подключение, без сертификатов всяких?
Спасибо!
AlexDem
яж не ошибся, там чисто по ключу подключение, без сертификатов всяких?
А в чем проблема сделать самому сертификат Х.509 сервера, клиента, ключей и пр., и пользоваться этим всем хозяйством?
Принцип безопасного соединения заключается в том, что поскольку те открытые ключи, которыми обмениваются клиент и сервер передаются изначально по незащищенному каналу и могут быть перехвачены, расшифрованы и подменены, поэтому достоверность ключей по которым клиент и сервер «узнают» друг-друга подтверждаются сертификатами, которые хранятся локально на клиенте и сервере и никуда не передаются во время сеанса связи, а следовательно не могут быть взломаны (ну, если их не похитили отдельно).
Поэтому VPN без сертификата это просто шифрование закрытым симметричным ключом.
zaka4kin
Доброго времени всем…
собрал стенд на virtualbox:
Win-клиент — NAT (10.0.10.0/24) — Ubuntu-Server 20.04 + VPN IKEv2-сервер (10.0.10.10)
адрес хоста 10.89.7.2. UDP 500, 4500 пробросил с 10.89.7.2 на 10.0.10.10 в Файл -> Настройки -> Сеть.
отключил брандмауэр на Windows и UFW на Ubuntu-server (подстраховался)…
подготовка сертификатов:
ipsec.conf:
пробовал и
left=%defaultroute
leftfirewall=yes
ipsec.secrets
не хочет подключаться и всё, «ошибка сопоставления групповой политики».
если и сервер и клиент в одной подсети, то подключение проходит,
без
[code]left=%defaultroute
leftfirewall=yes
естественно.
Что я упускаю из виду?
- Печать
Страницы: [1] Вверх
Пролог:
Прочел все мануалы по IPsec на DFL.
Затем прочел все мануалы по IPsec на других устройствах, которые смог найти.
Попробовал различные комбинации.
Вводная: имеется DFL-260 со статическим белым адресом с одноранговой локалью за ним. Хочу подключаться к этой локалке через IPsec туннель с мобильной связи, из любой точки. Т. е. подключаться придется зачастую с динамического серого (NAT) адреса.
Пробовал подключаться:
1. штатными средствами Win7 (L2TP IPsec VPN, IKEv2) (NAT);
2. штатными средствами Android (L2TP/IPSec PSK, IPSec Xauth PSK) (мобильный интернет — NAT);
3. штатными средствами Ios (IKEv2, IPSec, L2TP) (мобильный интернет — NAT).
Все безрезультатно.
1. При попытке подключения с Win7 по L2TP IPsec VPN, выдается ошибка 788: Попытка L2TP-подключения не удалась, поскольку на уровне безопасности не удалось согласовать параметры с удаленным компьютером.
В логах на DFL следующее:
Код:
2018-08-15
12:27:15
Info
IPSEC
1800904 ike_sa_created
ipsec_if=dynamic_ipsec local_ip=<ВНЕШНИЙ IP DFL> local_port=4500 remote_iface=wan remote_ip=<ВНЕШНИЙ IP компа> remote_port=57944 local_id=<ВНЕШНИЙ IP DFL> remote_id=<ЛОКАЛЬНЫЙ IP компа в его локальной сети>local_ike_spi=0xa1f871a70951d192 remote_ike_spi=0x53bc392752c1ec0c initiator=FALSE algorithms=aes256-cbc/hmac-sha1-96/hmac-sha1/MODP_2048 mode=Main lifetime=28800 ikeversion=1 local_behind_nat=TRUE remote_behind_nat=TRUE initial_contact=FALSE
2018-08-15
12:27:15
Info
IPSEC
1802023 ike_sa_statistics
done=183 success=19 failed=164
2018-08-15
12:27:15
Info
IPSEC
1802049 [b]ipsec_sa_failed[/b]
ipsec_sa_disabled
statusmsg=»No proposal chosen» reason=»Peer IP address mismatch. Local Traffic Selector mismatch.» local_peer=»<ВНЕШНИЙ IP DFL>:4500 ID <ВНЕШНИЙ IP DFL>» remote_peer=»<ВНЕШНИЙ IP компа>:57944 ID <ЛОКАЛЬНЫЙ IP компа в его локальной сети>» ike_spi_i=0x53bc392752c1ec0c ike_spi_r=0xa1f871a70951d192
2018-08-15
12:27:15
Notice
IPSEC
1800105 ike_delete_notification
local_ip=<ВНЕШНИЙ IP DFL> remote_ip=<ВНЕШНИЙ IP компа> cookies=0x53bc392752c1ec0ca1f871a70951d192 reason=»Received delete notification»
2018-08-15
12:27:15
Info
IPSEC
1800906 ike_sa_deleted
ipsec_if=dynamic_ipsec local_ip=<ВНЕШНИЙ IP DFL> local_port=4500 remote_iface=wan remote_ip=<ВНЕШНИЙ IP компа> remote_port=57944 local_id=<ВНЕШНИЙ IP DFL> remote_id=<ЛОКАЛЬНЫЙ IP компа в его локальной сети> local_ike_spi=0xa1f871a70951d192 remote_ike_spi=0x53bc392752c1ec0c peer_dead=FALSE
Я так понимаю, первая фаза(ike) проходит нормально, а вторая(ipsec) прерывается из-за несоответствия внешнего ip и «id» инициатора туннеля. Если я прав, то что с этим делать?
При попытке подключения по IKEv2, Win7 выдает ошибку 13868: Ошибка сопоставления групповой политики.
В логах DFL следующее:
Код:
2018-08-15
12:40:56
Error
IPSEC
1802221 no_matching_tunnel_found
packet_will_be_discarded
localaddr=<ВНЕШНИЙ IP DFL> remoteaddr=<ВНЕШНИЙ IP компа> srcif=wan
2018-08-15
12:40:56
Warning
IPSEC
1802022 ike_sa_failed
no_ike_sa
statusmsg=»No proposal chosen» reason=»» local_peer=»<ВНЕШНИЙ IP DFL>:500 ID (null)» remote_peer=»<ВНЕШНИЙ IP компа>:500 ID (null)» spi_i=0x1960bcb26ab80e2c spi_r=0x6460b7a0d3e77fc4 initiator=FALSE
2018-08-15
12:40:56
Info
IPSEC
1802023 ike_sa_statistics
done=204 success=19 failed=185
2. При попытке подключения с Android по L2TP/IPSec PSK, соединение висит в состоянии «подключение», затем, спустя секунд 30 — «сбой».
В логах DFL следующее:
Код:
2018-08-15
12:44:57
Error
IPSEC
1802221 no_matching_tunnel_found
packet_will_be_discarded
localaddr=<ВНЕШНИЙ IP DFL> remoteaddr=<ВНЕШНИЙ IP Android> srcif=wan
2018-08-15
12:44:57
Warning
IPSEC
1800107 ike_invalid_proposal
local_ip=<ВНЕШНИЙ IP DFL> remote_ip=<ВНЕШНИЙ IP Android> cookies=0xd473938d4b3cf3eb5230d23d5b24cf6d reason=»Could not find acceptable proposal»
2018-08-15
12:44:57
Warning
IPSEC
1802022 ike_sa_failed
no_ike_sa
statusmsg=»No proposal chosen» reason=»» local_peer=»<ВНЕШНИЙ IP DFL>:500 ID (null)» remote_peer=»<ВНЕШНИЙ IP Android>:500 ID (null)» spi_i=0xd473938d4b3cf3eb spi_r=0x5230d23d5b24cf6d initiator=FALSE
2018-08-15
12:44:57
Info
IPSEC
1802023 ike_sa_statistics
done=211 success=19 failed=192
Тут, я так понимаю, не угадал с набором алгоритмов первой фазы. Как их следует изменить?
При попытке подключения с Android по IPSec Xauth PSK, соединение висит в состоянии «подключение», затем, спустя секунд 30 — «сбой».
В логах DFL то же самое. (хотя, при каких-то других параметрах, в логе было что-то похожее на несоответствие IP и ID)
3. При попытках подключения Ios по IKEv2 и IPSec содержимое лога идентичное ситуации, когда неверно подобраны алгоритмы 1 фазы.
При попытке подключения по L2TP — несоответствие IP и ID.
Как быть, куда копать? Вообще, возможно ли поднятие туннеля в таких условиях?
Настройки IPsec:
Вложение:
Комментарий к файлу: Настройки IPsec 1
IPSec_01.jpg [ 53.82 KiB | Просмотров: 6270 ]
Вложение:
Комментарий к файлу: Настройки IPSec 2
IPSec_02.jpg [ 77.54 KiB | Просмотров: 6270 ]
Вложение:
Комментарий к файлу: Настройки IPsec 3
IPSec_03.jpg [ 98.89 KiB | Просмотров: 6270 ]
Последний раз редактировалось aNGEl0 Ср авг 15, 2018 13:01, всего редактировалось 1 раз.
I’ve tried all of the above and created a simple powershell script that does all of the configuration including adding the registry entry for behind a NAT firewall and using DH Group 14.
I’m still getting an 809 error when the Windows 10 computer is behind a pfSense router. I.e. if I have my surface pro hooked up to teathering on my android phone which has NAT then the Surface Pro will connect to the pFsense VPN no problem.
If however i have my surface pro at work behind work’s pfSense router and try and connect it to my home pfSense VPN with ipSec IKEv2 then it refuses to connect with 809 error and then a 631 informational message in the logs.
Using a Mac it works fine. Just Windows 10 that has issues.
On the client firewall version of pfSense outbound rules are set to automatic.
Any ideas as to what the problem could be? (The VPN is setup according to the ipSec and MSCHAP documentation and I’ve checked multiple times.
Here’s the pfsense host log too which seems to indicate that it’s working but then drops:
Jan 23 12:05:34
charon
02[JOB] <con1|28>deleting half open IKE_SA after timeout
Jan 23 12:05:06
charon
02[NET] <con1|28>sending packet: from 50.233.196.210[4500] to 10.100.0.63[4500] (1712 bytes)
Jan 23 12:05:06
charon
02[IKE] <con1|28>received retransmit of request with ID 1, retransmitting response
Jan 23 12:05:06
charon
02[ENC] <con1|28>parsed IKE_AUTH request 1 [ IDi CERTREQ N(MOBIKE_SUP) CPRQ(ADDR DNS NBNS SRV ADDR6 DNS6 SRV6) SA TSi TSr ]
Jan 23 12:05:06
charon
02[NET] <con1|28>received packet: from 10.100.0.63[4500] to 50.233.196.210[4500] (1328 bytes)
Jan 23 12:05:05
charon
02[NET] <con1|28>sending packet: from 50.233.196.210[4500] to 10.100.0.63[4500] (1712 bytes)
Jan 23 12:05:05
charon
02[IKE] <con1|28>received retransmit of request with ID 1, retransmitting response
Jan 23 12:05:05
charon
02[ENC] <con1|28>parsed IKE_AUTH request 1 [ IDi CERTREQ N(MOBIKE_SUP) CPRQ(ADDR DNS NBNS SRV ADDR6 DNS6 SRV6) SA TSi TSr ]
Jan 23 12:05:05
charon
02[NET] <con1|28>received packet: from 10.100.0.63[4500] to 50.233.196.210[4500] (1328 bytes)
Thanks!</con1|28></con1|28></con1|28></con1|28></con1|28></con1|28></con1|28></con1|28></con1|28>