A FAQ: is it mandatory to include the local IP address classes in the global VPN address class?

[Răzvan Sandu]

Hello,


Since the present tinc documentation is not very clear about this, please
explain the following: is it mandatory to include the local IP address
classes in the global VPN address class?


Namely, please consider the following setup (which works great in practice):


1. A tinc VPN, full mesh, with n nodes (n > 3)

2. tinc runs on the firewall, which is also the default gateway for each
local LAN

3. tinc run in router mode

4. Each tinc node has the following interfaces:

- eth0, external, with public IP address (does NAT/masquerading)

- eth1, internal (default gateway for the corresponding LAN), address
192.168.x.1, mask 255.255.255.0 (/24)

- myvpn, tinc virtual tunnel interface, address 192.168.x.1, mask
255.255.0.0 (/16)

- an /etc/tinc/myvpn/tinc-up script like:

#!/bin/sh

ifconfig $INTERFACE 192.168.x.1 netmask 255.255.0.0
ip route replace 10.0.0.0/8 dev $INTERFACE
ip route replace 172.16.0.0/12 dev $INTERFACE


(so that all private IP packets are routed go automatically into the mesh,
no one is "lost” around).


Now, the QUESTION itself:

Is it *mandatory* to use a VPN global addreess class (192.168.0.0/16 on the
myvpn virtual interface) that *includes* the local LANs (each
192.168.x.0/24s on the eth1 interface) - as explained into various pieces
of tinc documentation and examples?

Or can we have 192.168.x.0/24s on the local LANs and another, *different*
private class (say 10.0.0.0/8) common all the myvpn interfaces over the VPN?



(The tip is this: I've tried to use dynamic routing - Quagga OSPF - over
such a tinc mesh. But older Quagga (0.99) in CentOS get confused by the IP
ranges/masks if one needs to place eth1 and myvpn interfaces in *different*
OSPF areas. Older Quagga cannot explicitly assign an area to an interface -
has no "ip ospf area" command, on an interface basis - and wrongly puts all
interfaces in the area corresponding to the network with the shorter mask.
So using *diiferent* IP ranges on the eth1 and myvpn interfaces would solve
the problem until an updated Quagga package will offer a more elegant
solution, via the now missing "ip ospf area" command. CentOS alone has this
problem, all other main distros I've tested already include newer Quagga
packages).



Thanks a lot,
Răzvan
-------------- partea următoare --------------
Un ataşament HTML a fost eliminat   
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20170907/f5ec6552/attachment.html>