I have a question about the VPN IPsec IKEv2 test configuration of two RB750Gr3 (RouterOS v6.45.8 ) connected with WAN on same network.
I have test to understand the functionality of Indentities IDs, My-ID and Remote-ID.
Here the simplified config.
Notice that the IDs value in /ip ipsec identity was different from FQDN in certificate.
And RouterA remote-id=fqdn:B456 NOT match with RouterB my-id=fqdn:B123
When RouterA start as Initiator the connection fails.
When RouterB start as Initietor the connection was established and comunication through the VPN work.
My question was: WHY the connection was established also with IDs NOT MATCHED ???
The answer is the match-by=certificate setting in the /ip ipsec identity rows. With this setting, the 'Tik acting as IPsec responder uses the received certificate to match through the rows of the identity table and ignores the ID_I field from the IPsec initiator.
I not remember to write this, but if:
RoterA: my-id=fqdn:A123 remote-id=fqdn:A456
RoterB: my-id=fqdn:B123 remote-id=fqdn:A456
In any case it can NOT connect.
I want to mark that the my-id and remote-id was different with CM and SAN in certificates.
I not understand if what I explain in my first post, was the correct functionality or it is a bug to be correct.
I see in log that.
When RouterB was initiator, it send ID_I=B123, ID_R=A123 and cert.
In attached a log of RouterA and RouterB.
When RouterA was initiator, it send ID_I=A123, ID_R=B456 and cert
RouterB in log write “identity not found”.
With match-by=certificate I think ROS should check ID_I with certificate, but it not match. It is correct ?
It match with remote-id.
I think it should be use the cert to find the identity.
But I understand that ROS use ID_I to find the correct identity to verify Initiator, not use the cert.
And I understand that with my-id=auto and remote-id=auto, my-id and remote-id correspond to cert detail and consequently the identity was selected by cert.
If match-by=certificate I see that the ID_R in reply from responder, was not checked.
To add another layer of security I think that the match-by, may be splitted in
match-by-remote-id=yes/no
match-by-certificate=yes/no 2 RouterA Log.txt (4.38 KB) 2 RouterB Log.txt (4.87 KB)
This forum is a peer-to-peer help one, and not the primary input channel to Mikrotik product management, so there is no point in stating feature requests here. Officially you have to talk to your distributor who would forward it to Mikrotik, practically a support ticket sometimes helps if the suggestion is really useful.
But in this particular case, I cannot see the added value of checking an ID and a certificate. If someone is able to get hold of a certifcate’s private key, which should normally never leave the machine where it was created*), he’s as well able to copy the identity which is basically a plaintext string so there is no problem to forge it - unless it is authenticated by the certificate.
So there are two methods in use:
you use the identity protocol field to choose the correct row in the /ip ipsec identity table, and you just verify that the certificate the peer offers authenticates that identity and is issued by a certificate authority whose own certificate you’ve got in your certificate store - in this case, you don’t need to store every peer’s individual certificate there, the chain of trust (from the signing authority up to its root CA) is sufficient,
you use the certificate itself directly to choose the correct row - in this case, you must have all individual peers’ certificates in your certificate store so that you could refer to them from the /ip ipsec identity rows; in this case, you completely ignore the identity field of the protocol because checking it for a match with the certificate would bring no additional security - if someone was able to forge a certificate authentication, forging the ID as well would be no problem at all
*) the correct way is to create a cerificate request on the peer, which creates also the private key; then deliver only the request without the private key to the certification authority, which signs it, resulting in the certificate itself which is then delivered back to the client. The certificate cannot be used to sign a message without the private key, so interception of the request or of the signed certificate is useless, so you can use an open channel between the certificate user and the certification authority (but you must prove to the authority somehow that you are really you and that the request which they got is the one you’ve sent, otherwise the whole purpose is broken - if the MITM substitutes your certificate request by his own one and intercepts the resulting certificate, the resulting certificate will be incompatible with your private key whereas the MITM will have a valid certificate for your identity). Mikrotik’s wiki suggests the shortcut way, where the certificate request is generated and signed at the machine acting as a certificate authority itself, but this method assumes that the certificate and its private key will be delivered to the client via some secure path.