<div dir="ltr">Hello,<br><br><br>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?<br><br><br>Namely, please consider the following setup (which works great in practice):<br><br><br>1. A tinc VPN, full mesh, with n nodes (n > 3)<br><br>2. tinc runs on the firewall, which is also the default gateway for each local LAN<br><br>3. tinc run in router mode<br><br>4. Each tinc node has the following interfaces:<br><br>- eth0, external, with public IP address (does NAT/masquerading)<br><br>- eth1, internal (default gateway for the corresponding LAN), address 192.168.x.1, mask 255.255.255.0 (/24)<br><br>- myvpn, tinc virtual tunnel interface, address 192.168.x.1, mask 255.255.0.0 (/16)<br><br>- an /etc/tinc/myvpn/tinc-up script like:<br><br>#!/bin/sh<br><br>ifconfig $INTERFACE 192.168.x.1 netmask 255.255.0.0<br>ip route replace <a href="http://10.0.0.0/8">10.0.0.0/8</a> dev $INTERFACE<br>ip route replace <a href="http://172.16.0.0/12">172.16.0.0/12</a> dev $INTERFACE<br><br><br>(so that all private IP packets are routed go automatically into the mesh, no one is "lost” around).<br><br><br>Now, the QUESTION itself:<br><br>Is it *mandatory* to use a VPN global addreess class (<a href="http://192.168.0.0/16">192.168.0.0/16</a> 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?<br><br>Or can we have 192.168.x.0/24s on the local LANs and another, *different* private class (say <a href="http://10.0.0.0/8">10.0.0.0/8</a>) common all the myvpn interfaces over the VPN?<br><br><br><br>(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).<br><br><br><br>Thanks a lot,<br>Răzvan<br><br><br></div>