Hello,
it seems to me that the Mikrotik side does not like some aspects of the certificate the Strongswan side presents, plust there is possibly a slight misconfiguration.
2025-04-16 14:57:44 ipsec ipsec: ID_R (FQDN): protection1.cyberpointer.net subject: <C=HU, O=CyberPointer, CN=CyberPointer Root CA> key usage: key-cert-sign, crl-sign
Namely:
the Strongswan certificate is self signed - I don’t think it is the reason per se, but some stacks do not like this
the “key usage” list of the Strongswan certificate does not contain a tls-server item; I’m not sure about ROS 7, but in ROS 6, the certificate of an IPsec responder had to have tls-server on the key usage list, and the certificate of an IPsec initiator had to have tls-client there
there is only a CN (common name) field in the certificate; Strongswan itself (and other software too) ignores the CN field and needs the subject of the certificate to be present in the Subject-Alt-Name list. Mikrotik may have an issue with this too.
the identity row is configured with match-by=certificate but the Strongswan presents another ID, fqdn:protection1.cyberpointer.net . This is not an issue of the certificate itself but may be relevant - so if fixing the potential issues of the certificate does not help, try changing match-by to remote-id and set remote-id to fqdn:protection1.cyberpointer.net .
Hi!
I started creating the certificate from scratch using the Mikrotik factory solution, thinking that it would be the solution, but unfortunately it wasn’t.
I tried all the options in the identity menu but unfortunately I always got the same result: … parsed INFORMATIONAL request 2 [ N(AUTH_FAILED) ] …
Of course, it works perfectly under Linux and Windows, which I generated the certificate with Mikrotik. So I don’t understand what else you expect from me to make it work?
Of course, thank you for the suggestions!
Thank you!
Regards: DrCyberg
