IKE2 IPSec VPN: Windows claims policy match error

danergo · August 10, 2024, 1:09pm

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: http://forum.mikrotik.com/t/ipsec-ike2-with-certificates-vpn-server-guide-for-remote-access/149434/34

What could be the problem?

sindy · August 10, 2024, 1:44pm

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 · August 10, 2024, 3:08pm

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 · August 12, 2024, 7:34am

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 · August 12, 2024, 8:31am

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 · August 12, 2024, 11:04am

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:

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.
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.
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.