We have recently had to configure a site-to-site VPN between a MikroTik and a Cisco using IPSEC. As it happens, this was using IKEv1 rather than IKEv2 but I don't believe that this makes any difference to the ensuing discussion. FWIW, the Peers were directly visible to each other - i.e. no NAT-T was involved.
With all the IKE/IPSEC parameters in place at both ends, we were able to bring up the VPN from the MikroTik end by sending a Ping through the Tunnel.
However, with the MikroTik in a quiescent state, we were not able to bring up the VPN from the Cisco end.
Please bear in mind that the MikroTik was configured with an explicit "default deny" rule on the input chain, although it did have the factory default "permit established/related" rule in place.
After some experimentation, we came to the conclusion that we needed to add two rules to the input chain, namely:
permit udp 500 -> 500 ( suitably locked down to the peer IP address to allow the initial IKE/IPSEC Policy handshake to be completed )
permit ipsec-esp ( protocol 50 ) ( suitably locked down to the peer IP address to allow the tunnelled traffic to passthrough )
With the first rule in place, we were able to get the VPN to appear to come up, in that the "active peers" listing on the MikroTik showed the far end active, but no traffic could actually pass within the tunnel. Only once both rules were in place could we make the VPN properly establish as a "responder".
Obviously, we already had rules in place in the forward chain covering the traffic that we wanted to permit or exclude coming down the Tunnel.
The problem I have is that none of the extra UDP 500 and IPSec-ESP input chain requirements are mentioned in the MikroTik Documentation as far as I can see.
Have we somehow configured our Site-to-Site VPN wrong, or is the Documentation missing some explicit notes about these permissions in the input chain?
It also seems odd to me that the Kernel doesn't automatically add/remove the ipsec-esp rule on the fly once the IKE Policy has been established/torn-down, or maybe somehow make
the traffic match a "related" entry in the connections table - would it be possible to enhance Router OS to this effect? One could also imagine that a rule could be dynamically added to the input chain as Peers were added to the list of /ip IPSec peers to avoid having to manually configure the UDP 500 rule, although you'd probably have to permit UDP 4500 as well so as to for NAT-T Peers.