Hello Sandro
Hmm, this is an interesting one! The reason behind this restriction is the way that GRE keepalives are created, sent, and received.
Let’s take your scenario as an example. When R1 creates a keepalive, what it does is it first crafts the return packet, where it uses the IP address of R2 as the source IP and the IP address of R1 as the destination IP. Yes, that’s right, it’s not a typo. This premade keepalive response packet is then encapsulated within the keepalive request packet. This is how most keepalives work.
So when R1 sends its request, R2 simply decapsulates it and then routes it based on the IP and GRE headers. In a normal non-VRF situation, this works fine.
However, when VRFs are used, after the keepalive packet is decapsulated, it loses its association with the receiving tunnel interface and any VRFs configured on that tunnel interface. As a result, the remote endpoint attempts to route the packet using the global routing table instead of the VRF where the tunnel resides. This prevents the keepalive packet from being returned to the sender.
There is a workaround however! You can put a static route in the global routing table to allow the keepalives to be correctly routed back to the originating router. However, this assumes that the IOS will allow you to enable the keepalives which from what I see in your output.
I have created a NetworkLessons note with more information and with links to related material that I hope you and others will find useful. Thanks for this very interesting question which lead to me doing research and learning a lot more about this topic!
I hope this has been helpful!
Laz