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

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>

On Thu, Sep 07, 2017 at 10:35:36AM +0300, Răzvan Sandu wrote:
> 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?
Nothing is mandatory with tinc.
> 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?
Yes, you can do that as well. Note that in router mode, you have to then
provide two Subnets in each host config file; one for that node's
192.168.x.* address, and another for its 10.* address range.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20170907/8623a3a4/attachment.sig>