What you are essentially looking for is the "culprit" of the issue. If everything works properly:
- an icmp echo request packet is sent by the PC
- it reaches router A whose firewall lets it in
- the packet gets routed using the regular routing at router A via some interface
- the header of this packet matches the traffic selector of the IPsec policy at router A
- the policy diverts that packet into an SA, which encrypts it and encapsulates it into an ESP transport packet
- the transport packet, sent from Router A's own address, is routed towards router B using regular routing
- the packet is delivered to Router B
- router B's firewall lets the ESP packet in
- router B's IPsec stack finds the ESP packet to match an existing SA and the packet's sequence number successfully passes replay attack checks
- the IPsec stack decapsulates and decrypts the payload packet and hands it over to the IP stack as if it was a newly received one
- the IP stack determines it is a packet for the router itself or for some device behind it and lets the corresponding firewall chain (input or forward) process it
- the packet is delivered to the destination
- the destination host responds it with an icmp echo response packet
- the response packet is handled the same way like the request, except that the roles of the routers are swapped
And the ultimate task is to find out which of the steps breaks in those cases where you don't get the response and fix that. For start, you need to use ping with
count=1 and sniff for
ipsec-esp packets. If everything works, you should see an r1.r1.r1.r1 -> r2.r2.r2.r2 ESP packet at r1 and then at r2, carrying the icmp echo request, and then an r2.r2.r2.r2->r1.r1.r1.r1 ESP packet at r2 and then at r1, carrying the icmp echo response.
You need to make sure that no other traffic than those test pings is trying to pass through the tunnel, as you wouldn't be able to distinguish the ESP packets carrying that other traffic from those carrying the ping requests and responses by any property except size.
The request may not leave r1, or it may not reach r2, or the response may not leave r2, or it may not reach r1, or it may reach r1 but not be shown as coming. This should tell you what went wrong. If the encrypted request doesn't even leave r1, or if the response arrives to r1 but doesn't reach the PC, the issue is at the r1 site; if the request leaves r1 but the response doesn't come, the issue is in the network between them or at the r2 site.
There's no magic, just the boring job of splitting the path into halves, quarters etc. until you isolate the element that drops the packet.
For starters, you can sniff at the Mikrotik alone, and see wh