Răzvan Sandu
2017-Sep-07 07:35 UTC
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>
Guus Sliepen
2017-Sep-07 17:23 UTC
A FAQ: is it mandatory to include the local IP address classes in the global VPN address class?
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>
Reasonably Related Threads
- A FAQ: is it mandatory to include the local IP address classes in the global VPN address class?
- [Fwd: [quagga-users 2122] Linux advanced routing & quagga]
- Bugs related to tinc's initialization in systemd
- Routing and Redundancy Delima
- How to diagnostic UDP discovery failed situation