I am struggling to understand IPSEC in Mikrotik. There is a wiki article but it is very incomplete. Does anybody know where can I find information HOW EXACTLY mikrotik uses each part of configuration (profile, proposal, policy, policy group, peer, identity etc.). I understand how IPSEC works, but I struggle to match parts of configuration to what they define and when they are exactly used, and what is relation between them. For instance what is a relation betwen policy group and other parts of configuration. which parts of configuratoin are defining the group to be used, and which parts of configuration is later matched by policy group.
For instance: which part of configuratioin is used during IKE_SA_INIT? There is a mismatch between common sense and mikrotik wiki. Common sense would be that proposal is used during this phase but wiki states "Phase 1 (...)This phase should match following settings: authentication method DH group encryption algorithm exchange mode hash alorithm NAT-T DPD and lifetime (optional)" and those parameters are defined in policy not in the proposal. WTF?

I would like information like: for instance: policy is used (at which stage)(for what) and mikrotik is trying to match xxxx with yyy from policy definition, if matches than yyyy otherwise zzz etc.

As far as I understand there are main phases of IPSEC like IKE_SA_INIT, IKE_AUTH, CREATE_CHILD_SA.

Can anybody point me to a good description of those things or correct the below text generated by partly halucinating AI:

WARNING !!!!! THE BELOW TEXT MIGHT CONTAIN SERIOUS ERRORS AND MISUNDERSTANDINGS:

IKE_SA_INIT:
The router sends a packet with the initial SA proposal, including AES encryption and SHA-256 hashing algorithms, and a Diffie-Hellman group.
Initiator: Sends the initial packet containing the SA proposal, including encryption and hash algorithms, Diffie-Hellman group, and nonces.
Responder: Replies with its own SA proposal, including its chosen encryption and hash algorithms, Diffie-Hellman group, and nonces.
Packet Content: Contains the initial security association (SA) proposal, including encryption and hash algorithms, Diffie-Hellman group, and nonces.
Configuration match:
. PROBABLY WRONG!!! It is profile and NOT proposal. proposal settings in the router’s configuration: Encryption Algorithms, Authentication Algorithms, PFS Group. Lifetime not used now.?
. Encryption Algorithms: Used to establish the initial secure channel.
. Authentication Algorithms: Used to ensure the integrity and authenticity of the initial messages.
. PFS Group: Specifies the Diffie-Hellman group for the key exchange to generate the shared secret.
. Are peers and identities used at this stage?

IKE_AUTH:
The router sends a packet with the Diffie-Hellman public value, authentication data (e.g., a pre-shared key), and identity information.
o Initiator: Sends a packet with the Diffie-Hellman public value, authentication data, and identity information.
o Responder: Replies with its own Diffie-Hellman public value, authentication data, and identity information.
o Packet Content: Contains the Diffie-Hellman public value, authentication data, and identity information.
o Configuration Match:
1. Identity: Used to authenticate the peers (pre-shared key or certificates).
Is this true?: Identiy contains policy goup name which will be remembered by the router and later used to select proper encryption policy.
2. Peers? In summary, peers are configured first to establish the connection parameters, followed by identities to authenticate the connection. Both are crucial in Phase 1 of the IPsec packet flow, ensuring a secure and authenticated channel for data transmission.
3. Mode Config: If used, this can include configuration parameters like IP addresses assigned to the client.
4. Proposal again? Is it consulted at this stage? Or the option taken from proposal are just used by existing packet exchange?
1. Authentication Algorithms: Used again to authenticate the peers and ensure the integrity of the messages.
2. Encryption Algorithms: Used to secure the communication channel for the exchange of identity and authentication data.
3. Lifetime: Specifies the duration for which the IKE SA is valid.

CREATE_CHILD_SA:
The router sends a packet with the IPsec SA proposal, including AES encryption and SHA-256 hashing algorithms, and traffic selectors.
o Initiator: Sends a packet with the proposal for the IPsec SA, including encryption and authentication algorithms, and traffic selectors.
o Responder: Replies with its own proposal for the IPsec SA, including its chosen encryption and authentication algorithms, and traffic selectors.
o Configuration Match:
1. Proposal: Defines the encryption and authentication algorithms for the IPsec SA.
2. Policy: Specifies the traffic selectors (source and destination addresses, protocols, and ports).
3. Policy Group Consultation: At this stage, the router consults the policy group to determine which policies apply to the traffic selectors being proposed. The policy group helps in identifying the relevant policies that define the source and destination addresses, protocols, and ports that should be encrypted.
4. Traffic Selector Exchange: The router sends a packet with the traffic selectors, specifying the source and destination addresses and protocols.
o Initiator: Sends a packet with the traffic selectors that define which traffic will be protected by the IPsec SA.
o Responder: Replies with its own traffic selectors, confirming the traffic to be protected.
o Configuration Match:
1. Policy: Matches the traffic selectors defined in the policy configuration.
2. Policy Group Consultation: Again, the router consults the policy group to ensure that the traffic selectors match the policies defined within the group. This ensures that the correct traffic is selected for encryption based on the policies grouped together.

I can't give you a link to a better documentation that the Mikrotik one, but I can help you in question-and-anwer mode

First answer: Phase 1 proposal parameters are aggregated on rows of /ip/ipsec/profile, Phase 2 proposal parameters are aggregated on rows of /ip/ipsec/proposal.

Second answer: the user-specified names under /ip/ipsec/policy/group are just link objects that are used to aggregate policy templates that a remote peer (or a set of peers) is allowed to use. When a remote peer whose ID matches a particular /ip/ipsec/identity row suggests a policy (traffic selector and proposal), Mikrotik looks for a corresponding static policy linked to that peer; if none is found but generate-policy on that identity row is set to someting else than none, it tries to find a corresponding policy template among those whose group parameter matches the one indicated in the policy-template-group of the identity; if it finds one, it creates a policy from it.

Huge thanks! I am one small step further.
"Mikrotik looks for a corresponding static policy linked to that peer"

Can you please clarify how can you assign "static policy" linked to peer? I do not see "policy" field in 'peer' and no such thing in 'idenity'. Do you mean, that a Peer field in Policy itself will be used? and the policies are reverse matched to peer?

Also: if there is no policy group defined on identity I presume the router will be able to use any policy, both those with policy group empty, and with existing policy group? Or if there is no 'policy group' on ideentity, then only policies without 'policy group' can be used?

Do you mean, that a Peer field in Policy itself will be used? and the policies are reverse matched to peer?

Indeed. A manually configured policy must refer to one or two peer objects and if the actually connected remote initiator proposes a traffic selector, only the manually configured policies that refer to the peer object are taken into account. When acting as an initiator, RouterOS actively tries to negotiate these policies with the remote responder. Bear in mind that you can suppress the initiator behavior but you cannot suppress the responder one, so if two RouterOS peers run on public addresses, they both act as initiators unless you tell one of them not to do so, and then resolve the race conditions when two Phase 1 sessions try to negotiate the same Phase 2 SAs.

The optional second peer is for redundancy - the policies are always negotiated with only one of them.

if there is no policy group defined on identity...

Mikrotik uses the same approach like other vendors when showing the configuration - default settings of parameters are not shown unless explicitly requested (using the verbose parameter of the export command). So if generate-policy is set to port-strict or port-override but no policy-template-group seems to be set, the actual value of the policy-template-group parameter is default. And unless you touch the default settings (which you are free to do if you are ready/able to deal with the consequences), there is a single policy template in the default group, that refers to proposal default. So the identity always links to a single group of template policies (i.e. the choice of templates is always restricted this way), and this link is only used if the generate-policy parameter allows dynamic generation of policies. Nothing prevents you from configuring template policies with identical contents in multiple groups if you can find a use case for that.

Something is telling me that there is a failover approach - if you neither permit policy generation in identity nor configure any policies for the peer manually, a transport policy between the addresses of the peers gets established.

Yet another "apple style" (we know better than you what you need) behavior is there - in some scenario, RouterOS refuses to generate a tunnel policy with dst-address=0.0.0.0/0.

The following is IMO one of the very best guides on creating your IPSec under MikroTik
MikroTik IPSec ike2 VPN server: easy step-by-step guide by Nikita Tarikin

@CZFan has found this: viewtopic.php?t=151067#p814972

The following is IMO one of the very best guides on creating your IPSec under MikroTik
MikroTik IPSec ike2 VPN server: easy step-by-step guide by Nikita Tarikin

Unfortunately this is NOT explaining anything else than MTU size (maximum trasfer unit). There is a 'ready' configuration given and there is no explaination exactly when (during which stage, after which packet) and how (which configuration parameters are matched and against what and in what order).