Please see attached config file.

From the Mikrotik ... config (no "passive=yes" on /ipsec peer) I gather you expect a Mikrotik to make initial contact. However, you also have "send-initial-contact=no"

mode-config is in responder mode.

Not sure if this is helpful:
...

How could I see the actual contents of the packets?

this is something that puzzled me in the past, when successfully setting up other IPSec VPN's - this rule did not show any traffic either.
The purpose of this rule of course is to only accept IPsec traffic from specific IP's.

in other cases, if your router sends a packet first, the response is accepted by the action=accept connection-state=established rule, so they also do not reach that rule matching on src-address-list=VPN.

The Cisco seems to send NAT-keepalive and ESP (SPI=xxxxxxxxxxxx) packets.
Where else the Mikrotik sends IKE_SA_INIT packets.

Ah I see, so the "VPN IPsec filter rule for UDP 500,4500" only ever hits if the other side initiates the VPN negotiation? That makes sense... So I guess I can leave it as it is?

Correct. You can even remove the rule accepting anything from 34.XXX.XXX.251.

Got the following response:

I hope this screenshot reveals the information you wanted me to check?

I am wondering since it has the setting "mode tunnel" in it...
...
I am assuming that my Mikrotik configuration is the equivalent to what Cisco calls "crypto map", is this correct?

• transport mode is intended for encryption of nothing but the own traffic between the peers, so the IP headers of the payload packets are not transported as the addresses of the transport packet are the same ones as those of the payload packet. So there is no point in wasting 20 bytes of packet space for just a copy of that information.
• tunnel mode is intended to deliver any traffic (matching to the traffic selector, which has no special name in RouterOS and has been renamed to crypto map in IOS), so the IP header of the payload packet must be delivered too.

A VTI is breaking some of the security principles of IPsec, ...

Whatever reverse-matches a traffic selector of an existing IPsec policy, even of an inactive one, but did not arrive via the security association linked to that policy, must be dropped. Use of VTI breaks this principle. I know, I know, so does you-name-it over IPsec.

But it may be a bit complex to implement - the traffic selectors are negotiated between the peers, and for a security association used to transport traffic between two VTIs, the traffic selector must be 0.0.0.0/0<->0.0.0.0/0 (because you never know what will be routed via the tunnel). So to implement a VTI, you'd likely have to modify the IPsec code quite a lot so that these selectors were negotiated with the peer but not used locally to redirect/drop traffic, whilst the encapsulation and decapsulation would have to remain the same.

Why do you say two VTIs?

Couldn’t one still have an interface with the following flow:
...
Policy rules are quite simple and this double-check should not introduce a noticeable delay.

So to accept a 0.0.0.0/0<->0.0.0.0/0 from the remote peer supporting the VTI, the local peer not supporting it must also use 0.0.0.0/0<->0.0.0.0/0.

I still don't understand why a VTI requires negotiation of 0.0.0.0/0<->0.0.0.0/0 before other policies can be applied.

Since VTI represents a connection (persistent or dynamic?) to a specific peer with specific policies, why cannot it simply drop the traffic that does not match any of the negotiated selectors. If user tries to route traffic that does not match any selectors then drop it or issue an appropriate ICMP. Same for traffic from the IPsec connection counterpart.

It seems to me that you keep following the mental model where the VTI represents a single point of entry to a trunk of multiple policies (i.e. traffic selector to security association mappings), but none of the vendors that support VTI uses this approach. In the IPsec context, the very idea of VTI is to avoid the IPsec traffic selection approach completely, as it is so much different from the "normal routing" (and so limiting when it comes to redundancy - no alternative paths so no dynamic routing).

But then you kind of throw away much of the protocol and render many aspects of IKEv2 redundant. Don't you end up with a completely different beast in that case that's only somewhat based on IPsec's IKEv2?

Cisco's IPsec DVTI does not seem to require any <-> any policy as it expects a set of specific policies.
...

"Policy" is linked with "Proposal", right?

"Peer" is linked with "Profile", correct?

So Phase 2 SAs are rekeyed more frequently as they are suspected to transport much more data per unit of time than the Phase 1 SA.

RouterOS generates a default Proposal (phase 2) with a lifetime of 1d, and a default Profile (phase 1) with a lifetime of 1h.
Shouldn't the longer lifetime be assigned to phase 1?

When I add a new profile and a new proposal using command line on my favourite 6.47.10, specifying nothing but the name, the lifetime is set to 1d for a profile and to 30m for a proposal.

/ip ipsec profile
set [ find default=yes ] dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=1h
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=1d pfs-group=modp2048

It doesn’t, but it can be tolerated as traffic selector is not a route selector. I.e. the router shouldn’t start routing all traffic through IPsec, merely use the same SA for all its traffic.

Have you tried adding this specific, non-template, policy?

I'd rather understand where this "0.0.0.0/0 <=> 0.0.0.0/0 selector" issue is stemming from? Is this something I misconfigured on the RouterOS side? What exactly causes this on the Cisco side?

You've provided just a short excerpt from the log, but from there it seems to me that the offer for such a selector comes from Cisco side.

However, I don't know exactly how I have to setup the "action=none" policies, to avoid ordinary traffic ending up in the tunnel.

I find wireshark captures helpful to debugging some fundamental protocol misunderstanding (it's also very educational), since they can be straightforwardly mapped into actual RFCs. Logs are, after all, results of Mikrotik's processing and may hide the issue.

However, I don't know exactly how I have to setup the "action=none" policies, to avoid ordinary traffic ending up in the tunnel.

If I understand @sindy correctly, just add more specific policies (i.e. specific source addr. and/or destination addr. and/or protocols) and the same group and proposal, but set the action to none (perhaps you also need to set level to "use"?). Note that the list of policies is an an ordered one, so put them before "0.0.0.0/0 <=> 0.0.0.0/0". The net result should be:

1. During the negotiation "0.0.0.0/0 <=> 0.0.0.0/0" will be found which will let phase 2 to complete and establish communication SAs
2. The none policies will, hopefully, prevent RouterOS from routing through IPsec

Note that on RouterOS you can control even further what can go through IPsec via ipsec-policy parameter of a filter rule. I have not tried it, but looks like it allows to describe very complex setups by the means of marks.

Not sure it works for both directions of Phase 1, though.

Yes, that's the idea. There is no need for a proposal or a peer in action=none policies.

Note that on RouterOS you can control even further what can go through IPsec via ipsec-policy parameter of a filter rule. I have not tried it, but looks like it allows to describe very complex setups by the means of marks.

Unfortunately, it's the other way round.

Here's the full log

23:05:48 ipsec,debug proposal #1: 1 transform
23:05:48 ipsec,debug got the local address from ID payload 0.0.0.0[0] prefixlen=0 ul_proto=255
23:05:48 ipsec,debug got the peer address from ID payload 0.0.0.0[0] prefixlen=0 ul_proto=255
23:05:48 ipsec searching for policy for selector: 0.0.0.0/0 <=> 0.0.0.0/0
23:05:48 ipsec policy not found
23:05:48 ipsec failed to get proposal for responder.
23:05:48 ipsec,error 34.XXX.XXX.251 failed to pre-process ph2 packet.
23:05:48 ipsec,error 34.XXX.XXX.251 failed to pre-process ph2 packet.

Do you know how policy's level fits into this configuration? Cannot quite grasp when I would want to touch it, but from the description it seems to be useful here.

Unfortunately, it's the other way round.

Hmm, cannot it be used to control what traffic originating from RouterOS-side of connection can reach IPsec, e.g. via a mangle rule. Is it too late for that?

Are you sure peer's exchange mode was set to "IKEv2"?

We're still trying to get the VPN to work... this time trying IKE v1 (main).

So I figure the log does not reveal the cause for selector 0.0.0.0/0 <=> 0.0.0.0/0, neither does it reveal which side (RouterOS or Cisco) is causing this?

The log stems indeed from an IKE v1 (main) connection attempt.

We finally got the VPN to work (IKEv1), by making sure the Cisco router only acts as responder (passive). That way we avoid the 0.0.0.0/0<=>0.0.0.0/0 selector issue.
Thanks again to everyone for the help and the insights, which certainly improved my general understanding of VPN's.

It's actually a misconception I've suffered from myself for years. The send-initial-contact parameter has nothing to do with controlling whether the peer will initiate connections or not - this is what the passive parameter controls. INITIAL_CONTACT is an optional notification, asking the peer receiving it to drop any existing IKE connections from the same source IP address and continue only with the one within which this INITIAL_CONTACT has arrived.