Is it currently possible to get 2:1 relationships working?
There is a central site with dual wan (not failover).
Every remote site has only one wan.

When I try to make a tunnel (as foundation for upperlevel ipip tunnel) is works only when I make a connection to only one central wan peer.
If i enable the other peer which connects to the second wan, is repeatadly fail while spamming killing sa, new sa, peer authroized in log.
I can reproduce this with a test setup (CHR-VMs).
With IKEv1 it curently works like a charm but I wanted to migrate to IKEv2.

How is this possible?

Best regards.

Do you have two responder peers on the central site, each with local-address set to the IP of one of the two WANs, or you have a single responder peer and you rely on the local context to include the WAN IP automatically? There may be the difference between IKE(v1) and IKEv2 handling of the SAs.

originally I had two peers, each handling one of the wan addresses.
I tried single peer setup (with identity check and then apply policy templates accordingly) but this did not change anything.

It is strange. I use dual WAN on the initiator side (with a dedicated xauth identity for each peer) and have no problems with that, using exchange-mode=ike2 like you intend to. What authentication mode do you use? xauth or other?

I use rsa-signatures.
I initially tried xauth, but at that time it said that xauth is not support with ikev2. that may have changed.

Edit:
apparently it has not changed. I am unable to set rsa signature hybrid or psk yauth on the ikev2 peer

The issue with RSA signature is that the certificate proves the identity of the peer by its IP address, so you cannot create two identities for the same device if the certificate's subject is the IP address which is the same regardless via which WAN of the HQ machine you establish the connection. So if the IKEv2 stack takes into account only the remote peer's identity and doesn't look at the local end of the connection even if you create a separate peer for each, you'd have to experiment with my-id and certificate's subject on client side to see whether you can eventually use something else than IP address as peer ID and still get a successful connection. If yes, you'd then create two rsa-certified identities to allow the HQ machine distinguish between the two connections.

I did exactly this. one specific cert per peer on initiator, but did not change anything.

Yes, but what I'm talking about is the other end, the initiator, whose ID is the same (the IP address if you stay with my-id=auto) regardless to which HQ WAN IP it connects, so the HQ IKEv2 stack may be unable to distinguish between the two connections of that same initiator if it doesn't take its own WAN address into account. So you'd need two certificates at initiator end, each proving another identity, which thus would have to be something more than just the IP address alone (such as my-id=user-fqdn:a@1.2.3.4) in order to differ between the connections.

But if I get the updated manual right (I haven't tested the 6.44 anywhere yet), with the new /ip ipsec identity menu, you can identify the remote peer by matching its certificate directly rather than matching its ID authenticated by the certificate. So if you generate two certificates for the client, export them, place them to the certificate store of the HQ, and configure the identity with a reference to the local copy of the client's certificate, you may even not have to experiment with not-just-IP identities because the identity field would be completely ignored in that case. But it's only a theoretical assumption at the moment.

yes I did exactly this. initiator had one particular cert per peer id.
setting was user fqdn on id too.
only responder had single cert -> this could also be the problem I think.
but this did not solve the problem.
running version 6.44

Edit:
apparently it has not changed. I am unable to set rsa signature hybrid or psk xauth on the ikev2 peer

I have never tried the auth-method=rsa-signature-hybrid but I've been using auth-method=pre-shared-key-xauth for at least a year with exchange-mode=ike2 and it just works.

So to summarize, you have two peer identities (ID and certificate) at each end (the dual-WAN HQ and the single-WAN BO), and nevertheless the two connections affect each other in terms that if you activate both, they start killing each other? If so, I'm afraid it requires to switch on the debug of IPsec at the HQ (responder) side, log a single connection attempt for each of the initiator side peers, and look how the HQ idenitifies them. If the IKEv2 stack sticks with the remote IP address rather than peer identity further translated into SA identity, it looks like a serious bug to me.

But again, in my case, there is a single peer with single identity on the responder side (so a mirror arrangement as compared to yours) and the initiator side stack doesn't mix up the sessions.

Bigleaf sd-wan

@sindy
as both methods are not supported anymore for IKEv2 in 6.44 this is going to be a problem (also for you I think) in the future.
Every attempt was unsuccessful to make it work.
I will try to debug that.

@gotsprings
yeah it would be great if routeros had something like mesh tunneling or "SD-VPN". something like tinc would be great, but before that, ovpn with udp

@gotsprings
yeah it would be great if routeros had something like mesh tunneling or "SD-VPN". something like tinc would be great, but before that, ovpn with udp

I meant... SUBSCRIBE TO BIG LEAF'S Service.

I only dealt with them on one install so far. The customer found them himself.

BigLeaf takes all your ISPs and send all traffic to a static IP on their network. That's the IP that you use as your sites IP.
This works out pretty well in that NONE of your ISPs have to offer you a STATIC IP
Or EVEN A PUBLIC IP (Think carrier grade Nat)

If you really wanted to... you could set up something like this using an external VPN service... but if you knew how to do that... I doubt they would be in this thread.

@gotsprings
nah I don't want to involve third parties and could easily make this with systems myself. but I want a real end to end connectivity.

@sindy
today I tried to set up identities on both sides with unique certificate and unique ID (user fqdn matching the SAN in certificate) I even imported both certs on the systems and made an identity entry with remote cert. It did not change anything. one ikev2 connection (even running alongside an old IKEv1 connection) works like a charm. but as soon as I enable the "redundant" connection it starts to flap wildly.

Please try disabling "Send INITIAL_CONTACT" (send-initial-contact) option on both peers.

as soon as I enable the "redundant" connection it starts to flap wildly.

As said, only debug can show what is wrong in particular. I am currently out of both hardware and time to replicate your configuration although I know I'll have to deal with it sooner or later, so think about sending supout.rif from both machines to support@mikrotik.com yourself. A brief description of the issue and a reference to this forum topic is usually sufficient.

Please try disabling "Send INITIAL_CONTACT" (send-initial-contact) option on both peers.

I'd assume it means both peers on the HQ machine, not on the client one.

Please try disabling "Send INITIAL_CONTACT" (send-initial-contact) option on both peers.

wow that... I am amazed... worked. It is running.
May I ask why this solved the problem?

I only had initial contact on responder side -> disabled -> worked

I think the IKEv2 RFC explains the INITIAL_CONTACT message clearly.

The INITIAL_CONTACT notification asserts that this IKE SA is the only
IKE SA currently active between the authenticated identities. It MAY
be sent when an IKE SA is established after a crash, and the
recipient MAY use this information to delete any other IKE SAs it has
to the same authenticated identity without waiting for a timeout.
This notification MUST NOT be sent by an entity that may be
replicated (e.g., a roaming user's credentials where the user is
allowed to connect to the corporate firewall from two remote systems
at the same time).