It's kind of late, but if you didn't solve it, here is how:
Given your example just replace:
- publicip: 8.8.8.8 with 50.2.2.2
- publicip: 7.7.7.7 with 70.2.2.3
- private ip, could be any valid private address.
- privateip: 10.0.201.1 and 10.0.201.2
Public ips:
- A = 50.2.2.2-22
- B = 70.2.2.3
tunneling with gre:
On A:
# adding the interface for the tunnel
$ ip tunnel add tun2 mode gre remote 70.2.2.3 ttl 64
# setting the private ip address
$ ifconfig tun2 10.0.201.1/24
$ ifconfig tun2 up
# A point to point
$ ifconfig tun2 pointopoint 10.0.201.2
# enabling multicast (it's not necessary for this)
$ ifconfig tun2 multicast
$ ifconfig tun2 arp
$ ifconfig tun2 broadcast
# default route for the tunnel
$ ip route add 10.0.201.2 dev tun2
# enable ip forward
$ echo 1 > /proc/sys/net/ipv4/ip_forward
# add the permanent entries to the arp table in order to get the complete loop. (without this doesn't work)
# replace the public ips for your ips, and the mac for your real mac for your interface
# the word pub it's the most important here, if it's not there the arps will never go outside
$ arp -s 50.2.2.20 00:00:00:00:00:00 -i eth0 pub
$ arp -s 50.2.2.21 00:00:00:00:00:00 -i eth0 pub
$ arp -s 50.2.2.22 00:00:00:00:00:00 -i eth0 pub
On B:
# adding the interface for the tunnel
$ ip tunnel add tun2 mode gre remote 50.2.2.2 ttl 64
# setting the private ip address
$ ifconfig tun2 10.0.201.2/24
$ ifconfig tun2 up
# point to point B
$ ifconfig tun2 pointopoint 10.0.201.1
# enabling multicast (it's not necessary for this)
$ ifconfig tun2 multicast
$ ifconfig tun2 arp
$ ifconfig tun2 broadcast
# default route for the tunnel
$ ip route add 10.0.201.1 dev tun2
$ echo 1 > /proc/sys/net/ipv4/ip_forward
# putting the ips to listen in the eth0 as secondary ips
$ ip ad add 50.2.2.20/32 dev eth0
$ ip ad add 50.2.2.21/32 dev eth0
$ ip ad add 50.2.2.22/32 dev eth0
And that's it, you should have a fully functional tunnel and the ability to route ips that are far away from were you want to use them, so you can now start to bind some daemons to those IPs.
Another thing to have in mind is that if you have so many IPs, you've to be careful with your broadcast domain on point A, and if you're planning to tunnel more than 500 IPs, then you've to change the default values of Linux for the arp table in order to keep all entries:
$ echo 1024 > /proc/sys/net/ipv4/neigh/default/gc_thresh1
$ echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh2
$ echo 16384 > /proc/sys/net/ipv4/neigh/default/gc_thresh3
Sources:
I was looking for the same a long time ago and found your post.
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.
Best Answer
Give openvpn a shot. You can create tunnels over UDP or TCP.