I finally just upgraded from 6.43.x to 6.45.x, and I now have to use the new IPsec Peer Identity objects when making a IPsec tunnel.
My question is, WHY do I need to make an Identity object for each Peer? Why can't I re-use the same Identity on multiple Peers similarly to how I can with the IPsec Peer Profiles?
I have two routers with 500 IPsec tunnels each, and now I need to make an Identity for each of the Peers, even though they have the same exact authentication settings.
This just seems like a silly backwards approach to something that already had a fine solution that could have been copied. Even just keeping the options as part of the Peer would likely have been fine if this is how it is done.
Can anyone explain this weird design decision?
Re: IPsec Peer Identity - Why backwards?
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.
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.