How to setup an IPSec / GRE tunnel on Windows Server 2008

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 hellos 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're kind of fighting against the natural tendencies of how source IP address selection works when trying to do this. So why not just change your design up a little bit for it to flow more naturally?

The problem is that source IP address selection is done prior to the decision to push traffic down the tunnel. That means that it'll choose to use the "public" IP address as the source IP for any traffic originating through the tunnel.

On some OS:es, you can do fun things with routing, specifying source addresses on a route for host-originated traffic. I can't find anything like that on Windows though.

However, given your network design, I think the simplest way of solving this problem is to stop fighting with RFC1918 addresses on the server side, and just go ahead and set up a tunnel with SA's between your public ip 203.10.10.10 and the private IP addresses 10.16.0.0/15.

The clients would then address the server as 203.10.10.10 rather than 192.168.70.1, and everything else would hopefully just magically fall into place. That way, source IP selection will already pick an appropriate address that will work.

You can keep the old ipsec policy in place during a transition period, so that your clients may address the server either with the old RFC1918 address or with the new public address, while your DNS cache expires (assuming you're using DNS for this - if not, it's a good idea). After a transition period, the address 192.168.70.1 has no function any more.

The other option is to explicitly choose the source IP address when initiating connections from your server - which may be possible if it's custom software you've written yourself, but that's kinda hairy.

Finally, that loopback adapter idea is promising, it's odd that it shows up as "media disconnected" though. That sounds like a problem with the loopback adapter itself rather than with the idea though.