Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a GRE tunnel configured between two linux boxes. The tunnel works fine. I can ping from each host the other private ip.

Head privateip: 10.0.0.1

publicip: 8.8.8.8

Tail privateip: 10.0.0.2

publicip: 7.7.7.7

The public IP on Tail has the network block 9.9.9.0/23 statically routed over the 7.7.7.7 interface. The idea is to make the 9.9.9.0/23 ips work on servers on the 8.8.8.8 network.

I configure the tail host to route the /23 block. I mounted a 9.9 IP on the head server. I can ping the 9.9 ip from the tail to the head.

I can't ping the 9.9 ip from the public internet.

I think I need to add some other routes because of gateway issues, but I can't seem to wrap my mind around it (not a router guy, just beating my way through something that I have never done before and vaguely understand)

--danks

share|improve this question

2 Answers 2

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.

share|improve this answer

The routes need to exist in both directions, all the way through the path. I'm not quite sure from your description exactly what's not working.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.