Connect different LANs over openVPN

I now own three Raspberry Pi’s.

Using two of them (and my Guruplug as WiFi AP) I connected my new apartment with my old house (= parents) over VPN.

This way I can access the printers/scanners and NAS at home.

The 2 rPI’s are used as router (using a Macbook Air USB-to-Ethernet adapter as 2nd ethernet (eth1) port). Basic howto’s are easily found using Google to do this (a good starting point).

I made my own installation of Raspbian (as the downloadable image contains too much crap), details here (actually not that easy to find when Googling for bootstrap raspbian etc).


I’ve connected three different LANs over an OpenVPN connection:

  • LAN1 (home): (Gateway:, VPN ip:
  • LAN2 (apartment, ethernet): (Gateway:, VPN ip:
  • LAN3 (apartment, wifi): (Gateway:, VPN ip:

OpenVPN range: The subnet is in all cases.

LAN3 is connected via LAN2 to the internet. So the default gateway of router is

The gateway/routers are all Debian-based Linux systems. I’m using EDPnet as ISP, and thus need to use those Sagem/Belgacom approved routers (BBox-2 hardware). These Sagems are set in bridged mode, and don’t do the PPP stuff. PPPoeconfig on Debian takes care of most of the stuff. As EDPnet provides ipv6, I can ping6 from those routers.

The idea is to connect/ping each and every LAN from any of the clients connected the LANs (without running OpenVPN on the clients; only run it on the gateways).

For example: my PC with ip wants to connect to the NAS with ip

This can easily be achieved by setting a client-config-dir in the openvpn.conf file (or whatever the name of your config):

client-config-dir /etc/openvpn/tiete

And don’t forget to add route pushes:

push "route"
push "route"
push "route"

But here comes the annoying part. As I’m pushing routes via VPN, which is supposed to be my Guruplug’s default gateway as well (ISP > eth0:RaspberryPi:eth1 > eth0:Guruplug, remember?) this was causing quite some routing fuck ups.

The easiest way to solve this was to turn off VPN on the Guruplug all together, and route over the Raspberry Pi, by adding this line to /etc/network/interfaces:

up route add -net netmask gw dev eth1

Then I’ll change the client specific configs on the VPN. Create a file in whatever you picked as client-config-dir, and name it the actual VPN name (the name used when creating the key).

As I have three routers, I created three files (sheeva for my guruplug, Pi for my first rPI and Industry for my 2nd. Yep… Fancy names).

I also want to give a static IP address to the gateways, so I use the option:

ifconfig-push 10.9.8.<valid-ip> 10.9.8.<valid-ip - 1>

And I’ll also add the iroute option to push routes.

This is what it looks like for the router on the network (“Pi”):


For “Sheeva”, the WiFi AP on


And for plus routed over (“Industry”):


And don’t forget to set up masquerading over tun0 (or tun+) with iptables.

Now… Oddly enough, this didn’t require that much configuration, cursing and stress… And, well, it kind of just works.

From my Mac to my NAS:

nazgul ~ $ traceroute
traceroute to (, 64 hops max, 52 byte packets
 1 sheeva ( 1.936 ms 1.159 ms 0.800 ms
 2 ( 1.456 ms 1.776 ms 1.539 ms
 3 ( 55.745 ms 55.046 ms 54.734 ms
 4 ( 62.302 ms 55.327 ms 54.795 ms

From Pi (gateway to nazgul, my Mac:

pi ~ # traceroute
traceroute to (, 30 hops max, 60 byte packets
 1 ( 65.892 ms 74.177 ms 73.957 ms
 2 ( 73.441 ms 72.902 ms 72.342 ms
 3 ( 71.780 ms 71.187 ms 70.760 ms

From Heartbeat (, my Munin stats server to the printer:

heartbeat ~/bin # traceroute
traceroute to (, 30 hops max, 60 byte packets
 1 pi ( 39.835 ms 40.794 ms 41.567 ms
 2 ( 41.541 ms 42.452 ms 43.307 ms

From Heartbeat to Sheeva’s eth0 IP:

heartbeat ~/bin # traceroute
traceroute to (, 30 hops max, 60 byte packets
 1 industry ( 32.716 ms 32.615 ms 34.359 ms
 2 sheeva ( 34.405 ms 34.349 ms 35.014 ms

From Heartbeat to an Android device (not sure why the latency spike):

heartbeat ~/bin # traceroute
traceroute to (, 30 hops max, 60 byte packets
 1 industry ( 31.337 ms 32.269 ms 32.218 ms
 2 sheeva ( 33.006 ms 33.052 ms 32.996 ms
 3 ( 471.564 ms 472.169 ms 473.082 ms

Next up (once I have spare time): try to sync local DNS and fix local ipv6.

I’ll put most of the configs on Github at some point.


  1. Yeri Tiete says:

    The “up route add -net netmask gw dev eth1” doesn’t seem to correctly work after a reboot.

    It has to be placed in a script in /etc/network/if-up.d/

    For example name it “route”, add this content:

    route add -net netmask gw dev eth1

    and chmod +x route

    Reboot, and you should be okay.

  2. […] working decently at home after updating my RPi to Fritzbox […]

Leave a Reply...