That someone may have been me. There is an issue that incoming GRE packets match on connection-state=invalid even if GRE packets in the opposite direction are being sent (so seen by chain output) and hence get dropped if the factory default firewall rule set is used, which contains a chain=input connection-state=invalid action=drop rule. I usually add protocol=!gre to that rule’s list of match conditions, but that’s not enough and you have to disable the GRE tunnel at both ends for more than 10 minutes after adding that rule; the tunnel then comes up once you re-enable it after that time. It seems to me that only some CPU architectures are affected by this.
Mikrotik support suggests that enabling pptp under /ip firewall service-port resolves this issue too.
It is not clear to me whether you’ve only posted the firewall filter rules you deem relevant or whether there is really nothing else in your firewall (which would mean that your router can be easily attacked from the internet). Better post a complete /ip firewall filter export and /interface list export (or even better, the export of the complete configuration, following the hint in my automatic signature here below).
However, if the Mikrotik end says the tunnel is up, it means that you’re not affected by the connection tracking issue, otherwise the keepalive responses coming from the Cisco end would not reach the GRE stack and the interface would be deemed down.
The fact that it goes up and down at Cisco is surprising, but I don’t have much experience with Cisco. In any case, due to the way how GRE keepalive is designed, the keepalive response is not generated by the recipient of the keepalive request - it is decapsulated from the request, into which the sender has pre-generated it. This means that from the point of view of the firewall, the keepalive response packet is forwarded from the GRE tunnel interface to the WAN interface. So again depending on your complete firewall rules, it may be dropped; but in my understanding, if that was the case, the interface should be constantly seen as down at the Cisco end, not keep flashing between down and up.
You can open a CLI window, make it as wide as your screen allows, and run /tool sniffer quick ip-protocol=gre ip-address=cisco_router_public_ip in it. This should show you whether the keepalive response packets emerge from the GRE interface with source address mikrotik_router_public_ip and leave through the WAN one.