Describe the issue
When trying to connect to IKEv2 VPN I get a policy match error as pictured below.
Starting Pluto (Libreswan Version 4.5 IKEv2 IKEv1 XFRM XFRMI esp-hw-offload FORK PTHREAD_SETSCHEDPRIO NSS (IPsec profile) (native-PRF) SYSTEMD_WATCHDOG LIBCAP_NG AUTH_PAM NETWORKMANAGER CURL(non-NSS)) pid:2443
core dump dir: /run/pluto
secrets file: /etc/ipsec.secrets
leak-detective enabled
NSS crypto [enabled]
XAUTH PAM support [enabled]
initializing libevent in pthreads mode: headers: 2.1.12-stable (2010c00); library: 2.1.12-stable (2010c00)
NAT-Traversal support [enabled]
Encryption algorithms:
AES_CCM_16 {256,192,*128} IKEv1: ESP IKEv2: ESP FIPS aes_ccm, aes_ccm_c
AES_CCM_12 {256,192,*128} IKEv1: ESP IKEv2: ESP FIPS aes_ccm_b
AES_CCM_8 {256,192,*128} IKEv1: ESP IKEv2: ESP FIPS aes_ccm_a
3DES_CBC [*192] IKEv1: IKE ESP IKEv2: IKE ESP FIPS NSS(CBC) 3des
CAMELLIA_CTR {256,192,*128} IKEv1: ESP IKEv2: ESP
CAMELLIA_CBC {256,192,*128} IKEv1: IKE ESP IKEv2: IKE ESP NSS(CBC) camellia
AES_GCM_16 {256,192,*128} IKEv1: ESP IKEv2: IKE ESP FIPS NSS(GCM) aes_gcm, aes_gcm_c
AES_GCM_12 {256,192,*128} IKEv1: ESP IKEv2: IKE ESP FIPS NSS(GCM) aes_gcm_b
AES_GCM_8 {256,192,*128} IKEv1: ESP IKEv2: IKE ESP FIPS NSS(GCM) aes_gcm_a
AES_CTR {256,192,*128} IKEv1: IKE ESP IKEv2: IKE ESP FIPS NSS(CTR) aesctr
AES_CBC {256,192,*128} IKEv1: IKE ESP IKEv2: IKE ESP FIPS NSS(CBC) aes
NULL_AUTH_AES_GMAC {256,192,*128} IKEv1: ESP IKEv2: ESP FIPS aes_gmac
NULL [] IKEv1: ESP IKEv2: ESP
CHACHA20_POLY1305 [*256] IKEv1: IKEv2: IKE ESP NSS(AEAD) chacha20poly1305
Hash algorithms:
MD5 IKEv1: IKE IKEv2: NSS
SHA1 IKEv1: IKE IKEv2: IKE FIPS NSS sha
SHA2_256 IKEv1: IKE IKEv2: IKE FIPS NSS sha2, sha256
SHA2_384 IKEv1: IKE IKEv2: IKE FIPS NSS sha384
SHA2_512 IKEv1: IKE IKEv2: IKE FIPS NSS sha512
PRF algorithms:
HMAC_MD5 IKEv1: IKE IKEv2: IKE native(HMAC) md5
HMAC_SHA1 IKEv1: IKE IKEv2: IKE FIPS NSS sha, sha1
HMAC_SHA2_256 IKEv1: IKE IKEv2: IKE FIPS NSS sha2, sha256, sha2_256
HMAC_SHA2_384 IKEv1: IKE IKEv2: IKE FIPS NSS sha384, sha2_384
HMAC_SHA2_512 IKEv1: IKE IKEv2: IKE FIPS NSS sha512, sha2_512
AES_XCBC IKEv1: IKEv2: IKE native(XCBC) aes128_xcbc
Integrity algorithms:
HMAC_MD5_96 IKEv1: IKE ESP AH IKEv2: IKE ESP AH native(HMAC) md5, hmac_md5
HMAC_SHA1_96 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS NSS sha, sha1, sha1_96, hmac_sha1
HMAC_SHA2_512_256 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS NSS sha512, sha2_512, sha2_512_256, hmac_sha2_512
HMAC_SHA2_384_192 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS NSS sha384, sha2_384, sha2_384_192, hmac_sha2_384
HMAC_SHA2_256_128 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS NSS sha2, sha256, sha2_256, sha2_256_128, hmac_sha2_256
HMAC_SHA2_256_TRUNCBUG IKEv1: ESP AH IKEv2: AH
AES_XCBC_96 IKEv1: ESP AH IKEv2: IKE ESP AH native(XCBC) aes_xcbc, aes128_xcbc, aes128_xcbc_96
AES_CMAC_96 IKEv1: ESP AH IKEv2: ESP AH FIPS aes_cmac
NONE IKEv1: ESP IKEv2: IKE ESP FIPS null
DH algorithms:
NONE IKEv1: IKEv2: IKE ESP AH FIPS NSS(MODP) null, dh0
MODP1024 IKEv1: IKE ESP AH IKEv2: IKE ESP AH NSS(MODP) dh2
MODP1536 IKEv1: IKE ESP AH IKEv2: IKE ESP AH NSS(MODP) dh5
MODP2048 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS NSS(MODP) dh14
MODP3072 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS NSS(MODP) dh15
MODP4096 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS NSS(MODP) dh16
MODP6144 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS NSS(MODP) dh17
MODP8192 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS NSS(MODP) dh18
DH19 IKEv1: IKE IKEv2: IKE ESP AH FIPS NSS(ECP) ecp_256, ecp256
DH20 IKEv1: IKE IKEv2: IKE ESP AH FIPS NSS(ECP) ecp_384, ecp384
DH21 IKEv1: IKE IKEv2: IKE ESP AH FIPS NSS(ECP) ecp_521, ecp521
DH31 IKEv1: IKE IKEv2: IKE ESP AH NSS(ECP) curve25519
testing CAMELLIA_CBC:
Camellia: 16 bytes with 128-bit key
Camellia: 16 bytes with 128-bit key
Camellia: 16 bytes with 256-bit key
Camellia: 16 bytes with 256-bit key
testing AES_GCM_16:
empty string
one block
two blocks
two blocks with associated data
testing AES_CTR:
Encrypting 16 octets using AES-CTR with 128-bit key
Encrypting 32 octets using AES-CTR with 128-bit key
Encrypting 36 octets using AES-CTR with 128-bit key
Encrypting 16 octets using AES-CTR with 192-bit key
Encrypting 32 octets using AES-CTR with 192-bit key
Encrypting 36 octets using AES-CTR with 192-bit key
Encrypting 16 octets using AES-CTR with 256-bit key
Encrypting 32 octets using AES-CTR with 256-bit key
Encrypting 36 octets using AES-CTR with 256-bit key
testing AES_CBC:
Encrypting 16 bytes (1 block) using AES-CBC with 128-bit key
Encrypting 32 bytes (2 blocks) using AES-CBC with 128-bit key
Encrypting 48 bytes (3 blocks) using AES-CBC with 128-bit key
Encrypting 64 bytes (4 blocks) using AES-CBC with 128-bit key
testing AES_XCBC:
RFC 3566 Test Case 1: AES-XCBC-MAC-96 with 0-byte input
RFC 3566 Test Case 2: AES-XCBC-MAC-96 with 3-byte input
RFC 3566 Test Case 3: AES-XCBC-MAC-96 with 16-byte input
RFC 3566 Test Case 4: AES-XCBC-MAC-96 with 20-byte input
RFC 3566 Test Case 5: AES-XCBC-MAC-96 with 32-byte input
RFC 3566 Test Case 6: AES-XCBC-MAC-96 with 34-byte input
RFC 3566 Test Case 7: AES-XCBC-MAC-96 with 1000-byte input
RFC 4434 Test Case AES-XCBC-PRF-128 with 20-byte input (key length 16)
RFC 4434 Test Case AES-XCBC-PRF-128 with 20-byte input (key length 10)
RFC 4434 Test Case AES-XCBC-PRF-128 with 20-byte input (key length 18)
testing HMAC_MD5:
RFC 2104: MD5_HMAC test 1
RFC 2104: MD5_HMAC test 2
RFC 2104: MD5_HMAC test 3
1 CPU cores online
starting up 1 helper threads
started thread for helper 0
using Linux xfrm kernel support code on #1 SMP Debian 5.10.70-1 (2021-09-30)
systemd watchdog for ipsec service configured with timeout of 200000000 usecs
watchdog: sending probes every 100 secs
seccomp security for helper not supported
seccomp security not supported
"l2tp-psk": added IKEv1 connection
"xauth-psk": added IKEv1 connection
"ikev2-cp": loaded private key matching left certificate 'dkay.xyz'
"ikev2-cp": added IKEv2 connection
listening for IKE messages
Kernel supports NIC esp-hw-offload
adding UDP interface ens0 x.x.x.x:500
adding UDP interface ens0 x.x.x.x:4500
adding UDP interface lo 127.0.0.1:500
adding UDP interface lo 127.0.0.1:4500
forgetting secrets
loading secrets from "/etc/ipsec.secrets"
packet from x.x.x.x:500: ISAKMP_v2_IKE_SA_INIT message received on x.x.x.x:500 but no suitable connection found with IKEv2 policy
packet from x.x.x.x:500: responding to IKE_SA_INIT (34) message (Message ID 0) with unencrypted notification NO_PROPOSAL_CHOSEN
-
-
danergo
Member Candidate
- Posts: 191
- Joined: Tue Dec 24, 2019 8:49 pm
IKE2 IPSec VPN: Windows claims policy match error
Sat Aug 10, 2024 4:09 pm
Hi,
I’ve setup an IKE2 IPSec VPN server on my MTIK.
Android phone can perfectly connect to it, without any special thing (only I had to import the client certificate to it).
Same server, but with Windows 11 client (client certificate has been imported to automatic store), but now VPN connection fails with this below error message:
Policy match error. It must been a Windows thing, because I tried logging IPSec on TIK, but it didn’t show anything during Windows11 client connection.
I know this is not a MikroTik thing, but maybe someone had the same problem with Windows11.
Note: I have imported both CA and Client certificates on Win11 to automatic stores, and then moved CA to «Trusted Root Certification Authorities».
My client certificate is placed (automatically) to «People» store, its «intended purpose is «Client Authentication».
My config is based on this guide: viewtopic.php?p=961983
What could be the problem?
-
sindy
Forum Guru
- Posts: 11558
- Joined: Mon Dec 04, 2017 9:19 pm
Re: IKE2 IPSec VPN: Windows claims policy match error
Sat Aug 10, 2024 4:44 pm
I haven’t tried with Windows 11 yet, but with Windows 10 and RouterOS 6, the certificate issued for the Windows themselves had to be used as a machine certificate, not user («people») one.
However, the error message does not look like an authentication error, as it mentions policies, not credentials. It may be simply incorrect, but the IPsec log from the Mikrotik may still show something.
And a blind shot without seeing your actual configuration — Windows (10 in my case) do not like the src-address in the policy template you use to be set to anything else than 0.0.0.0/0.
Slightly off topic, regarding the authentication of the Windows client to the server using a certificate: the last time I tried, it was not possible to import the client certificate without entering the password for the private key. So instead of having to request the password to «unlock» the certificate key each time when connecting to the VPN, the Windows machine could connect to the VPN server at any time without asking for anything. Due to this, as soon as User Manager 5 become available in RouterOS 7, I have switched to EAP authentication where the Windows VPN client checks the server certificate but asks the user for username and password to authenticate itself to the server. And since Mikrotik has added TOTP to their RADIUS server (user manager), you can even use 2-factor authentication this way.
-
TheCat12
Long time Member
- Posts: 546
- Joined: Fri Dec 31, 2021 9:13 pm
Re: IKE2 IPSec VPN: Windows claims policy match error
Sat Aug 10, 2024 6:08 pm
Based on previous experience with setting up IKEv2 on Windows, I suspect that encryption methods can’t be negotiated between the parties. To troubleshoot that we will need apart from an exported config a log print with IPsec logging turned on:
/system logging
add topics=ipsec,!debug
-
-
danergo
Member Candidate
- Posts: 191
- Joined: Tue Dec 24, 2019 8:49 pm
Topic Author
Re: IKE2 IPSec VPN: Windows claims policy match error
Mon Aug 12, 2024 10:34 am
Thank you, I managed to get a little bit deeper info from your recommended log: it turned out Win11 still insist on using modp1024 (whereas Android devices tend to accept higher DHs, like modp2048).
Now, setting everything to modp1024 I managed to get further, but Windows still fails to establish connection:
Now I have promising lines in this ipsec (ipsec && !packet) log:
Aug/12/2024 09:17:24 ipsec ipsec-start: matched proposal:
Aug/12/2024 09:17:24 ipsec ipsec-start: peer is MS Windows (ISAKMPOAKLEY 9)
Aug/12/2024 09:17:24 ipsec,info ipsec-start: acquired a.b.c.d address for x.y.z.w, CN=xxx
Aug/12/2024 09:17:24 ipsec ipsec-start: matched proposal:
Aug/12/2024 09:17:24 ipsec ipsec-start: ike auth: finish
I do also have a suspicious line:
Aug/12/2024 09:17:24 ipsec,debug ipsec-start: ignoring unterminated SAN: DNS: ::myveryownsubdomain.mydomain.net
Also, continuing good ones:
Aug/12/2024 09:17:25 ipsec ipsec-start: IPsec-SA established: a.b.c.d[38820]->x.y.z.w[4500] spi=0x4b7e148
Aug/12/2024 09:17:25 ipsec ipsec-start: IPsec-SA established: x.y.z.w[4500]->a.b.c.d[38820] spi=0x7f4bbf16
And now the last lines where it fails:
Aug/12/2024 09:19:24 ipsec ipsec-start: sending dpd packet
Aug/12/2024 09:19:24 ipsec ipsec-start: <- ike2 request, exchange: INFORMATIONAL:0 a.b.c.d[38820] 3088ca4e01e54a7f:c424a7ed0bb9b162
Aug/12/2024 09:19:24 ipsec,debug ipsec-start: ===== sending 160 bytes from x.y.z.w[4500] to a.b.c.d[38820]
Aug/12/2024 09:19:24 ipsec,debug ipsec-start: 1 times of 164 bytes message will be sent to a.b.c.d[38820]
Aug/12/2024 09:19:29 ipsec ipsec-start: dpd: retransmit
Aug/12/2024 09:19:29 ipsec,debug ipsec-start: ===== sending 160 bytes from x.y.z.w[4500] to a.b.c.d[38820]
Aug/12/2024 09:19:29 ipsec,debug ipsec-start: 1 times of 164 bytes message will be sent to a.b.c.d[38820]
Aug/12/2024 09:19:29 ipsec,debug ipsec-start: KA: x.y.z.w[4500]->a.b.c.d[38820]
Aug/12/2024 09:19:29 ipsec,debug ipsec-start: 1 times of 1 bytes message will be sent to a.b.c.d[38820]
Aug/12/2024 09:19:34 ipsec ipsec-start: dpd: retransmit
Aug/12/2024 09:19:34 ipsec,debug ipsec-start: ===== sending 160 bytes from x.y.z.w[4500] to a.b.c.d[38820]
Aug/12/2024 09:19:34 ipsec,debug ipsec-start: 1 times of 164 bytes message will be sent to a.b.c.d[38820]
Aug/12/2024 09:19:39 ipsec ipsec-start: dpd: retransmit
Aug/12/2024 09:19:39 ipsec,debug ipsec-start: ===== sending 160 bytes from x.y.z.w[4500] to a.b.c.d[38820]
Aug/12/2024 09:19:39 ipsec,debug ipsec-start: 1 times of 164 bytes message will be sent to a.b.c.d[38820]
Aug/12/2024 09:19:44 ipsec ipsec-start: dpd: retransmit
Aug/12/2024 09:19:44 ipsec,debug ipsec-start: ===== sending 160 bytes from x.y.z.w[4500] to a.b.c.d[38820]
Aug/12/2024 09:19:44 ipsec,debug ipsec-start: 1 times of 164 bytes message will be sent to a.b.c.d[38820]
Aug/12/2024 09:19:49 ipsec ipsec-start: dpd: max retransmit failures reached
Aug/12/2024 09:19:49 ipsec,info ipsec-start: killing ike2 SA: Main x.y.z.w[4500]-a.b.c.d[38820] spi:c424a7ed0bb9b162:3088ca4e01e54a7f
Aug/12/2024 09:19:49 ipsec ipsec-start: IPsec-SA killing: a.b.c.d[38820]->x.y.z.w[4500] spi=0x4b7e148
Aug/12/2024 09:19:49 ipsec ipsec-start: IPsec-SA killing: x.y.z.w[4500]->a.b.c.d[38820] spi=0x7f4bbf16
Aug/12/2024 09:19:49 ipsec ipsec-start: removing generated policy
Aug/12/2024 09:19:49 ipsec ipsec-start: adding payload: DELETE
dpd packet seem to be unable to transmit. What does this mean?
@sindy: regarding src-address in template: I currently have 0.0.0.0, which address shall I use here? I might run a test in spite this 0.0.0.0 worked earlier (with different Mikrotik, different Windows11 PC, and of course different certificates).
Thank you!
-
-
danergo
Member Candidate
- Posts: 191
- Joined: Tue Dec 24, 2019 8:49 pm
Topic Author
Re: IKE2 IPSec VPN: Windows claims policy match error
Mon Aug 12, 2024 11:31 am
Now I receive vpn error 13801 (checked in event viewer, for rasclient).
According to MS:
The machine certificate on the RAS server expired. The client machine doesn’t have the root certificate for validating the RAS server certificate. The client machine’s VPN server name doesn’t match the subjectName value on the server certificate.
I have imported 3 certificates:
-client (machine, personal)
-server (machine, trusted root)
-ca (machine, trusted root)
And I have created the VPN with the MachineCertificateIssuerFilter option pointing to my ca certificated exported from certlm.
-
-
danergo
Member Candidate
- Posts: 191
- Joined: Tue Dec 24, 2019 8:49 pm
Topic Author
Re: IKE2 IPSec VPN: Windows claims policy match error
Mon Aug 12, 2024 2:04 pm
Ok, Folks, thank you all putting your efforts to this question.
I’ve figured it out, my results are below, summary: Windows is far more picky during server verification than Android:
1. Server address
On Android, VPN Connection’s server address doesn’t need to be matched to server’s certificate’s CN, while on Windows, it must.
This is a (+1) for Windows’s security.
2. Subject alt name
Android doesn’t really care what’s presented on the server’s certificate’s alt name field, while Windows is really picky about it.
3. Bug in Winbox (v7.15.1):
When adding subject alt name, two double colons (::) are automatically placed into value field.
::mydomain.net
Works with android, but not with Windows.
IMHO it should be much better not adding anything to this field during activation.
After generating a new certificate for the server with correct alt name field value, Windows started to connect just fine as android.
Adding NegotiateDH2048_AES256 into Windows registry
By default Windows 7 up to Windows 11 propose only the weak modp1024 Diffie-Hellman key exchange algorithm that has been deprecated by NIST Special Publication 800-57 Part 3 Revision 1 since 2015:
ike = 3des-aes128-aes192-aes256-sha1-sha256-sha384-modp1024
Therefore, any attempt connect to IKEv2 VPN server, you will getting Policy match error
message.
You will need to enable the modp2048 Diffie-Hellman group by adding the NegotiateDH2048_AES256 DWORD into the Windows registry using regedit.
Download following zip file:
NegotiateDH2048_AES256.zip
NOTE: You do not need to import this file again if you have already imported it, or if you have already upgraded your Diffie-Hellman group to 2048 bits.
If already upgraded to 2048 bits or already imported this file, do skip this and proceed to Setting IKEv2 VPN client section.
ADMINISTRATOR NOTE:
Merging NegotiateDH2048_AES256 into Windows registry will require administrator access privilege. If encounter following message, then you will need switch from current Windows user and login as administrator. Once merged into registry, you may switch back to your own Windows user.
Once downloaded, proceed to extract or decompress it. You should see one (1) NegotiateDH2048_AES256.reg
file.
Double click on it to automatically merge NegotiateDH2048_AES256 into Windows registry.
Click Yes to continue
Click Ok to close the dialog box
Once NegotiateDH2048_AES256 added into your Windows registry, you are now ready to create a new IKEv2 VPN connection.
VPN information as stated below will be located within activation form email:
— VPN Server hostname
— User name
— Password
Create VPN connection
1. Select the Start button, then select Settings > Network & Internet > VPN > Add a VPN connection.
2. In Add a VPN connection, do the following:
- For VPN provider, choose Windows (built-in)
- For Connection name box, enter a name you’ll recognize (for example, My Personal VPN). This is the VPN connection name you’ll look for when connecting
- For Server name or address box, enter the address for the VPN server hostname
- For VPN type, choose IKEv2
- For Type of sign-in info, choose User name and password
- For User name (optional), enter your VPN user name
- For Password (optional), enter your VPN password
- Mark Remember my sign-in info
3. Click Save.
Edit VPN connection properties
Once the VPN connection created, open its properties via Network Connections
tool box.
- Press Win + R to open the Run command dialog box.
- Type
ncpa.cpl
and press Enter to open theNetwork Connections
tool.
3. Select the VPN connection you have created earlier and right-mouse on it to select Properties
4. On Security
tab, set Type of VPN
to IKEv2.
5. Ensure Authentication
is set to Microsoft Secured password (EAP-MSCHAP v2) (encryption enabled).
6. On Networking
tab, make some changes to the VPN properties by following the order numbering
You are now ready connect to the IKEv2 VPN server. Select your VPN connection and click on Connect
button
Connect to a VPN
-
On the far right of the taskbar, select the Network icon
-
Connect to IKEv2 VPN server you have created just now.
Once VPN connection no longer needed, select your VPN connection and click on Disconnect
. This will end your VPN session.
==========================================================================================
If you face any difficulties on the setup, please feel free to contact our support team by submitting a ticket on https://247livesupport.biz or emailing out support team at [email protected].
Чтобы выяснить, в чем заключается проблема, вы должны, в качестве первого шага, включить ведение журнала и посмотреть, что происходит во время процесса подключения. Вот пример конфигурации, который я использую на своем сервере.
/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 =
}
}
}
Вы можете использовать его и проанализировать файл журнала, чтобы обнаружить проблему. Если вы не сможете разобраться, опубликуйте журнал подключений здесь, я постараюсь вам помочь.