Fri Jun 26, 2020 4:03 pm
I'm not a Mikrotik developer so I'm not defending my own decision, but I like the new approach as it finally allows to select pre-shared keys per remote peer on a common local peer (which wasn't possible with the old approach), and in a way it unifies the various types of setup.
In the old setup, the authentication information (username, password, secret) for the remote was linked to the local peer itself, except if the local one was a wide-open responder-only peer where part of the authentication information (xauth-username and xauth-password) could be individualized per remote peer; however, the PSK (secret) had to be the same for all remote peers, and with certificate-based authentication, you could not tell the individual remote peers connecting to you from dynamic addresses from one another in any way.
The new setup links all authentication information to the ID of the remote peer (the ID can be a fqdn-like string, an IP number, an user@fqdn string, or the certificate itself) in a unified way. So now, at the wide-open responder side, you can use a single peer and represent each remote peer by its individual row in /ip ipsec identity, with individual authentication data, and even with individual settings via an individual mode-config profile. Your case, where you use the same authentication information for multiple remote peers, is quite a rare one.
But the upgrade should have done the conversion, so are you only concerned about the process of adding a new peer where you have to put the information into two tables rather than one, or is there any other concern? I normally do like aggregation of configuration information into profiles which you can refer to from the individually configured objects, but it never came to my mind to use a profile for any authentication-related information.