Once again, I've managed to tinker through the problem (but not for too long as the original question and this answer supposes it to be :). I've been through almost a month researching the solution for the problem, and I'll leave it documented here just in case anyone happens to bump at the same problem.
Actually, the loopback interface is really what I knew it to be: an address assigned to a dummy, always up interface on a machine. The connectivity problem between the remote GRE router and my router was due to another problem: GRE keep-alive packets.
It turned out that the remote Cisco router was actually sending me odd GRE-encapsulated packets through the tunnel. These packets encapsulated another GRE packet, and these, on the other hand, carried a protocol number of zero. A quick browse indicated that these packets are GRE keep-alive packets, which are send periodically (in my case, every 10 seconds almost exactly) and, if properly deencapsulated and rerouted by the peer, should be echoed back to the sender, since the innermost destination address contained the sender's source address.
The fact is that the Linux kernel did not properly feed the deencapsulated keep-alive packet again into the routing chain. If it did, the packet would be rerouted back to the sender without further complications. Instead, it delivered the packet to userspace, so that it was possible to write a simple program that listened to such packets in raw mode, and echoed them back to the sender. Running this program and echoing back a couple of packets to the Cisco router, the GRE tunnel went 'up' on the remote side, the PIM routers exchanged hello
s and I finally could listen to the multicast traffic that I expected to listen to.
I've learned a lot from this experience, specially the part that, when messing with obscure protocols (or, at least, obscure protocol features), you can't simply count at all on peer-knowledge. No single network analyst on the remote side could help me in any aspect in this regard, probably because this behavior was undocumented.
You'll want to get the remote end to enable NAT-T on their end of the connection as well.
IPSec communication cryptographically signs the entire packet - any change to the IP header will invalidate that signature. NAT works by rewriting the source and/or destination IP fields; having NAT on either end of the connection means that every packet is having the header changed in transit; the source is changed on packets leaving your 192.168
network, and the destination is changed on inbound packets.
NAT-T counteracts this by encapsulating the entire ESP packet in a new UDP packet. The UDP packet can safely have its headers mangled to the satisfaction of any NAT devices, while the ESP payload will make the entire trip unchanged. The remote node will need to enable this to protect the packets they're sending your way from the NAT modifications, and you'll both need to be allowing UDP port 4500.
This may not be the only issue in the configuration of the VPN tunnel, but it would certainly explain a malformed payload message; give it a shot, and let us know if any further issues come up!
Best Answer
Don't use tunnel mode in your IPSec Policy.
That's what causes Torch to show the GRE packets.
Since you are encrypting the whole GRE connection, it will be just as secure by not using tunnel mode. Packets going through the tunnel will be encrypted anyway so no one will be able to see who is communicating with who inside the tunnel.
To a 3rd party sniffing the traffic it will be pretty much the same regardless of tunnel mode (ie: 1.1.1.1 communicates with 2.2.2.2 over protocol 50-ipsec - there's no benefit in trying to hide this information with tunnel mode).
Also you will have less packet overhead.
From Mikrotik Wiki: