1

I'm having a really hard time trying to estabilish a VPN connection using a GRE over IPsec tunnel. The problem is that it involves some sort of "loopback" connection which I don't understand -- let alone be able to configure --, and the only help I could find is related to configuring Cisco routers.

My network is composed of a router and a single host running Debian Linux. My task is to create a GRE tunnel over an IPsec infrastructure, which is particularly intended to route multicast traffic between my network, which I am allowed to configure, and a remote network, for which I only bear a form containing some setup information (IP addresses and phase information for IPsec). For now it suffices to estabilish a communication between this single host and the remote network, but in the future it will be desirable for the traffic to be routed to other machines on my network.

As I said this GRE tunnel involves a "loopback" connection which I have no idea of how to configure. From my previous understanding, a loopback connection is simply a local pseudo-device used mostly for testing purposes, but in this context it might be something more specific that I do not have the knowledge of.

I have managed to properly estabilish the IPsec communication using racoon and ipsec-tools, and I believe I'm familiar with the creation of tunnels and addition of addresses to interfaces using ip, so the focus is on the GRE step. The worst part is that the remote peers do not respond to ping requests and the debugging of the general setup is very difficult due to the encrypted nature of the traffic.

There are two pairs of IP addresses involved: one pair for the GRE tunnel peer-to-peer connection and one pair for the "loopback" part. There is also an IP range involved, which is supposed to be the final IP addresses for the hosts inside the VPN.

My question is: how (or if) can this setup be done? Do I need some special software or another daemon, or does the Linux kernel handle every aspect of the GRE/IPsec tunneling?

Please inform me if any extra information could be useful.

Any help is greatly appreciated.

Improve this question

2 Answers 2

Reset to default
3

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.

Improve this answer
1

I am not sure how multicast works but I can tell you how I got GRE over IPSec working. Most linux installations support gre so you wouldn't need to install anything extra for it.


I created a Host-to-Host IPSec tunnel and then followed the steps mentioned here to create the tunnel. http://lartc.org/lartc.html#LARTC.TUNNEL.GRE

Remember to enable packet forwarding :)

Improve this answer
1
  • Sameer: Thanks for the answer. I've been following these tutorials and looking at many, many more sources in this terrible battle to get the tunnel up :). I am really suspectful that there is some peer-side problem that I've been unable to fully grasp in order to inform the guys at the other end and evolve to a solution to this problem.
    – alecov
    Mar 28, 2011 at 20:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .