OK. So I've set up a test and found out that match-by=certificate is the reason; if I set it (the default value is remote-id), an otherwise working setup breaks the same way like yours.

You are affected by the issue, so it is your job to send that to support@mikrotik.com.

That doesn't necessarily mean that if you change just this you're good; while Mikrotik as an initiator sincerely ignores the key-usage value of the responder's certificate, it may not be the case with Windows.

Sadly, I wasn't able to make my Windows 10 even send the initial packet, so I cannot tell you what they send as an ID and whether they care about key-usage of the server's certificate or not.

Still, if you set match-by=remote-id, you should get further, and the log might show the ID which the Windows client sends, so you could create a certificate with the proper subject-alt-name and be up and running long before Mikrotik fixes it. Search for peer's ID in the log, although it shows only the value, not the type of the ID.

Would be fine if you could post the result, or the whole log if it is too much for you to find also the ID type there using Wireshark.

But this solution does not make sense because you lose the ability to authorize the customer.

But this solution does not make sense because you lose the ability to authorize the customer.

Oh my. So it seems the bug is a more complex one. When you want to identify individual peers (and possibly provide individual treatment like policy-template-group and mode-config to them), a particular row in /ip ipsec identity has to be chosen either by the certificate itself or by the peer ID (authenticated using a certificate if auth-method=rsa-signature is chosen or by some other method otherwise). And to my understanding the bug is that the stack starts searching for the identity row too early, while it doesn't have the ID (or certificate) yet. So if you set match-by=certificate, it fails because it hasn't yet got the certificate to choose the row; if you set match-by=remote-id but provide no remote-id value, the /ip ipsec identity row can be chosen already at that moment because no information is missing; but if you set a particular remote-id value to the row, the row cannot be chosen at that moment because the stack hasn't got the ID value from the peer yet.

Mikrotik expressly states in the documentation that choice of /ip ipsec identity row by certificate is possible, and as the ID and certificate come in the same message, I think the intention is that both ways work and the reason why they fail is the same, the premature search for the row (or maybe only a premature termination of the negotiation if a matching row is not found at that moment).

So add this information to the ticket, or simply put a link to this topic there. I haven't found anything relevant in the change notes of 6.45beta so Mikrotik may not be aware of it yet.

In the ticket I added a link to this thread so support will stay up to date with the information.

In the ticket I added a link to this thread so support will stay up to date with the information.

Nevertheless, would you mind finding out what ID type and value the Windows embedded client sends? It could be useful for others.

If you cannot find it there and don't want to publish the log here, let me know, I'll send my e-mail to the address you've leaked earlier.

Sure, I do not see a problem to throw it in, let me just say honestly, I do not know where to look for it

Hola amigos. Tengo un problema con mi VPN.

Mi configuracion es como sigue.

Rb2011(A) - WAN recibe ip publica dinamica -----LAN es 192.168.2.254
Rb2011(B) - WAN recibe ip publica dinamica -----LAN es 192.168.1.254
RB1100AHX2 - 2 PUERTOS WAN que reciben ips de los RB arriba. PUERTO LAN es 192.168.51.1
Mimosa 192.168.51.20
AirFiber 192.168.51.22

Mi problema es que cree una red VPN para conectarme usando el RB2011(A), a este equipo me conecto sin problemas, pero no puedo acceder a mis equipos mimosa y airfiber. Les comento que todo esta conectado via cable ethernet. Y yo accedo a mi vpn desde mi casa.

Alguna solucion?

Mi problema es que cree una red VPN para conectarme usando el RB2011(A), a este equipo me conecto sin problemas, pero no puedo acceder a mis equipos mimosa y airfiber
...
Alguna solucion?

1. su problema está relacionado con este tema solo de forma general, comience un tema nuevo, por favor
2. el idioma de este foro es el inglés; usa un traductor automático si no confía en sus habilidades en inglés, y permita que traduzca el resultado del inglés al revés al español para verificar si el sentido no ha cambiado

Sure, I do not see a problem to throw it in, let me just say honestly, I do not know where to look for it

Use the same /system logging settings you did before, set match-by=remote-id and remote-id=auto, run /log print follow-only file=ipsec-startup where topics~"ipsec", let the client successfully connect, break the /log print, download the file. If you want to hide your public IP (if any), be aware that it can be found in the decrypted raw packet data which are however necessary for the analysis, so substituting it only where it is visible in the text part of the log is not sufficient. So if you don't want to make it visible to all readers of this forum, say so and I'll send you an e-mail.

Off topic, at the moment IKEv2 seems to me to be a better option for Windows clients than L2TP - among other things because it is the only VPN where the client can receive from the server a list of subnets to be routed via the VPN. For all other VPN types, you can either make the tunnel the default route for all traffic, or you have to configure routes manually on the client. The same mechanism (DHCPINFORM) can be used also with L2TP but Mikrotik only supports it for IKEv2.

/ip ipsec profile
add dh-group=ecp256,ecp384,ecp521,ec2n185,ec2n155,modp8192,modp6144,modp4096,modp3072,modp2048,modp1536,modp1024,modp768 enc-algorithm=\
    aes-256,camellia-256,aes-192,camellia-192,aes-128,camellia-128,3des,blowfish,des name=l2tp_profile
/ip ipsec peer
add name=peer1 passive=yes profile=l2tp_profile
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha512,sha256,sha1,md5,null enc-algorithms="aes-256-cbc,aes-256-ctr,aes-256-gcm,camellia-256,aes-192-cbc,aes-192-ctr,\
    aes-192-gcm,camellia-192,aes-128-cbc,aes-128-ctr,aes-128-gcm,camellia-128,3des,blowfish,twofish,des,null" pfs-group=none
/ppp profile
add name=L2TP use-compression=no use-encryption=required use-ipv6=no use-mpls=no use-upnp=no
/interface l2tp-server server
set authentication=mschap2 default-profile=L2TP enabled=yes ipsec-secret=dupa12345
/ip ipsec identity
add auth-method=rsa-signature certificate=Server generate-policy=port-strict notrack-chain=prerouting peer=peer1 remote-certificate=Client
/ppp secret
add local-address=10.10.10.1 name=wmanka password= profile=L2TP remote-address=10.10.10.2

wireshark dissection code

Payload: Identification (5)
    Next payload: Certificate (6)
    Reserved: 00
    Payload length: 59
    ID type: DER_ASN1_DN (9)
    Protocol ID: Unused
    Port: Unused
    Identification Data:
    ID_DER_ASN1_DN: 0
        rdnSequence: 2 items (id-at-commonName=wojtek.manka.96<kvasnaryba>gmail.com,id-at-countryName=PL)
            RDNSequence item: 1 item (id-at-countryName=PL)
                RelativeDistinguishedName item (id-at-countryName=PL)
                    Id: 2.5.4.6 (id-at-countryName)
                    CountryName: PL
            RDNSequence item: 1 item (id-at-commonName=wojtek.manka.96<kvasnaryba>gmail.com)
                RelativeDistinguishedName item (id-at-commonName=wojtek.manka.96<kvasnaryba>gmail.com)
                    Id: 2.5.4.3 (id-at-commonName)
                    DirectoryString: uTF8String (4)
                        uTF8String: wojtek.manka.96<kvasnaryba>gmail.com

OK, so Wireshark says the certificate itself (or rather its informational part alone) is used as initiator ID - ID type: DER_ASN1_DN (9)

wireshark dissection code

Payload: Identification (5)
    Next payload: Certificate (6)
    Reserved: 00
    Payload length: 59
    ID type: DER_ASN1_DN (9)
    Protocol ID: Unused
    Port: Unused
    Identification Data:
    ID_DER_ASN1_DN: 0
        rdnSequence: 2 items (id-at-commonName=wojtek.manka.96<kvasnaryba>gmail.com,id-at-countryName=PL)
            RDNSequence item: 1 item (id-at-countryName=PL)
                RelativeDistinguishedName item (id-at-countryName=PL)
                    Id: 2.5.4.6 (id-at-countryName)
                    CountryName: PL
            RDNSequence item: 1 item (id-at-commonName=wojtek.manka.96<kvasnaryba>gmail.com)
                RelativeDistinguishedName item (id-at-commonName=wojtek.manka.96<kvasnaryba>gmail.com)
                    Id: 2.5.4.3 (id-at-commonName)
                    DirectoryString: uTF8String (4)
                        uTF8String: wojtek.manka.96<kvasnaryba>gmail.com

Which likely makes it impossible to separate the peer ID itself from its authentication by means of a certificate, so when the client certificate expires and you replace it by a new one at the client, you have to update the configuration also at the server with the new certificate to match on. The search for the row in /ip ipsec identity compares not only the DN part but also the rest of the certificate data - if you generate two certificates with the same common-name and subject-alt-name and sign them using two different CAs (because RouterOS won't let you sign two certificates with the same common-name by the same CA), and use one of them as remote-certificate of a row in /ip ipsec identity, you cannot set one at client's row in /ip ipsec identity at the server and the other one at the client although the DN part is the same in both. Any of the two works if set for use at both client and server side. I wonder whether it would be a security hole to match only on the DN of the remote-certificate and accept any valid certificate with the same DN?

The above applies to IKEv2 of course, it could not be tested with L2TP over IKE(v1) due to the bug, but the principle remains the same for both.

Do I understand correctly Your anwer that using DER_ASN1_DN as the common name of a client certificate would theoretically allow L2TP + IPSEC to be connected to certificates ??

I believe that no support for EAP (and thus "current user" certificates) is current limitation of MikroTik's IKEv2.

!) ike2 - added support for EAP authentication methods (eap-tls, eap-ttls, eap-peap) as initiator (CLI only);
----------------------

Actually, I'm not sure about anything, just trying the power of suggestion thing, but it would definitely make sense.

@sindy - I see that in general the solution to this problem that the certificate identifies the client will be difficult if at all possible.

And that's what I keep saying, in your part of the country the legal stimulatives must be much better than in mine.

Loosely related question, have you ever tried to install two "local machine" certificates on Windows issued by different CAs and see what happens?

In this situation, I want to stay with IPSEC, it remains IKEv2.