GRE tunnels

From Smop.co.uk

Jump to: navigation, search

A few months ago I needed to setup a tunnel between two networks in order to temporarily work around a network issue. There were several possibilities:

  • ssh tunnel (would suffice, but wanted something which would resume)
  • ssh vpn (ditto)
  • vtun (userspace tunnel)
  • GRE tunnels (kernel based)

I decided to use GRE tunnels since it seemed the best solution (kernel based, uses a standard protocol, simple to setup).

I used the excellent documentation from LARTC to setup the network.

In this example we'll have two sites:

  • siteA has IPs 5.6.7.x
  • siteB has IPs 1.2.3.x, 10.x

On the GRE endpoint at siteA

  • ip tunnel add siteb mode gre remote 1.2.3.4 local 5.6.7.8 ttl 255
  • ip link set siteb up
  • ip addr add 5.6.7.8 siteb
  • ip route add 10/8 dev siteb
    • could put more routes here if you like
  • echo 1 > /proc/sys/net/ipv4/ip_forward

If boxes at siteA aren't currently sending traffic via the GRE endpoint (5.6.7.8) we need to tell them to do so:

  • route add -net 1.2.3.0 netmask 255.255.255.0 gw 5.6.7.8
  • route add -net 10.0.0.0 netmask 255.0.0.0 gw 5.6.7.8


On the GRE endpoint at siteB

Here we needed to do source routing so that packets from 10.* go down the GRE tunnel but everything else goes across the internet (in particular, the GRE packets themselves). If we don't do this, then GRE packets will be sent down the tunnel (i.e. recursion!)

  • ip tunnel add sitea mode gre remote 5.6.7.8 local 1.2.3.4 ttl 255
  • ip link set sitea up
  • ip addr add 10.1.1.2 sitea
  • echo "200 sitea" >> /etc/iproute2/rt_tables
  • ip rule add from 10.0.0.0/8 table sitea
    • could put more rules here if you liked
  • ip route add 5.6.7/24 dev sitea table sitea
  • echo 1 > /proc/sys/net/ipv4/ip_forward

rp_filter catch

Due to the network setup we had, when this was in place the firewall was sending us traffic from siteA via the public interface which we would reply on a DMZ interface. We therefore had to either turn off rp_filter (which we turned on as it's a good idea):

  • #echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter

or better, add a route back (so that rp_filter says it's okay:

  • route add -net 5.6.7.0 netmask 255.255.255.0 gw 10.1.1.1
Personal tools